From owner-ips@ece.cmu.edu Mon Oct 1 01:12: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 BAA07170 for ; Mon, 1 Oct 2001 01:12:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9145ZW01566 for ips-outgoing; Mon, 1 Oct 2001 00:05: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 f9145XP01561 for ; Mon, 1 Oct 2001 00:05:33 -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 AAA77506 for ; Mon, 1 Oct 2001 00:03:10 -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 f9145Ws253000 for ; Sun, 30 Sep 2001 22:05:32 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: Immediate Data To: 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 21:04:44 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 09/30/2001 10:05:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I thought it would be useful to explain why I think that Immediate Data is important to iSCSI, so here it is: 1. Immediate Data permits the elimination of an additional network handshake/interaction. 2. This is important since some applications have a key sensitivity to Latency. The most important of these is Database. 3. Not only is Database sensitive to Latency, it generally has small I/O writes. 4. The hardware HBAs that many of you folks are building, include a TCP/IP Offload Engines (TOEs). This permits support of Gigabit Line speed without Server Load. However, even though many of you are attempting to parallelize as much of the TOE processing as possible, TCP/IP processing will still add latency to each iSCSI interaction, as compared to Fibre Channel. 5. If we want iSCSI to be performance competitive with Fibre Channel, we need to do something about the additional Latency left in the path even with HW HBAs. One important way to do this, is to simply eliminate the extra handshake that Fibre Channel uses on the small Writes. 6. Please note that this is not a big problem with large transfers, since the Latency is Amortized over more data. 7. So it is the Immediate Data feature of iSCSI that will make an important difference in the Key Response Time Sensitive Applications, which by luck only transfer a small amounts of data at a time. 8. When we attempt to let iSCSI shine on the "at-distance" storage environment, the value of Immediate Data, and Unsolicited Data are even more valuable. However, my concern at this time is for Immediate Data. Now the above is the reason that I think Immediate Data is key and important to the acceptance of iSCSI in the Enterprise Environment. And the following says why I think it is simple: A. Creating a Buffer Manager that can allocate buffers that are chained together, is kind of fundamental to the high performance environment we are attempting to work with. All the processes (whether iSCSI or SCSI) will allocate buffers (from the Buffer Manager), place data in one or more of these buffers, and pass the pointe list to the next process. There will be no copying of data. B. This works the same whether the data comes in with the command or separately. When it comes in with the command, the iSCSI process will request the Max buffers from the Buffer manager, and will be given one or more pointers to buffer elements. The Command and Data will be placed into one of more of the buffer segments, then the buffers that are filled, will be queued, in some manner, to the next iSCSI or SCSI Process. The unused buffer segments will be re-queued on the free queue. (I know I am telling you the obvious, but for some reason this message is not getting across.) C. Having every thing (including the data) arrive with the command, eliminates the code path overhead that is needed to collates data with commands. D. Since the only thing that is moved is pointers, it becomes a Zero Copy technique at its very core. E. The only thing that needs to be managed is the overall buffer space. And that needs to be managed anyway. The iSCSI Window management are the functions that are suppose to be used to control that. F. The issue of having enough memory is probably not a real world problem except at the very extremes. And you need to have the exact same code to manage the iSCSI Windows regardless of what caused the buffer space to run low. G. When a Storage Controller is expected to handle a large number of connections, the Storage Controller is expected to have a large pool of RAM storage, and when the Storage Controller is expected to handle only a small number of connections, it is hard not to have enough memory, since the price and availability of small RAMs is problematical. All the above, leads me to the belief that ImmediateData=yes, is the simplest, and most conservative option. And it solves the Latency issue with Enterprise Databases, thereby assuring the success of iSCSI in the Enterprise as well as the "at-distance" computing environment. . . . 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 Oct 1 03: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 DAA21757 for ; Mon, 1 Oct 2001 03:01:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f916NFQ05920 for ips-outgoing; Mon, 1 Oct 2001 02:23: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 f916NCP05915 for ; Mon, 1 Oct 2001 02:23:13 -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 IAA246684 for ; Mon, 1 Oct 2001 08:23: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 f916N5C38900 for ; Mon, 1 Oct 2001 08:23:05 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: typo X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Mon, 1 Oct 2001 09:23:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/10/2001 09:23:06, Serialize complete at 01/10/2001 09:23:06 Content-Type: multipart/alternative; boundary="=_alternative 00231C98C2256AD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00231C98C2256AD8_= Content-Type: text/plain; charset="us-ascii" Eddy & all, The tool that I used (Word 2000) broke some links and was crashing (literally) on me every 10 minutes. We will attempt to move to a good tool on 09. Julo "Eddy Quicksall" 30-09-01 19:56 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: typo In the -08 spec ... For additional usage semantics of Reject PDU, please see section 1.1. and commands to designate iSCSI devices or ports. As noted in 1.1, the There is not a section 1.1. Eddy_Quicksall@iVivity.com --=_alternative 00231C98C2256AD8_= Content-Type: text/html; charset="us-ascii"
Eddy & all,

The tool that I used (Word 2000) broke some links and was crashing (literally) on me every 10 minutes.
We will attempt to move to a good tool on 09.

Julo


"Eddy Quicksall" <EQuicksall@mediaone.net>

30-09-01 19:56
Please respond to "Eddy Quicksall"

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        typo

       


In the -08 spec ...

For additional usage semantics of Reject PDU, please see section 1.1.

and

commands to designate iSCSI devices or ports. As noted in 1.1, the

There is not a section 1.1.

Eddy_Quicksall@iVivity.com

--=_alternative 00231C98C2256AD8_=-- From owner-ips@ece.cmu.edu Mon Oct 1 05:32: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 FAA09239 for ; Mon, 1 Oct 2001 05:32:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f918Oj209327 for ips-outgoing; Mon, 1 Oct 2001 04:24:45 -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 f918OdP09319 for ; Mon, 1 Oct 2001 04:24:42 -0400 (EDT) Received: by dcmtechdom.dcmtech.co.in with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 13:56:25 +0530 Message-ID: <7FADCB99FC82D41199F9000629A85D1A01C6531C@dcmtechdom.dcmtech.co.in> From: Nitin Dhingra To: ips@ece.cmu.edu Subject: Data Consistency: Multiple Initiator's to same Target Date: Mon, 1 Oct 2001 13:56:24 +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 Does iScsi protocol has to take care about data consistency when multiple initiator's are connected to the same target? If so, why isn't it specified anywhere in the draft? - Nitin From owner-ips@ece.cmu.edu Mon Oct 1 06:02: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 GAA09662 for ; Mon, 1 Oct 2001 06:02:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9160ok05285 for ips-outgoing; Mon, 1 Oct 2001 02:00: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 f9160lP05277 for ; Mon, 1 Oct 2001 02:00:48 -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 IAA279632 for ; Mon, 1 Oct 2001 08:00:39 +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 f9160bC140570 for ; Mon, 1 Oct 2001 08:00:38 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: new iSCSI draft 08.txt X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Mon, 1 Oct 2001 09:00:35 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/10/2001 09:00:38, Serialize complete at 01/10/2001 09:00:38 Content-Type: multipart/alternative; boundary="=_alternative 00210DD2C2256AD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00210DD2C2256AD8_= Content-Type: text/plain; charset="us-ascii" Sure you can - Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 30-09-01 19:41 Please respond to "Eddy Quicksall" To: cc: Subject: RE: new iSCSI draft 08.txt 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 --=_alternative 00210DD2C2256AD8_= Content-Type: text/html; charset="us-ascii"
Sure you can - Julo


"Eddy Quicksall" <EQuicksall@mediaone.net>
Sent by: owner-ips@ece.cmu.edu

30-09-01 19:41
Please respond to "Eddy Quicksall"

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: new  iSCSI draft 08.txt

       


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















--=_alternative 00210DD2C2256AD8_=-- From owner-ips@ece.cmu.edu Mon Oct 1 06: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 GAA09714 for ; Mon, 1 Oct 2001 06:04:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9198E021178 for ips-outgoing; Mon, 1 Oct 2001 05:08: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 f9198DP21173 for ; Mon, 1 Oct 2001 05:08:13 -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 FAA72292; Mon, 1 Oct 2001 05:05:50 -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 f9198Bs256454; Mon, 1 Oct 2001 03:08:11 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: Data Consistency: Multiple Initiator's to same Target To: Nitin Dhingra Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 1 Oct 2001 02:07:18 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/01/2001 03:08:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Only within an iSCSI Session. Not across sessions. . . . 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 Nitin Dhingra @ece.cmu.edu on 10/01/2001 01:26:24 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Data Consistency: Multiple Initiator's to same Target Does iScsi protocol has to take care about data consistency when multiple initiator's are connected to the same target? If so, why isn't it specified anywhere in the draft? - Nitin From owner-ips@ece.cmu.edu Mon Oct 1 06:17: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 GAA09865 for ; Mon, 1 Oct 2001 06:17:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f915x1d05209 for ips-outgoing; Mon, 1 Oct 2001 01:59: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 f915wwP05204 for ; Mon, 1 Oct 2001 01:58:58 -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 HAA95880 for ; Mon, 1 Oct 2001 07:58:51 +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 f915woB224110 for ; Mon, 1 Oct 2001 07:58:50 +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" Message-ID: Date: Mon, 1 Oct 2001 08:58:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/10/2001 08:58:49, Serialize complete at 01/10/2001 08:58:49 Content-Type: multipart/alternative; boundary="=_alternative 0020E3BCC2256AD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0020E3BCC2256AD8_= Content-Type: text/plain; charset="us-ascii" Eddy, For binary negotiations 08 spells out completely that you don't need the I->T no (there is even an example). Other than that the spec does not forbid the behavior Santosh would like to see but does not mandate it either. The exchange is mandated to include only what is needed by both parties to compute the new result. The response required is there to make sure that new values are used not old or defaults. Julo "Eddy Quicksall" 30-09-01 20:19 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iscsi : iscsi parameter default values 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 ################################## --=_alternative 0020E3BCC2256AD8_= Content-Type: text/html; charset="us-ascii"
Eddy,

For binary negotiations 08 spells out completely that you don't need the I->T no (there is even an example).
Other than that the spec does not forbid the behavior Santosh would like to see but does not mandate it either.
The exchange is mandated to include only what is needed by both parties to compute the new result.
The response required is there to make sure that new values are used not old or defaults.

Julo




"Eddy Quicksall" <EQuicksall@mediaone.net>

30-09-01 20:19
Please respond to "Eddy Quicksall"

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

       


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

                   <santoshr@cup.       To:     ips@ece.cmu.edu

                   hp.com>              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 <rsnively@brocade.com> 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'"
> > <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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >

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

--=_alternative 0020E3BCC2256AD8_=-- From owner-ips@ece.cmu.edu Mon Oct 1 08:19: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 IAA13242 for ; Mon, 1 Oct 2001 08:19:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91BFmv24795 for ips-outgoing; Mon, 1 Oct 2001 07:15:48 -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 f91BFfP24788 for ; Mon, 1 Oct 2001 07:15:44 -0400 (EDT) Received: by dcmtechdom.dcmtech.co.in with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 16:47:28 +0530 Message-ID: <7FADCB99FC82D41199F9000629A85D1A01C65320@dcmtechdom.dcmtech.co.in> From: Nitin Dhingra To: "'John Hufferd'" Cc: ips@ece.cmu.edu Subject: RE: Data Consistency: Multiple Initiator's to same Target Date: Mon, 1 Oct 2001 16:47:27 +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 Then what is the solution across sessions. Should we allow only one I-T nexus for one Target Device for maintaining data consistency or is there any better solution to this? - Nitin -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, October 01, 2001 2:07 AM To: Nitin Dhingra Cc: ips@ece.cmu.edu Subject: Re: Data Consistency: Multiple Initiator's to same Target Only within an iSCSI Session. Not across sessions. . . . 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 Nitin Dhingra @ece.cmu.edu on 10/01/2001 01:26:24 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Data Consistency: Multiple Initiator's to same Target Does iScsi protocol has to take care about data consistency when multiple initiator's are connected to the same target? If so, why isn't it specified anywhere in the draft? - Nitin From owner-ips@ece.cmu.edu Mon Oct 1 08:27: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 IAA13714 for ; Mon, 1 Oct 2001 08:27:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91BwtY26185 for ips-outgoing; Mon, 1 Oct 2001 07:58:55 -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 f91BwoP26176 for ; Mon, 1 Oct 2001 07:58:51 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 14:00:44 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B9861@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Date: Mon, 1 Oct 2001 14:00:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14A70.B16A2280" 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_01C14A70.B16A2280 Content-Type: text/plain; charset="iso-8859-1" Thanks Julian, please find my further comments in the message -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 30, 2001 6:07 PM To: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous 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 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather say it this way the responder computes the value with its own supported values and responds with a value y which the responder thinks is correct 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 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, but it is highly unlikely for the responder to reject the final result because the rule states that (lower or higher of two will be the result) and so the offering party should be able to accept the lower or higher range as defined by rule. In case the key is dependent upon some range of fixed values then the negotiation should be performed as list negotiation and not numerical negotiation. This might be what you "conventionally" do - I don't and that shows that convention like morals are a matter of geography :-) [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) The advantage of this set of rules is that it allows an external observer to know what was selected without knowing the rules [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this case, I guess that the external observer has to know the rules to double check the value is correct or not 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. [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is no reject , but it can be a problem in future . Consider your example of DataPDULength in your own message. Suppose offering party sends a value of 16,384 (this is also lowest value it can send) and responding party responds with 8,192. In this case the offering party will have to reject the negotiation. So a reject message is needed in this case also. Sanjeev "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 ################################## ------_=_NextPart_001_01C14A70.B16A2280 Content-Type: text/html; charset="iso-8859-1"
Thanks Julian, please find my further comments in the message
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, September 30, 2001 6:07 PM
To: ips@ece.cmu.edu
Subject: RE: iscsi : numerical negotiation wording is ambiguous


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
    [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather say it this way the responder computes the value with its own supported values and responds with a value y which the responder thinks is correct 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
    [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, but it is highly unlikely for the responder to reject the final result because the rule states that (lower or higher of two will be the result) and so the offering party should be able to accept the lower or higher range as defined by rule. In case the key is dependent upon some range of fixed values then the negotiation should be performed as list negotiation and not numerical negotiation.

    This might be what you "conventionally" do - I don't and that shows that convention like morals are a matter of geography :-)
    [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) 

    The advantage of this set of rules is that it allows an external observer to know what was selected without knowing the rules
    [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this case, I guess that the external observer has to know the rules to double check the value is correct or not
    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.
    [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is no reject , but it can be a problem in future . Consider your example of DataPDULength in your own message. Suppose offering party sends a value of 16,384 (this is also lowest value it can send) and responding party responds with 8,192. In this case the offering party will have to reject the negotiation. So a reject message is needed in this case also.
 
Sanjeev
"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
##################################


------_=_NextPart_001_01C14A70.B16A2280-- From owner-ips@ece.cmu.edu Mon Oct 1 09:31: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 JAA16758 for ; Mon, 1 Oct 2001 09:31:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91CJXP26928 for ips-outgoing; Mon, 1 Oct 2001 08:19:33 -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 f91CJUP26924 for ; Mon, 1 Oct 2001 08:19:30 -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 OAA84798 for ; Mon, 1 Oct 2001 14:19: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 f91CJGB246530 for ; Mon, 1 Oct 2001 14:19:16 +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: Mon, 1 Oct 2001 14:19:14 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/10/2001 15:19:15, Serialize complete at 01/10/2001 15:19:15 Content-Type: multipart/alternative; boundary="=_alternative 0043B85D42256AD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0043B85D42256AD8_= Content-Type: text/plain; charset="us-ascii" Sanjeev, You are just missreading my text. In your example there is no need for a reject. Both parties will KNOW that the value selected is the lower of the 2 i.e. 8192. There is no reject. Julo "Sanjeev Bhagat (TRIPACE/Zoetermeer)" 01-10-01 14:00 Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iscsi : numerical negotiation wording is ambiguous Thanks Julian, please find my further comments in the message -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, September 30, 2001 6:07 PM To: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous 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 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather say it this way the responder computes the value with its own supported values and responds with a value y which the responder thinks is correct 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 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, but it is highly unlikely for the responder to reject the final result because the rule states that (lower or higher of two will be the result) and so the offering party should be able to accept the lower or higher range as defined by rule. In case the key is dependent upon some range of fixed values then the negotiation should be performed as list negotiation and not numerical negotiation. This might be what you "conventionally" do - I don't and that shows that convention like morals are a matter of geography :-) [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) The advantage of this set of rules is that it allows an external observer to know what was selected without knowing the rules [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this case, I guess that the external observer has to know the rules to double check the value is correct or not 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. [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is no reject , but it can be a problem in future . Consider your example of DataPDULength in your own message. Suppose offering party sends a value of 16,384 (this is also lowest value it can send) and responding party responds with 8,192. In this case the offering party will have to reject the negotiation. So a reject message is needed in this case also. Sanjeev "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 0043B85D42256AD8_= Content-Type: text/html; charset="us-ascii"
Sanjeev,

You are just missreading my text.
In your example there is no need for a reject.
Both parties will KNOW that the value selected is the lower of the 2 i.e. 8192.
There is no reject.

Julo


"Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>

01-10-01 14:00
Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iscsi : numerical negotiation wording is ambiguous

       


Thanks Julian, please find my further comments in the message
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, September 30, 2001 6:07 PM
To: ips@ece.cmu.edu
Subject: RE: iscsi : numerical negotiation wording is ambiguous

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
[Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather say it this way the responder computes the value with its own supported values and responds with a value y which the responder thinks is correct 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
[Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, but it is highly unlikely for the responder to reject the final result because the rule states that (lower or higher of two will be the result) and so the offering party should be able to accept the lower or higher range as defined by rule. In case the key is dependent upon some range of fixed values then the negotiation should be performed as list negotiation and not numerical negotiation.

This might be what you "conventionally" do - I don't and that shows that convention like morals are a matter of geography :-)
[Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-)

The advantage of this set of rules is that it allows an external observer to know what was selected without knowing the rules
[Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this case, I guess that the external observer has to know the rules to double check the value is correct or not
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.
[Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is no reject , but it can be a problem in future . Consider your example of DataPDULength in your own message. Suppose offering party sends a value of 16,384 (this is also lowest value it can send) and responding party responds with 8,192. In this case the offering party will have to reject the negotiation. So a reject message is needed in this case also.
 
Sanjeev
"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 0043B85D42256AD8_=-- From owner-ips@ece.cmu.edu Mon Oct 1 10:15: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 KAA18244 for ; Mon, 1 Oct 2001 10:15:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91D8du29128 for ips-outgoing; Mon, 1 Oct 2001 09:08:39 -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 f91CEhP26773 for ; Mon, 1 Oct 2001 08:14:43 -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 f91CF4x08078; Mon, 1 Oct 2001 08:15:04 -0400 (EDT) From: "Eddy Quicksall" To: "'John Hufferd'" , "'Sanjeev Bhagat \(TRIPACE/Zoetermeer\)'" Cc: Subject: RE: iscsi : iscsi parameter default values Date: Mon, 1 Oct 2001 08:14:29 -0400 Message-ID: <000701c14a72$a4901e00$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 John, I don't think you are considering existing cache code that was written around parallel SCSI. That is the basics for the arguments that everyone is giving you. Remember, we want iSCSI to be a hit and if people can't port easily, it will be a problem. As I said before, the default value is no big deal because one can always "just say no" (or yes). Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Sunday, September 30, 2001 4:42 PM To: Sanjeev Bhagat (TRIPACE/Zoetermeer) Cc: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values 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 Mon Oct 1 10:17: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 KAA18309 for ; Mon, 1 Oct 2001 10:17:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91D8oP29137 for ips-outgoing; Mon, 1 Oct 2001 09:08:50 -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 f91CwsP28648 for ; Mon, 1 Oct 2001 08:58:54 -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 f91CxQx25942; Mon, 1 Oct 2001 08:59:26 -0400 (EDT) From: "Eddy Quicksall" To: "'John Hufferd'" , Subject: RE: iSCSI: Immediate Data Date: Mon, 1 Oct 2001 08:58:59 -0400 Message-ID: <000e01c14a78$d6ebc0b0$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 John, I think you are missing the opposition's point. I don't think anyone is arguing that immediate data does not give a performance boost in most cases ... rather what should the default be? For me, I don't care because I support it. But for the others, I personally side with them because you are telling them that it is "easy" and for legacy cache code, it is probably not easy (for obvious reasons). I see a lot of "memory is cheep" but it seems like you are therefore saying "we'll only use iSCSI in heavy weight controllers". What about disk drives, don't we want iSCSI there too? What about bridge controllers? I think if you took a pole, you would find that most out there are not in the heavy weight arena that you are in. If we want iSCSI to be an overwhelming success, we need to make it easy to port existing code bases and just add a transport layer. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, October 01, 2001 12:05 AM To: ips@ece.cmu.edu Subject: iSCSI: Immediate Data I thought it would be useful to explain why I think that Immediate Data is important to iSCSI, so here it is: 1. Immediate Data permits the elimination of an additional network handshake/interaction. 2. This is important since some applications have a key sensitivity to Latency. The most important of these is Database. 3. Not only is Database sensitive to Latency, it generally has small I/O writes. 4. The hardware HBAs that many of you folks are building, include a TCP/IP Offload Engines (TOEs). This permits support of Gigabit Line speed without Server Load. However, even though many of you are attempting to parallelize as much of the TOE processing as possible, TCP/IP processing will still add latency to each iSCSI interaction, as compared to Fibre Channel. 5. If we want iSCSI to be performance competitive with Fibre Channel, we need to do something about the additional Latency left in the path even with HW HBAs. One important way to do this, is to simply eliminate the extra handshake that Fibre Channel uses on the small Writes. 6. Please note that this is not a big problem with large transfers, since the Latency is Amortized over more data. 7. So it is the Immediate Data feature of iSCSI that will make an important difference in the Key Response Time Sensitive Applications, which by luck only transfer a small amounts of data at a time. 8. When we attempt to let iSCSI shine on the "at-distance" storage environment, the value of Immediate Data, and Unsolicited Data are even more valuable. However, my concern at this time is for Immediate Data. Now the above is the reason that I think Immediate Data is key and important to the acceptance of iSCSI in the Enterprise Environment. And the following says why I think it is simple: A. Creating a Buffer Manager that can allocate buffers that are chained together, is kind of fundamental to the high performance environment we are attempting to work with. All the processes (whether iSCSI or SCSI) will allocate buffers (from the Buffer Manager), place data in one or more of these buffers, and pass the pointe list to the next process. There will be no copying of data. B. This works the same whether the data comes in with the command or separately. When it comes in with the command, the iSCSI process will request the Max buffers from the Buffer manager, and will be given one or more pointers to buffer elements. The Command and Data will be placed into one of more of the buffer segments, then the buffers that are filled, will be queued, in some manner, to the next iSCSI or SCSI Process. The unused buffer segments will be re-queued on the free queue. (I know I am telling you the obvious, but for some reason this message is not getting across.) C. Having every thing (including the data) arrive with the command, eliminates the code path overhead that is needed to collates data with commands. D. Since the only thing that is moved is pointers, it becomes a Zero Copy technique at its very core. E. The only thing that needs to be managed is the overall buffer space. And that needs to be managed anyway. The iSCSI Window management are the functions that are suppose to be used to control that. F. The issue of having enough memory is probably not a real world problem except at the very extremes. And you need to have the exact same code to manage the iSCSI Windows regardless of what caused the buffer space to run low. G. When a Storage Controller is expected to handle a large number of connections, the Storage Controller is expected to have a large pool of RAM storage, and when the Storage Controller is expected to handle only a small number of connections, it is hard not to have enough memory, since the price and availability of small RAMs is problematical. All the above, leads me to the belief that ImmediateData=yes, is the simplest, and most conservative option. And it solves the Latency issue with Enterprise Databases, thereby assuring the success of iSCSI in the Enterprise as well as the "at-distance" computing environment. . . . 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 Oct 1 11:00: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 LAA19753 for ; Mon, 1 Oct 2001 11:00:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91Dd5e00367 for ips-outgoing; Mon, 1 Oct 2001 09:39:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ext1.pirus.com ([4.36.58.197]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f91Dd3P00362 for ; Mon, 1 Oct 2001 09:39:03 -0400 (EDT) Message-Id: <200110011339.f91Dd3P00362@ece.cmu.edu> Received: by ext1.pirus.com with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Oct 2001 09:42:50 -0400 From: "Wood, Ken" To: "'ips@ece.cmu.edu'" Subject: remove Date: Mon, 1 Oct 2001 09:42:43 -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 remove From owner-ips@ece.cmu.edu Mon Oct 1 12:40: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 MAA22772 for ; Mon, 1 Oct 2001 12:40:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91FNPZ06117 for ips-outgoing; Mon, 1 Oct 2001 11:23: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 f91FNNP06111 for ; Mon, 1 Oct 2001 11:23: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 LAA69128 for ; Mon, 1 Oct 2001 11:20: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 f91FMox280240 for ; Mon, 1 Oct 2001 09:22:51 -0600 Importance: Normal Subject: Re: iSCSI: ISID issue To: "John Hufferd" , ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 1 Oct 2001 08:22:49 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/01/2001 08:22:50 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, Without burning too many cycles, my first thought is "I can't imagine what rules to impose". As I said in the note, the initiator may have specific reasons for doing certain things (identifying itself in special ways), but the target has now way of knowing them. So, I can't the the basis for any such rules. The only rule at all would be "not two duplicate SSIDs to the same initiator", but that doesn't gain anything. You could say the target is "allowed" to do certain things, but there is no motiviation for it to do so (so it probably won't). Jim Hafner John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 09/28/2001 05:19:58 pm Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: ISID issue 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 Mon Oct 1 12:42: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 MAA22878 for ; Mon, 1 Oct 2001 12:42:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91FprZ08001 for ips-outgoing; Mon, 1 Oct 2001 11:51:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f91FpoP07997 for ; Mon, 1 Oct 2001 11:51:51 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id LAA00906 for ips@ece.cmu.edu; Mon, 1 Oct 2001 11:51:40 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkg-vty54.as.wcom.net [206.175.236.54]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id LAA00882 for ; Mon, 1 Oct 2001 11:51:34 -0400 (EDT) Message-ID: <3BB8922F.CDC217F3@compuserve.com> Date: Mon, 01 Oct 2001 10:56:31 -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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, I was not aware that you were proposing that iSCSI not support the Disconnect-Reconnect mode page at all. Now that would be a radical step. If on the other hand you are proposing that iSCSI have a Maximum Burst Size but refuse to provide that information in the Disconnect-Reconnect mode page whose page code iSCSI devices accept, then I think you are at least violating the ISP charter as regards interactions with T10 standards (specifically SPC-2). This is my rather strongly held opinion and unless you find an argument that is substantially better than anything presented to date I expect to maintain this opinion to the bitter end. Ralph Weber From owner-ips@ece.cmu.edu Mon Oct 1 12:43: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 MAA22899 for ; Mon, 1 Oct 2001 12:43:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91FcnR07248 for ips-outgoing; Mon, 1 Oct 2001 11:38:49 -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 f91FcmP07244 for ; Mon, 1 Oct 2001 11:38:48 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id CF9921F5FB; Mon, 1 Oct 2001 08:38:34 -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 IAA09040; Mon, 1 Oct 2001 08:38:29 -0700 (PDT) Message-ID: <3BB88F92.C8B95E18@cup.hp.com> Date: Mon, 01 Oct 2001 08:45:23 -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: ENDL_TX@computer.org, IPS Reflector Subject: Re: iscsi : default iscsi mode page settings - Consensus call References: <277DD60FB639D511AC0400B0D068B71ECAD7B2@CORPMX14> <3BB7BE8D.2B9AB2EE@compuserve.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph Weber wrote: > I read SPC-2 to promise applications that such > a value will appear in the proper field in the > Disconnect-Reconnect mode page. Ralph, I don't see where in SPC-2 is it stated that "such a value (MaximumBurstSize) will appear in the disconnect-reconnect mode page of each protocol." I read the following in SPC-2 definition of disconnect-reconnect mode page : "The parameters appropriate to each protocol and their interpretation for that protocol may be specified in the individual protocol documents." Further below in that same section : "If a parameter that is not appropriate for the specific protocol implemented by the SCSI device is non-zero, the device server shall return CHECK CONDITION status. The sense key shall be set to ILLEGAL REQUEST and the asc set to ILLEGAL FIELD IN PARAMETER LIST." Since there are other fields in this mode page that differ from one SCSI transport to another, I don't see how an application that is performing a mode sense/select operation can be guaranteed reliable semantics when it uses the SPC-2 definition of this page. Any such application will need to be aware of all the SCSI transport specific versions of this page and use the appropriate version based on the transport in use. Also, the mode sense(6) & mode sense(10) sections state that : "If an application issues a mode sense command with a page code that is not supported by the target, the device server shall return CHECK CONDITION status and the sense key shall be set to ILLEGAL REQUEST and the asc to INVALID FIELD IN CDB." The above implies that specific implementations are allowed to not support certain page codes [like the disconnect-reconnect mode page]. In the case of iscsi, a class of targets (iscsi targets) will not be supporting this page. Again, from the above, I don't see how an application would be guaranteed that every SCSI target would support the disconnect-reconnect mode page. Please help me understand where in the SPC-2 definition is the application assured that : a) the disconnect-reconnect page code is required to be supported on all targets. b) all or any specific fields of the disconnect-reconnect field definitions will be available to the application in each of the SCSI transports. Thanks, Santosh > 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 -- ################################## 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 Mon Oct 1 13: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 NAA24281 for ; Mon, 1 Oct 2001 13:29:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91GVmt10369 for ips-outgoing; Mon, 1 Oct 2001 12:31:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f91GVkP10365 for ; Mon, 1 Oct 2001 12:31:46 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f91GVd113518 for ; Mon, 1 Oct 2001 12:31:40 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14A96.8B7E634E" Subject: IPS-All: RE: next meeting Date: Mon, 1 Oct 2001 12:31:38 -0400 Message-ID: <9410A0F67DFE7F4D998D45382364983617B195@nc8220exchange.ral.lucent.com> Thread-Topic: next meeting Thread-Index: AcFJgMkBiBN1pQHHQRe0h+TKJntSfQBFYlKg From: "Elizabeth Rodriguez" To: "Bill Strahm" , "Eddy Quicksall" , Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C14A96.8B7E634E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bill is correct -- The next IPS WG meeting will be during the next IETF meeting in Salt Lake City. Specific times for the meetings have not yet been set, but expect two sessions, as in the past. =20 Also, the meetings will cover all IPS drafts. =20 Thanks, =20 Elizabeth -----Original Message----- From: Bill Strahm [mailto:bill@sanera.net] Sent: Saturday, September 29, 2001 10:40 PM To: Eddy Quicksall; ips@ece.cmu.edu Subject: RE: next meeting 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). =20 =20 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? =20 Eddy_Quicksall@iVivity.com =20 ------_=_NextPart_001_01C14A96.8B7E634E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bill=20 is correct --
The=20 next IPS WG meeting will be during the next IETF meeting in Salt Lake=20 City.
Specific times for the meetings have not yet = been set,=20 but expect two sessions, as in the past.
 
Also,=20 the meetings will cover all IPS drafts.
 
Thanks,
 
Elizabeth
-----Original Message-----
From: Bill Strahm=20 [mailto:bill@sanera.net]
Sent: Saturday, September 29, 2001 = 10:40=20 PM
To: Eddy Quicksall; ips@ece.cmu.edu
Subject: = RE: next=20 meeting

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=20 IETF meeting Dec 9-13th in Salt Lake City (David/Elizabeth, I am = assuming IPS=20 will 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=20 know where and when the next IPS meeting for general attendance=20 is?
 
Eddy_Quicksall@iVivity.com=
 
------_=_NextPart_001_01C14A96.8B7E634E-- From owner-ips@ece.cmu.edu Mon Oct 1 13:29: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 NAA24295 for ; Mon, 1 Oct 2001 13:29:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91GHDt09493 for ips-outgoing; Mon, 1 Oct 2001 12:17:13 -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 f91GHBP09488 for ; Mon, 1 Oct 2001 12:17: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 MAA124318 for ; Mon, 1 Oct 2001 12:14:48 -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 f91GFsx198176 for ; Mon, 1 Oct 2001 10:15:54 -0600 Importance: Normal Subject: Re: iSCSI: ISID kicker issue To: "John Hufferd" , ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 1 Oct 2001 09:15:50 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/01/2001 09:15:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, Some comments in line Jim Hafner John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 09/28/2001 05:48:59 pm Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: ISID kicker issue 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. First, the T10 folks are trying to come up with "additional and optional features" that would move in the diretion you're saying. That is partly to make the wedge-driver's job easier. But that doesn't mean that iSCSI can ignore the current defined and well-understood model. We have to live with the current model AND see how what we do might affect (enable or prevent enabling) the new features. Having the target provide the SSID, in my mind, will prevent the new features from being made available. But you folks then spun down a path of having the application define what session it wanted to use, ..... Well, I didn't go down this path. This is what I think David is suggesting and I'm questioning. In my mind, the lower layers (based on some policy) establishes sessions well before the application kicks in. The application takes what it gets in whatever form the lower layer want to present it internally to the application. David seems to be suggesting that the application drive session establishment. 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. I haven't seen an application like this either, but maybe David has or is expecting to see them. I'm not sure all the T10 people would agree with your last statement. There is resistence to the new proposals at T10. In particular, whatever comes out of T10 will NOT break (or even confuse) any existing implementations of the current model. That we do have to live with. Keep in mind that there are two independent proposals in T10. One would "disregard the target port" (and this is moving forward slowly). The other would "disregard the initiator port" (this has been stalled for a while). The latter is closer to what your "apply to the total system" words say, but I think your intent is actually the join of the two. My point with the "kicker" is that the suggested change to SSID generation might completely disable iSCSI from using these new features (because we won't have 'named' SCSI initiator ports anymore). 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. But then you can't have more than one session per initiator node to target portal group! (That would be two parallel nexus!). Your suggestion is to have all iSCSI initiators modeled as single SCSI Initiator Port'ed. There are conflicting interests here (multiple connections per session, unlimited numbers of sessions, limitations of the SAM-2 and SPC-2 models, etc.). When you try to open one up twist on the model for simplification, it tends to trample on another. As I've said, I've been around this whole topic from every angle I can think of, and where I ended up (with the model as defined in draft -08) was the only option I found that provided the most flexibility for all issues, properties, models,... I haven't seen anything that would cause me to change my opinion about the right model. The issue in my mind is still (a) what action does the target perform to enforce the ISID RULE (this is what started this tangled web of threads) and (b) what is the best way to implement the initiator so that it doesn't unknowingly break the ISID RULE and so cause the target to implement its 'action'. I think this should be straight forward to implement. I do not see the problem with the Kicker. The problem is two fold (as I've said above). Either, you don't name SCSI initiator ports and so make it very difficult for the new features (and even for the current model) OR you have only one (named) SCSI initiator port and end up limiting the session construction flexibility that one might want. 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? One of my points is that I think it is important that iSCSI provide Names for SCSI Initiator Ports. I think these names have to come from the initiator (not be generated by the targets). The names have to provide enough flexibility to allow maximum session multiplicity and be the basis for SCSI Target identification of the SCSI Initiator Port for the purposes of (most importantly, but not exclusively) SCSI reservations (of today and tomorrow). The only thing I've found so far is ISID on which to hang that property. Other proposals all seem to end up (to me) as either having less functionality (e.g., more session restrictions) or duplicate functionality. . . . 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 Mon Oct 1 13:33: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 NAA24470 for ; Mon, 1 Oct 2001 13:33:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91GBgC09204 for ips-outgoing; Mon, 1 Oct 2001 12:11:42 -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 f91GBdP09200 for ; Mon, 1 Oct 2001 12:11:39 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id B53831F7BC for ; Mon, 1 Oct 2001 09:11:33 -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 JAA10597; Mon, 1 Oct 2001 09:11:29 -0700 (PDT) Message-ID: <3BB8974F.BFD84BFA@cup.hp.com> Date: Mon, 01 Oct 2001 09:18:23 -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 X-Priority: 1 (Highest) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, As the one who started this thread, please allow me to raise one important consideration to this discussion. This discussion has gone down the path of whether immediate data boosts performance and is implementable or whether it is so demanding that it is not feasible to implement. I believe the decision on what the default value must assume for this parameter must be based on what is going to be the simplest for the login process and which setting minimizes the overheads involved for completion of login. The reason for applying the above criteria is that it provides the benefit of completing login negotiation in a single handshake and in most cases, where initiator goes with the defaults, allows no negotiation to be required whatsoever. [in the case where no security is being negotiated.]. This has the significant benefit of boosting iscsi interoperability, since it has been seen that login is one of the most painful areas of iscsi. With the above in mind, let us consider the 2 cases, Immediate data default to "yes" & "no" (assuming neither side is interested in security) : In the first case (default immediate data="yes') : -------------------------------------------------- - Initiator wishes to use immediate data. Target does not support it. I -> T : (no key is sent. default assumed for immediate data). (CSG=Operational, NSG=FullFeaturePhase). T=1 T -> I : ImmediateData="no" (tgt does not support imm data.) (CSG=Operational,NSG=Operational). T=0 I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1 (no keys to negotiate. negotiation completed at initiator. only phase change taking place.) T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1 (target completes phase change. both sides move to FFP.) Thus, in the above model, there's an extra dummy login handshake, when the default ImmediateData is "yes" but targets don't support it for the sole purpose of completing the login phase change. Now, take the case of default ImmediateData set to "no" : --------------------------------------------------------- - Initiator wants to use immediate data. target does not support it. (same scenario as above). I -> T : ImmediateData="yes" (CSG=Operational. NSG=FullFeaturePhase.). T=1 T -> I : ImmediateData="no" (CSG=Operational. NSG=FullFeaturePhase). T=1 - Initiator does not want to use immediate data. I -> T : (no key is sent. defaults assumed). (CSG=Operational. NSG=FullFeaturePhase). T=1 T -> I : (targets can accept all defaults since they are conservative.) (CSG=Operational, NSG=FullFeaturePhase). T=1 Thus, as you can see from the above, the login process involves the least number of exchanges when the default for ImmediateData is chosen to be "no", as opposed to a default of "yes". It DOES NOT matter whether some believe ImmediateData is useful and feasible or some believe it is useful but not feasible, or yet some others believe it is not useful. What MUST govern this decision is which default allows for the simplest login operation. From the above, it seems to me like a default of "no" for ImmediateData allows login to be completed in a single handshake in the case where initiators wishes to use immediate data or not, and in the case where target supports immediate data or not. Therefore, I request the group to please consider setting the ImmediateData default to "no" and vote for the setting of "no". This decision benefits BOTH the camp of immediate data users and non-users, since both benefit from minimized steps in the login process. Thanks, Santosh -------------------------------------------------------------------------- Robert Snively wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- ################################## 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 Mon Oct 1 13:36: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 NAA24594 for ; Mon, 1 Oct 2001 13:36:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91GgRa11011 for ips-outgoing; Mon, 1 Oct 2001 12:42:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from philotas.hosting.pacbell.net (philotas.hosting.pacbell.net [216.100.99.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f91GgMP11006 for ; Mon, 1 Oct 2001 12:42:23 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by philotas.hosting.pacbell.net id MAA00350; Mon, 1 Oct 2001 12:42:18 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: Subject: RE: iscsi : iscsi parameter default values Date: Mon, 1 Oct 2001 09:41:18 -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 Julian, You still did not answer my question. If you do have any information (specific product related), I would really appreciate that. Thanks, Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, September 28, 2001 10:52 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > 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" > > "Julian Satran" , > 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 Mon Oct 1 13:39: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 NAA24738 for ; Mon, 1 Oct 2001 13:39:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91GTMn10165 for ips-outgoing; Mon, 1 Oct 2001 12:29: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 f91GTIP10160 for ; Mon, 1 Oct 2001 12:29:18 -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 SAA03970 for ; Mon, 1 Oct 2001 18:29:11 +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 f91GTAB292154 for ; Mon, 1 Oct 2001 18:29:10 +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" Message-ID: Date: Mon, 1 Oct 2001 19:28:58 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/10/2001 19:29:10, Serialize complete at 01/10/2001 19:29:10 Content-Type: multipart/alternative; boundary="=_alternative 005A960BC2256AD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005A960BC2256AD8_= Content-Type: text/plain; charset="us-ascii" ... the debate would be of some interest if the examples where correct. But unfortunately they are not. Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 01-10-01 18:18 Please respond to Santosh Rao To: ips@ece.cmu.edu cc: Subject: Re: iscsi : iscsi parameter default values All, As the one who started this thread, please allow me to raise one important consideration to this discussion. This discussion has gone down the path of whether immediate data boosts performance and is implementable or whether it is so demanding that it is not feasible to implement. I believe the decision on what the default value must assume for this parameter must be based on what is going to be the simplest for the login process and which setting minimizes the overheads involved for completion of login. The reason for applying the above criteria is that it provides the benefit of completing login negotiation in a single handshake and in most cases, where initiator goes with the defaults, allows no negotiation to be required whatsoever. [in the case where no security is being negotiated.]. This has the significant benefit of boosting iscsi interoperability, since it has been seen that login is one of the most painful areas of iscsi. With the above in mind, let us consider the 2 cases, Immediate data default to "yes" & "no" (assuming neither side is interested in security) : In the first case (default immediate data="yes') : -------------------------------------------------- - Initiator wishes to use immediate data. Target does not support it. I -> T : (no key is sent. default assumed for immediate data). (CSG=Operational, NSG=FullFeaturePhase). T=1 T -> I : ImmediateData="no" (tgt does not support imm data.) (CSG=Operational,NSG=Operational). T=0 I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1 (no keys to negotiate. negotiation completed at initiator. only phase change taking place.) T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1 (target completes phase change. both sides move to FFP.) Thus, in the above model, there's an extra dummy login handshake, when the default ImmediateData is "yes" but targets don't support it for the sole purpose of completing the login phase change. Now, take the case of default ImmediateData set to "no" : --------------------------------------------------------- - Initiator wants to use immediate data. target does not support it. (same scenario as above). I -> T : ImmediateData="yes" (CSG=Operational. NSG=FullFeaturePhase.). T=1 T -> I : ImmediateData="no" (CSG=Operational. NSG=FullFeaturePhase). T=1 - Initiator does not want to use immediate data. I -> T : (no key is sent. defaults assumed). (CSG=Operational. NSG=FullFeaturePhase). T=1 T -> I : (targets can accept all defaults since they are conservative.) (CSG=Operational, NSG=FullFeaturePhase). T=1 Thus, as you can see from the above, the login process involves the least number of exchanges when the default for ImmediateData is chosen to be "no", as opposed to a default of "yes". It DOES NOT matter whether some believe ImmediateData is useful and feasible or some believe it is useful but not feasible, or yet some others believe it is not useful. What MUST govern this decision is which default allows for the simplest login operation. From the above, it seems to me like a default of "no" for ImmediateData allows login to be completed in a single handshake in the case where initiators wishes to use immediate data or not, and in the case where target supports immediate data or not. Therefore, I request the group to please consider setting the ImmediateData default to "no" and vote for the setting of "no". This decision benefits BOTH the camp of immediate data users and non-users, since both benefit from minimized steps in the login process. Thanks, Santosh -------------------------------------------------------------------------- Robert Snively wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## --=_alternative 005A960BC2256AD8_= Content-Type: text/html; charset="us-ascii"
... the debate would be of some interest if the examples where correct.

But unfortunately they are not.

Julo


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

01-10-01 18:18
Please respond to Santosh Rao

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Re: iscsi : iscsi parameter default values

       


All,

As the one who started this thread, please allow me to raise one
important consideration to this discussion.

This discussion has gone down the path of whether immediate data boosts
performance and is implementable or whether it is so demanding that it
is not feasible to implement.


I believe the decision on what the default value must assume for this
parameter must be based on what is going to be the simplest for the
login process and which setting minimizes the overheads involved for
completion of login.

The reason for applying the above criteria is that it provides the
benefit of completing login negotiation in a single handshake and in
most cases, where initiator goes with the defaults, allows no
negotiation to be required whatsoever. [in the case where no security is
being negotiated.]. This has the significant benefit of boosting iscsi
interoperability, since it has been seen that login is one of the most
painful areas of iscsi.

With the above in mind, let us consider the 2 cases, Immediate data
default to "yes" & "no" (assuming neither side is interested in
security) :

In the first case (default immediate data="yes') :
--------------------------------------------------
- Initiator wishes to use immediate data. Target does not support it.

I -> T : (no key is sent. default assumed for immediate data).
                 (CSG=Operational, NSG=FullFeaturePhase). T=1

T -> I : ImmediateData="no" (tgt does not support imm data.)
                 (CSG=Operational,NSG=Operational). T=0

I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1
        (no keys to negotiate.
         negotiation completed at initiator.
         only phase change taking place.)

T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1
        (target completes phase change.
         both sides move to FFP.)


Thus, in the above model, there's an extra dummy login handshake, when
the default ImmediateData is "yes" but targets don't support it for the
sole purpose of completing the login phase change.


Now, take the case of default ImmediateData set to "no" :
---------------------------------------------------------
- Initiator wants to use immediate data. target does not support it.
(same scenario as above).

I -> T : ImmediateData="yes"
        (CSG=Operational. NSG=FullFeaturePhase.). T=1

T -> I : ImmediateData="no"
                 (CSG=Operational. NSG=FullFeaturePhase). T=1


- Initiator does not want to use immediate data.

I -> T : (no key is sent. defaults assumed).
        (CSG=Operational. NSG=FullFeaturePhase). T=1

T -> I : (targets can accept all defaults since they
                  are conservative.)
                 (CSG=Operational, NSG=FullFeaturePhase). T=1

     
Thus, as you can see from the above, the login process involves the
least number of exchanges when the default for ImmediateData is chosen
to be "no", as opposed to a default of "yes".

It DOES NOT matter whether some believe ImmediateData is useful and
feasible or some believe it is useful but not feasible, or yet some
others believe it is not useful.

What MUST govern this decision is which default allows for the simplest
login operation.

From the above, it seems to me like a default of "no" for ImmediateData
allows login to be completed in a single handshake in the case where
initiators wishes to use immediate data or not, and in the case where
target supports immediate data or not.

Therefore, I request the group to please consider setting the
ImmediateData default to "no" and vote for the setting of "no". This
decision benefits BOTH the camp of immediate data users and non-users,
since both benefit from minimized steps in the login process.

Thanks,
Santosh


--------------------------------------------------------------------------

Robert Snively wrote:
>
> 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >

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

--=_alternative 005A960BC2256AD8_=-- From owner-ips@ece.cmu.edu Mon Oct 1 13:40: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 NAA24777 for ; Mon, 1 Oct 2001 13:40:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91GfT710935 for ips-outgoing; Mon, 1 Oct 2001 12:41:29 -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 f91GfRP10928 for ; Mon, 1 Oct 2001 12:41:27 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 34B101F578; Mon, 1 Oct 2001 09:41:21 -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 JAA12413; Mon, 1 Oct 2001 09:41:16 -0700 (PDT) Message-ID: <3BB89E4A.EB882113@cup.hp.com> Date: Mon, 01 Oct 2001 09:48: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: ENDL_TX@computer.org, IPS Reflector Subject: Re: iscsi : default iscsi mode page settings - Consensus call References: <277DD60FB639D511AC0400B0D068B71ECAD7B2@CORPMX14> <3BB7BE8D.2B9AB2EE@compuserve.com> <3BB88F92.C8B95E18@cup.hp.com> <3BB89169.7389EA14@compuserve.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph Weber wrote: > > Santosh, > > I was not aware that you were proposing that iSCSI > not support the Disconnect-Reconnect mode page at > all. Now that would be a radical step. Ralph, The intent was that iscsi not specify any iscsi specific mode pages (as Julian brought up a few days ago.). Could you please clarify why & how would this be in violation of SPC-2, in particular, commenting on the following clarifications that I previously sought : Where in the SPC-2 definition is the application assured that : a) the disconnect-reconnect page code is required to be supported on all targets. b) all or any specific fields of the disconnect-reconnect field definitions will be available to the application across all of the SCSI transports. In the absence of the above 2 assurances to applications, how would iscsi be breaking any legacy applications by taking this "radical" step. (?) IMHO, the parameter rounding mechanism renders the mode sense/select mechanism of parameter negotiation inefficient, when compared with a text key based scheme, and the intent of these changes is to simplify the negotiation of these parameters and localize them to iscsi specific efficient negotiation schemes like the current text key negotiation. Thanks & Regards, Santosh > If on the other hand you are proposing that iSCSI > have a Maximum Burst Size but refuse to provide > that information in the Disconnect-Reconnect mode > page whose page code iSCSI devices accept, then > I think you are at least violating the ISP charter > as regards interactions with T10 standards (specifically > SPC-2). > > This is my rather strongly held opinion and unless > you find an argument that is substantially better > than anything presented to date I expect to maintain > this opinion to the bitter end. > > Ralph Weber -- ################################## 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 Mon Oct 1 14: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 OAA25542 for ; Mon, 1 Oct 2001 14:06:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91GsJ511727 for ips-outgoing; Mon, 1 Oct 2001 12:54:19 -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 f91GsHP11723 for ; Mon, 1 Oct 2001 12:54:17 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id 4EF9D1F6AF; Mon, 1 Oct 2001 09:54: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 JAA13358; Mon, 1 Oct 2001 09:54:01 -0700 (PDT) Message-ID: <3BB8A147.BF018089@cup.hp.com> Date: Mon, 01 Oct 2001 10:00: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 Cc: Jim Hafner , David Black Subject: Re: iSCSI: ISID issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, John, Jim & All, Before we go down the path of attempting to select a different rule for the creation of initiator ports, I would like to request the group to take another look ath Jim's ISID scheme. I think comparisions to FC's mess-up of the node WWN are not fair to the current ISID rule, since, unlike in FC, the worst case scenario with the ISID rule, is that each iscsi driver on the system will take up a different iscsi initiator name. In most O.S.', there will be 1 or perhaps 2 or maybe a few in the worst case( < 5 - 6 ?), operational iscsi drivers functioning actively on that system. Thus, we're really looking at an ideal goal of 1 initiator name being diluted to perhaps, 1 initiator name per iscsi driver active on the system. I don't think this is too bad and is not comparable with FC, where each HBA takes a different node name. Given that all iscsi HBA vendors will need to have SOME host O.S. driver component which they will be writing, it is possible for them to hand out ISIDs to their adapters within their own driver domain. The ISID rule works fine as long as ISIDs are ditributed within the domain of each iscsi driver and since, the number of iscsi drivers supported on an O.S. are'nt going to be that large, I think, this is'nt as big an issue as FC's node name problems.(which scales linearly with the number of HBAs, not the number of drivers). I support Jim's efforts on the "ISID rule" and think it is a reasonable expectation, given that, we decided to support Multi-Cxn/Session and thereby, got burdened with the "virtual SCSI port" concept. Thanks, Santosh Jim Hafner wrote: > > John, > > Without burning too many cycles, my first thought is "I can't imagine what > rules to impose". As I said in the note, the initiator may have specific > reasons for doing certain things (identifying itself in special ways), but > the target has now way of knowing them. So, I can't the the basis for any > such rules. The only rule at all would be "not two duplicate SSIDs to the > same initiator", but that doesn't gain anything. You could say the target > is "allowed" to do certain things, but there is no motiviation for it to do > so (so it probably won't). > > Jim Hafner > > John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 09/28/2001 05:19:58 pm > > Sent by: owner-ips@ece.cmu.edu > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: ISID issue > > 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 > --------------------------------------------------- -- ################################## 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 Mon Oct 1 14: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 OAA25610 for ; Mon, 1 Oct 2001 14:09:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91HCb612845 for ips-outgoing; Mon, 1 Oct 2001 13:12:37 -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 f91HCYP12840 for ; Mon, 1 Oct 2001 13:12:35 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail16.vwh1.net (RS ver 1.0.60s) with SMTP id 031635232; Mon, 1 Oct 2001 13:11:56 -0400 (EDT) From: "Dev - Platys" To: "IPS Reflector" Cc: Subject: RE: iscsi : default iscsi mode page settings - Consensus call Date: Mon, 1 Oct 2001 10:18:13 -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: <3BB88F92.C8B95E18@cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, I prefer that the default value for ImmediateData be set 'no'. This allows the initiators/targets, that support immediate data or not, to negotiate this value with minimal handshakes during login phase. I feel that discussions on the benefits of immediate data, complexity of implementing it etc, though useful, have gone off path, to determine what could be the default value. My vote is for the default value of 'Immediatedata' to be set as 'No'. Thanks Deva Adaptec From owner-ips@ece.cmu.edu Mon Oct 1 14:11: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 OAA25707 for ; Mon, 1 Oct 2001 14:11:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91HAqJ12734 for ips-outgoing; Mon, 1 Oct 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 antigonus.hosting.pacbell.net (antigonus.hosting.pacbell.net [216.100.98.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f91HAmP12729 for ; Mon, 1 Oct 2001 13:10:49 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by antigonus.hosting.pacbell.net id NAA13206; Mon, 1 Oct 2001 13:10:22 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "Robert Snively" , "'Julian Satran'" , Subject: RE: iscsi : iscsi parameter default values Date: Mon, 1 Oct 2001 10:09:23 -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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, I agree with Robert on the complexity issue. I think the approach you tend to take is of a TCP accelerator with iSCSI in software. If you look at it from the perspective of zero copy adapters which do all iSCSI protocol processing, and combine that with the current buffer management scheme implemented by a number of arrays, immediate data/unsolicited data requires a significant change to the SCSI <-> SCSI transport API + the buffer management scheme in the array. The question is not of immediate vs unsolicited data. The question is of whether a targeted host buffer is ready to receive the data when it comes. My understanding is this is based on talking to only some of the array engineers. If your experience is specifically otherwise, it would be worthwhile sharing that. On the other hand, I think it would be worthwhile having a discussion on default values for all parameters. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Robert Snively > Sent: Saturday, September 29, 2001 10:48 PM > 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 Mon Oct 1 14:16: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 OAA25819 for ; Mon, 1 Oct 2001 14:16:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91HSEc13777 for ips-outgoing; Mon, 1 Oct 2001 13:28:14 -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 f91HSCP13771 for ; Mon, 1 Oct 2001 13:28:12 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 10:28:00 -0700 Message-ID: From: Sharon Yao To: ips@ece.cmu.edu Subject: remove Date: Mon, 1 Oct 2001 10:27:55 -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 Mon Oct 1 14:53: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 OAA26991 for ; Mon, 1 Oct 2001 14:53:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91HumC15572 for ips-outgoing; Mon, 1 Oct 2001 13:56:48 -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 f91HtQP15453 for ; Mon, 1 Oct 2001 13:55:27 -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 f91HtHx11728; Mon, 1 Oct 2001 13:55:21 -0400 (EDT) From: "Eddy Quicksall" To: "'Santosh Rao'" , Subject: RE: iscsi : iscsi parameter default values Date: Mon, 1 Oct 2001 13:54:41 -0400 Message-ID: <002e01c14aa2$2b0108d0$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: <3BB8974F.BFD84BFA@cup.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here-here (In english that means Yah! or Right On!) :-) Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Monday, October 01, 2001 12:18 PM To: ips@ece.cmu.edu Subject: Re: iscsi : iscsi parameter default values Importance: High All, As the one who started this thread, please allow me to raise one important consideration to this discussion. This discussion has gone down the path of whether immediate data boosts performance and is implementable or whether it is so demanding that it is not feasible to implement. I believe the decision on what the default value must assume for this parameter must be based on what is going to be the simplest for the login process and which setting minimizes the overheads involved for completion of login. The reason for applying the above criteria is that it provides the benefit of completing login negotiation in a single handshake and in most cases, where initiator goes with the defaults, allows no negotiation to be required whatsoever. [in the case where no security is being negotiated.]. This has the significant benefit of boosting iscsi interoperability, since it has been seen that login is one of the most painful areas of iscsi. With the above in mind, let us consider the 2 cases, Immediate data default to "yes" & "no" (assuming neither side is interested in security) : In the first case (default immediate data="yes') : -------------------------------------------------- - Initiator wishes to use immediate data. Target does not support it. I -> T : (no key is sent. default assumed for immediate data). (CSG=Operational, NSG=FullFeaturePhase). T=1 T -> I : ImmediateData="no" (tgt does not support imm data.) (CSG=Operational,NSG=Operational). T=0 I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1 (no keys to negotiate. negotiation completed at initiator. only phase change taking place.) T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1 (target completes phase change. both sides move to FFP.) Thus, in the above model, there's an extra dummy login handshake, when the default ImmediateData is "yes" but targets don't support it for the sole purpose of completing the login phase change. Now, take the case of default ImmediateData set to "no" : --------------------------------------------------------- - Initiator wants to use immediate data. target does not support it. (same scenario as above). I -> T : ImmediateData="yes" (CSG=Operational. NSG=FullFeaturePhase.). T=1 T -> I : ImmediateData="no" (CSG=Operational. NSG=FullFeaturePhase). T=1 - Initiator does not want to use immediate data. I -> T : (no key is sent. defaults assumed). (CSG=Operational. NSG=FullFeaturePhase). T=1 T -> I : (targets can accept all defaults since they are conservative.) (CSG=Operational, NSG=FullFeaturePhase). T=1 Thus, as you can see from the above, the login process involves the least number of exchanges when the default for ImmediateData is chosen to be "no", as opposed to a default of "yes". It DOES NOT matter whether some believe ImmediateData is useful and feasible or some believe it is useful but not feasible, or yet some others believe it is not useful. What MUST govern this decision is which default allows for the simplest login operation. >From the above, it seems to me like a default of "no" for ImmediateData allows login to be completed in a single handshake in the case where initiators wishes to use immediate data or not, and in the case where target supports immediate data or not. Therefore, I request the group to please consider setting the ImmediateData default to "no" and vote for the setting of "no". This decision benefits BOTH the camp of immediate data users and non-users, since both benefit from minimized steps in the login process. Thanks, Santosh ------------------------------------------------------------------------ -- Robert Snively wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- ################################## 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 Mon Oct 1 14:55: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 OAA27037 for ; Mon, 1 Oct 2001 14:55:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91IUuG17955 for ips-outgoing; Mon, 1 Oct 2001 14:30:56 -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 f91IUqP17946 for ; Mon, 1 Oct 2001 14:30:52 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 4F9C31F635; Mon, 1 Oct 2001 11:30:41 -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 LAA22835; Mon, 1 Oct 2001 11:30:36 -0700 (PDT) Message-ID: <3BB8B7EA.E5C980C1@cup.hp.com> Date: Mon, 01 Oct 2001 11:37:30 -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: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , "'Julian Satran'" Subject: Re: iscsi : numerical negotiation wording is ambiguous References: <8C59010722BBD31194640050DA6EC6971B9861@ZOETERMEER> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian & Sanjeev, Responding to both your mails...... Julian : I think you may have mis-interpreted my comments. I believe Sanjeev has clarified the intent of my suggestions. I am *not* suggesting that the responder send back its values and these be blindly imposed on the originator. On the contrary, my suggestion is that the computation of the result of the negotiation (higher or lower of the 2 values) be only performed by the responder and sent back to the originator. The result of the negotiation is the same in both cases and there is no REJECT required in my case nor yours. The difference is the advantages I've stated in my model. Sanjeev, in response to your comment : " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. " There is NO need for any REJECT in the above case. If the initiator is'nt satisfied with the value returned by the originator and cannot function with the negotiated values, it can simply close the TCP connection. There is no need to send any REJECT. Thanks, Santosh > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > Thanks Julian, please find my further comments in the message > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Sunday, September 30, 2001 6:07 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : numerical negotiation wording is > ambiguous > > 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 > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > say it this way the responder computes the value with > its own supported values and responds with a value y > which the responder thinks is correct 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 > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > but it is highly unlikely for the responder to reject > the final result because the rule states that (lower or > higher of two will be the result) and so the offering > party should be able to accept the lower or higher > range as defined by rule. In case the key is dependent > upon some range of fixed values then the negotiation > should be performed as list negotiation and not > numerical negotiation. > > This might be what you "conventionally" do - I don't > and that shows that convention like morals are a matter > of geography :-) > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > The advantage of this set of rules is that it allows an > external observer to know what was selected without > knowing the rules > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > case, I guess that the external observer has to know > the rules to double check the value is correct or not > 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. > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. > > > Sanjeev > "Sanjeev Bhagat > (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" > , Julian > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > 30-09-01 16:32 Subject: RE: iscsi : > Please respond to "Sanjeev numerical negotiation wording is > Bhagat (TRIPACE/Zoetermeer)" 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 > -- ################################## 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 Mon Oct 1 14:55: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 OAA27063 for ; Mon, 1 Oct 2001 14:55:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91IgTu18934 for ips-outgoing; Mon, 1 Oct 2001 14:42:29 -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 f91IPjP17492 for ; Mon, 1 Oct 2001 14:25:46 -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 f91IQGx22057; Mon, 1 Oct 2001 14:26:16 -0400 (EDT) From: "Eddy Quicksall" To: , Subject: RE: iscsi : iscsi parameter default values Date: Mon, 1 Oct 2001 14:25:45 -0400 Message-ID: <003101c14aa6$7ec39ce0$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 In the target that I was involved with once, the cache would need significant change for immediate data. So, the change is not only in the transport layer, it is in the cache layer (ugh!). :-( Eddy -----Original Message----- From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] Sent: Monday, October 01, 2001 12:41 PM To: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Julian, You still did not answer my question. If you do have any information (specific product related), I would really appreciate that. Thanks, Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, September 28, 2001 10:52 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > 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" > > "Julian Satran" , > 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 Mon Oct 1 14:56: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 OAA27107 for ; Mon, 1 Oct 2001 14:56:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91I7nq16183 for ips-outgoing; Mon, 1 Oct 2001 14:07:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f91I7mP16178 for ; Mon, 1 Oct 2001 14:07:48 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA31016 for ; Mon, 1 Oct 2001 13:05:20 -0500 Received: from d04nms33.raleigh.ibm.com (d04nms33.raleigh.ibm.com [9.67.228.22]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f91I7f231086 for ; Mon, 1 Oct 2001 14:07:41 -0400 Importance: Normal Subject: remove To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Pradeep Vincent" Date: Mon, 1 Oct 2001 14:07:40 -0400 X-MIMETrack: Serialize by Router on D04NMS33/04/M/IBM(Release 5.0.8 |June 18, 2001) at 10/01/2001 02:07:40 PM MIME-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk From owner-ips@ece.cmu.edu Mon Oct 1 14:56: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 OAA27119 for ; Mon, 1 Oct 2001 14:56:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91I39c15924 for ips-outgoing; Mon, 1 Oct 2001 14:03:09 -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 f91I34P15917 for ; Mon, 1 Oct 2001 14:03:05 -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 LAA21891 for ; Mon, 1 Oct 2001 11:02:54 -0700 (PDT) Received: from aimexc06.corp.adaptec.com (aimexc06.corp.adaptec.com [162.62.62.46]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA23090 for ; Mon, 1 Oct 2001 10:49:23 -0700 (PDT) Received: by aimexc06.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 11:02:53 -0700 Message-ID: From: "Fischer, Michael" To: ips@ece.cmu.edu Subject: RE: iSCSI: Immediate Data Date: Mon, 1 Oct 2001 11:02:49 -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 Well, here is my $.02 (overpriced as it may be). I agree that the performance of ImmediateData my be indisputable but as I have not seen any metrics or performed any tests on it myself I cannot say. I, however, do not think that it is as easy as just saying yes or no to the ImmediateData command. If you do not support the defaults, how can you claim to be a iSCSI device? Michael Fischer From owner-ips@ece.cmu.edu Mon Oct 1 15: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 PAA27432 for ; Mon, 1 Oct 2001 15:03:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91IgdM18973 for ips-outgoing; Mon, 1 Oct 2001 14:42:39 -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 f91IbnP18501 for ; Mon, 1 Oct 2001 14:37:49 -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 f91IcLx09694 for ; Mon, 1 Oct 2001 14:38:22 -0400 (EDT) From: "Eddy Quicksall" To: Subject: RE: iscsi : default iscsi mode page settings - Consensus call Date: Mon, 1 Oct 2001 14:37:52 -0400 Message-ID: <003301c14aa8$2fa52dc0$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 vote NO. Eddy -----Original Message----- From: Dev - Platys [mailto:deva@platys.com] Sent: Monday, October 01, 2001 1:18 PM To: IPS Reflector Cc: deva@platys.com Subject: RE: iscsi : default iscsi mode page settings - Consensus call All, I prefer that the default value for ImmediateData be set 'no'. This allows the initiators/targets, that support immediate data or not, to negotiate this value with minimal handshakes during login phase. I feel that discussions on the benefits of immediate data, complexity of implementing it etc, though useful, have gone off path, to determine what could be the default value. My vote is for the default value of 'Immediatedata' to be set as 'No'. Thanks Deva Adaptec From owner-ips@ece.cmu.edu Mon Oct 1 15:04: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 PAA27488 for ; Mon, 1 Oct 2001 15:04:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91IgYG18948 for ips-outgoing; Mon, 1 Oct 2001 14:42:34 -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 f91IaqP18398 for ; Mon, 1 Oct 2001 14:36:53 -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 f91IbEx08269 for ; Mon, 1 Oct 2001 14:37:14 -0400 (EDT) From: "Eddy Quicksall" To: Subject: RE: iscsi : iscsi parameter default values Date: Mon, 1 Oct 2001 14:36:43 -0400 Message-ID: <003201c14aa8$0670c720$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 Regarding targets, upper layers I have dealt with usually involve cache. It is the cache layer that people don't want to change ... for obvious reasons. Where I've been exposed, the cache layer gets a request (perhaps to perform a write CDB); then it needs to allocate buffers (often needing to flush unneeded buffers in the process). In pSCSI, there is normally a disconnect after the CDB so other CDB's can come flying in during this process. Then, the cache layer makes a request to the transport layer for the data to be transferred directly to the buffers. For immediate data, the transport must put the data someplace because the cache layer has not even been notified. So using existing code, when the cache layer gets the request, flushes buffers and asks for the data to be transferred, the data must be copied from the transport buffers to the cache buffers. To overcome this, one would change the cache code and write the transport code so the transport code would have APIs to allocate buffers (and flush?) or the cache would use the transport memory as its cache buffers (a.k.a chained buffers). Now, if you have a lot of connections using 10Gig, I doubt if you will be able to execute much cache related buffer management code anyway. If ImmediateData=yes, the cache code would have to be changed and that could be a buggy effort. If ImmediateData=no, one could simply use R2T and port existing code more easily. Eddy -----Original Message----- From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] Sent: Monday, October 01, 2001 1:09 PM To: Robert Snively; 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Julian, I agree with Robert on the complexity issue. I think the approach you tend to take is of a TCP accelerator with iSCSI in software. If you look at it from the perspective of zero copy adapters which do all iSCSI protocol processing, and combine that with the current buffer management scheme implemented by a number of arrays, immediate data/unsolicited data requires a significant change to the SCSI <-> SCSI transport API + the buffer management scheme in the array. The question is not of immediate vs unsolicited data. The question is of whether a targeted host buffer is ready to receive the data when it comes. My understanding is this is based on talking to only some of the array engineers. If your experience is specifically otherwise, it would be worthwhile sharing that. On the other hand, I think it would be worthwhile having a discussion on default values for all parameters. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Robert Snively > Sent: Saturday, September 29, 2001 10:48 PM > 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 Mon Oct 1 15:22: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 PAA28049 for ; Mon, 1 Oct 2001 15:22:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91IlN119377 for ips-outgoing; Mon, 1 Oct 2001 14:47:23 -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 f91IlLP19371 for ; Mon, 1 Oct 2001 14:47:21 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 8AE995D5; Mon, 1 Oct 2001 11:47:20 -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 LAA24075; Mon, 1 Oct 2001 11:47:00 -0700 (PDT) Message-ID: <3BB8BBC2.DF1B514E@cup.hp.com> Date: Mon, 01 Oct 2001 11:53:54 -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: Paul Koning Cc: ips@ece.cmu.edu Subject: Re: iscsi : iscsi parameter default values References: <3BB8974F.BFD84BFA@cup.hp.com> <15288.44858.544000.700476@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Paul, My comments inline. Thanks, Santosh Paul Koning wrote: > > Excerpt of message (sent 1 October 2001) by Santosh Rao: > > All, > > > > As the one who started this thread, please allow me to raise one > > important consideration to this discussion. > > ... > > The reason for applying the above criteria is that it provides the > > benefit of completing login negotiation in a single handshake and in > > most cases, where initiator goes with the defaults, allows no > > negotiation to be required whatsoever. [in the case where no security is > > being negotiated.]. This has the significant benefit of boosting iscsi > > interoperability, since it has been seen that login is one of the most > > painful areas of iscsi. > > > > With the above in mind, let us consider the 2 cases, Immediate data > > default to "yes" & "no" (assuming neither side is interested in > > security) : > > > > In the first case (default immediate data="yes') : > > -------------------------------------------------- > > - Initiator wishes to use immediate data. Target does not support it. > > > > I -> T : (no key is sent. default assumed for immediate data). > > (CSG=Operational, NSG=FullFeaturePhase). T=1 > > > > T -> I : ImmediateData="no" (tgt does not support imm data.) > > (CSG=Operational,NSG=Operational). T=0 > > > > I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1 > > (no keys to negotiate. > > negotiation completed at initiator. > > only phase change taking place.) > > > > T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1 > > (target completes phase change. > > both sides move to FFP.) > > > > > > Thus, in the above model, there's an extra dummy login handshake, when > > the default ImmediateData is "yes" but targets don't support it for the > > sole purpose of completing the login phase change. > > If I understand this right, what you're saying is that a message with > a login parameter omitted has different semantics than a message with > that same parameter supplied and set equal to its default value. That's correct. The difference in semantics is due to the following text in Section 5.1 of the Rev 08 draft : "An initiator that can operate without security and with all the operational parameters taking the default values issues the Login with the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase. If the target is also ready to forego security and LoginOperationalNegotiation the Login response is empty and has T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase in the next stage." The conclusion from the above is that if the initiator sent in all defaults and some of these defaults are not acceptable to the target, it must respond with T bit set to 0 & NSG set to Operational. (Target is unable to accept defaults and needs to explicitly originate keys to notify the initiator that its defaults are unacceptable. Thus, target could not forego operational negotiation due to its inability to comply with the defaults and needs to respond with T=0.) > The > difference is that in the latter case the target can respond with a > different value for the parameter, whereas it cannot do so if the > parameter is omitted. Now, I'm not sure if we're saying the same thing :-} The target IS allowed to respond with a different value even when the initiator used defaults. However, since it did not forego operational negotiation, based on the above quoted text, one has to conclude that it is not allowed to change phase to FFP and must set T=0. > > I do not find this rule in the discussion of the login request and > response messages in the 0.8 spec. > > In any case, it seems strange and counterproductive to have such a > rule. The conventional meaning of "default" is that you can omit > stating the value of a parameter if its value is the default value, > but the effect is the same whether you supplied it or not. > > So I think the entire discussion can be cleared up with a simple > repair: allow the target to ask for a different value for a parameter > whether the parameter was omitted or not. > > (An alternative repair is to do away with the notion of default values > entirely, and require all parameters to be stated.) > > In any case, though, the spec needs to change, either to express the > rule Santosh referred to, or to express one of the repairs I > suggested. I think this login blob is all setup for inter-operability problems and needs to be REALLY simplified and clarified. For example, the above redundancy seems un-necessary and could be gotten rid of. The spec needs to explicitly clarify WHEN the target & initiator can explicitly change phases. -- ################################## 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 Mon Oct 1 15:38: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 PAA28627 for ; Mon, 1 Oct 2001 15:38:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91J01A20339 for ips-outgoing; Mon, 1 Oct 2001 15:00:01 -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 f91IxxP20334 for ; Mon, 1 Oct 2001 14:59:59 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 4948972F; Mon, 1 Oct 2001 11:59: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 LAA24840; Mon, 1 Oct 2001 11:59:54 -0700 (PDT) Message-ID: <3BB8BEC8.985D2033@cup.hp.com> Date: Mon, 01 Oct 2001 12:06:48 -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 : numerical negotiation wording is ambiguous References: <8C59010722BBD31194640050DA6EC6971B986C@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 do not believe your example is in line with the discussion. I'd rather you considered the case of an FC initiator that got back a PLOGI response with parameters that are not acceptable for that initiator. Do you expect the initiator to send a LS_RJT to the target ??? I would hope not :) The FC initiator would give up on that Nx_Port and move onto another one. Ditto for iSCSI. Either re-negotiate parameters, or close the TCP connection. REJECTs are only sent from targets to initiators. Regards, Santosh "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > Julian, Santosh, > > Here is what i have to say > > In either of the cases reject message is not needed if there is no double > check required. > > A reject is needed in both cases to allow some flexibility and i will give > you an example for this > > All SCSI devices today available have Sync options for more than 10MB/sec. > > Consider a chip designed which works fine for sync negotiation rate of > upto40MB/sec but misbehaves or behaves illegally for sync options less than > 10 MB/sec. In such case a device driver for such a chip will start > negotiating with the SCSI device for 40 MB/sec. If the SCSI device returns a > value of 8MB/sec then in this case the device driver must send a reject > message for sync negotiation. (although it is an illegal condition but it > still allows room for slightly misbehaving devices to operate properly in > Non-SYNC mode). This is my basis of saying that we must have a reject > message in both cases although it is strictly not required. > > Sanjeev > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Monday, October 01, 2001 8:38 PM > To: ips@ece.cmu.edu > Cc: Sanjeev Bhagat (TRIPACE/Zoetermeer); 'Julian Satran' > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > Julian & Sanjeev, > > Responding to both your mails...... > > Julian : > > I think you may have mis-interpreted my comments. I believe Sanjeev has > clarified the intent of my suggestions. > > I am *not* suggesting that the responder send back its values and these > be blindly imposed on the originator. On the contrary, my suggestion is > that the computation of the result of the negotiation (higher or lower > of the 2 values) be only performed by the responder and sent back to the > originator. > > The result of the negotiation is the same in both cases and there is no > REJECT required in my case nor yours. The difference is the advantages > I've stated in my model. > > Sanjeev, in response to your comment : > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. " > > There is NO need for any REJECT in the above case. If the initiator > is'nt satisfied with the value returned by the originator and cannot > function with the negotiated values, it can simply close the TCP > connection. There is no need to send any REJECT. > > 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 Mon Oct 1 15:38: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 PAA28639 for ; Mon, 1 Oct 2001 15:38:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91ImR719499 for ips-outgoing; Mon, 1 Oct 2001 14:48:27 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail07a.vwh1.net (mail07a.vwh1.net [209.238.9.57]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f91ImOP19493 for ; Mon, 1 Oct 2001 14:48:24 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail10.vwh1.net (RS ver 1.0.60s) with SMTP id 046881479; Mon, 1 Oct 2001 14:48:08 -0400 (EDT) From: "Dev - Platys" To: , "Robert Snively" , "'Julian Satran'" , Subject: RE: iscsi : iscsi parameter default values Date: Mon, 1 Oct 2001 11:54:24 -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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I posted it earlier on the wrong thread. Here it is. Thanks to Eddy for notifying me. I prefer that the default value for ImmediateData be set 'no'. This allows the initiators/targets, that support immediate data or not, to negotiate this value with minimal handshakes during login phase. I feel that discussions on the benefits of immediate data, complexity of implementing it etc, though useful, have gone off path, to determine what could be the default value. My vote is for the default value of 'Immediatedata' to be set as 'No'. Thanks Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Somesh Gupta Sent: Monday, October 01, 2001 10:09 AM To: Robert Snively; 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Julian, I agree with Robert on the complexity issue. I think the approach you tend to take is of a TCP accelerator with iSCSI in software. If you look at it from the perspective of zero copy adapters which do all iSCSI protocol processing, and combine that with the current buffer management scheme implemented by a number of arrays, immediate data/unsolicited data requires a significant change to the SCSI <-> SCSI transport API + the buffer management scheme in the array. The question is not of immediate vs unsolicited data. The question is of whether a targeted host buffer is ready to receive the data when it comes. My understanding is this is based on talking to only some of the array engineers. If your experience is specifically otherwise, it would be worthwhile sharing that. On the other hand, I think it would be worthwhile having a discussion on default values for all parameters. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Robert Snively > Sent: Saturday, September 29, 2001 10:48 PM > 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 Mon Oct 1 15: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 PAA28689 for ; Mon, 1 Oct 2001 15:40:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91IqdB19763 for ips-outgoing; Mon, 1 Oct 2001 14:52:39 -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 f91IqbP19758 for ; Mon, 1 Oct 2001 14:52:37 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id D73692E0; Mon, 1 Oct 2001 11:52: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 LAA24376; Mon, 1 Oct 2001 11:52:32 -0700 (PDT) Message-ID: <3BB8BD0E.7847A1@cup.hp.com> Date: Mon, 01 Oct 2001 11:59:27 -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 : 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 Julian, It would be more helpful to the discussion if you pointed out why you think the examples are incorrect, rather than your terse comment below :) Specifically, my example is based on the following text from Section 5.1 of Rev 08 draft which states : "An initiator that can operate without security and with all the operational parameters taking the default values issues the Login with the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase. If the target is also ready to forego security and LoginOperationalNegotiation the Login response is empty and has T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase in the next stage." I look forward to your clarification of the expected login handshakes in the scenarios I raised. Thanks, Santosh Julian Satran wrote: > > ... the debate would be of some interest if the examples where > correct. > > But unfortunately they are not. > > Julo > > Santosh Rao > To: ips@ece.cmu.edu > Sent by: owner-ips@ece.cmu.edu cc: > Subject: Re: iscsi : > 01-10-01 18:18 iscsi parameter default values > Please respond to Santosh Rao > > > All, > > As the one who started this thread, please allow me to raise one > important consideration to this discussion. > > This discussion has gone down the path of whether immediate data > boosts > performance and is implementable or whether it is so demanding that it > is not feasible to implement. > > I believe the decision on what the default value must assume for this > parameter must be based on what is going to be the simplest for the > login process and which setting minimizes the overheads involved for > completion of login. > > The reason for applying the above criteria is that it provides the > benefit of completing login negotiation in a single handshake and in > most cases, where initiator goes with the defaults, allows no > negotiation to be required whatsoever. [in the case where no security > is > being negotiated.]. This has the significant benefit of boosting iscsi > interoperability, since it has been seen that login is one of the most > painful areas of iscsi. > > With the above in mind, let us consider the 2 cases, Immediate data > default to "yes" & "no" (assuming neither side is interested in > security) : > > In the first case (default immediate data="yes') : > -------------------------------------------------- > - Initiator wishes to use immediate data. Target does not support it. > > I -> T : (no key is sent. default assumed for immediate data). > (CSG=Operational, NSG=FullFeaturePhase). T=1 > > T -> I : ImmediateData="no" (tgt does not support imm data.) > (CSG=Operational,NSG=Operational). T=0 > > I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1 > (no keys to negotiate. > negotiation completed at initiator. > only phase change taking place.) > > T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1 > (target completes phase change. > both sides move to FFP.) > > Thus, in the above model, there's an extra dummy login handshake, when > the default ImmediateData is "yes" but targets don't support it for > the > sole purpose of completing the login phase change. > > Now, take the case of default ImmediateData set to "no" : > --------------------------------------------------------- > - Initiator wants to use immediate data. target does not support it. > (same scenario as above). > > I -> T : ImmediateData="yes" > (CSG=Operational. NSG=FullFeaturePhase.). T=1 > > T -> I : ImmediateData="no" > (CSG=Operational. NSG=FullFeaturePhase). T=1 > > - Initiator does not want to use immediate data. > > I -> T : (no key is sent. defaults assumed). > (CSG=Operational. NSG=FullFeaturePhase). T=1 > > T -> I : (targets can accept all defaults since they > are conservative.) > (CSG=Operational, NSG=FullFeaturePhase). T=1 > > > Thus, as you can see from the above, the login process involves the > least number of exchanges when the default for ImmediateData is chosen > to be "no", as opposed to a default of "yes". > > It DOES NOT matter whether some believe ImmediateData is useful and > feasible or some believe it is useful but not feasible, or yet some > others believe it is not useful. > > What MUST govern this decision is which default allows for the > simplest > login operation. > > >From the above, it seems to me like a default of "no" for > ImmediateData > allows login to be completed in a single handshake in the case where > initiators wishes to use immediate data or not, and in the case where > target supports immediate data or not. > > Therefore, I request the group to please consider setting the > ImmediateData default to "no" and vote for the setting of "no". This > decision benefits BOTH the camp of immediate data users and non-users, > since both benefit from minimized steps in the login process. > > Thanks, > Santosh > > -------------------------------------------------------------------------- > > Robert Snively wrote: > > > > 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 > > > > -- ################################## 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 Mon Oct 1 15:41: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 PAA28726 for ; Mon, 1 Oct 2001 15:41:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91JIhB21651 for ips-outgoing; Mon, 1 Oct 2001 15:18:43 -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 f91JIfP21646 for ; Mon, 1 Oct 2001 15:18:41 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 21:20:36 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B986D@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" , "Sanjeev Bhagat (TRIPACE/Zoetermeer)" Cc: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Date: Mon, 1 Oct 2001 21:20:31 +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 Oke, i can accept this because a renogotiation still allows some room for flexibility where a little misbehaving devices can still work. So if we come to conclusion of this thread we dont need an reject message in both case and there should be a consensus call for the way of negotiation whether (initiator determined negotiation or responder determined) Sanjeev -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Monday, October 01, 2001 9:07 PM To: Sanjeev Bhagat (TRIPACE/Zoetermeer) Cc: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous Sanjeev, I do not believe your example is in line with the discussion. I'd rather you considered the case of an FC initiator that got back a PLOGI response with parameters that are not acceptable for that initiator. Do you expect the initiator to send a LS_RJT to the target ??? I would hope not :) The FC initiator would give up on that Nx_Port and move onto another one. Ditto for iSCSI. Either re-negotiate parameters, or close the TCP connection. REJECTs are only sent from targets to initiators. Regards, Santosh "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > Julian, Santosh, > > Here is what i have to say > > In either of the cases reject message is not needed if there is no double > check required. > > A reject is needed in both cases to allow some flexibility and i will give > you an example for this > > All SCSI devices today available have Sync options for more than 10MB/sec. > > Consider a chip designed which works fine for sync negotiation rate of > upto40MB/sec but misbehaves or behaves illegally for sync options less than > 10 MB/sec. In such case a device driver for such a chip will start > negotiating with the SCSI device for 40 MB/sec. If the SCSI device returns a > value of 8MB/sec then in this case the device driver must send a reject > message for sync negotiation. (although it is an illegal condition but it > still allows room for slightly misbehaving devices to operate properly in > Non-SYNC mode). This is my basis of saying that we must have a reject > message in both cases although it is strictly not required. > > Sanjeev > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Monday, October 01, 2001 8:38 PM > To: ips@ece.cmu.edu > Cc: Sanjeev Bhagat (TRIPACE/Zoetermeer); 'Julian Satran' > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > Julian & Sanjeev, > > Responding to both your mails...... > > Julian : > > I think you may have mis-interpreted my comments. I believe Sanjeev has > clarified the intent of my suggestions. > > I am *not* suggesting that the responder send back its values and these > be blindly imposed on the originator. On the contrary, my suggestion is > that the computation of the result of the negotiation (higher or lower > of the 2 values) be only performed by the responder and sent back to the > originator. > > The result of the negotiation is the same in both cases and there is no > REJECT required in my case nor yours. The difference is the advantages > I've stated in my model. > > Sanjeev, in response to your comment : > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. " > > There is NO need for any REJECT in the above case. If the initiator > is'nt satisfied with the value returned by the originator and cannot > function with the negotiated values, it can simply close the TCP > connection. There is no need to send any REJECT. > > 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 Mon Oct 1 16:05: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 QAA29264 for ; Mon, 1 Oct 2001 16:05:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91JNua22014 for ips-outgoing; Mon, 1 Oct 2001 15:23: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 f91JNpP22007 for ; Mon, 1 Oct 2001 15:23:51 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 21:25:46 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B986E@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Eddy Quicksall'" , ips@ece.cmu.edu Subject: RE: iscsi : default iscsi mode page settings - Consensus call Date: Mon, 1 Oct 2001 21:25:39 +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 vote for no as well. -----Original Message----- From: Eddy Quicksall [mailto:EQuicksall@mediaone.net] Sent: Monday, October 01, 2001 8:38 PM To: ips@ece.cmu.edu Subject: RE: iscsi : default iscsi mode page settings - Consensus call I vote NO. Eddy -----Original Message----- From: Dev - Platys [mailto:deva@platys.com] Sent: Monday, October 01, 2001 1:18 PM To: IPS Reflector Cc: deva@platys.com Subject: RE: iscsi : default iscsi mode page settings - Consensus call All, I prefer that the default value for ImmediateData be set 'no'. This allows the initiators/targets, that support immediate data or not, to negotiate this value with minimal handshakes during login phase. I feel that discussions on the benefits of immediate data, complexity of implementing it etc, though useful, have gone off path, to determine what could be the default value. My vote is for the default value of 'Immediatedata' to be set as 'No'. Thanks Deva Adaptec From owner-ips@ece.cmu.edu Mon Oct 1 16:16: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 QAA29511 for ; Mon, 1 Oct 2001 16:16:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91JaOc22877 for ips-outgoing; Mon, 1 Oct 2001 15:36:24 -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 f91JaMP22868 for ; Mon, 1 Oct 2001 15:36:22 -0400 (EDT) Received: (from mailgate@localhost) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id PAA13889 for ips@ece.cmu.edu; Mon, 1 Oct 2001 15:36:15 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkm-vty23.as.wcom.net [216.192.225.23]) by siaar1aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id PAA13840 for ; Mon, 1 Oct 2001 15:36:10 -0400 (EDT) Message-ID: <3BB8C6D0.62ADFD02@compuserve.com> Date: Mon, 01 Oct 2001 14:41:04 -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> <3BB7BE8D.2B9AB2EE@compuserve.com> <3BB88F92.C8B95E18@cup.hp.com> <3BB89169.7389EA14@compuserve.com> <3BB89E4A.EB882113@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 > Ralph Weber wrote: > > > > Santosh, > > > > I was not aware that you were proposing that iSCSI > > not support the Disconnect-Reconnect mode page at > > all. Now that would be a radical step. > > Ralph, > > The intent was that iscsi not specify any iscsi specific mode pages (as > Julian brought up a few days ago.). Could you please clarify why & how > would this be in violation of SPC-2 ... If the words "mode page" never appear in the iSCSI draft, then there is no problem with SPC-2. If the words "Disconnect-Reconnect mode page" and "SHALL NOT implement" appear too close to each other, then there is a problem. > In particular, commenting on the following clarifications that I > previously sought : > > Where in the SPC-2 definition is the application assured that : > > a) the disconnect-reconnect page code is required to be supported on all > targets. The Disconnect-Reconnect mode page is and should be allowed to be supported by any target. > b) all or any specific fields of the disconnect-reconnect field > definitions will be available to the application across all of the SCSI > transports. The only reason for not including fields in the protocol specific description of the Disconnect-Reconnect mode page is that said fields do not apply to that protocol. Neither of these prescriptions are written down since until now they have been obvious to all. Ralph Weber From owner-ips@ece.cmu.edu Mon Oct 1 16:16: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 QAA29523 for ; Mon, 1 Oct 2001 16:16:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91JZOS22799 for ips-outgoing; Mon, 1 Oct 2001 15:35: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 f91JZLP22792 for ; Mon, 1 Oct 2001 15:35: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 D2C101F508 for ; Mon, 1 Oct 2001 12:35: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 MAA26791; Mon, 1 Oct 2001 12:35:11 -0700 (PDT) Message-ID: <3BB8C70D.9FCE4F12@cup.hp.com> Date: Mon, 01 Oct 2001 12:42: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: IPS Reflector Subject: iscsi : originating & responding parties in login. 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've YET another login question for you : Please refer the following text in Section 2.2.4 of the Rev 08 draft : "For numerical negotiations, the responding party MUST respond with the required key." When the initiator uses the default settings for a login key (i.e. does not send the key) and a target does not support that default, it has to originate the key in its login response to notify the initiator that it does not support the default. In the above example, who is the originating party & responding party ? Is the initiator always considered an originating party for all the operational and security keys, even if it did not explicitly send that key in its login ? If the target originated a login key, say DataPDULength, (and is therefore, to be considered as the originating party ?), based on your rule quoted above, the exchange would be : I -> T : (no key is sent for DataPDULength. Assumes default of 16 units. (8K).) T -> I : DataPDULength=8 I -> T : DataPDULength=8 (See quoted rule above.) The definition of originating & responding party is not clear when defaults are used by the initiator and can lead to [mis- ?]interpretations such as the above. The above response from I -> T seems redundant to me. I suggest that the draft clearly state who the originating & responding party are when defaults are used, so as to avoid confusion along the above lines. 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 Mon Oct 1 16:16: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 QAA29536 for ; Mon, 1 Oct 2001 16:16:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91Jqo624016 for ips-outgoing; Mon, 1 Oct 2001 15:52: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 f91JqmP24010 for ; Mon, 1 Oct 2001 15:52:48 -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 PAA27218; Mon, 1 Oct 2001 15:50: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 f91Jqcx149808; Mon, 1 Oct 2001 13:52:38 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Immediate Data To: "Fischer, Michael" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 1 Oct 2001 12:51:48 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/01/2001 01:52:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mike, Defaults imply only that they are defaults, not that they are a required by an iSCSI profile. If you do not want to support a default, just say NO. iSCSI conformance is determined by the MUST statements in the protocol document. . . . 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 "Fischer, Michael" @ece.cmu.edu on 10/01/2001 11:02:49 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI: Immediate Data Well, here is my $.02 (overpriced as it may be). I agree that the performance of ImmediateData my be indisputable but as I have not seen any metrics or performed any tests on it myself I cannot say. I, however, do not think that it is as easy as just saying yes or no to the ImmediateData command. If you do not support the defaults, how can you claim to be a iSCSI device? Michael Fischer From owner-ips@ece.cmu.edu Mon Oct 1 16:17: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 QAA29555 for ; Mon, 1 Oct 2001 16:17:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91JikE23471 for ips-outgoing; Mon, 1 Oct 2001 15:44: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 f91JihP23460 for ; Mon, 1 Oct 2001 15:44: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 VAA48202 for ; Mon, 1 Oct 2001 21:44: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 f91JiZB26862 for ; Mon, 1 Oct 2001 21:44:35 +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: Mon, 1 Oct 2001 22:44:30 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/10/2001 22:44:35 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Ralph, That was the path and endlless-month mail exchange (with very little new argument in each round) has brought us. In summary: it was considered bad form to leave 2 layers (the layering argument) own (change) mode page variable we attempted to segregate the variables and argue that the burst-sizes are used by iSCSI but their values will be dictated by SCSI as they determine the multiplexing capabilities of the transport against this the argument was made that the mode page mechanism is hard to handle and a specific protocol has anyhow a mode page setup that is specific (that is not the current practice but is not explicitly forbidden by SPC) with all the above it makes little sense to support any mode page content (as SCSI can't control any value) My question is - would returning the mode pages with a read-only content make any-sense (considering that SCSI can't directly control the burst values and that is the only reason SCSI may want them)? The alternative would be (as I attempted) to leave both burst values under SCSI control (where layering will require them to be) against which a majority (of 2) brought the "very hard to handle" argument (which BTW has some ground as text mode negotiations are easier than the set/enquiry ) and reopen the consensus-call. Regards, Julo Ralph Weber serve.com> cc: Sent by: Subject: Re: iscsi : default iscsi mode page owner-ips@ece.cmu. settings - Consensus call edu 01-10-01 17:56 Please respond to ENDL_TX Santosh, I was not aware that you were proposing that iSCSI not support the Disconnect-Reconnect mode page at all. Now that would be a radical step. If on the other hand you are proposing that iSCSI have a Maximum Burst Size but refuse to provide that information in the Disconnect-Reconnect mode page whose page code iSCSI devices accept, then I think you are at least violating the ISP charter as regards interactions with T10 standards (specifically SPC-2). This is my rather strongly held opinion and unless you find an argument that is substantially better than anything presented to date I expect to maintain this opinion to the bitter end. Ralph Weber From owner-ips@ece.cmu.edu Mon Oct 1 16:17: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 QAA29591 for ; Mon, 1 Oct 2001 16:17:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91JnFO23746 for ips-outgoing; Mon, 1 Oct 2001 15:49:15 -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 f91JnCP23733 for ; Mon, 1 Oct 2001 15:49:13 -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 PAA66104; Mon, 1 Oct 2001 15:46:49 -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 f91JnAx226730; Mon, 1 Oct 2001 13:49:11 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Immediate Data To: "Eddy Quicksall" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 1 Oct 2001 12:48:19 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/01/2001 01:49:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, On a Disk Drive you are going to have probably less then 5 connections. You can not buy memory small enough to be a problem in that environment. Same is true with controllers with 50 connection capability. And by the way, in small environments, if you have to do a move, you will NOT notice the extra overhead. So ImmediateData=Yes is conservative for everyone. . . . 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" on 10/01/2001 05:58:59 AM To: John Hufferd/San Jose/IBM@IBMUS, cc: Subject: RE: iSCSI: Immediate Data John, I think you are missing the opposition's point. I don't think anyone is arguing that immediate data does not give a performance boost in most cases ... rather what should the default be? For me, I don't care because I support it. But for the others, I personally side with them because you are telling them that it is "easy" and for legacy cache code, it is probably not easy (for obvious reasons). I see a lot of "memory is cheep" but it seems like you are therefore saying "we'll only use iSCSI in heavy weight controllers". What about disk drives, don't we want iSCSI there too? What about bridge controllers? I think if you took a pole, you would find that most out there are not in the heavy weight arena that you are in. If we want iSCSI to be an overwhelming success, we need to make it easy to port existing code bases and just add a transport layer. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, October 01, 2001 12:05 AM To: ips@ece.cmu.edu Subject: iSCSI: Immediate Data I thought it would be useful to explain why I think that Immediate Data is important to iSCSI, so here it is: 1. Immediate Data permits the elimination of an additional network handshake/interaction. 2. This is important since some applications have a key sensitivity to Latency. The most important of these is Database. 3. Not only is Database sensitive to Latency, it generally has small I/O writes. 4. The hardware HBAs that many of you folks are building, include a TCP/IP Offload Engines (TOEs). This permits support of Gigabit Line speed without Server Load. However, even though many of you are attempting to parallelize as much of the TOE processing as possible, TCP/IP processing will still add latency to each iSCSI interaction, as compared to Fibre Channel. 5. If we want iSCSI to be performance competitive with Fibre Channel, we need to do something about the additional Latency left in the path even with HW HBAs. One important way to do this, is to simply eliminate the extra handshake that Fibre Channel uses on the small Writes. 6. Please note that this is not a big problem with large transfers, since the Latency is Amortized over more data. 7. So it is the Immediate Data feature of iSCSI that will make an important difference in the Key Response Time Sensitive Applications, which by luck only transfer a small amounts of data at a time. 8. When we attempt to let iSCSI shine on the "at-distance" storage environment, the value of Immediate Data, and Unsolicited Data are even more valuable. However, my concern at this time is for Immediate Data. Now the above is the reason that I think Immediate Data is key and important to the acceptance of iSCSI in the Enterprise Environment. And the following says why I think it is simple: A. Creating a Buffer Manager that can allocate buffers that are chained together, is kind of fundamental to the high performance environment we are attempting to work with. All the processes (whether iSCSI or SCSI) will allocate buffers (from the Buffer Manager), place data in one or more of these buffers, and pass the pointe list to the next process. There will be no copying of data. B. This works the same whether the data comes in with the command or separately. When it comes in with the command, the iSCSI process will request the Max buffers from the Buffer manager, and will be given one or more pointers to buffer elements. The Command and Data will be placed into one of more of the buffer segments, then the buffers that are filled, will be queued, in some manner, to the next iSCSI or SCSI Process. The unused buffer segments will be re-queued on the free queue. (I know I am telling you the obvious, but for some reason this message is not getting across.) C. Having every thing (including the data) arrive with the command, eliminates the code path overhead that is needed to collates data with commands. D. Since the only thing that is moved is pointers, it becomes a Zero Copy technique at its very core. E. The only thing that needs to be managed is the overall buffer space. And that needs to be managed anyway. The iSCSI Window management are the functions that are suppose to be used to control that. F. The issue of having enough memory is probably not a real world problem except at the very extremes. And you need to have the exact same code to manage the iSCSI Windows regardless of what caused the buffer space to run low. G. When a Storage Controller is expected to handle a large number of connections, the Storage Controller is expected to have a large pool of RAM storage, and when the Storage Controller is expected to handle only a small number of connections, it is hard not to have enough memory, since the price and availability of small RAMs is problematical. All the above, leads me to the belief that ImmediateData=yes, is the simplest, and most conservative option. And it solves the Latency issue with Enterprise Databases, thereby assuring the success of iSCSI in the Enterprise as well as the "at-distance" computing environment. . . . 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 Oct 1 16: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 PAA28652 for ; Mon, 1 Oct 2001 15:38:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91IjqI19249 for ips-outgoing; Mon, 1 Oct 2001 14:45: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 f91IjoP19245 for ; Mon, 1 Oct 2001 14:45:50 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 20:47:45 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B986C@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" , ips@ece.cmu.edu Cc: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , "'Julian Satran'" Subject: RE: iscsi : numerical negotiation wording is ambiguous Date: Mon, 1 Oct 2001 20:47:44 +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 Julian, Santosh, Here is what i have to say In either of the cases reject message is not needed if there is no double check required. A reject is needed in both cases to allow some flexibility and i will give you an example for this All SCSI devices today available have Sync options for more than 10MB/sec. Consider a chip designed which works fine for sync negotiation rate of upto40MB/sec but misbehaves or behaves illegally for sync options less than 10 MB/sec. In such case a device driver for such a chip will start negotiating with the SCSI device for 40 MB/sec. If the SCSI device returns a value of 8MB/sec then in this case the device driver must send a reject message for sync negotiation. (although it is an illegal condition but it still allows room for slightly misbehaving devices to operate properly in Non-SYNC mode). This is my basis of saying that we must have a reject message in both cases although it is strictly not required. Sanjeev -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Monday, October 01, 2001 8:38 PM To: ips@ece.cmu.edu Cc: Sanjeev Bhagat (TRIPACE/Zoetermeer); 'Julian Satran' Subject: Re: iscsi : numerical negotiation wording is ambiguous Julian & Sanjeev, Responding to both your mails...... Julian : I think you may have mis-interpreted my comments. I believe Sanjeev has clarified the intent of my suggestions. I am *not* suggesting that the responder send back its values and these be blindly imposed on the originator. On the contrary, my suggestion is that the computation of the result of the negotiation (higher or lower of the 2 values) be only performed by the responder and sent back to the originator. The result of the negotiation is the same in both cases and there is no REJECT required in my case nor yours. The difference is the advantages I've stated in my model. Sanjeev, in response to your comment : " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. " There is NO need for any REJECT in the above case. If the initiator is'nt satisfied with the value returned by the originator and cannot function with the negotiated values, it can simply close the TCP connection. There is no need to send any REJECT. Thanks, Santosh > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > Thanks Julian, please find my further comments in the message > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Sunday, September 30, 2001 6:07 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : numerical negotiation wording is > ambiguous > > 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 > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > say it this way the responder computes the value with > its own supported values and responds with a value y > which the responder thinks is correct 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 > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > but it is highly unlikely for the responder to reject > the final result because the rule states that (lower or > higher of two will be the result) and so the offering > party should be able to accept the lower or higher > range as defined by rule. In case the key is dependent > upon some range of fixed values then the negotiation > should be performed as list negotiation and not > numerical negotiation. > > This might be what you "conventionally" do - I don't > and that shows that convention like morals are a matter > of geography :-) > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > The advantage of this set of rules is that it allows an > external observer to know what was selected without > knowing the rules > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > case, I guess that the external observer has to know > the rules to double check the value is correct or not > 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. > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. > > > Sanjeev > "Sanjeev Bhagat > (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" > , Julian > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > 30-09-01 16:32 Subject: RE: iscsi : > Please respond to "Sanjeev numerical negotiation wording is > Bhagat (TRIPACE/Zoetermeer)" 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 > -- ################################## 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 Mon Oct 1 17:29: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 RAA01699 for ; Mon, 1 Oct 2001 17:29:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91L49o29158 for ips-outgoing; Mon, 1 Oct 2001 17:04:09 -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 f91KFhP25576 for ; Mon, 1 Oct 2001 16:15:43 -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 f91KGEx29481; Mon, 1 Oct 2001 16:16:14 -0400 (EDT) From: "Eddy Quicksall" To: "'John Hufferd'" Cc: Subject: RE: iSCSI: Immediate Data Date: Mon, 1 Oct 2001 16:15:23 -0400 Message-ID: <004201c14ab5$dad36e70$0102a8c0@eddylaptop> 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 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 Our product will support ImmdiateData. But I am writing all of the code from scratch so I don't have a problem. But for others porting existing code, I can see a problem. Mentioning memory below was probably a mis-guided point of mine as you have pointed out below. Thanks. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, October 01, 2001 3:48 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Immediate Data Eddy, On a Disk Drive you are going to have probably less then 5 connections. You can not buy memory small enough to be a problem in that environment. Same is true with controllers with 50 connection capability. And by the way, in small environments, if you have to do a move, you will NOT notice the extra overhead. So ImmediateData=Yes is conservative for everyone. . . . 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" on 10/01/2001 05:58:59 AM To: John Hufferd/San Jose/IBM@IBMUS, cc: Subject: RE: iSCSI: Immediate Data John, I think you are missing the opposition's point. I don't think anyone is arguing that immediate data does not give a performance boost in most cases ... rather what should the default be? For me, I don't care because I support it. But for the others, I personally side with them because you are telling them that it is "easy" and for legacy cache code, it is probably not easy (for obvious reasons). I see a lot of "memory is cheep" but it seems like you are therefore saying "we'll only use iSCSI in heavy weight controllers". What about disk drives, don't we want iSCSI there too? What about bridge controllers? I think if you took a pole, you would find that most out there are not in the heavy weight arena that you are in. If we want iSCSI to be an overwhelming success, we need to make it easy to port existing code bases and just add a transport layer. Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, October 01, 2001 12:05 AM To: ips@ece.cmu.edu Subject: iSCSI: Immediate Data I thought it would be useful to explain why I think that Immediate Data is important to iSCSI, so here it is: 1. Immediate Data permits the elimination of an additional network handshake/interaction. 2. This is important since some applications have a key sensitivity to Latency. The most important of these is Database. 3. Not only is Database sensitive to Latency, it generally has small I/O writes. 4. The hardware HBAs that many of you folks are building, include a TCP/IP Offload Engines (TOEs). This permits support of Gigabit Line speed without Server Load. However, even though many of you are attempting to parallelize as much of the TOE processing as possible, TCP/IP processing will still add latency to each iSCSI interaction, as compared to Fibre Channel. 5. If we want iSCSI to be performance competitive with Fibre Channel, we need to do something about the additional Latency left in the path even with HW HBAs. One important way to do this, is to simply eliminate the extra handshake that Fibre Channel uses on the small Writes. 6. Please note that this is not a big problem with large transfers, since the Latency is Amortized over more data. 7. So it is the Immediate Data feature of iSCSI that will make an important difference in the Key Response Time Sensitive Applications, which by luck only transfer a small amounts of data at a time. 8. When we attempt to let iSCSI shine on the "at-distance" storage environment, the value of Immediate Data, and Unsolicited Data are even more valuable. However, my concern at this time is for Immediate Data. Now the above is the reason that I think Immediate Data is key and important to the acceptance of iSCSI in the Enterprise Environment. And the following says why I think it is simple: A. Creating a Buffer Manager that can allocate buffers that are chained together, is kind of fundamental to the high performance environment we are attempting to work with. All the processes (whether iSCSI or SCSI) will allocate buffers (from the Buffer Manager), place data in one or more of these buffers, and pass the pointe list to the next process. There will be no copying of data. B. This works the same whether the data comes in with the command or separately. When it comes in with the command, the iSCSI process will request the Max buffers from the Buffer manager, and will be given one or more pointers to buffer elements. The Command and Data will be placed into one of more of the buffer segments, then the buffers that are filled, will be queued, in some manner, to the next iSCSI or SCSI Process. The unused buffer segments will be re-queued on the free queue. (I know I am telling you the obvious, but for some reason this message is not getting across.) C. Having every thing (including the data) arrive with the command, eliminates the code path overhead that is needed to collates data with commands. D. Since the only thing that is moved is pointers, it becomes a Zero Copy technique at its very core. E. The only thing that needs to be managed is the overall buffer space. And that needs to be managed anyway. The iSCSI Window management are the functions that are suppose to be used to control that. F. The issue of having enough memory is probably not a real world problem except at the very extremes. And you need to have the exact same code to manage the iSCSI Windows regardless of what caused the buffer space to run low. G. When a Storage Controller is expected to handle a large number of connections, the Storage Controller is expected to have a large pool of RAM storage, and when the Storage Controller is expected to handle only a small number of connections, it is hard not to have enough memory, since the price and availability of small RAMs is problematical. All the above, leads me to the belief that ImmediateData=yes, is the simplest, and most conservative option. And it solves the Latency issue with Enterprise Databases, thereby assuring the success of iSCSI in the Enterprise as well as the "at-distance" computing environment. . . . 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 Oct 1 17:30: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 RAA01721 for ; Mon, 1 Oct 2001 17:30:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91KSFs26464 for ips-outgoing; Mon, 1 Oct 2001 16:28: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 f91KSBP26457 for ; Mon, 1 Oct 2001 16:28:11 -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 WAA127082 for ; Mon, 1 Oct 2001 22:28: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.97.1) with ESMTP id f91KS4B105024 for ; Mon, 1 Oct 2001 22:28:04 +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: Mon, 1 Oct 2001 23:27:53 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 01/10/2001 23:28:04, Serialize complete at 01/10/2001 23:28:04 Content-Type: multipart/alternative; boundary="=_alternative 006E8553C2256AD8_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006E8553C2256AD8_= Content-Type: text/plain; charset="us-ascii" Santosh, We are getting nowhere. Even if requester is doing it's stuff - the requester will have to check and be prepared for a mistake. The coding will require a reject. Julo Santosh Rao Sent by: santoshr@cup.hp.com 01-10-01 20:37 Please respond to Santosh Rao To: ips@ece.cmu.edu cc: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , Julian Satran/Haifa/IBM@IBMIL Subject: Re: iscsi : numerical negotiation wording is ambiguous Julian & Sanjeev, Responding to both your mails...... Julian : I think you may have mis-interpreted my comments. I believe Sanjeev has clarified the intent of my suggestions. I am *not* suggesting that the responder send back its values and these be blindly imposed on the originator. On the contrary, my suggestion is that the computation of the result of the negotiation (higher or lower of the 2 values) be only performed by the responder and sent back to the originator. The result of the negotiation is the same in both cases and there is no REJECT required in my case nor yours. The difference is the advantages I've stated in my model. Sanjeev, in response to your comment : " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. " There is NO need for any REJECT in the above case. If the initiator is'nt satisfied with the value returned by the originator and cannot function with the negotiated values, it can simply close the TCP connection. There is no need to send any REJECT. Thanks, Santosh > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > Thanks Julian, please find my further comments in the message > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Sunday, September 30, 2001 6:07 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : numerical negotiation wording is > ambiguous > > 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 > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > say it this way the responder computes the value with > its own supported values and responds with a value y > which the responder thinks is correct 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 > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > but it is highly unlikely for the responder to reject > the final result because the rule states that (lower or > higher of two will be the result) and so the offering > party should be able to accept the lower or higher > range as defined by rule. In case the key is dependent > upon some range of fixed values then the negotiation > should be performed as list negotiation and not > numerical negotiation. > > This might be what you "conventionally" do - I don't > and that shows that convention like morals are a matter > of geography :-) > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > The advantage of this set of rules is that it allows an > external observer to know what was selected without > knowing the rules > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > case, I guess that the external observer has to know > the rules to double check the value is correct or not > 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. > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. > > > Sanjeev > "Sanjeev Bhagat > (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" > , Julian > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > 30-09-01 16:32 Subject: RE: iscsi : > Please respond to "Sanjeev numerical negotiation wording is > Bhagat (TRIPACE/Zoetermeer)" 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 > -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## --=_alternative 006E8553C2256AD8_= Content-Type: text/html; charset="us-ascii"
Santosh,

We are getting nowhere. Even if requester is doing it's stuff - the requester will have to check and be prepared for a mistake. The coding will require a reject.

Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@cup.hp.com

01-10-01 20:37
Please respond to Santosh Rao

       
        To:        ips@ece.cmu.edu
        cc:        "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>, Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iscsi : numerical negotiation wording is ambiguous

       


Julian & Sanjeev,

Responding to both your mails......

Julian :

I think you may have mis-interpreted my comments. I believe Sanjeev has
clarified the intent of my suggestions.

I am *not* suggesting that the responder send back its values and these
be blindly imposed on the originator. On the contrary, my suggestion is
that the computation of the result of the negotiation (higher or lower
of the 2 values) be only performed by the responder and sent back to the
originator.

The result of the negotiation is the same in both cases and there is no
REJECT required in my case nor yours. The difference is the advantages
I've stated in my model.


Sanjeev, in response to your comment :

" [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
>  no reject , but it can be a problem in future .
>  Consider your example of DataPDULength in your own
>  message. Suppose offering party sends a value of 16,384
>  (this is also lowest value it can send) and responding
>  party responds with 8,192. In this case the offering
>  party will have to reject the negotiation. So a reject
>  message is needed in this case also. "


There is NO need for any REJECT in the above case. If the initiator
is'nt satisfied with the value returned by the originator and cannot
function with the negotiated values, it can simply close the TCP
connection. There is no need to send any REJECT.


Thanks,
Santosh


> "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
>
> Thanks Julian, please find my further comments in the message
>
>      -----Original Message-----
>      From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>      Sent: Sunday, September 30, 2001 6:07 PM
>      To: ips@ece.cmu.edu
>      Subject: RE: iscsi : numerical negotiation wording is
>      ambiguous
>
>      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
>           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather
>           say it this way the responder computes the value with
>           its own supported values and responds with a value y
>           which the responder thinks is correct 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
>           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct,
>           but it is highly unlikely for the responder to reject
>           the final result because the rule states that (lower or
>           higher of two will be the result) and so the offering
>           party should be able to accept the lower or higher
>           range as defined by rule. In case the key is dependent
>           upon some range of fixed values then the negotiation
>           should be performed as list negotiation and not
>           numerical negotiation.
>
>           This might be what you "conventionally" do - I don't
>           and that shows that convention like morals are a matter
>           of geography :-)
>           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-)
>
>           The advantage of this set of rules is that it allows an
>           external observer to know what was selected without
>           knowing the rules
>           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this
>           case, I guess that the external observer has to know
>           the rules to double check the value is correct or not
>           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.
>           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
>           no reject , but it can be a problem in future .
>           Consider your example of DataPDULength in your own
>           message. Suppose offering party sends a value of 16,384
>           (this is also lowest value it can send) and responding
>           party responds with 8,192. In this case the offering
>           party will have to reject the negotiation. So a reject
>           message is needed in this case also.
>
>
>      Sanjeev
>       "Sanjeev Bhagat
>       (TRIPACE/Zoetermeer)"                    To:        "'Santosh Rao'"
>       <sbhagat@tripace.com>            <santoshr@cup.hp.com>, Julian
>       Sent by: owner-ips@ece.cmu.edu   Satran/Haifa/IBM@IBMIL
>                                                cc:        ips@ece.cmu.edu
>       30-09-01 16:32                           Subject:        RE: iscsi :
>       Please respond to "Sanjeev       numerical negotiation wording is
>       Bhagat (TRIPACE/Zoetermeer)"     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
>


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

--=_alternative 006E8553C2256AD8_=-- From owner-ips@ece.cmu.edu Mon Oct 1 17:35: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 RAA01840 for ; Mon, 1 Oct 2001 17:35:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91LBL329711 for ips-outgoing; Mon, 1 Oct 2001 17:11:21 -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 f91LB5P29682 for ; Mon, 1 Oct 2001 17:11:05 -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 f91LBbx16473 for ; Mon, 1 Oct 2001 17:11:37 -0400 (EDT) From: "Eddy Quicksall" To: Subject: RE: iscsi : iscsi parameter default values Date: Mon, 1 Oct 2001 17:11:05 -0400 Message-ID: <004a01c14abd$96fe09f0$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 Looking at this from another view point ... Isn't support of R2T required anyway because the Expected Data Transfer Length may exceed the FirstBurstSize? So, wouldn't that make "no" the "lowest common denominator"? If so, I would think that "no" would therefore be the default. Just food for thought. Eddy -----Original Message----- From: Dev - Platys [mailto:deva@platys.com] Sent: Monday, October 01, 2001 2:54 PM To: somesh_gupta@silverbacksystems.com; Robert Snively; 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Folks, I posted it earlier on the wrong thread. Here it is. Thanks to Eddy for notifying me. I prefer that the default value for ImmediateData be set 'no'. This allows the initiators/targets, that support immediate data or not, to negotiate this value with minimal handshakes during login phase. I feel that discussions on the benefits of immediate data, complexity of implementing it etc, though useful, have gone off path, to determine what could be the default value. My vote is for the default value of 'Immediatedata' to be set as 'No'. Thanks Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Somesh Gupta Sent: Monday, October 01, 2001 10:09 AM To: Robert Snively; 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Julian, I agree with Robert on the complexity issue. I think the approach you tend to take is of a TCP accelerator with iSCSI in software. If you look at it from the perspective of zero copy adapters which do all iSCSI protocol processing, and combine that with the current buffer management scheme implemented by a number of arrays, immediate data/unsolicited data requires a significant change to the SCSI <-> SCSI transport API + the buffer management scheme in the array. The question is not of immediate vs unsolicited data. The question is of whether a targeted host buffer is ready to receive the data when it comes. My understanding is this is based on talking to only some of the array engineers. If your experience is specifically otherwise, it would be worthwhile sharing that. On the other hand, I think it would be worthwhile having a discussion on default values for all parameters. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Robert Snively > Sent: Saturday, September 29, 2001 10:48 PM > 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 Mon Oct 1 18:21: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 SAA03166 for ; Mon, 1 Oct 2001 18:21:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91M1Ww03236 for ips-outgoing; Mon, 1 Oct 2001 18:01:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail07a.vwh1.net (mail07a.vwh1.net [209.238.9.57]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f91M1UP03231 for ; Mon, 1 Oct 2001 18:01:30 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail10.vwh1.net (RS ver 1.0.60s) with SMTP id 046334538; Mon, 1 Oct 2001 18:01:06 -0400 (EDT) From: "Dev - Platys" To: "Santosh Rao" , "IPS Reflector" Subject: RE: iscsi : originating & responding parties in login. Date: Mon, 1 Oct 2001 15:07:24 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3BB8C70D.9FCE4F12@cup.hp.com> X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, My thinking is that in this case, the initiator will be the originator (implicitily negotiating for the default value for DataPDULength). Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Santosh Rao Sent: Monday, October 01, 2001 12:42 PM To: IPS Reflector Subject: iscsi : originating & responding parties in login. Julian, I've YET another login question for you : Please refer the following text in Section 2.2.4 of the Rev 08 draft : "For numerical negotiations, the responding party MUST respond with the required key." When the initiator uses the default settings for a login key (i.e. does not send the key) and a target does not support that default, it has to originate the key in its login response to notify the initiator that it does not support the default. In the above example, who is the originating party & responding party ? Is the initiator always considered an originating party for all the operational and security keys, even if it did not explicitly send that key in its login ? If the target originated a login key, say DataPDULength, (and is therefore, to be considered as the originating party ?), based on your rule quoted above, the exchange would be : I -> T : (no key is sent for DataPDULength. Assumes default of 16 units. (8K).) T -> I : DataPDULength=8 I -> T : DataPDULength=8 (See quoted rule above.) The definition of originating & responding party is not clear when defaults are used by the initiator and can lead to [mis- ?]interpretations such as the above. The above response from I -> T seems redundant to me. I suggest that the draft clearly state who the originating & responding party are when defaults are used, so as to avoid confusion along the above lines. 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 Mon Oct 1 18:22: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 SAA03231 for ; Mon, 1 Oct 2001 18:22:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91LjD202266 for ips-outgoing; Mon, 1 Oct 2001 17:45:13 -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 f91LjBP02262 for ; Mon, 1 Oct 2001 17:45:11 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id D2C3B852; Mon, 1 Oct 2001 14:45: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 OAA08738; Mon, 1 Oct 2001 14:45:06 -0700 (PDT) Message-ID: <3BB8E581.4C566B57@cup.hp.com> Date: Mon, 01 Oct 2001 14:52: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: Julian Satran , 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, It does appear that we are getting nowhere with this discussion :<. I would like to re-iterate the advantages of the "responder computes negotiation result" model vs. the "both sides compute negotiation result" model again : 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. The originator only needs to only check that the response it got back is acceptable. Standard parsing technique in mass storage. (ex : FC PLOGI, FC PRLI, SCSI Mode Sense parsing by initiator uses the same scheme.) 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. 6) Less protocol rules to be enforced. No need to call out the rules for each side explicitly. The responder picks the result & sends it back to originator. Clearly, at least 3 developers read the draft to imply the negotiation scheme in use is "responder picks the negotiation result". So, there is room for mis-interpretation here. Based on the above advantages, I feel it is a safer model, with no room for mis-interpretations. In addition, it aids debugging & involves less code. Lastly, I suggest that the draft call out explicitly that the initiator is ALWAYS the originating party and the target is ALWAYS the responding party for ALL security and operational keys. This is due to each key having either a default value(in case initiator chose to use the default and not send the key), or the key is mandated to be sent by initiator. Thanks, Santosh Julian Satran wrote: > > Santosh, > > We are getting nowhere. Even if requester is doing it's stuff - the > requester will have to check and be prepared for a mistake. The coding > will require a reject. > > Julo > > Santosh Rao > To: ips@ece.cmu.edu > Sent by: santoshr@cup.hp.com cc: "Sanjeev Bhagat > (TRIPACE/Zoetermeer)" > 01-10-01 20:37 , Julian > Please respond to Santosh Rao Satran/Haifa/IBM@IBMIL > Subject: Re: iscsi : > numerical negotiation wording is > ambiguous > > > > Julian & Sanjeev, > > Responding to both your mails...... > > Julian : > > I think you may have mis-interpreted my comments. I believe Sanjeev > has > clarified the intent of my suggestions. > > I am *not* suggesting that the responder send back its values and > these > be blindly imposed on the originator. On the contrary, my suggestion > is > that the computation of the result of the negotiation (higher or lower > of the 2 values) be only performed by the responder and sent back to > the > originator. > > The result of the negotiation is the same in both cases and there is > no > REJECT required in my case nor yours. The difference is the advantages > I've stated in my model. > > Sanjeev, in response to your comment : > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. " > > There is NO need for any REJECT in the above case. If the initiator > is'nt satisfied with the value returned by the originator and cannot > function with the negotiated values, it can simply close the TCP > connection. There is no need to send any REJECT. > > Thanks, > Santosh > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Thanks Julian, please find my further comments in the message > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Sunday, September 30, 2001 6:07 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : numerical negotiation wording is > > ambiguous > > > > 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > say it this way the responder computes the value with > > its own supported values and responds with a value y > > which the responder thinks is correct 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > but it is highly unlikely for the responder to reject > > the final result because the rule states that (lower or > > higher of two will be the result) and so the offering > > party should be able to accept the lower or higher > > range as defined by rule. In case the key is dependent > > upon some range of fixed values then the negotiation > > should be performed as list negotiation and not > > numerical negotiation. > > > > This might be what you "conventionally" do - I don't > > and that shows that convention like morals are a matter > > of geography :-) > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > The advantage of this set of rules is that it allows an > > external observer to know what was selected without > > knowing the rules > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > case, I guess that the external observer has to know > > the rules to double check the value is correct or not > > 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. > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. > > > > > > Sanjeev > > "Sanjeev Bhagat > > (TRIPACE/Zoetermeer)" To: "'Santosh > Rao'" > > , Julian > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > cc: > ips@ece.cmu.edu > > 30-09-01 16:32 Subject: RE: > iscsi : > > Please respond to "Sanjeev numerical negotiation wording > is > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > -- > ################################## > 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 Mon Oct 1 18:25: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 SAA03344 for ; Mon, 1 Oct 2001 18:25:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91LVDd01354 for ips-outgoing; Mon, 1 Oct 2001 17:31:13 -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 f91LVBP01348 for ; Mon, 1 Oct 2001 17:31:11 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 14:31:05 -0700 Message-ID: From: Charles Monia To: "'IPS Reflector'" , T10@t10.org Subject: RE: iSCSI:Request/Response Ordering Date: Mon, 1 Oct 2001 14:30: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 Ed's note is correct in the main, I believe the behavior specified in SAM is not the only determinant of ordering behavior. Strictly speaking, the ordering guarantees should also be a function of the device model. For example, the streaming device model may require that simple commands from a single initiator be processed in the order received. I don't know if this consideration is reflected in the device-dependent SCSI specs. Charles > -----Original Message----- > From: Edward A. Gardner [mailto:eag@ophidian.com] > Sent: Saturday, September 29, 2001 8:16 PM > To: Sanjeev Bhagat (TRIPACE/Zoetermeer); 'IPS Reflector'; T10@t10.org > Subject: Re: iSCSI:Request/Response Ordering > > > * From the T10 Reflector (t10@t10.org), posted by: > * "Edward A. Gardner" > * > 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 > > > > * > * 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 Oct 1 18:26: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 SAA03362 for ; Mon, 1 Oct 2001 18:26:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91Leb802024 for ips-outgoing; Mon, 1 Oct 2001 17:40:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail07a.vwh1.net (mail07a.vwh1.net [209.238.9.57]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f91LeYP02015 for ; Mon, 1 Oct 2001 17:40:34 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail10.vwh1.net (RS ver 1.0.60s) with SMTP id 046709805; Mon, 1 Oct 2001 17:40:02 -0400 (EDT) From: "Dev - Platys" To: "Julian Satran" , Subject: RE: iscsi : numerical negotiation wording is ambiguous Date: Mon, 1 Oct 2001 14:46:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C14A87.D587C610" 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.6600 In-Reply-To: X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C14A87.D587C610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Julian, I am not sure why a 'REJECT' is required. Can you please explain why is this required? I am with Santosh in this. >There is NO need for any REJECT in the above >case. If the initiator >is'nt satisfied with the value returned by the >originator and cannot >function with the negotiated values, it can simply >close the TCP >connection. There is no need to send any >REJECT. Thanks Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Monday, October 01, 2001 1:28 PM To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous Santosh, We are getting nowhere. Even if requester is doing it's stuff - the requester will have to check and be prepared for a mistake. The coding will require a reject. Julo Santosh Rao Sent by: santoshr@cup.hp.com 01-10-01 20:37 Please respond to Santosh Rao To: ips@ece.cmu.edu cc: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , Julian Satran/Haifa/IBM@IBMIL Subject: Re: iscsi : numerical negotiation wording is ambiguous Julian & Sanjeev, Responding to both your mails...... Julian : I think you may have mis-interpreted my comments. I believe Sanjeev has clarified the intent of my suggestions. I am *not* suggesting that the responder send back its values and these be blindly imposed on the originator. On the contrary, my suggestion is that the computation of the result of the negotiation (higher or lower of the 2 values) be only performed by the responder and sent back to the originator. The result of the negotiation is the same in both cases and there is no REJECT required in my case nor yours. The difference is the advantages I've stated in my model. Sanjeev, in response to your comment : " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. " There is NO need for any REJECT in the above case. If the initiator is'nt satisfied with the value returned by the originator and cannot function with the negotiated values, it can simply close the TCP connection. There is no need to send any REJECT. Thanks, Santosh > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > Thanks Julian, please find my further comments in the message > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Sunday, September 30, 2001 6:07 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : numerical negotiation wording is > ambiguous > > 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 > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > say it this way the responder computes the value with > its own supported values and responds with a value y > which the responder thinks is correct 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 > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > but it is highly unlikely for the responder to reject > the final result because the rule states that (lower or > higher of two will be the result) and so the offering > party should be able to accept the lower or higher > range as defined by rule. In case the key is dependent > upon some range of fixed values then the negotiation > should be performed as list negotiation and not > numerical negotiation. > > This might be what you "conventionally" do - I don't > and that shows that convention like morals are a matter > of geography :-) > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > The advantage of this set of rules is that it allows an > external observer to know what was selected without > knowing the rules > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > case, I guess that the external observer has to know > the rules to double check the value is correct or not > 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. > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. > > > Sanjeev > "Sanjeev Bhagat > (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" > , Julian > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > 30-09-01 16:32 Subject: RE: iscsi : > Please respond to "Sanjeev numerical negotiation wording is > Bhagat (TRIPACE/Zoetermeer)" 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 > -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## ------=_NextPart_000_0002_01C14A87.D587C610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Julian,
 
I am=20 not sure why a 'REJECT' is required.
Can=20 you please explain why is this required?
 
I am=20 with Santosh in this.
 
>There is NO need for any REJECT in the = above=20 >case. If the initiator
>is'nt satisfied with the value = returned by the=20 >originator and cannot
>function with the negotiated values, it = can=20 simply >close the TCP
>connection. There is no need to send any = >REJECT.

Thanks
 
Deva
Adaptec

 
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Monday, October 01, 2001 1:28 PM
To:=20 ips@ece.cmu.edu
Subject: Re: iscsi : numerical negotiation = wording=20 is ambiguous


Santosh,

We = are getting=20 nowhere. Even if requester is doing it's stuff - the requester will = have to=20 check and be prepared for a mistake. The coding will require a = reject.=20

Julo


Santosh Rao=20 <santoshr@cup.hp.com>
Sent by: santoshr@cup.hp.com=20

01-10-01 20:37 =
Please respond to Santosh Rao =

        =
        To: =    =20    ips@ece.cmu.edu
        cc:      =20  "Sanjeev Bhagat (TRIPACE/Zoetermeer)" = <sbhagat@tripace.com>,=20 Julian Satran/Haifa/IBM@IBMIL
        Subject:     =  =20  Re: iscsi : numerical negotiation wording is = ambiguous=20

     =20  


Julian & Sanjeev,

Responding to both your=20 mails......

Julian :

I think you may have = mis-interpreted my=20 comments. I believe Sanjeev has
clarified the intent of my = suggestions.=20

I am *not* suggesting that the responder send back its values = and=20 these
be blindly imposed on the originator. On the contrary, my = suggestion=20 is
that the computation of the result of the negotiation (higher or = lower
of the 2 values) be only performed by the responder and sent = back to=20 the
originator.

The result of the negotiation is the same in = both=20 cases and there is no
REJECT required in my case nor yours. The = difference=20 is the advantages
I've stated in my model.


Sanjeev, in = response=20 to your comment :

" [Sanjeev Bhagat (TRIPACE/Zoetermeer)] = Although=20 there is
>  no reject , but it can be a problem in future = .
>=20  Consider your example of DataPDULength in your own
>=20  message. Suppose offering party sends a value of 16,384
>=20  (this is also lowest value it can send) and responding
>=20  party responds with 8,192. In this case the offering
> =  party=20 will have to reject the negotiation. So a reject
>  message = is=20 needed in this case also. "


There is NO need for any REJECT = in the=20 above case. If the initiator
is'nt satisfied with the value = returned by the=20 originator and cannot
function with the negotiated values, it can = simply=20 close the TCP
connection. There is no need to send any=20 REJECT.


Thanks,
Santosh


> "Sanjeev Bhagat=20 (TRIPACE/Zoetermeer)" wrote:
>
> Thanks Julian, please = find my=20 further comments in the message
>
>    =20  -----Original Message-----
>      From: = Julian=20 Satran [mailto:Julian_Satran@il.ibm.com]
>     =  Sent:=20 Sunday, September 30, 2001 6:07 PM
>      To:=20 ips@ece.cmu.edu
>      Subject: RE: iscsi : = numerical=20 negotiation wording is
>      ambiguous
> =
>=20      Sanjeev,
>
>      I am = not=20 sure clear I made the tiny diference between what I
>   =  =20  say and what Santosh said:
>
>     =  Santosh=20 says:
>
>        1. a requester sends = A=3Dvaluex
>        2. a responder sends=20 B=3Dvaluey
>        3. the responder assumes = that the=20 value y is the correct
>           = value and so=20 does an external observer
>           = [Sanjeev=20 Bhagat (TRIPACE/Zoetermeer)] I would rather
>     =  =20     say it this way the responder computes the value = with
>=20           its own supported values and = responds with=20 a value y
>           which the = responder=20 thinks is correct and so does an
>         =  =20 external observer
>        4. the requester = checks=20 that valuey is conformant (he will
>         =  =20 not believe it) and will reject it if not conformant
>   =  =20       else it will accept it
>     =  =20     [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although = correct,
>=20           but it is highly unlikely for the = responder=20 to reject
>           the final result = because=20 the rule states that (lower or
>         =  =20 higher of two will be the result) and so the offering
>   =  =20       party should be able to accept the lower or=20 higher
>           range as defined by = rule. In=20 case the key is dependent
>           = upon some=20 range of fixed values then the negotiation
>     =    =20   should be performed as list negotiation and not =
>           = numerical=20 negotiation.
>
>           This = might be=20 what you "conventionally" do - I don't
>       =  =20   and that shows that convention like morals are a matter
> =  =20         of geography :-)
>     =  =20     [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-)
> =
>=20           The advantage of this set of rules = is that=20 it allows an
>           external = observer to=20 know what was selected without
>         =  =20 knowing the rules
>           [Sanjeev = Bhagat=20 (TRIPACE/Zoetermeer)] Even in this
>         =  =20 case, I guess that the external observer has to know
>   =  =20       the rules to double check the value is correct or = not
>           The disadvantage is = that=20 messages have to be "built",
>         =   an=20 additional reject states exists and MOST IMPORTANT
>   =  =20       you need both messages
>
>   =  =20       In what I said:
>
>     =  =20     1. The requester sends A=3Dvaluex
>     =  =20     2. The Responder has to send either nothing (if = valuex
>=20           is enough on both sides to compute = the=20 result like in
>           the case in = which=20 the function is a Boolean AND and the
>       =  =20   value is NO) or valuey
>         =   3.=20 Both the requestor and responder have to compute the
>   =  =20       value (they have to know the rules anyhow) and so = does
>           the external = observer
>=20
>           The disadvantage is that = the=20 external observer has to
>           = know the=20 rules
>           The advantage is that = there=20 is no reject, in binary
>          =20 negotiations you can go away with shorter negotiations
>   =  =20       and you can set strings at fixed values.
> =  =20         [Sanjeev Bhagat (TRIPACE/Zoetermeer)] = Although=20 there is
>           no reject , but it = can be=20 a problem in future .
>           = Consider your=20 example of DataPDULength in your own
>       =  =20   message. Suppose offering party sends a value of 16,384
> =  =20         (this is also lowest value it can send) = and=20 responding
>           party responds = with=20 8,192. In this case the offering
>         =  =20 party will have to reject the negotiation. So a reject
>   =  =20       message is needed in this case also.
> =
>=20
>      Sanjeev
>       = "Sanjeev=20 Bhagat
>       (TRIPACE/Zoetermeer)"   =    =20              To:     =  =20  "'Santosh Rao'"
>       = <sbhagat@tripace.com>=20            <santoshr@cup.hp.com>,=20 Julian
>       Sent by: owner-ips@ece.cmu.edu =  =20 Satran/Haifa/IBM@IBMIL
>           =  =20                     =  =20              cc:     =  =20  ips@ece.cmu.edu
>       30-09-01 16:32 =  =20                     =  =20   Subject:        RE: iscsi :
>   =  =20   Please respond to "Sanjeev       numerical = negotiation=20 wording is
>       Bhagat (TRIPACE/Zoetermeer)" =  =20   ambiguous
>
>
>
>    =20  All,
>
>      I agree with Santosh = that the=20 responding party must respond
>      the result=20 of
>      the negotiation as compared with the = value from=20 offering
>      party. All
>    =20  negotiations in SCSI like (sync, disconnect etc) are = also
>  =20    done the same way.
>      I also = object to=20 Julian's reason of a simple minded target
>     =  which=20 wants to
>      send certain fixed values only. = In case a=20 simple minded
>      target identifies a
> =  =20    value which it cannot support or is less than the value = a
>=20      target can
>      support, = then there=20 should be a method for target to reject
>     =  such=20 a
>      negotiation and the default values be = accepted=20 on both side
>      as a result of
>   =  =20  negotiation.
>
>      1 Because even = if=20 simple minded target sends its fixed value
>     =  which=20 is
>      greater than the value sent by offering = party=20 then the final
>      result of
>   =  =20  negotiation will be taken as ( lesser of the two) and in
> =  =20    this case target
>      which which = cannot=20 support the lower value will produce some
>    =20  illegal
>      results.
>
> =  =20    2. if simple minded target wants to send its own value=20 and
>      wants it to be
>    =20  accpeted then the responding party is not negotiating = but
>  =20    forcing the result
>      on = initiator(this=20 method should not be allowed unless
>     =  explicitly=20 mentioned).
>
>      however if there is = another=20 proposal of numeric negotiation
>      in which=20 the
>      responding party can force its result = to be=20 over ridden by
>      the offering
>   =  =20  party's result then it is acceptable for offering party = and
>=20      responding party
>      to = send there=20 own supported key-value result and it can then
>     =  be=20 computed at
>      offering party's end.
> =
>=20      IMP: (May be I am missing something here) I do not = see how=20 a
>      numeric
>     =  negotiation=20 can be rejected. Is it possible to reject such
>    =20  kind of
>      negotiaion?
>
> =  =20    Sanjeev
>
>     =  -----Original=20 Message-----
>      From: Santosh Rao=20 [mailto:santoshr@cup.hp.com]
>      Sent: Friday, = September 28, 2001 11:15 PM
>      To: Julian=20 Satran
>      Cc: ips@ece.cmu.edu
>   =  =20  Subject: Re: iscsi : numerical negotiation wording is
> =  =20    ambiguous
>
>      Julian = &=20 All,
>
>      I request the group to take = a close=20 look at this negotiation
>      process
> =  =20    again and [re-]evaluate the alternative being = proposed.
>=20
>      Further, it appears that the login stage=20 negotiation  is
>      also = following
>  =20    the same algorithm as the login key negotiation, = wherein
>=20      originator &
>     =  responder=20 offer their respective values and both sides need
>   =  =20  to determine
>      the result of the = negotiation.=20 i.e. both initiator and
>      target need = to
>=20      compare their NSG with the other party's NSG and = pick=20 the
>      lower of the
>    =20  2.
>
>      I suggest that both the = login=20 key negotiation and the login
>     =  stage
>  =20    negotiation follow the policy that the originator offers=20 a
>      value and the
>    =20  responder picks the result of the negotiation based on = (the
>=20      offered
>      value & = its own=20 value). The value picked by the responder is
>     =  sent=20 back
>      to the originator.
>
> =  =20    This model has the following advantages :
> =
>  =20    1) Only one side picks the result of the negotiaton.=20 Hence,
>      the 2 sides
>    =20  cannot go out of sync on the value picked.
>
> =  =20    2) The originator knows the negotiated result at the = the
>=20      responder since
>      the = responder=20 sends back the result of the negotiation.
>
>   =  =20  3) This model is easier to debug because of (1) & = (2).
>=20
>      4) Less code since only 1 party = (responder) needs=20 to perform
>      the
>    =20  computation to pick the result of the negotiation.
> =
>=20      5) This scheme leaves less room for interop = problems=20 and
>      mis-interpretation since it is the = more=20 familiar negotiation
>      technique
> =  =20    that is in use in most other mass storage protocols. (ex=20 :
>      FC PLOGI, FC
>     =  PRLI,=20 etc). From a first reading of the current negotiation
>   =  =20  scheme, it
>      is'nt readily apparent = that the=20 currently defined model is
>     =  different
>=20      from the above and requires both sides to be = picking=20 the
>      result of the
>    =20  negotiation, instead of just the responder.
>
> =  =20    Comments ?
>
>     =  Thanks,
>=20      Santosh
>


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


------=_NextPart_000_0002_01C14A87.D587C610-- From owner-ips@ece.cmu.edu Mon Oct 1 18:26: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 SAA03373 for ; Mon, 1 Oct 2001 18:26:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91LY2k01586 for ips-outgoing; Mon, 1 Oct 2001 17:34:02 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail07a.vwh1.net (mail07a.vwh1.net [209.238.9.57]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f91LXxP01581 for ; Mon, 1 Oct 2001 17:33:59 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail10.vwh1.net (RS ver 1.0.60s) with SMTP id 045517938; Mon, 1 Oct 2001 17:33:40 -0400 (EDT) From: "Dev - Platys" To: "Eddy Quicksall" , Subject: RE: iscsi : iscsi parameter default values Date: Mon, 1 Oct 2001 14:39:57 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <004a01c14abd$96fe09f0$0102a8c0@eddylaptop> X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thats a good point. Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, October 01, 2001 2:11 PM To: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Looking at this from another view point ... Isn't support of R2T required anyway because the Expected Data Transfer Length may exceed the FirstBurstSize? So, wouldn't that make "no" the "lowest common denominator"? If so, I would think that "no" would therefore be the default. Just food for thought. Eddy -----Original Message----- From: Dev - Platys [mailto:deva@platys.com] Sent: Monday, October 01, 2001 2:54 PM To: somesh_gupta@silverbacksystems.com; Robert Snively; 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Folks, I posted it earlier on the wrong thread. Here it is. Thanks to Eddy for notifying me. I prefer that the default value for ImmediateData be set 'no'. This allows the initiators/targets, that support immediate data or not, to negotiate this value with minimal handshakes during login phase. I feel that discussions on the benefits of immediate data, complexity of implementing it etc, though useful, have gone off path, to determine what could be the default value. My vote is for the default value of 'Immediatedata' to be set as 'No'. Thanks Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Somesh Gupta Sent: Monday, October 01, 2001 10:09 AM To: Robert Snively; 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Julian, I agree with Robert on the complexity issue. I think the approach you tend to take is of a TCP accelerator with iSCSI in software. If you look at it from the perspective of zero copy adapters which do all iSCSI protocol processing, and combine that with the current buffer management scheme implemented by a number of arrays, immediate data/unsolicited data requires a significant change to the SCSI <-> SCSI transport API + the buffer management scheme in the array. The question is not of immediate vs unsolicited data. The question is of whether a targeted host buffer is ready to receive the data when it comes. My understanding is this is based on talking to only some of the array engineers. If your experience is specifically otherwise, it would be worthwhile sharing that. On the other hand, I think it would be worthwhile having a discussion on default values for all parameters. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Robert Snively > Sent: Saturday, September 29, 2001 10:48 PM > 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 Mon Oct 1 18:27: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 SAA03426 for ; Mon, 1 Oct 2001 18:27:47 -0400 (EDT) From: owner-ips@ece.cmu.edu Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91LvHN02969 for ips-outgoing; Mon, 1 Oct 2001 17:57:17 -0400 (EDT) Date: Mon, 1 Oct 2001 17:57:17 -0400 (EDT) Message-Id: <200110012157.f91LvHN02969@ece.cmu.edu> X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f [24.147.1.156]) >> by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f91LPVP00897 >> for ; Mon, 1 Oct 2001 17:25:31 -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 f91LQ4x07306 >> for ; Mon, 1 Oct 2001 17:26:04 -0400 (EDT) >> From: "Eddy Quicksall" >> To: >> Subject: test via reply >> Date: Mon, 1 Oct 2001 17:25:22 -0400 >> Message-ID: <004e01c14abf$9a3d92a0$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: >> >> Directed to Dave at IPS for a test. >> >> Eddy Sender: owner-ips@ece.cmu.edu Precedence: bulk From owner-ips@ece.cmu.edu Mon Oct 1 19: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 TAA03935 for ; Mon, 1 Oct 2001 19:04:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91MJJs04335 for ips-outgoing; Mon, 1 Oct 2001 18:19:19 -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 f91MJIP04331 for ; Mon, 1 Oct 2001 18:19:18 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Oct 2001 18:19:13 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD7F0@CORPMX14> From: Black_David@emc.com To: santoshr@cup.hp.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISID issue Date: Mon, 1 Oct 2001 18:11: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 Santosh Rao wrote: > I think comparisions to FC's mess-up of the node WWN are not fair to the > current ISID rule, since, unlike in FC, the worst case scenario with the > ISID rule, is that each iscsi driver on the system will take up a > different iscsi initiator name. At least FC had the Port WWN to fall back on. This is headed for a situation where the iSCSI Initiator Name is unusable for access control configuration because whether it corresponds to the network interface, the HBA (e.g., suppose there are two interfaces on the HBA), the driver, or the OS image is implementation-dependent. In FC it is completely unambiguous what the Port WWN corresponds to, and that's why it's usually used for LUN masking and mapping solutions. We're at risk of screwing that up, e.g. ... > Given that all iscsi HBA vendors will need to have SOME host O.S. driver > component which they will be writing, it is possible for them to hand > out ISIDs to their adapters within their own driver domain. The ISID > rule works fine as long as ISIDs are ditributed within the domain of > each iscsi driver and since, the number of iscsi drivers supported on an > O.S. are'nt going to be that large, I think, this is'nt as big an issue > as FC's node name problems.(which scales linearly with the number of > HBAs, not the number of drivers). Actually it's worse because there isn't a single Initiator Name convention. The only out I can see here is LUN masking/mapping configurations based on IP addresses. Simple stupid rules that ensure that everything works the same way every time are necessary to make this sort of access control mechanism useful (otherwise it will get misconfigured by a harried admin who doesn't have the time to appreciate the subtlety of our discussions). Jim Hafner wrote: > First, the T10 folks are trying to come up with "additional and optional > features" that would move in the diretion you're saying. That is partly to > make the wedge-driver's job easier. But that doesn't mean that iSCSI can > ignore the current defined and well-understood model. We have to live with > the current model AND see how what we do might affect (enable or prevent > enabling) the new features. > > Having the target provide the SSID, in my mind, will prevent the new > features from being made available. I worry that we're already in trouble with the new features. In Parallel SCSI or Fibre Channel, ports are hardware entities and exhaustive connection setup results in every Initiator Port being connected to every possible Target Port, and the reservation spanning works, in part because things like Unix /dev names are used to encode which Initiator port was used. At least as iSCSI currently stands, we're not in that situation because ISID usage is implementation-dependent - if an Initiator chooses to never reuse an ISID across all of its connections to all Target Ports, the result is no reservation sharing. That's permissible as things currently stand and "will prevent the new features from being made available". If I follow Jim's line of reasoning, I think the result is "SHOULD use the same ISID values to connect to different Targets and Target Portal Groups" as a recommendation for boot and setup behavior so that the Ports behave in the same fashion as existing SCSI Ports - one can then rebuild existing structures (e.g., /dev names in Unix) on that base. That seems like a change from what's been discussed - in essence, one or a few ISIDs would get configured into each iSCSI implementation and all of them would be exhaustively connected to every validly accessible (where "validly" is meant to encompass discovery scope restrictions) Target Portal Group on boot. How many current implementations are doing or anticipate doing that? How many current implementations intend to set up multiple sessions (initially or for error recovery) to the same Target Portal Group and hence need more than one ISID? One alternative would be to eliminate the ISID as a carrier of the Initiator Port Name and assign that to a text key, which splits the issues of how to provide support for this to be created reservation functionality from lower level functional issues in the iSCSI protocol. FWIW, Jim is right to observe that this is a consequence of multi-connection sessions that span hardware interfaces. SAM's world view is that a Port is a hardware interface and hence some sort of hardware interface identifier can be used to name it. Sessions that span hardware interfaces cause the SCSI Initiator Port to become a software entity and are at the root of this. Sessions with multiple connections but restricted to a hardware interface do not cause issues - to a first approximation Fibre Channel does this already via multiple concurrent exchanges within a single N_Port to N_Port session. This is another alternative - if iSCSI Ports were hardware ports, we'd be guaranteed to line up well with T10, but that would be a major change. --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 Oct 1 19:05: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 TAA04006 for ; Mon, 1 Oct 2001 19:05:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91Mhgh05814 for ips-outgoing; Mon, 1 Oct 2001 18:43:42 -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 f91MhdP05810 for ; Mon, 1 Oct 2001 18:43: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 SAA26728; Mon, 1 Oct 2001 18:41:10 -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 f91MhVx204674; Mon, 1 Oct 2001 16:43:31 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iscsi : iscsi parameter default values To: Santosh Rao Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 1 Oct 2001 15:42:38 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/01/2001 04:43:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I think your logic reverses if the support wanted is yes and the target is supporting yes. If they say No they clearly do not care about extra handshakes sense R2T is all they have and it requires extra handshakes. . . . 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 10/01/2001 09:18:23 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: iscsi : iscsi parameter default values All, As the one who started this thread, please allow me to raise one important consideration to this discussion. This discussion has gone down the path of whether immediate data boosts performance and is implementable or whether it is so demanding that it is not feasible to implement. I believe the decision on what the default value must assume for this parameter must be based on what is going to be the simplest for the login process and which setting minimizes the overheads involved for completion of login. The reason for applying the above criteria is that it provides the benefit of completing login negotiation in a single handshake and in most cases, where initiator goes with the defaults, allows no negotiation to be required whatsoever. [in the case where no security is being negotiated.]. This has the significant benefit of boosting iscsi interoperability, since it has been seen that login is one of the most painful areas of iscsi. With the above in mind, let us consider the 2 cases, Immediate data default to "yes" & "no" (assuming neither side is interested in security) : In the first case (default immediate data="yes') : -------------------------------------------------- - Initiator wishes to use immediate data. Target does not support it. I -> T : (no key is sent. default assumed for immediate data). (CSG=Operational, NSG=FullFeaturePhase). T=1 T -> I : ImmediateData="no" (tgt does not support imm data.) (CSG=Operational,NSG=Operational). T=0 I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1 (no keys to negotiate. negotiation completed at initiator. only phase change taking place.) T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1 (target completes phase change. both sides move to FFP.) Thus, in the above model, there's an extra dummy login handshake, when the default ImmediateData is "yes" but targets don't support it for the sole purpose of completing the login phase change. Now, take the case of default ImmediateData set to "no" : --------------------------------------------------------- - Initiator wants to use immediate data. target does not support it. (same scenario as above). I -> T : ImmediateData="yes" (CSG=Operational. NSG=FullFeaturePhase.). T=1 T -> I : ImmediateData="no" (CSG=Operational. NSG=FullFeaturePhase). T=1 - Initiator does not want to use immediate data. I -> T : (no key is sent. defaults assumed). (CSG=Operational. NSG=FullFeaturePhase). T=1 T -> I : (targets can accept all defaults since they are conservative.) (CSG=Operational, NSG=FullFeaturePhase). T=1 Thus, as you can see from the above, the login process involves the least number of exchanges when the default for ImmediateData is chosen to be "no", as opposed to a default of "yes". It DOES NOT matter whether some believe ImmediateData is useful and feasible or some believe it is useful but not feasible, or yet some others believe it is not useful. What MUST govern this decision is which default allows for the simplest login operation. From the above, it seems to me like a default of "no" for ImmediateData allows login to be completed in a single handshake in the case where initiators wishes to use immediate data or not, and in the case where target supports immediate data or not. Therefore, I request the group to please consider setting the ImmediateData default to "no" and vote for the setting of "no". This decision benefits BOTH the camp of immediate data users and non-users, since both benefit from minimized steps in the login process. Thanks, Santosh -------------------------------------------------------------------------- Robert Snively wrote: > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- ################################## 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 Mon Oct 1 19:06: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 TAA04025 for ; Mon, 1 Oct 2001 19:06:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91MXwN05279 for ips-outgoing; Mon, 1 Oct 2001 18:33:58 -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 f91MXsP05274 for ; Mon, 1 Oct 2001 18:33: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 SAA63574; Mon, 1 Oct 2001 18:31: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 f91MXqx90964; Mon, 1 Oct 2001 16:33:52 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iscsi : iscsi parameter default values To: "Dev - Platys" Cc: "Eddy Quicksall" , X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 1 Oct 2001 15:33:01 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/01/2001 04:33:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk You will need the same type of Immediate Data handling code to handle the Login. The Login Parameters are in the extended Data Section of the PDU. So you have to have that code anyway. Given that you have to have the code anyway, in both cases ImmediateData=Yes and No -- Yes is the simplest, the best performing, and the lowest overhead, so Yes should be the default. . . . 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 "Dev - Platys" @ece.cmu.edu on 10/01/2001 02:39:57 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , cc: Subject: RE: iscsi : iscsi parameter default values Thats a good point. Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, October 01, 2001 2:11 PM To: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Looking at this from another view point ... Isn't support of R2T required anyway because the Expected Data Transfer Length may exceed the FirstBurstSize? So, wouldn't that make "no" the "lowest common denominator"? If so, I would think that "no" would therefore be the default. Just food for thought. Eddy -----Original Message----- From: Dev - Platys [mailto:deva@platys.com] Sent: Monday, October 01, 2001 2:54 PM To: somesh_gupta@silverbacksystems.com; Robert Snively; 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Folks, I posted it earlier on the wrong thread. Here it is. Thanks to Eddy for notifying me. I prefer that the default value for ImmediateData be set 'no'. This allows the initiators/targets, that support immediate data or not, to negotiate this value with minimal handshakes during login phase. I feel that discussions on the benefits of immediate data, complexity of implementing it etc, though useful, have gone off path, to determine what could be the default value. My vote is for the default value of 'Immediatedata' to be set as 'No'. Thanks Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Somesh Gupta Sent: Monday, October 01, 2001 10:09 AM To: Robert Snively; 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Julian, I agree with Robert on the complexity issue. I think the approach you tend to take is of a TCP accelerator with iSCSI in software. If you look at it from the perspective of zero copy adapters which do all iSCSI protocol processing, and combine that with the current buffer management scheme implemented by a number of arrays, immediate data/unsolicited data requires a significant change to the SCSI <-> SCSI transport API + the buffer management scheme in the array. The question is not of immediate vs unsolicited data. The question is of whether a targeted host buffer is ready to receive the data when it comes. My understanding is this is based on talking to only some of the array engineers. If your experience is specifically otherwise, it would be worthwhile sharing that. On the other hand, I think it would be worthwhile having a discussion on default values for all parameters. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Robert Snively > Sent: Saturday, September 29, 2001 10:48 PM > 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 Mon Oct 1 19:12: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 TAA04223 for ; Mon, 1 Oct 2001 19:12:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91MZbU05368 for ips-outgoing; Mon, 1 Oct 2001 18:35:37 -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 f91MZaP05364 for ; Mon, 1 Oct 2001 18:35:36 -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 49AB634B for ; Mon, 1 Oct 2001 16:35:35 -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 C3C064F6 for ; Mon, 1 Oct 2001 16:35:34 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id PAA04223 for ips@ece.cmu.edu; Mon, 1 Oct 2001 15:34:35 -0700 (PDT) From: Dave Sheehy Message-Id: <200110012234.PAA04223@acropora.rose.agilent.com> Subject: RE: iscsi : iscsi parameter default values To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Mon, 01 Oct 2001 15:34:34 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, > 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. I just want to point out that the data is NOT required to be in an immediately following PDU. There can be any number (up to MaxCmdSN) of intervening non-data PDUs between the command and data. Dave From owner-ips@ece.cmu.edu Mon Oct 1 19:56: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 TAA04997 for ; Mon, 1 Oct 2001 19:56:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f91N8xD07338 for ips-outgoing; Mon, 1 Oct 2001 19:08:59 -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 f91N8uP07332 for ; Mon, 1 Oct 2001 19:08: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 DE57858C; Mon, 1 Oct 2001 16:08: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 QAA18334; Mon, 1 Oct 2001 16:08:49 -0700 (PDT) Message-ID: <3BB8F91F.5C53AF77@cup.hp.com> Date: Mon, 01 Oct 2001 16:15: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: John Hufferd 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 John Hufferd wrote: > > I think your logic reverses if the support wanted is yes and the target is > supporting yes. How so ? Here are the scenarios when initiator wants to use immediate data and target supports it, first with default ImmediateData set to "yes" and then, with default Immediatedata set to "no". In both cases, a single login handshake occurs. The only difference being that when ImmediateData defaults to "yes", the key need not be sent in either direction, whereas when it defaults to no, the ImmediateData key travels in both directions in the login payload. (FFP = FullFeaturePhase). Default ImmediateData="yes" --------------------------- Initator wants immediate data & targets supports it. ---------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 Default ImmediateData="no" -------------------------- Initiator wants immediate data and target supports it. ----------------------------------------------------------- I -> T : ImmediateData="yes" (CSG=Operational, NSG=FFP). T=1 T -> I : Immediatedata="yes" (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) Same number of handshakes in both cases. The only difference is that the key is not sent in the first case, and key is explicitly exchanged in the 2nd case. > If they say No they clearly do not care about extra handshakes sense R2T is > all they have and it requires extra handshakes. Hmm.... The way I see it, an initiator that does not use ImmediateData is a simple initiator and is more interested in seeing a simpler login (completed in a single login req/rsp) than one that does support ImmediateData. Those implementations that can do the extra work of supporting ImmediateData can well do the extra work of negotiating for its use. Regards, Santosh > Santosh Rao @ece.cmu.edu on 10/01/2001 09:18:23 AM > > Sent by: owner-ips@ece.cmu.edu > > To: ips@ece.cmu.edu > cc: > Subject: Re: iscsi : iscsi parameter default values > > All, > > As the one who started this thread, please allow me to raise one > important consideration to this discussion. > > This discussion has gone down the path of whether immediate data boosts > performance and is implementable or whether it is so demanding that it > is not feasible to implement. > > I believe the decision on what the default value must assume for this > parameter must be based on what is going to be the simplest for the > login process and which setting minimizes the overheads involved for > completion of login. > > The reason for applying the above criteria is that it provides the > benefit of completing login negotiation in a single handshake and in > most cases, where initiator goes with the defaults, allows no > negotiation to be required whatsoever. [in the case where no security is > being negotiated.]. This has the significant benefit of boosting iscsi > interoperability, since it has been seen that login is one of the most > painful areas of iscsi. > > With the above in mind, let us consider the 2 cases, Immediate data > default to "yes" & "no" (assuming neither side is interested in > security) : > > In the first case (default immediate data="yes') : > -------------------------------------------------- > - Initiator wishes to use immediate data. Target does not support it. > > I -> T : (no key is sent. default assumed for immediate data). > (CSG=Operational, NSG=FullFeaturePhase). T=1 > > T -> I : ImmediateData="no" (tgt does not support imm data.) > (CSG=Operational,NSG=Operational). T=0 > > I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1 > (no keys to negotiate. > negotiation completed at initiator. > only phase change taking place.) > > T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1 > (target completes phase change. > both sides move to FFP.) > > Thus, in the above model, there's an extra dummy login handshake, when > the default ImmediateData is "yes" but targets don't support it for the > sole purpose of completing the login phase change. > > Now, take the case of default ImmediateData set to "no" : > --------------------------------------------------------- > - Initiator wants to use immediate data. target does not support it. > (same scenario as above). > > I -> T : ImmediateData="yes" > (CSG=Operational. NSG=FullFeaturePhase.). T=1 > > T -> I : ImmediateData="no" > (CSG=Operational. NSG=FullFeaturePhase). T=1 > > - Initiator does not want to use immediate data. > > I -> T : (no key is sent. defaults assumed). > (CSG=Operational. NSG=FullFeaturePhase). T=1 > > T -> I : (targets can accept all defaults since they > are conservative.) > (CSG=Operational, NSG=FullFeaturePhase). T=1 > > Thus, as you can see from the above, the login process involves the > least number of exchanges when the default for ImmediateData is chosen > to be "no", as opposed to a default of "yes". > > It DOES NOT matter whether some believe ImmediateData is useful and > feasible or some believe it is useful but not feasible, or yet some > others believe it is not useful. > > What MUST govern this decision is which default allows for the simplest > login operation. > > >From the above, it seems to me like a default of "no" for ImmediateData > allows login to be completed in a single handshake in the case where > initiators wishes to use immediate data or not, and in the case where > target supports immediate data or not. > > Therefore, I request the group to please consider setting the > ImmediateData default to "no" and vote for the setting of "no". This > decision benefits BOTH the camp of immediate data users and non-users, > since both benefit from minimized steps in the login process. > > Thanks, > Santosh > > -------------------------------------------------------------------------- > > Robert Snively wrote: > > > > 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 -- ################################## 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 Tue Oct 2 08:24: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 IAA06587 for ; Tue, 2 Oct 2001 08:24:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92BZxj24379 for ips-outgoing; Tue, 2 Oct 2001 07:35:59 -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 f92B2XP22752 for ; Tue, 2 Oct 2001 07:02:33 -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 HAA03232; Tue, 2 Oct 2001 07:02:29 -0400 (EDT) Message-Id: <200110021102.HAA03232@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-08.txt Date: Tue, 02 Oct 2001 07:02: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 : iSCSI Author(s) : J. Satran et al. Filename : draft-ietf-ips-iscsi-08.txt Pages : 211 Date : 01-Oct-01 The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This memo describes a transport protocol for SCSI that operates on top of TCP. The iSCSI protocol aims to be fully compliant with the requirements laid out in the SCSI Architecture Model - 2 [SAM2] document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-08.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-iscsi-08.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-08.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: <20011001112731.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-iscsi-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-iscsi-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011001112731.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Oct 2 08:29: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 IAA06807 for ; Tue, 2 Oct 2001 08:29:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92BZqs24364 for ips-outgoing; Tue, 2 Oct 2001 07:35:52 -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 f92B2RP22741 for ; Tue, 2 Oct 2001 07:02:28 -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 HAA03216; Tue, 2 Oct 2001 07:02:24 -0400 (EDT) Message-Id: <200110021102.HAA03216@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-security-01.txt Date: Tue, 02 Oct 2001 07:02:23 -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 : Securing iSCSI, iFCP and FCIP Author(s) : B. Aboba et al. Filename : draft-ietf-ips-security-01.txt Pages : 48 Date : 01-Oct-01 This document discusses how iSCSI and iFCP may utilize IPsec to provide authentication, integrity, confidentiality and replay protection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-01.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-security-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-security-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: <20011001112720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011001112720.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Oct 2 10:47: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 KAA14651 for ; Tue, 2 Oct 2001 10:47:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92DnC401900 for ips-outgoing; Tue, 2 Oct 2001 09:49:12 -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 f92DnAP01895 for ; Tue, 2 Oct 2001 09:49:10 -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 f92DngT12005; Tue, 2 Oct 2001 09:49:42 -0400 (EDT) From: "Eddy Quicksall" To: "'John Hufferd'" , "'Dev - Platys'" Cc: Subject: RE: iscsi : iscsi parameter default values Date: Tue, 2 Oct 2001 09:48:57 -0400 Message-ID: <002701c14b49$0545a270$0102a8c0@eddylaptop> 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 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 First, realize I just want to give information as I see it from an objective standpoint. Regarding your reply below, login is not cached so the "immediate data" techniques used there are quite different then the techniques used during full feature phase in legacy cache. In another mail, I explained why some legacy cache implementations would have to be changed and cache is probably the last thing you would want to change if you are in a "time to market" crunch. Remember, this is not in the transport layer. The thing we should probably be looking at is "what requires the least number of round trips and are the round trips really significant". Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, October 01, 2001 6:33 PM To: Dev - Platys Cc: Eddy Quicksall; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values You will need the same type of Immediate Data handling code to handle the Login. The Login Parameters are in the extended Data Section of the PDU. So you have to have that code anyway. Given that you have to have the code anyway, in both cases ImmediateData=Yes and No -- Yes is the simplest, the best performing, and the lowest overhead, so Yes should be the default. . . . 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 "Dev - Platys" @ece.cmu.edu on 10/01/2001 02:39:57 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , cc: Subject: RE: iscsi : iscsi parameter default values Thats a good point. Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, October 01, 2001 2:11 PM To: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Looking at this from another view point ... Isn't support of R2T required anyway because the Expected Data Transfer Length may exceed the FirstBurstSize? So, wouldn't that make "no" the "lowest common denominator"? If so, I would think that "no" would therefore be the default. Just food for thought. Eddy From owner-ips@ece.cmu.edu Tue Oct 2 13:04: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 NAA21271 for ; Tue, 2 Oct 2001 13:04:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92GfOR15073 for ips-outgoing; Tue, 2 Oct 2001 12:41: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 f92GfLP15066 for ; Tue, 2 Oct 2001 12:41: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 60FEF1F827; Tue, 2 Oct 2001 09:41: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 JAA28506; Tue, 2 Oct 2001 09:41:07 -0700 (PDT) Message-ID: <3BB9EFC4.860D9897@cup.hp.com> Date: Tue, 02 Oct 2001 09:48: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: Eddy Quicksall Cc: "'John Hufferd'" , ips@ece.cmu.edu Subject: Re: iscsi : iscsi parameter default values References: <001601c14b5c$74c0ee80$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 Eddy, My comments inline. Thanks, Santosh Eddy Quicksall wrote: > > Would all cases look like these? (If I made a mistake, please correct it). > > Note that I am attempting to use the rule specified as: > > The negotiation MAY > proceed only up to the point where both parties can unequivocally > compute the result; continuing beyond this point is OPTIONAL. > > And my interpretation of the rule is that when a responder gets a binary > value, it can compare that against the default and can therefore compute the > result and therefore does not need to respond if the result is what he > wants. > > Am I correct in my interpretation? > > Eddy > > Default ImmediateData="yes" > =========================== > Initiator wants immediate data & target supports it. > --------------------------------------------------- > > I -> T : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > T -> I : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > yes * yes = yes Correct. > > Initiator does not want immediate data & target supports it. > ----------------------------------------------------------- > > I -> T : ImmediateData="no". > (CSG=Operational, NSG=FFP). T=1 > > T -> I : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > no * yes = no Correct. > > Initiator wants immediate data & target does not support it. > ----------------------------------------------------------- > > I -> T : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > T -> I : ImmediateData="no". > (CSG=Operational, NSG=FFP). T=1 > > yes * no = no IMO, the above is in violation of the below rule found in Section 5.1 : "An initiator that can operate without security and with all the operational parameters taking the default values issues the Login with the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase. If the target is also ready to forego security and LoginOperationalNegotiation the Login response is empty and has T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase in the next stage. " Thus, when a target cannot accept the defaults, it must float its own values for the keys and in this case, it cannot perform a phase change, [since it did not forego operational negotiation.] Hence, per the current draft wording, I believe the above case would be : > I -> T : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > T -> I : ImmediateData="no". > (CSG=Operational, NSG=Operational). T=0 I -> T : (no key sent) (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 > > yes * no = no However, I do believe the above rule is flawed and should be modified. A target must be allowed to perform a phase change any time it has no more operational keys to negotiate and this should apply regardless of whether defaults are sent or keys are explicitly sent. This should not be dependent on whether the target had to forego operational negotiation, whether it sent an empty login response or sent keys back , etc. > > Initiator does not want immediate data & does not target support it. > ------------------------------------------------------------------- > > I -> T : ImmediateData="no". > (CSG=Operational, NSG=FFP). T=1 > > T -> I : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > no * yes = no Correct. > > Default ImmediateData="no" > ========================== > Initiator wants immediate data & target supports it. > ----------------------------------------------------------- > > I -> T : ImmediateData="yes" > (CSG=Operational, NSG=FFP). T=1 > > T -> I : (no key sent). > (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) > > yes * no = no If the target supports immediate data it would send back a key indicating the same. Thus, the above should be : I -> T : ImmediateData="yes" (CSG=Operational, NSG=FFP). T=1 T -> I : ImmediateData="yes" CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) yes * yes = yes Note the difference in the target's phase change since in this case, all key exchanges were explicit and the above "flawed" rule did not apply. I suggest we make the modification suggested to the rule to enforce more consistent target behaviour. > > Initiator does not want immediate data & target supports it. > -------------------------------------------------------------- > > I -> T : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > T -> I : (no key sent) > (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) > > no * no = no Correct. > Initiator wants immediate data & target does not support it. > ----------------------------------------------------------- > > I -> T : ImmediateData="yes". > (CSG=Operational, NSG=FFP). T=1 > > T -> I : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > yes * no = no Correct. > > Initiator does not want immediate data & does not target support it. > ------------------------------------------------------------------- > > I -> T : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > T -> I : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > no * no = no Correct. On a seperate note, I believe the following changes are required in the login process : 1) All these rules about both sides having to compute the result of the negotiation are complicating the login procedure. Why not just follow the standard practice of letting the target pick the negotiation result and send it back in its response ? This allows for several advantages like less code (only 1 side computing the result), ease of debugging (target state is known to initiator), etc. 2) (1) also simplifies the case where responder silently drops a key instead of responding to each key that was sent. I think a response from the target for each key sent by the initiator is more explicit and simpler. 3) The draft should state that the initiator is the originator and the target is the responder for ALL security and operational keys. (either due to the use of defaults or mandated keys). > > Eddy > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Monday, October 01, 2001 7:16 PM > To: John Hufferd > Cc: ips@ece.cmu.edu > Subject: Re: iscsi : iscsi parameter default values > > John Hufferd wrote: > > > > I think your logic reverses if the support wanted is yes and the > target is > > supporting yes. > > How so ? > > Here are the scenarios when initiator wants to use immediate data and > target supports it, first with default ImmediateData set to "yes" and > then, with default Immediatedata set to "no". In both cases, a single > login handshake occurs. The only difference being that when > ImmediateData defaults to "yes", the key need not be sent in either > direction, whereas when it defaults to no, the ImmediateData key travels > in both directions in the login payload. > > (FFP = FullFeaturePhase). > > Default ImmediateData="yes" > --------------------------- > Initator wants immediate data & targets supports it. > ---------------------------------------------------- > > I -> T : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > T -> I : (no key sent). > (CSG=Operational, NSG=FFP). T=1 > > Default ImmediateData="no" > -------------------------- > Initiator wants immediate data and target supports it. > ----------------------------------------------------------- > > I -> T : ImmediateData="yes" > (CSG=Operational, NSG=FFP). T=1 > > T -> I : Immediatedata="yes" > (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) > > Same number of handshakes in both cases. The only difference is that the > key is not sent in the first case, and key is explicitly exchanged in > the 2nd case. > > > If they say No they clearly do not care about extra handshakes sense > R2T is > > all they have and it requires extra handshakes. > > Hmm.... The way I see it, an initiator that does not use ImmediateData > is a simple initiator and is more interested in seeing a simpler login > (completed in a single login req/rsp) than one that does support > ImmediateData. > > Those implementations that can do the extra work of supporting > ImmediateData can well do the extra work of negotiating for its use. > > 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 Tue Oct 2 13:05: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 NAA21284 for ; Tue, 2 Oct 2001 13:05:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92GG1r13159 for ips-outgoing; Tue, 2 Oct 2001 12:16:01 -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 f92FaRP10539 for ; Tue, 2 Oct 2001 11:36: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 IAA16006 for ; Tue, 2 Oct 2001 08:36:20 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 08:36:19 -0700 Message-ID: From: Robert Snively To: ips@ece.cmu.edu Subject: RE: iSCSI : default iSCSI mode page settings - Consensus call Date: Tue, 2 Oct 2001 08:36:18 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, In an offline discussion, we have picked at a thread central to this fabric. That is basically the view that one has of the structure of targets. ------------------ Note sent out a day ago --------------- Traditional network environments talk from one big host memory to another big host memory. In the storage space, the memory in the target is actually distributed between whatever caching and preprocessing space the target platform may have and the space held by each logical unit. In some cases (RAIDs) the distribution is heavily in favor of the target platform cache. In others (tapes), individual logical units may have 100s of Megabytes of buffering which are not available to other logical units. If you have mixed types of logical units or if you have the memory distributed unevenly among the logical units, different values are normal among different LUs. Different sessions to the same LU may also have different properties. In particular, the LU may give away resources freely for the first few sessions, but more sparingly for subsequent sessions. Alternatively, the LU may share the resources dynamically, providing UNIT ATTENTION indications if it must change the values. The iSCSI target is merely a handy portal to the logical units and device servers, which really run the show. While many targets are simplified, sharing parameters across LUs and sessions, there is no requirement for that. Sophisticated devices may have individual parameters for each LU and session. iSCSI is trying hard to ignore the differences between storage and networking devices, but the differences are justified and genuine. ---------------- Some of the questions that triggered the note ----- > Are you saying that these parameters need to be able to have different > values for each LU among several LUs of single target in a single > session? > > Also would different sessions to the same LU all need to use the same > value? --------------- And a succinct summary of the thoughts --------------- If I understand correctly, in your view, such parameter negotiations should be per initiator and per LU. Parameters which are unique per logical unit can be set (or "negotiated") *only* via mode pages. Whether or not changing the value for one logical unit changes it for others would be target end implementer's choice, subject to appropriate parameter change notifications to the initiator(s). The values negotiated during login would be per initiator and per target default/initial values to be used when per LU mode pages have not been subsequently modified by this initiator. I am not reading that you think these values should not be settable at the per session level. Only that you believe there is a real need to be able to change them at the per LU level so that the per session values can be over-ridden for specific LUs. Changing the value for one LU via the mode pages would not have to change it for other LUs in this session nor for other sessions to this LU. Is that about right? --------- My answer would be yes ------------------------------------- From owner-ips@ece.cmu.edu Tue Oct 2 13: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 NAA21356 for ; Tue, 2 Oct 2001 13:06:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92GG6a13172 for ips-outgoing; Tue, 2 Oct 2001 12:16: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 f92FjDP11084 for ; Tue, 2 Oct 2001 11:45:13 -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 IAA16665; Tue, 2 Oct 2001 08:45:07 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 08:45:06 -0700 Message-ID: From: Robert Snively To: "'Dave Sheehy'" , ips@ece.cmu.edu Subject: RE: iSCSI : iSCSI parameter default values Date: Tue, 2 Oct 2001 08:45:05 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Dave, Of course there can, but during normal operation, all of them are either data or commands, since SCSI has no other outbound transactions from an initiator. In either case, they are useful functions that overlap and make proper use of the link during any latency periods. If a target is capable of handling data immediately following a command (by allowing any form of unsolicited data, immediate or not), then a wise initiator will help the target along by providing that data in a timely fashion. That could be as soon as a few nanoseconds after the command, whether or not the data was in a separate PDU. Bob > -----Original Message----- > From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com] > Sent: Monday, October 01, 2001 3:35 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > Robert, > > > 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. > > I just want to point out that the data is NOT required to be in an > immediately following PDU. There can be any number (up to MaxCmdSN) of > intervening non-data PDUs between the command and data. > > Dave > > From owner-ips@ece.cmu.edu Tue Oct 2 13:06: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 NAA21368 for ; Tue, 2 Oct 2001 13:06:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92GGXZ13220 for ips-outgoing; Tue, 2 Oct 2001 12:16:33 -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 f92FaRP10539 for ; Tue, 2 Oct 2001 11:36: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 IAA16006 for ; Tue, 2 Oct 2001 08:36:20 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 08:36:19 -0700 Message-ID: From: Robert Snively To: ips@ece.cmu.edu Subject: RE: iSCSI : default iSCSI mode page settings - Consensus call Date: Tue, 2 Oct 2001 08:36:18 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, In an offline discussion, we have picked at a thread central to this fabric. That is basically the view that one has of the structure of targets. ------------------ Note sent out a day ago --------------- Traditional network environments talk from one big host memory to another big host memory. In the storage space, the memory in the target is actually distributed between whatever caching and preprocessing space the target platform may have and the space held by each logical unit. In some cases (RAIDs) the distribution is heavily in favor of the target platform cache. In others (tapes), individual logical units may have 100s of Megabytes of buffering which are not available to other logical units. If you have mixed types of logical units or if you have the memory distributed unevenly among the logical units, different values are normal among different LUs. Different sessions to the same LU may also have different properties. In particular, the LU may give away resources freely for the first few sessions, but more sparingly for subsequent sessions. Alternatively, the LU may share the resources dynamically, providing UNIT ATTENTION indications if it must change the values. The iSCSI target is merely a handy portal to the logical units and device servers, which really run the show. While many targets are simplified, sharing parameters across LUs and sessions, there is no requirement for that. Sophisticated devices may have individual parameters for each LU and session. iSCSI is trying hard to ignore the differences between storage and networking devices, but the differences are justified and genuine. ---------------- Some of the questions that triggered the note ----- > Are you saying that these parameters need to be able to have different > values for each LU among several LUs of single target in a single > session? > > Also would different sessions to the same LU all need to use the same > value? --------------- And a succinct summary of the thoughts --------------- If I understand correctly, in your view, such parameter negotiations should be per initiator and per LU. Parameters which are unique per logical unit can be set (or "negotiated") *only* via mode pages. Whether or not changing the value for one logical unit changes it for others would be target end implementer's choice, subject to appropriate parameter change notifications to the initiator(s). The values negotiated during login would be per initiator and per target default/initial values to be used when per LU mode pages have not been subsequently modified by this initiator. I am not reading that you think these values should not be settable at the per session level. Only that you believe there is a real need to be able to change them at the per LU level so that the per session values can be over-ridden for specific LUs. Changing the value for one LU via the mode pages would not have to change it for other LUs in this session nor for other sessions to this LU. Is that about right? --------- My answer would be yes ------------------------------------- From owner-ips@ece.cmu.edu Tue Oct 2 13:07: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 NAA21398 for ; Tue, 2 Oct 2001 13:07:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92GjPv15317 for ips-outgoing; Tue, 2 Oct 2001 12:45: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 f92GeFP14992 for ; Tue, 2 Oct 2001 12:40:15 -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 JAA20853; Tue, 2 Oct 2001 09:40:04 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <411AFVV2>; Tue, 2 Oct 2001 09:40:03 -0700 Message-ID: From: Robert Snively To: "'John Hufferd'" , Robert Snively Cc: ips@ece.cmu.edu Subject: RE: iSCSI : iSCSI parameter default values Date: Tue, 2 Oct 2001 09:40:01 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk John, What I really wanted to point out is that the destination of the data is NOT the buffer, nor is it a memory space behind the buffer. It is a non-volatile protected storage medium, which may be either a set of disk drives with the proper degrees of RAID redundancy or (at least temporarily) some kind of replicated non-volatile RAM. It is that protected space which must be made available for received data. If you tack the data into the command PDU, you must treat the whole combination. You may treat it as protected, or you may treat it as recoverable, depending on how complex you want your PDU retransmission algorithm to be, but in either case you will have to post-process it to separate the command, interpret the command, and move the data portion to the proper resting place, where it can be available for subsequent accesses by other commands. If you leave it separate, you can treat the command as a unit which does not have to be separated out or analyzed until you get around to it, placing the data in a pre-allocated portion of the non-volatile storage for later tagging and referencing when the command is interpreted. Better yet, if you use R2T, you can request the data at the proper time to have it delivered (in any convenient order of course) directly to the proper destination disk drive or to a pre-tagged portion of non-volatile storage. It is this type of operation that is truly "zero-copy" in the SCSI and storage sense. 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: Sunday, September 30, 2001 2:29 AM > To: Robert Snively > Cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > 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 Tue Oct 2 13: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 NAA21617 for ; Tue, 2 Oct 2001 13:11:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92G9Dd12735 for ips-outgoing; Tue, 2 Oct 2001 12:09:13 -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 f92G95P12723 for ; Tue, 2 Oct 2001 12:09:06 -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 f92G8Ar14915; Tue, 2 Oct 2001 12:08:10 -0400 (EDT) From: "Eddy Quicksall" To: "'Santosh Rao'" , "'John Hufferd'" Cc: Subject: RE: iscsi : iscsi parameter default values Date: Tue, 2 Oct 2001 12:08:17 -0400 Message-ID: <001601c14b5c$74c0ee80$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: <3BB8F91F.5C53AF77@cup.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Would all cases look like these? (If I made a mistake, please correct it). Note that I am attempting to use the rule specified as: The negotiation MAY proceed only up to the point where both parties can unequivocally compute the result; continuing beyond this point is OPTIONAL. And my interpretation of the rule is that when a responder gets a binary value, it can compare that against the default and can therefore compute the result and therefore does not need to respond if the result is what he wants. Am I correct in my interpretation? Eddy Default ImmediateData="yes" =========================== Initiator wants immediate data & target supports it. --------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 yes * yes = yes Initiator does not want immediate data & target supports it. ----------------------------------------------------------- I -> T : ImmediateData="no". (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 no * yes = no Initiator wants immediate data & target does not support it. ----------------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : ImmediateData="no". (CSG=Operational, NSG=FFP). T=1 yes * no = no Initiator does not want immediate data & does not target support it. ------------------------------------------------------------------- I -> T : ImmediateData="no". (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 no * yes = no Default ImmediateData="no" ========================== Initiator wants immediate data & target supports it. ----------------------------------------------------------- I -> T : ImmediateData="yes" (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) yes * no = no Initiator does not want immediate data & target supports it. -------------------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent) (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) no * no = no Initiator wants immediate data & target does not support it. ----------------------------------------------------------- I -> T : ImmediateData="yes". (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 yes * no = no Initiator does not want immediate data & does not target support it. ------------------------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 no * no = no Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Monday, October 01, 2001 7:16 PM To: John Hufferd Cc: ips@ece.cmu.edu Subject: Re: iscsi : iscsi parameter default values John Hufferd wrote: > > I think your logic reverses if the support wanted is yes and the target is > supporting yes. How so ? Here are the scenarios when initiator wants to use immediate data and target supports it, first with default ImmediateData set to "yes" and then, with default Immediatedata set to "no". In both cases, a single login handshake occurs. The only difference being that when ImmediateData defaults to "yes", the key need not be sent in either direction, whereas when it defaults to no, the ImmediateData key travels in both directions in the login payload. (FFP = FullFeaturePhase). Default ImmediateData="yes" --------------------------- Initator wants immediate data & targets supports it. ---------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 Default ImmediateData="no" -------------------------- Initiator wants immediate data and target supports it. ----------------------------------------------------------- I -> T : ImmediateData="yes" (CSG=Operational, NSG=FFP). T=1 T -> I : Immediatedata="yes" (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) Same number of handshakes in both cases. The only difference is that the key is not sent in the first case, and key is explicitly exchanged in the 2nd case. > If they say No they clearly do not care about extra handshakes sense R2T is > all they have and it requires extra handshakes. Hmm.... The way I see it, an initiator that does not use ImmediateData is a simple initiator and is more interested in seeing a simpler login (completed in a single login req/rsp) than one that does support ImmediateData. Those implementations that can do the extra work of supporting ImmediateData can well do the extra work of negotiating for its use. Regards, Santosh From owner-ips@ece.cmu.edu Tue Oct 2 13:48: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 NAA22823 for ; Tue, 2 Oct 2001 13:48:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92HIV017874 for ips-outgoing; Tue, 2 Oct 2001 13:18:31 -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 f92HGOP17712 for ; Tue, 2 Oct 2001 13:16:24 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f92HGIS29576 for ; Tue, 2 Oct 2001 13:16:18 -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 f92HGH425164 for ; Tue, 2 Oct 2001 13:16:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15289.63111.458000.384023@gargle.gargle.HOWL> Date: Tue, 2 Oct 2001 13:16:55 -0400 From: Paul Koning To: ips@ece.cmu.edu Subject: ISCSI: Error in 10.3.3 of iscsi-08 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 The last paragraph of section 10.3.3 is badly misleading. 10.3.3 says about pre-shared key: "the only practical usage under this configuration is a group pre-shared key". That is clearly false. Standard practice for IPsec is that a pre-shared key is unique to a given pair of communicating entities. The only exception is when dynamic addresses are used, as discussed accurately in the security draft, section 5.8.2). As a minimum, 10.3.3 needs to be reworded so it describes the real world. The following text would do this: IKE main mode with pre-shared key authentication method SHOULD NOT be used (while pre-shared keys in many cases offer good security, situations where dynamically assigned addresses are used force the use of a group pre-shared key which creates vulnerability to man-in-the-middle attack). Preferably, the requirement should be changed so the reasoning for the restriction matches the restriction. The following text achieves this: IKE main mode with pre-shared key authentication method SHOULD NOT be used when either the initiator or the target uses dynamically assigned IP addresses (while pre-shared keys in many cases offer good security, situations where dynamically assigned addresses are used force the use of a group pre-shared key which creates vulnerability to man-in-the-middle attack). If this second solution is adopted, section 2.3 in the security spec also needs a corresponding change (first two sentences of page 10). paul From owner-ips@ece.cmu.edu Tue Oct 2 13: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 NAA22864 for ; Tue, 2 Oct 2001 13:48:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92H6t217128 for ips-outgoing; Tue, 2 Oct 2001 13:06:55 -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 f92H6DP17060 for ; Tue, 2 Oct 2001 13:06:13 -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 KAA23402; Tue, 2 Oct 2001 10:06:05 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <411AFWQ8>; Tue, 2 Oct 2001 10:06:04 -0700 Message-ID: From: Robert Snively To: "'John Hufferd'" , ips@ece.cmu.edu Subject: RE: iSCSI: Immediate Data Date: Tue, 2 Oct 2001 10:06:04 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk John, Some minor disagreements here: > 1. Immediate Data permits the elimination of an additional network > handshake/interaction. Immediate Data is not necessary to eliminate the handshake. Use Unsolicited Data with InitialR2T = no, and (assuming you have a decent initiator) you get the same result. > > 2. This is important since some applications have a key sensitivity to > Latency. The most important of these is Database. Database is certainly sensitive to latency, but the real latency is to the SCSI Response, which formalizes the promise that the data will never, ever, be lost from the storage. Even the use of InitialR2T = yes on long links is a second-order performance effect on this if your storage is a disk drive. > 3. Not only is Database sensitive to Latency, it generally > has small I/O > writes. This is application dependent. Most database programs out of the box tend to use small block transfers, but well-tuned databases that are doing work other than OLTP tend to cluster writes into much larger blocks when possible. > 4. The hardware HBAs that many of you folks are building, > include a TCP/IP > Offload Engines (TOEs). This permits support of Gigabit Line > speed without > Server Load. However, even though many of you are attempting to > parallelize as much of the TOE processing as possible, TCP/IP > processing > will still add latency to each iSCSI interaction, as compared to Fibre > Channel. What can I say? You have hit a basic truth. .... snip .... > > 7. So it is the Immediate Data feature of iSCSI that will > make an important > difference in the Key Response Time Sensitive Applications, > which by luck > only transfer a small amounts of data at a time. See 1-3. > 8. When we attempt to let iSCSI shine on the "at-distance" storage > environment, the value of Immediate Data, and Unsolicited > Data are even > more valuable. However, my concern at this time is for > Immediate Data. I am absolutely in agreement with your assessment of unsolicited data at distance, but immediate data is not a necessary part of that improvement. As for simplicity: > A. Creating a Buffer Manager that can allocate buffers that > are chained > together, is kind of fundamental to the high performance > environment we are > attempting to work with. All the processes (whether iSCSI or > SCSI) will > allocate buffers (from the Buffer Manager), place data in one > or more of > these buffers, and pass the pointer list to the next process. > There will be > no copying of data. See my previous note considering the actual destination of data, which is not in a memory address space. It is in this way that storage differs from networking. You can't pass pointers about, but must place the data into a storage space that has the properties of non-volatility, redundancy, coherence, and accessibility through the SCSI command set. ... snip ... From owner-ips@ece.cmu.edu Tue Oct 2 13:49: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 NAA22894 for ; Tue, 2 Oct 2001 13:49:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92Gl9c15446 for ips-outgoing; Tue, 2 Oct 2001 12:47:09 -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 f92GeFP14992 for ; Tue, 2 Oct 2001 12:40:15 -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 JAA20853; Tue, 2 Oct 2001 09:40:04 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <411AFVV2>; Tue, 2 Oct 2001 09:40:03 -0700 Message-ID: From: Robert Snively To: "'John Hufferd'" , Robert Snively Cc: ips@ece.cmu.edu Subject: RE: iSCSI : iSCSI parameter default values Date: Tue, 2 Oct 2001 09:40:01 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk John, What I really wanted to point out is that the destination of the data is NOT the buffer, nor is it a memory space behind the buffer. It is a non-volatile protected storage medium, which may be either a set of disk drives with the proper degrees of RAID redundancy or (at least temporarily) some kind of replicated non-volatile RAM. It is that protected space which must be made available for received data. If you tack the data into the command PDU, you must treat the whole combination. You may treat it as protected, or you may treat it as recoverable, depending on how complex you want your PDU retransmission algorithm to be, but in either case you will have to post-process it to separate the command, interpret the command, and move the data portion to the proper resting place, where it can be available for subsequent accesses by other commands. If you leave it separate, you can treat the command as a unit which does not have to be separated out or analyzed until you get around to it, placing the data in a pre-allocated portion of the non-volatile storage for later tagging and referencing when the command is interpreted. Better yet, if you use R2T, you can request the data at the proper time to have it delivered (in any convenient order of course) directly to the proper destination disk drive or to a pre-tagged portion of non-volatile storage. It is this type of operation that is truly "zero-copy" in the SCSI and storage sense. 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: Sunday, September 30, 2001 2:29 AM > To: Robert Snively > Cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > 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 Tue Oct 2 13:59: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 NAA23504 for ; Tue, 2 Oct 2001 13:59:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92HPaH18330 for ips-outgoing; Tue, 2 Oct 2001 13:25:36 -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 f92HPYP18325 for ; Tue, 2 Oct 2001 13:25:34 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel12.hp.com (Postfix) with ESMTP id 667C01F56F; Tue, 2 Oct 2001 10:25:21 -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 399221F52F; Tue, 2 Oct 2001 10:25:20 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 10:25:20 -0700 Message-ID: <499DC368E25AD411B3F100902740AD6508E99A8D@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: santoshr@cup.hp.com, ips@ece.cmu.edu Cc: "'Black_David@emc.com'" Subject: RE: iSCSI: ISID issue Date: Tue, 2 Oct 2001 10:25:19 -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 > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, October 01, 2001 3:11 PM > To: santoshr@cup.hp.com; ips@ece.cmu.edu > Subject: RE: iSCSI: ISID issue > > > Santosh Rao wrote: > > > I think comparisions to FC's mess-up of the node WWN are > not fair to the > > current ISID rule, since, unlike in FC, the worst case > scenario with the > > ISID rule, is that each iscsi driver on the system will take up a > > different iscsi initiator name. > > At least FC had the Port WWN to fall back on. This is headed for a > situation > where the iSCSI Initiator Name is unusable for access control > configuration > because whether it corresponds to the network interface, the > HBA (e.g., > suppose > there are two interfaces on the HBA), the driver, or the OS image is > implementation-dependent. In FC it is completely unambiguous what the > Port WWN corresponds to, and that's why it's usually used for > LUN masking > and mapping solutions. We're at risk of screwing that up, e.g. ... I would like to second David's concern about not leaving targets with a deterministic way of knowing who/what the initiators identifier relates to. This is not only bad for access control mechanisms but it make topology mapping (and related concepts) more difficult for management software developers. -Shawn ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- ------------------------------------------------------- From owner-ips@ece.cmu.edu Tue Oct 2 15: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 PAA25853 for ; Tue, 2 Oct 2001 15:03:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92IYf723085 for ips-outgoing; Tue, 2 Oct 2001 14:34:41 -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 f92IYdP23081 for ; Tue, 2 Oct 2001 14:34: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 OAA15440; Tue, 2 Oct 2001 14:32: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 f92IYbV76442; Tue, 2 Oct 2001 12:34:37 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iscsi : iscsi parameter default values To: "Eddy Quicksall" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 2 Oct 2001 11:33:00 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/02/2001 12:34:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, Only one correction below. . . . 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" on 10/02/2001 09:08:17 AM To: "'Santosh Rao'" , John Hufferd/San Jose/IBM@IBMUS cc: Subject: RE: iscsi : iscsi parameter default values Would all cases look like these? (If I made a mistake, please correct it). Note that I am attempting to use the rule specified as: The negotiation MAY proceed only up to the point where both parties can unequivocally compute the result; continuing beyond this point is OPTIONAL. And my interpretation of the rule is that when a responder gets a binary value, it can compare that against the default and can therefore compute the result and therefore does not need to respond if the result is what he wants. Am I correct in my interpretation? Eddy Default ImmediateData="yes" =========================== Initiator wants immediate data & target supports it. --------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 yes * yes = yes Initiator does not want immediate data & target supports it. ----------------------------------------------------------- I -> T : ImmediateData="no". (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 no * yes = no Initiator wants immediate data & target does not support it. ----------------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : ImmediateData="no". (CSG=Operational, NSG=FFP). T=1 yes * no = no Initiator does not want immediate data & does not target support it. ------------------------------------------------------------------- I -> T : ImmediateData="no". (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 no * yes = no Default ImmediateData="no" ========================== Initiator wants immediate data & target supports it. ----------------------------------------------------------- I -> T : ImmediateData="yes" (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) yes * no = no [Huff] yes * no (but OK) = Yes [/Huff] Initiator does not want immediate data & target supports it. -------------------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent) (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) no * no = no Initiator wants immediate data & target does not support it. ----------------------------------------------------------- I -> T : ImmediateData="yes". (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 yes * no = no Initiator does not want immediate data & does not target support it. ------------------------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 no * no = no Eddy -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Monday, October 01, 2001 7:16 PM To: John Hufferd Cc: ips@ece.cmu.edu Subject: Re: iscsi : iscsi parameter default values John Hufferd wrote: > > I think your logic reverses if the support wanted is yes and the target is > supporting yes. How so ? Here are the scenarios when initiator wants to use immediate data and target supports it, first with default ImmediateData set to "yes" and then, with default Immediatedata set to "no". In both cases, a single login handshake occurs. The only difference being that when ImmediateData defaults to "yes", the key need not be sent in either direction, whereas when it defaults to no, the ImmediateData key travels in both directions in the login payload. (FFP = FullFeaturePhase). Default ImmediateData="yes" --------------------------- Initator wants immediate data & targets supports it. ---------------------------------------------------- I -> T : (no key sent). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent). (CSG=Operational, NSG=FFP). T=1 Default ImmediateData="no" -------------------------- Initiator wants immediate data and target supports it. ----------------------------------------------------------- I -> T : ImmediateData="yes" (CSG=Operational, NSG=FFP). T=1 T -> I : Immediatedata="yes" (CSG=Operational, NSG=FFP). T=1 (tgt has no more keys to send.) Same number of handshakes in both cases. The only difference is that the key is not sent in the first case, and key is explicitly exchanged in the 2nd case. > If they say No they clearly do not care about extra handshakes sense R2T is > all they have and it requires extra handshakes. Hmm.... The way I see it, an initiator that does not use ImmediateData is a simple initiator and is more interested in seeing a simpler login (completed in a single login req/rsp) than one that does support ImmediateData. Those implementations that can do the extra work of supporting ImmediateData can well do the extra work of negotiating for its use. Regards, Santosh From owner-ips@ece.cmu.edu Tue Oct 2 15:04: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 PAA25929 for ; Tue, 2 Oct 2001 15:04:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92IFEW21713 for ips-outgoing; Tue, 2 Oct 2001 14:15: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 f92IFDP21709 for ; Tue, 2 Oct 2001 14:15:13 -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 OAA98320; Tue, 2 Oct 2001 14:12:49 -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 f92IF9V151868; Tue, 2 Oct 2001 12:15:09 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Immediate Data 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: Tue, 2 Oct 2001 11:14:16 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/02/2001 12:15:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Rober, Comment in line. . . . 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 10/02/2001 10:06:04 AM To: John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: RE: iSCSI: Immediate Data John, Some minor disagreements here: > 1. Immediate Data permits the elimination of an additional network > handshake/interaction. Immediate Data is not necessary to eliminate the handshake. Use Unsolicited Data with InitialR2T = no, and (assuming you have a decent initiator) you get the same result. [Huff] The point is that Immediate Data is simpler then the above since it is with the CDB [/Huff] > > 2. This is important since some applications have a key sensitivity to > Latency. The most important of these is Database. Database is certainly sensitive to latency, but the real latency is to the SCSI Response, which formalizes the promise that the data will never, ever, be lost from the storage. Even the use of InitialR2T = yes on long links is a second-order performance effect on this if your storage is a disk drive. [Huff]Now you are firmly on my turf. Almost all Raid Controllers, have Caches with Non Volatile Storage. (Or at least all the ones to which Database response is important have Non Volatile RAM for Write Caching.) The Non Volatile Write to Cache is what takes the Disk Latency out of the equation. So with immediate data the response to small writes can be very fast. [/Huff] > 3. Not only is Database sensitive to Latency, it generally > has small I/O > writes. This is application dependent. Most database programs out of the box tend to use small block transfers, but well-tuned databases that are doing work other than OLTP tend to cluster writes into much larger blocks when possible. [Huff] Most of the I/O operations are still small. It is from these that we need to remove as much latency as possible. We do not need to do anything special for the Large I/O. [/Huff] > 4. The hardware HBAs that many of you folks are building, > include a TCP/IP > Offload Engines (TOEs). This permits support of Gigabit Line > speed without > Server Load. However, even though many of you are attempting to > parallelize as much of the TOE processing as possible, TCP/IP > processing > will still add latency to each iSCSI interaction, as compared to Fibre > Channel. What can I say? You have hit a basic truth. .... snip .... > > 7. So it is the Immediate Data feature of iSCSI that will > make an important > difference in the Key Response Time Sensitive Applications, > which by luck > only transfer a small amounts of data at a time. See 1-3. [Huff] and my responses. [/Huff] > 8. When we attempt to let iSCSI shine on the "at-distance" storage > environment, the value of Immediate Data, and Unsolicited > Data are even > more valuable. However, my concern at this time is for > Immediate Data. I am absolutely in agreement with your assessment of unsolicited data at distance, but immediate data is not a necessary part of that improvement. [Huff] I can not understand why you dislike immediate data, and still seem to like unsolicited data. You will have almost all the same iSCSI code path in the node anyway if you handle Login. Why you would not like a code path that makes this important reduction, seems a bit strange. [/Huff] As for simplicity: > A. Creating a Buffer Manager that can allocate buffers that > are chained > together, is kind of fundamental to the high performance > environment we are > attempting to work with. All the processes (whether iSCSI or > SCSI) will > allocate buffers (from the Buffer Manager), place data in one > or more of > these buffers, and pass the pointer list to the next process. > There will be > no copying of data. See my previous note considering the actual destination of data, which is not in a memory address space. It is in this way that storage differs from networking. You can't pass pointers about, but must place the data into a storage space that has the properties of non-volatility, redundancy, coherence, and accessibility through the SCSI command set. [Huff] I have no idea why you say this. Our storage controllers and our competition has been doing this for years. The Non Volatile (RAM) Memory is completely addressable. And yes the Cache Manager looks a lot like all buffer managers, and there are a lot of pointers. [/Huff] ... snip ... From owner-ips@ece.cmu.edu Tue Oct 2 15:04: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 PAA25954 for ; Tue, 2 Oct 2001 15:04:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92IDFn21604 for ips-outgoing; Tue, 2 Oct 2001 14:13:15 -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 f92IDDP21600 for ; Tue, 2 Oct 2001 14:13:14 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id LAA13342; Tue, 2 Oct 2001 11:12:59 -0700 (PDT) From: "Rod Harrison" To: "Robert Snively" , "'Dave Sheehy'" , Subject: RE: iSCSI : iSCSI parameter default values Date: Tue, 2 Oct 2001 19:15:18 +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 A target supporting unsolicited data must be prepared to receive "other" PDUs between the command PDU and the separate DATA-IN carrying the data. The most important thing for an initiator when a new command is starting is to get the command PDU to the target as soon as possible. This allows the target to send R2Ts for data past the FirstBurstSize. To that end, upon receipt of a SCSI CDB from the host an initiator could immediately queue a DMA, then build and send the command PDU. Many other CDBs could be processed in this way before the first DMA completes, in which case the target may see a series of command PDUs before it sees any DATA-OUTs. The only limitation I can find in the spec in this area is the last paragraph of 2.2.5 (v08) which says the initiator MUST send unsolicited data on the same connection and in the same order as the commands. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Robert Snively Sent: Tuesday, October 02, 2001 4:45 PM To: 'Dave Sheehy'; ips@ece.cmu.edu Subject: RE: iSCSI : iSCSI parameter default values Dave, Of course there can, but during normal operation, all of them are either data or commands, since SCSI has no other outbound transactions from an initiator. In either case, they are useful functions that overlap and make proper use of the link during any latency periods. If a target is capable of handling data immediately following a command (by allowing any form of unsolicited data, immediate or not), then a wise initiator will help the target along by providing that data in a timely fashion. That could be as soon as a few nanoseconds after the command, whether or not the data was in a separate PDU. Bob > -----Original Message----- > From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com] > Sent: Monday, October 01, 2001 3:35 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > Robert, > > > 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. > > I just want to point out that the data is NOT required to be in an > immediately following PDU. There can be any number (up to MaxCmdSN) of > intervening non-data PDUs between the command and data. > > Dave > > From owner-ips@ece.cmu.edu Tue Oct 2 15:45: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 PAA26987 for ; Tue, 2 Oct 2001 15:45:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92IsMu24533 for ips-outgoing; Tue, 2 Oct 2001 14:54: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 f92IsIP24523 for ; Tue, 2 Oct 2001 14:54: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 OAA52092; Tue, 2 Oct 2001 14:51: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.97.1) with ESMTP id f92IsHV124424; Tue, 2 Oct 2001 12:54:17 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI : iSCSI parameter default values To: Robert Snively , "Eddy Quicksall" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Tue, 2 Oct 2001 11:53:23 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/02/2001 12:54:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bob, I really do understand your statements about the cache. I just think that they are over stated. Ed, First off let me also say to, that you points ( on another note regarding Caches) are right on. Especially your points with regards to having to do something to match the new capabilities of iSCSI with old Cache Manager designs. It is possible that not all are flexible enough to make a easy adaption. (But some/many are.) Bob, The Data parts of on immediate data are clearly identifiable in the PDU. It is very reasonable to fork the input as it is coming in. That is, put the data into NVRAM cache memory as the data comes in, and place the CDB etc, wherever you want it. At that time, all the associations can be marked as well. I over stated the code path identity between Login handling and Write I/O immediate Data. But the receive code path is very similar, it is just that the Data probably will not go to the NVRAM cache. Instead it would be forked into a Text parsing work area. But the code is very close to the same. And my point is, to worry about the few line of code difference is missing the key point and the value of Immediate Data. . . . 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 10/02/2001 09:40:01 AM To: John Hufferd/San Jose/IBM@IBMUS, Robert Snively cc: ips@ece.cmu.edu Subject: RE: iSCSI : iSCSI parameter default values John, What I really wanted to point out is that the destination of the data is NOT the buffer, nor is it a memory space behind the buffer. It is a non-volatile protected storage medium, which may be either a set of disk drives with the proper degrees of RAID redundancy or (at least temporarily) some kind of replicated non-volatile RAM. It is that protected space which must be made available for received data. If you tack the data into the command PDU, you must treat the whole combination. You may treat it as protected, or you may treat it as recoverable, depending on how complex you want your PDU retransmission algorithm to be, but in either case you will have to post-process it to separate the command, interpret the command, and move the data portion to the proper resting place, where it can be available for subsequent accesses by other commands. If you leave it separate, you can treat the command as a unit which does not have to be separated out or analyzed until you get around to it, placing the data in a pre-allocated portion of the non-volatile storage for later tagging and referencing when the command is interpreted. Better yet, if you use R2T, you can request the data at the proper time to have it delivered (in any convenient order of course) directly to the proper destination disk drive or to a pre-tagged portion of non-volatile storage. It is this type of operation that is truly "zero-copy" in the SCSI and storage sense. 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: Sunday, September 30, 2001 2:29 AM > To: Robert Snively > Cc: ips@ece.cmu.edu > Subject: RE: iscsi : iscsi parameter default values > > > > 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 Tue Oct 2 15:48: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 PAA27067 for ; Tue, 2 Oct 2001 15:48:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f92JEu526007 for ips-outgoing; Tue, 2 Oct 2001 15:14: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 f92JEsP26001 for ; Tue, 2 Oct 2001 15:14: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 PAA37310; Tue, 2 Oct 2001 15:12: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 f92JDVV250680; Tue, 2 Oct 2001 13:13:43 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI : default iSCSI mode page settings - Consensus call 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: Tue, 2 Oct 2001 12:12:39 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/02/2001 01:13:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bob, I think I agree with the direction of the note, but need to be sure we are on the same (mode) page:-) If you are saying the some values that effect an LU should be in LU specific Mode Pages, then fine in theory. I just need to understand which ones you are referring to. Since many of the Session parameters must be applied at the Transport, we need to know which iSCSI negotiated values you feel should be in the LU specific mode pages? Or did I miss understand you statements? . . . 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 10/02/2001 08:36:18 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iSCSI : default iSCSI mode page settings - Consensus call Folks, In an offline discussion, we have picked at a thread central to this fabric. That is basically the view that one has of the structure of targets. ------------------ Note sent out a day ago --------------- Traditional network environments talk from one big host memory to another big host memory. In the storage space, the memory in the target is actually distributed between whatever caching and preprocessing space the target platform may have and the space held by each logical unit. In some cases (RAIDs) the distribution is heavily in favor of the target platform cache. In others (tapes), individual logical units may have 100s of Megabytes of buffering which are not available to other logical units. If you have mixed types of logical units or if you have the memory distributed unevenly among the logical units, different values are normal among different LUs. Different sessions to the same LU may also have different properties. In particular, the LU may give away resources freely for the first few sessions, but more sparingly for subsequent sessions. Alternatively, the LU may share the resources dynamically, providing UNIT ATTENTION indications if it must change the values. The iSCSI target is merely a handy portal to the logical units and device servers, which really run the show. While many targets are simplified, sharing parameters across LUs and sessions, there is no requirement for that. Sophisticated devices may have individual parameters for each LU and session. iSCSI is trying hard to ignore the differences between storage and networking devices, but the differences are justified and genuine. ---------------- Some of the questions that triggered the note ----- > Are you saying that these parameters need to be able to have different > values for each LU among several LUs of single target in a single > session? > > Also would different sessions to the same LU all need to use the same > value? --------------- And a succinct summary of the thoughts --------------- If I understand correctly, in your view, such parameter negotiations should be per initiator and per LU. Parameters which are unique per logical unit can be set (or "negotiated") *only* via mode pages. Whether or not changing the value for one logical unit changes it for others would be target end implementer's choice, subject to appropriate parameter change notifications to the initiator(s). The values negotiated during login would be per initiator and per target default/initial values to be used when per LU mode pages have not been subsequently modified by this initiator. I am not reading that you think these values should not be settable at the per session level. Only that you believe there is a real need to be able to change them at the per LU level so that the per session values can be over-ridden for specific LUs. Changing the value for one LU via the mode pages would not have to change it for other LUs in this session nor for other sessions to this LU. Is that about right? --------- My answer would be yes ------------------------------------- From owner-ips@ece.cmu.edu Tue Oct 2 21:55: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 VAA07657 for ; Tue, 2 Oct 2001 21:55:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f931BgS18539 for ips-outgoing; Tue, 2 Oct 2001 21:11: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 f931BeP18530 for ; Tue, 2 Oct 2001 21:11: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 1963345; Tue, 02 Oct 2001 18:11:38 -0700 Message-ID: <3BBA66C3.9448B949@redswitch.com> Date: Tue, 02 Oct 2001 18:15: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-08 Comments 1 through 10 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Comment 1: Section 3.17 Page 101: "Reject is used to indicate an iSCSI error condition (protocol, unsupported option etc.)." - Please enhance the description of the Reject PDU. Please specify exactly what it is used for, when, and why. I realize that there is a forward reference on the following page, but feel that a more robust definition of the reject functionality also belongs here. Comment 2: Section 3.18 on Page 104: - Please add a definition of the I Bit. I assume it is the same meaning as the previous definition in other PDUs of I and Immediate. I feel these fields should be specified for each PDU. Comment 3: Section 3.19.1 on Page "3.19.1 Target Transfer Tag" "Whenever the NOP-In is not issued in response to a NOP-Out the StatSN field will contain as usual the next StatSN but StatSN for this connection is not advanced." - Why is the above text in a section titled "3.19.1 Target Transfer Tag"? - It almost appears the this text belongs in NOP-Out? - Please elaborate on the meaning and proper placement for this text. Comment 4: Section 5.1 on Page 112: "-Login Response with Login Accept as a final response (T bit set to 1 and the NSG in both command [and] response are set to FullFeaturePhase). The response includes the protocol version supported by the target and the session ID and may include iSCSI operational or security parameters (depending on the current stage)." Change "a' to "and". Comment 5: Section 5.2 on Page 115: "If security is established in the login phase then after the security negotiation is complete, each iSCSI PDU MUST include the appropriate digest field if any." "All PDUs sent after the security negotiation stage MUST be built using the agreed security." - The two sets of quoted text shown above are a bit redundant, or at least could be combined into a single paragraph. By the way I do realize there are two distinct phases here. - Could we be a little more specific in the second statement? Something like "MUST be composed of the fields or tuples specified by the agreed upon protocol specification". Comment 6: Section 5.2 on Page 115: "If the security negotiation fails at the target then the target MUST send the appropriate Login Response PDU. If the security negotiation fails at the initiator, the initiator [shall] drop the connection." - Do you really mean "shall"? Shall is IEEE terminology do you not mean "MUST"? This is a recurring problem in many places in the draft, for brevity I would suggest a text search and examination of each "shall". Comment 7: Section 5.3 on Page 115: "Session specific parameters can be specified only during the login phase begun by a login command [containing a null TSID] (e.g., the maximum number of connections that can be used for this session). Connection specific parameters, if any, can be specified during the login phase begun by any login command. Thus, a session is operational once it has at least one connection." - Do you not mean the first or leading login? If true please add this terminology. Comment 8: Section 6 on Page 116: "If the target responds to a text request with the F bit set to 1, with a text response with the F bit set to 0, the initiator [must] keep sending the text request (even empty) with the F bit set to 1 until it gets the text response with the F bit set to 1. Responding to a text request with the F bit set to 1 with an empty (no key=value pairs) is not an error but is discouraged." - "must" versus "MUST"! Do you not mean "MUST"? This is a recurring problem in many places in the draft, for brevity I would suggest a text search and examination of each "must'. Comment 9: Section 8.11 on Page 131: "Usage of within a connection and within a command recovery classes MUST NOT be attempted before the connection is in full feature phase." - I think there is a english problem here, or maybe dropped words. Comment 10: Section 8.11.4 on Page 134: "Session recovery implies closing of all [the] TCP connections, aborting at target all executing and queued tasks for the given initiator, terminating at initiator all [the] outstanding SCSI commands with an appropriate SCSI service response and restarting a session on a new connection set (TCP connection establishment and login on all new connections)." - Minor english suggest adding "the" in two places. From owner-ips@ece.cmu.edu Tue Oct 2 21:56: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 VAA07725 for ; Tue, 2 Oct 2001 21:56:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f930s6O17576 for ips-outgoing; Tue, 2 Oct 2001 20:54:06 -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 f930s4P17572 for ; Tue, 2 Oct 2001 20:54:05 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Oct 2001 17:53:53 -0700 Message-ID: From: Charles Monia To: IPS Reflector Subject: Common Encapsulation:draft-monia-ips-enccrcex-00.txt Date: Tue, 2 Oct 2001 17:53:50 -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 Hi Ralph: Suggest the following tweek to the proposed change: > "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]." > To clarify the meaning of "frame content", I suggest adding a cross reference as shown below: "...FC frame content (see section 5.1),... Charles > -----Original Message----- > From: Ralph Weber [mailto:ralphoweber@compuserve.com] > Sent: Saturday, September 29, 2001 5:10 AM > To: IPS Reflector > Subject: Re: I-D ACTION:draft-monia-ips-enccrcex-00.txt > > > 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 Tue Oct 2 22:41: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 WAA10200 for ; Tue, 2 Oct 2001 22:41:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f931i3o20378 for ips-outgoing; Tue, 2 Oct 2001 21:44:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from philotas.hosting.pacbell.net (philotas.hosting.pacbell.net [216.100.99.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f931hsP20361 for ; Tue, 2 Oct 2001 21:44:00 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by philotas.hosting.pacbell.net id VAA20402; Tue, 2 Oct 2001 21:43:34 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "Robert Snively" , "'John Hufferd'" Cc: Subject: RE: iSCSI : iSCSI parameter default values Date: Tue, 2 Oct 2001 18:42:21 -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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Comments in Line. > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Robert Snively > Sent: Tuesday, October 02, 2001 9:40 AM > To: 'John Hufferd'; Robert Snively > Cc: ips@ece.cmu.edu > Subject: RE: iSCSI : iSCSI parameter default values > > > John, > > What I really wanted to point out is that the destination > of the data is NOT the buffer, nor is it a memory space > behind the buffer. It is a non-volatile protected storage medium, > which may be either a set of disk drives with the proper degrees > of RAID redundancy or (at least temporarily) some kind of > replicated non-volatile RAM. > > It is that protected space which must be made available for received data. > If you tack the data into the command PDU, you must treat the > whole combination. You may treat it as protected, or you may treat > it as recoverable, depending on how complex you want your PDU > retransmission algorithm to be, but in either case you will have > to post-process it to separate the command, interpret the command, > and move the data portion to the proper resting place, where it > can be available for subsequent accesses by other commands. > > If you leave it separate, you can treat the command as a unit > which does not have to be separated out or analyzed until you get > around to it, placing the data in a pre-allocated portion of > the non-volatile storage for later tagging and referencing when > the command is interpreted. > > Better yet, if you use R2T, you can request the data at the > proper time to have it delivered (in any convenient order of > course) directly to the proper destination disk drive or to a pre-tagged > portion of non-volatile storage. It is this type of operation that > is truly "zero-copy" in the SCSI and storage sense. The caveat should be "the way it is done today". with the proper PDU header/data split, and with the right buffer management scheme, zero copy can be done with immediate/unsolicited data. > > 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: Sunday, September 30, 2001 2:29 AM > > To: Robert Snively > > Cc: ips@ece.cmu.edu > > Subject: RE: iscsi : iscsi parameter default values > > > > > > > > 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 Tue Oct 2 22: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 WAA10387 for ; Tue, 2 Oct 2001 22:46:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9320dK21182 for ips-outgoing; Tue, 2 Oct 2001 22:00: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 f9320bP21176 for ; Tue, 2 Oct 2001 22:00: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 1963375; Tue, 02 Oct 2001 19:00:39 -0700 Message-ID: <3BBA7240.57093835@redswitch.com> Date: Tue, 02 Oct 2001 19:04:48 -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-08 Comments 11 though 18 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Comment 11: Section 9.1.1 on Page 137: "For an iSCSI Initiator, the SID values used by the session coordinators should be configurable parameters and the SID name space should be partitioned among the Initiator Portal Groups. This allows each Initiator Portal Group to act independently of other portal groups when selecting an SID for a logic; this facilitates enforcement of the SID RULE (see 2.5.3) at the initiator." - I do not believe "Initiator Portal Groups" as been defined. Please define in the Architecture Section at the beginning of the document. Comment 12: Section 9.3 on Page 138: "A task management command may reach the target and, in the case [where] immediate delivery was requested, be executed before all of the tasks it was meant to act upon have been delivered or even reached the target." - Please add the [where]. Comment 13: Appendix C on page 180: "18 RFMarkInt" and section 19 "The receiver indicates the minimum to maximum interval (in 4-byte words) [that] the receiver wants the markers. In case the receiver wants only a specific value, only a single value has to be specified." - Please add the [that]. - Please add an example to this section, and section 19. Comment 14: Appendix c on page 181: "19 SFMarkInt" "Indicates at what interval (in 4-byte words) the sender [accepts, expects] to send the markers. The number MUST be within the range required by the receiver. 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)." - Please replace [accepts] with [expects]. Comment 15: Appendix C on Page 185: 28 DataPDUInOrder "No is used by iSCSI to indicate that the data PDUs [within sequences] can be in any order. Yes is used to indicate that data PDUs within sequences have to be at continuously increasing addresses and overlays are forbidden." - Do you really mean within sequences? I thought this refereed to the ordering of the transfer of one sequence relative to another, and not the PDUs within a sequence? Comment 16: Appendix E on Page 190: "iSCSI addresses belonging with the same portal group tag support spanning multiple-connection sessions across this set of addresses." - An english problem, I would suggest a rewording. Comment 17: Appendix F on page 192: "This clause defines the alias entry formats and codes used in these commands to designate iSCSI devices or ports. As noted in 1.1, the protocol identifier used in these formats shall be set to 0x05 (see [SPC3]) and the format code values are defined in the following table:" - The IEEE uses the term clause, do we really want to use it in this context? I would suggest replacing [clause] with [Appendix]. Comment 18: - The numbering of the sections seem to increase across all appendices. I would suggest renumbering of the sections local to each appendix. From owner-ips@ece.cmu.edu Wed Oct 3 03:55: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 DAA02198 for ; Wed, 3 Oct 2001 03:55:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f937Adl06499 for ips-outgoing; Wed, 3 Oct 2001 03:10: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 f937AbP06494 for ; Wed, 3 Oct 2001 03:10: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 JAA65212 for ; Wed, 3 Oct 2001 09:10: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 f937ADU260114 for ; Wed, 3 Oct 2001 09:10:14 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - draft in PDF form contains bookmarks X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Oct 2001 10:10:13 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 10:10:13, Serialize complete at 03/10/2001 10:10:13 Content-Type: multipart/alternative; boundary="=_alternative 0027070BC2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0027070BC2256ADA_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, Robert Elliott has kindly suggested that we produce the pdf for of the draft with Bookmarks. I have and I have replaced the draft on my site with the one including bookmarks. Enjoy reading, Julo --=_alternative 0027070BC2256ADA_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

Robert Elliott has kindly suggested that we produce the pdf for of the draft with Bookmarks.
I have and I have replaced the draft on my site with the one including bookmarks.

Enjoy reading,
Julo --=_alternative 0027070BC2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 07:16: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 HAA07529 for ; Wed, 3 Oct 2001 07:16:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93ANuV25661 for ips-outgoing; Wed, 3 Oct 2001 06:23:56 -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 f93ANsP25656 for ; Wed, 3 Oct 2001 06:23:54 -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 MAA42564 for ; Wed, 3 Oct 2001 12:23: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.97.1) with ESMTP id f93ANgU252878 for ; Wed, 3 Oct 2001 12:23:43 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Oct 2001 13:23:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 13:23:43, Serialize complete at 03/10/2001 13:23:43 Content-Type: multipart/alternative; boundary="=_alternative 00392440C2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00392440C2256ADA_= Content-Type: text/plain; charset="us-ascii" Dear colleagues: The table at the end of 9.3 contains commands that do not need anymore the special handling described in the 9.3 The correct table is: +------------------+------------------------------------------+ | Function | Candidacy Selection | +------------------+------------------------------------------+ | Abort Task Set | All tasks associated with the specified | | | LUN and initiator. | +------------------+------------------------------------------+ | Clear Task Set | All tasks associated with the specified | | | LUN and initiator. For all other | | | initiators all tasks at LUN with no | | | regard to order. | +------------------+------------------------------------------+ Julo --=_alternative 00392440C2256ADA_= Content-Type: text/html; charset="us-ascii"
Dear colleagues:

The table at the end of 9.3 contains commands that do not need anymore the special handling described in the 9.3

The correct table is:


+------------------+------------------------------------------+
| Function         | Candidacy Selection                      |
+------------------+------------------------------------------+
| Abort Task Set   | All tasks associated with the specified  |
|                  | LUN and initiator.                       |
+------------------+------------------------------------------+
| Clear Task Set   | All tasks associated with the specified  |
|                  | LUN and initiator. For all other         |
|                  | initiators all tasks at LUN with no      |
|                  | regard to order.                         |
+------------------+------------------------------------------+


Julo --=_alternative 00392440C2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 08:03: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 IAA09064 for ; Wed, 3 Oct 2001 08:03:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93BKtn28116 for ips-outgoing; Wed, 3 Oct 2001 07:20:55 -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 f93BCXP27780 for ; Wed, 3 Oct 2001 07:12:33 -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 HAA07169; Wed, 3 Oct 2001 07:12:29 -0400 (EDT) Message-Id: <200110031112.HAA07169@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-ifcp-05.txt Date: Wed, 03 Oct 2001 07:12: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 : iFCP - A Protocol for Internet Fibre Channel Storage Networking Author(s) : C. Monia et al. Filename : draft-ietf-ips-ifcp-05.txt Pages : 91 Date : 02-Oct-01 This document specifies an architecture and gateway-to-gateway protocol for the implementation of Fibre Channel fabric functionality on a network in which TCP/IP switching and routing elements replace Fibre Channel components. The protocol enables the attachment of existing Fibre Channel storage products to an IP network by supporting the fabric services required by such devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-05.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-ifcp-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-ifcp-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: <20011002120743.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-ifcp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-ifcp-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011002120743.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Wed Oct 3 08:05: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 IAA09163 for ; Wed, 3 Oct 2001 08:05:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93BmTn29421 for ips-outgoing; Wed, 3 Oct 2001 07:48:29 -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 f93BmRP29417 for ; Wed, 3 Oct 2001 07:48:27 -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 NAA85410 for ; Wed, 3 Oct 2001 13:48:20 +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 f93BmJU142070 for ; Wed, 3 Oct 2001 13:48:20 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: [Fwd: iscsi : task mgmt response codes.] X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Oct 2001 14:48:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 14:48:19, Serialize complete at 03/10/2001 14:48:19 Content-Type: multipart/alternative; boundary="=_alternative 0040E401C2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0040E401C2256ADA_= Content-Type: text/plain; charset="us-ascii" Santosh, Sorry for not answering explicitly - I was overwhelmed. The text in 08 has an additional statement that might help clarify: For additional usage semantics, see section 8.1. Regards, Julo Santosh Rao Sent by: santoshr@cup.hp.com 01-10-01 21:54 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: [Fwd: iscsi : task mgmt response codes.] Julian, I did'nt hear back from you on the below issue. I look forward to your comments on the same. Thanks, Santosh Santosh Rao wrote: > > 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 ################################## --=_alternative 0040E401C2256ADA_= Content-Type: text/html; charset="us-ascii"
Santosh,

Sorry for not answering explicitly - I was overwhelmed. The text in 08 has an additional statement that might help clarify:

For additional usage semantics, see section 8.1.

Regards,
Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@cup.hp.com

01-10-01 21:54
Please respond to Santosh Rao

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        [Fwd: iscsi : task mgmt response codes.]

       


Julian,

I did'nt hear back from you on the below issue. I look forward to your
comments on the same.

Thanks,
Santosh


Santosh Rao wrote:
>
> 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
##################################

--=_alternative 0040E401C2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 08: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 IAA09786 for ; Wed, 3 Oct 2001 08:14:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93APOW25732 for ips-outgoing; Wed, 3 Oct 2001 06:25: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 f93APKP25727 for ; Wed, 3 Oct 2001 06:25:20 -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 MAA46714 for ; Wed, 3 Oct 2001 12:25: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 f93APCI78534 for ; Wed, 3 Oct 2001 12:25:12 +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" Message-ID: Date: Wed, 3 Oct 2001 13:25:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 13:25:12, Serialize complete at 03/10/2001 13:25:12 Content-Type: multipart/alternative; boundary="=_alternative 003947D8C2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003947D8C2256ADA_= Content-Type: text/plain; charset="us-ascii" I think I sent them out to you in a private note. Julo Santosh Rao Sent by: santoshr@cup.hp.com 01-10-01 20:59 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iscsi : iscsi parameter default values Julian, It would be more helpful to the discussion if you pointed out why you think the examples are incorrect, rather than your terse comment below :) Specifically, my example is based on the following text from Section 5.1 of Rev 08 draft which states : "An initiator that can operate without security and with all the operational parameters taking the default values issues the Login with the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase. If the target is also ready to forego security and LoginOperationalNegotiation the Login response is empty and has T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase in the next stage." I look forward to your clarification of the expected login handshakes in the scenarios I raised. Thanks, Santosh Julian Satran wrote: > > ... the debate would be of some interest if the examples where > correct. > > But unfortunately they are not. > > Julo > > Santosh Rao > To: ips@ece.cmu.edu > Sent by: owner-ips@ece.cmu.edu cc: > Subject: Re: iscsi : > 01-10-01 18:18 iscsi parameter default values > Please respond to Santosh Rao > > > All, > > As the one who started this thread, please allow me to raise one > important consideration to this discussion. > > This discussion has gone down the path of whether immediate data > boosts > performance and is implementable or whether it is so demanding that it > is not feasible to implement. > > I believe the decision on what the default value must assume for this > parameter must be based on what is going to be the simplest for the > login process and which setting minimizes the overheads involved for > completion of login. > > The reason for applying the above criteria is that it provides the > benefit of completing login negotiation in a single handshake and in > most cases, where initiator goes with the defaults, allows no > negotiation to be required whatsoever. [in the case where no security > is > being negotiated.]. This has the significant benefit of boosting iscsi > interoperability, since it has been seen that login is one of the most > painful areas of iscsi. > > With the above in mind, let us consider the 2 cases, Immediate data > default to "yes" & "no" (assuming neither side is interested in > security) : > > In the first case (default immediate data="yes') : > -------------------------------------------------- > - Initiator wishes to use immediate data. Target does not support it. > > I -> T : (no key is sent. default assumed for immediate data). > (CSG=Operational, NSG=FullFeaturePhase). T=1 > > T -> I : ImmediateData="no" (tgt does not support imm data.) > (CSG=Operational,NSG=Operational). T=0 > > I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1 > (no keys to negotiate. > negotiation completed at initiator. > only phase change taking place.) > > T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1 > (target completes phase change. > both sides move to FFP.) > > Thus, in the above model, there's an extra dummy login handshake, when > the default ImmediateData is "yes" but targets don't support it for > the > sole purpose of completing the login phase change. > > Now, take the case of default ImmediateData set to "no" : > --------------------------------------------------------- > - Initiator wants to use immediate data. target does not support it. > (same scenario as above). > > I -> T : ImmediateData="yes" > (CSG=Operational. NSG=FullFeaturePhase.). T=1 > > T -> I : ImmediateData="no" > (CSG=Operational. NSG=FullFeaturePhase). T=1 > > - Initiator does not want to use immediate data. > > I -> T : (no key is sent. defaults assumed). > (CSG=Operational. NSG=FullFeaturePhase). T=1 > > T -> I : (targets can accept all defaults since they > are conservative.) > (CSG=Operational, NSG=FullFeaturePhase). T=1 > > > Thus, as you can see from the above, the login process involves the > least number of exchanges when the default for ImmediateData is chosen > to be "no", as opposed to a default of "yes". > > It DOES NOT matter whether some believe ImmediateData is useful and > feasible or some believe it is useful but not feasible, or yet some > others believe it is not useful. > > What MUST govern this decision is which default allows for the > simplest > login operation. > > >From the above, it seems to me like a default of "no" for > ImmediateData > allows login to be completed in a single handshake in the case where > initiators wishes to use immediate data or not, and in the case where > target supports immediate data or not. > > Therefore, I request the group to please consider setting the > ImmediateData default to "no" and vote for the setting of "no". This > decision benefits BOTH the camp of immediate data users and non-users, > since both benefit from minimized steps in the login process. > > Thanks, > Santosh > > -------------------------------------------------------------------------- > > Robert Snively wrote: > > > > 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 > > > > -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## --=_alternative 003947D8C2256ADA_= Content-Type: text/html; charset="us-ascii"
I think I sent them out to you in a private note. Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@cup.hp.com

01-10-01 20:59
Please respond to Santosh Rao

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

       


Julian,
It would be more helpful to the discussion if you pointed out why you
think the examples are incorrect, rather than your terse comment below
:)

Specifically, my example is based on the following text from Section 5.1
of Rev 08 draft which states :

"An initiator that can operate without security and with all the
operational parameters taking the default values issues the Login with
the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG
set to FullFeaturePhase. If the target is also ready to forego security
and LoginOperationalNegotiation the Login response is empty and has T
bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to
FullFeaturePhase in the next stage."

I look forward to your clarification of the expected login handshakes in
the scenarios I raised.

Thanks,
Santosh




Julian Satran wrote:
>
> ... the debate would be of some interest if the examples where
> correct.
>
> But unfortunately they are not.
>
> Julo
>
>   Santosh Rao
>   <santoshr@cup.hp.com>                   To:        ips@ece.cmu.edu
>   Sent by: owner-ips@ece.cmu.edu          cc:
>                                           Subject:        Re: iscsi :
>   01-10-01 18:18                  iscsi parameter default values
>   Please respond to Santosh Rao
>
>
> All,
>
> As the one who started this thread, please allow me to raise one
> important consideration to this discussion.
>
> This discussion has gone down the path of whether immediate data
> boosts
> performance and is implementable or whether it is so demanding that it
> is not feasible to implement.
>
> I believe the decision on what the default value must assume for this
> parameter must be based on what is going to be the simplest for the
> login process and which setting minimizes the overheads involved for
> completion of login.
>
> The reason for applying the above criteria is that it provides the
> benefit of completing login negotiation in a single handshake and in
> most cases, where initiator goes with the defaults, allows no
> negotiation to be required whatsoever. [in the case where no security
> is
> being negotiated.]. This has the significant benefit of boosting iscsi
> interoperability, since it has been seen that login is one of the most
> painful areas of iscsi.
>
> With the above in mind, let us consider the 2 cases, Immediate data
> default to "yes" & "no" (assuming neither side is interested in
> security) :
>
> In the first case (default immediate data="yes') :
> --------------------------------------------------
> - Initiator wishes to use immediate data. Target does not support it.
>
> I -> T : (no key is sent. default assumed for immediate data).
>                  (CSG=Operational, NSG=FullFeaturePhase). T=1
>
> T -> I : ImmediateData="no" (tgt does not support imm data.)
>                  (CSG=Operational,NSG=Operational). T=0
>
> I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1
>         (no keys to negotiate.
>          negotiation completed at initiator.
>          only phase change taking place.)
>
> T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1
>         (target completes phase change.
>          both sides move to FFP.)
>
> Thus, in the above model, there's an extra dummy login handshake, when
> the default ImmediateData is "yes" but targets don't support it for
> the
> sole purpose of completing the login phase change.
>
> Now, take the case of default ImmediateData set to "no" :
> ---------------------------------------------------------
> - Initiator wants to use immediate data. target does not support it.
> (same scenario as above).
>
> I -> T : ImmediateData="yes"
>         (CSG=Operational. NSG=FullFeaturePhase.). T=1
>
> T -> I : ImmediateData="no"
>                  (CSG=Operational. NSG=FullFeaturePhase). T=1
>
> - Initiator does not want to use immediate data.
>
> I -> T : (no key is sent. defaults assumed).
>         (CSG=Operational. NSG=FullFeaturePhase). T=1
>
> T -> I : (targets can accept all defaults since they
>                   are conservative.)
>                  (CSG=Operational, NSG=FullFeaturePhase). T=1
>
>
> Thus, as you can see from the above, the login process involves the
> least number of exchanges when the default for ImmediateData is chosen
> to be "no", as opposed to a default of "yes".
>
> It DOES NOT matter whether some believe ImmediateData is useful and
> feasible or some believe it is useful but not feasible, or yet some
> others believe it is not useful.
>
> What MUST govern this decision is which default allows for the
> simplest
> login operation.
>
> >From the above, it seems to me like a default of "no" for
> ImmediateData
> allows login to be completed in a single handshake in the case where
> initiators wishes to use immediate data or not, and in the case where
> target supports immediate data or not.
>
> Therefore, I request the group to please consider setting the
> ImmediateData default to "no" and vote for the setting of "no". This
> decision benefits BOTH the camp of immediate data users and non-users,
> since both benefit from minimized steps in the login process.
>
> Thanks,
> Santosh
>
> --------------------------------------------------------------------------
>
> Robert Snively wrote:
> >
> > 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
> > > >


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

--=_alternative 003947D8C2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 08:56: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 IAA11886 for ; Wed, 3 Oct 2001 08:56:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93C8ir00450 for ips-outgoing; Wed, 3 Oct 2001 08:08:44 -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 f93C8fP00442 for ; Wed, 3 Oct 2001 08:08:42 -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 OAA60170 for ; Wed, 3 Oct 2001 14:08:34 +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 f93C8YI15438 for ; Wed, 3 Oct 2001 14:08:34 +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" Message-ID: Date: Wed, 3 Oct 2001 15:08:32 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 15:08:33, Serialize complete at 03/10/2001 15:08:33 Content-Type: multipart/alternative; boundary="=_alternative 0042BE13C2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0042BE13C2256ADA_= Content-Type: text/plain; charset="us-ascii" Santosh, I see now where you took your rules from. Those where meant to be only examples but I will reformulate the offending paragraph as: An initiator that can operate without security and with all the operational parameters taking the default values issues the Login with the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase. If the target is also ready to forego security and can finish its LoginOperationalNegotiation the Login response has T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase in the next stage. Regards, Julo Santosh Rao Sent by: santoshr@cup.hp.com 01-10-01 23:36 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iscsi : iscsi parameter default values Julian, The login section is somewhat contradictory b/n the wording you point out below and the following wording : "An initiator that can operate without security and with all the operational parameters taking the default values issues the Login with the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase. If the target is also ready to forego security and LoginOperationalNegotiation the Login response is empty and has T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase in the next stage." Per the above wording, the target can : - only set T bit to 1 and change phase from Operational to FullFeaturePhase if it has no keys to send back. Thus, when a target is unable to function with a default key setting, it will need to originate a key, remain in operational phase and respond with T=0. From the above wording, it appears that while the key negotiation has ended (per your wording below), the login remains in Operational Phase due to the target having to return NSG=Operational (per the above wording). Hence, the scenario/example I sent earlier is valid, per the above wordings in the draft rev 08. I suggest the following that the above wording be re-phrased to allow the target to change phase any time it is done with its keys and has no more parameters to send. (i.e. it can set T=1 and still send back parameters. Login response need not be empty.) Regards, Santosh Julian Satran wrote: > > Santosh, > > I assume that you know by now but here is the key anyhow: > > Robert, > > The I and T are required to send enough messages so that every one of > them will be able to evaluate the result with new data (stated > explicitly with an example in 2.2.4 > > 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). > > This is one of the reasons of selecting a computed value. > > You introduce an exchange not needed. > The behavior you want is supported but not mandated. > I will introduce explicit wording in 09. > > Julo > > Santosh Rao > To: Julian > Sent by: santoshr@cup.hp.com Satran/Haifa/IBM@IBMIL > cc: > 01-10-01 19:08 Subject: Re: iscsi : > Please respond to Santosh Rao iscsi parameter default values > > > > Julian, > > Could you please comment on why the examples are incorrect and what > are > the login hand-shakes for the scenarios suggested. > > Thanks, > Santosh > > Julian Satran wrote: > > > > ... the debate would be of some interest if the examples where > > correct. > > > > But unfortunately they are not. > > > > Julo > > > > Santosh Rao > > To: ips@ece.cmu.edu > > Sent by: owner-ips@ece.cmu.edu cc: > > Subject: Re: iscsi > : > > 01-10-01 18:18 iscsi parameter default values > > Please respond to Santosh Rao > > > > > > All, > > > > As the one who started this thread, please allow me to raise one > > important consideration to this discussion. > > > > This discussion has gone down the path of whether immediate data > > boosts > > performance and is implementable or whether it is so demanding that > it > > is not feasible to implement. > > > > I believe the decision on what the default value must assume for > this > > parameter must be based on what is going to be the simplest for the > > login process and which setting minimizes the overheads involved for > > completion of login. > > > > The reason for applying the above criteria is that it provides the > > benefit of completing login negotiation in a single handshake and in > > most cases, where initiator goes with the defaults, allows no > > negotiation to be required whatsoever. [in the case where no > security > > is > > being negotiated.]. This has the significant benefit of boosting > iscsi > > interoperability, since it has been seen that login is one of the > most > > painful areas of iscsi. > > > > With the above in mind, let us consider the 2 cases, Immediate data > > default to "yes" & "no" (assuming neither side is interested in > > security) : > > > > In the first case (default immediate data="yes') : > > -------------------------------------------------- > > - Initiator wishes to use immediate data. Target does not support > it. > > > > I -> T : (no key is sent. default assumed for immediate data). > > (CSG=Operational, NSG=FullFeaturePhase). T=1 > > > > T -> I : ImmediateData="no" (tgt does not support imm data.) > > (CSG=Operational,NSG=Operational). T=0 > > > > I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1 > > (no keys to negotiate. > > negotiation completed at initiator. > > only phase change taking place.) > > > > T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1 > > (target completes phase change. > > both sides move to FFP.) > > > > Thus, in the above model, there's an extra dummy login handshake, > when > > the default ImmediateData is "yes" but targets don't support it for > > the > > sole purpose of completing the login phase change. > > > > Now, take the case of default ImmediateData set to "no" : > > --------------------------------------------------------- > > - Initiator wants to use immediate data. target does not support it. > > (same scenario as above). > > > > I -> T : ImmediateData="yes" > > (CSG=Operational. NSG=FullFeaturePhase.). T=1 > > > > T -> I : ImmediateData="no" > > (CSG=Operational. NSG=FullFeaturePhase). T=1 > > > > - Initiator does not want to use immediate data. > > > > I -> T : (no key is sent. defaults assumed). > > (CSG=Operational. NSG=FullFeaturePhase). T=1 > > > > T -> I : (targets can accept all defaults since they > > are conservative.) > > (CSG=Operational, NSG=FullFeaturePhase). T=1 > > > > > > Thus, as you can see from the above, the login process involves the > > least number of exchanges when the default for ImmediateData is > chosen > > to be "no", as opposed to a default of "yes". > > > > It DOES NOT matter whether some believe ImmediateData is useful and > > feasible or some believe it is useful but not feasible, or yet some > > others believe it is not useful. > > > > What MUST govern this decision is which default allows for the > > simplest > > login operation. > > > > >From the above, it seems to me like a default of "no" for > > ImmediateData > > allows login to be completed in a single handshake in the case where > > initiators wishes to use immediate data or not, and in the case > where > > target supports immediate data or not. > > > > Therefore, I request the group to please consider setting the > > ImmediateData default to "no" and vote for the setting of "no". This > > decision benefits BOTH the camp of immediate data users and > non-users, > > since both benefit from minimized steps in the login process. > > > > 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 0042BE13C2256ADA_= Content-Type: text/html; charset="us-ascii"
Santosh,

I see now where you took your rules from. Those where meant to be only examples but I will reformulate the offending paragraph as:

An initiator that can operate without security and with all the operational parameters taking the default values issues the Login with the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase. If the target is also ready to forego security and can finish its LoginOperationalNegotiation the Login response  has T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to FullFeaturePhase in the next stage.

Regards,
Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@cup.hp.com

01-10-01 23:36
Please respond to Santosh Rao

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        Re: iscsi : iscsi parameter default values

       


Julian,

The login section is somewhat contradictory b/n the wording you point
out below and the following wording :

"An initiator that can operate without security and with all the
operational parameters taking the default values issues the Login with
the T bit set to 1, the CSG set to LoginOperationalNegotiation and NSG
set to FullFeaturePhase. If the target is also ready to forego security
and LoginOperationalNegotiation the Login response is empty and has T
bit set to 1, the CSG set to LoginOperationalNegotiation and NSG set to
FullFeaturePhase in the next stage."

Per the above wording, the target can :
- only set T bit to 1 and change phase from Operational to
FullFeaturePhase if it has no keys to send back.

Thus, when a target is unable to function with a default key setting, it
will need to originate a key, remain in operational phase and respond
with T=0.

From the above wording, it appears that while the key negotiation has
ended (per your wording below), the login remains in Operational Phase
due to the target having to return NSG=Operational (per the above
wording). Hence, the scenario/example I sent earlier is  valid, per the
above wordings in the draft rev 08.

I suggest the following that the above wording be re-phrased to allow
the target to change phase any time it is done with its keys and has no
more parameters to send. (i.e. it can set T=1 and still send back
parameters. Login response need not be empty.)

Regards,
Santosh


Julian Satran wrote:
>
> Santosh,
>
> I assume that you know by now but here is the key anyhow:
>
> Robert,
>
> The I and T are required to send enough messages so that every one of
> them will be able to evaluate the result with new data (stated
> explicitly  with an example in 2.2.4
>
> 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).
>
> This is one of the reasons of selecting a computed value.
>
> You introduce an exchange not needed.
> The behavior you want is supported but not mandated.
> I will introduce explicit wording in 09.
>
> Julo
>
>   Santosh Rao
>   <santoshr@cup.hp.com>                 To:        Julian
>   Sent by: santoshr@cup.hp.com  Satran/Haifa/IBM@IBMIL
>                                         cc:
>   01-10-01 19:08                        Subject:        Re: iscsi :
>   Please respond to Santosh Rao iscsi parameter default values
>
>
>
> Julian,
>
> Could you please comment on why the examples are incorrect and what
> are
> the login hand-shakes for the scenarios suggested.
>
> Thanks,
> Santosh
>
> Julian Satran wrote:
> >
> > ... the debate would be of some interest if the examples where
> > correct.
> >
> > But unfortunately they are not.
> >
> > Julo
> >
> >   Santosh Rao
> >   <santoshr@cup.hp.com>                   To:        ips@ece.cmu.edu
> >   Sent by: owner-ips@ece.cmu.edu          cc:
> >                                           Subject:        Re: iscsi
> :
> >   01-10-01 18:18                  iscsi parameter default values
> >   Please respond to Santosh Rao
> >
> >
> > All,
> >
> > As the one who started this thread, please allow me to raise one
> > important consideration to this discussion.
> >
> > This discussion has gone down the path of whether immediate data
> > boosts
> > performance and is implementable or whether it is so demanding that
> it
> > is not feasible to implement.
> >
> > I believe the decision on what the default value must assume for
> this
> > parameter must be based on what is going to be the simplest for the
> > login process and which setting minimizes the overheads involved for
> > completion of login.
> >
> > The reason for applying the above criteria is that it provides the
> > benefit of completing login negotiation in a single handshake and in
> > most cases, where initiator goes with the defaults, allows no
> > negotiation to be required whatsoever. [in the case where no
> security
> > is
> > being negotiated.]. This has the significant benefit of boosting
> iscsi
> > interoperability, since it has been seen that login is one of the
> most
> > painful areas of iscsi.
> >
> > With the above in mind, let us consider the 2 cases, Immediate data
> > default to "yes" & "no" (assuming neither side is interested in
> > security) :
> >
> > In the first case (default immediate data="yes') :
> > --------------------------------------------------
> > - Initiator wishes to use immediate data. Target does not support
> it.
> >
> > I -> T : (no key is sent. default assumed for immediate data).
> >                  (CSG=Operational, NSG=FullFeaturePhase). T=1
> >
> > T -> I : ImmediateData="no" (tgt does not support imm data.)
> >                  (CSG=Operational,NSG=Operational). T=0
> >
> > I -> T : (CSG=Operational, NSG=FullFeaturePhase). T=1
> >         (no keys to negotiate.
> >          negotiation completed at initiator.
> >          only phase change taking place.)
> >
> > T -> I : (CSG=Operational, NSG=FullFeaturePhase). T=1
> >         (target completes phase change.
> >          both sides move to FFP.)
> >
> > Thus, in the above model, there's an extra dummy login handshake,
> when
> > the default ImmediateData is "yes" but targets don't support it for
> > the
> > sole purpose of completing the login phase change.
> >
> > Now, take the case of default ImmediateData set to "no" :
> > ---------------------------------------------------------
> > - Initiator wants to use immediate data. target does not support it.
> > (same scenario as above).
> >
> > I -> T : ImmediateData="yes"
> >         (CSG=Operational. NSG=FullFeaturePhase.). T=1
> >
> > T -> I : ImmediateData="no"
> >                  (CSG=Operational. NSG=FullFeaturePhase). T=1
> >
> > - Initiator does not want to use immediate data.
> >
> > I -> T : (no key is sent. defaults assumed).
> >         (CSG=Operational. NSG=FullFeaturePhase). T=1
> >
> > T -> I : (targets can accept all defaults since they
> >                   are conservative.)
> >                  (CSG=Operational, NSG=FullFeaturePhase). T=1
> >
> >
> > Thus, as you can see from the above, the login process involves the
> > least number of exchanges when the default for ImmediateData is
> chosen
> > to be "no", as opposed to a default of "yes".
> >
> > It DOES NOT matter whether some believe ImmediateData is useful and
> > feasible or some believe it is useful but not feasible, or yet some
> > others believe it is not useful.
> >
> > What MUST govern this decision is which default allows for the
> > simplest
> > login operation.
> >
> > >From the above, it seems to me like a default of "no" for
> > ImmediateData
> > allows login to be completed in a single handshake in the case where
> > initiators wishes to use immediate data or not, and in the case
> where
> > target supports immediate data or not.
> >
> > Therefore, I request the group to please consider setting the
> > ImmediateData default to "no" and vote for the setting of "no". This
> > decision benefits BOTH the camp of immediate data users and
> non-users,
> > since both benefit from minimized steps in the login process.
> >
> > 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 0042BE13C2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 09:00: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 JAA12223 for ; Wed, 3 Oct 2001 09:00:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93CGeF00867 for ips-outgoing; Wed, 3 Oct 2001 08:16: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 f93CGZP00861 for ; Wed, 3 Oct 2001 08:16: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 OAA34524 for ; Wed, 3 Oct 2001 14:16: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.97.1) with ESMTP id f93CGRI263758 for ; Wed, 3 Oct 2001 14:16:28 +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: Wed, 3 Oct 2001 15:16:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 15:16:27, Serialize complete at 03/10/2001 15:16:27 Content-Type: multipart/alternative; boundary="=_alternative 004376EDC2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004376EDC2256ADA_= Content-Type: text/plain; charset="us-ascii" Santosh, Yes we are getting nowhere. You do not seem to accept the disadvantages of restricting the selection to the responder and I will not agree to add a restriction unless it has unequivocal value. Recall please that both sides have to effect the same computation anyhow and you add a reject state (and thus make the state machines more complex) only for having a clear result on the wire (internally the result is the same in all cases). Julo Santosh Rao Sent by: santoshr@cup.hp.com 01-10-01 23:52 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: Re: iscsi : numerical negotiation wording is ambiguous Julian, It does appear that we are getting nowhere with this discussion :<. I would like to re-iterate the advantages of the "responder computes negotiation result" model vs. the "both sides compute negotiation result" model again : 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. The originator only needs to only check that the response it got back is acceptable. Standard parsing technique in mass storage. (ex : FC PLOGI, FC PRLI, SCSI Mode Sense parsing by initiator uses the same scheme.) 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. 6) Less protocol rules to be enforced. No need to call out the rules for each side explicitly. The responder picks the result & sends it back to originator. Clearly, at least 3 developers read the draft to imply the negotiation scheme in use is "responder picks the negotiation result". So, there is room for mis-interpretation here. Based on the above advantages, I feel it is a safer model, with no room for mis-interpretations. In addition, it aids debugging & involves less code. Lastly, I suggest that the draft call out explicitly that the initiator is ALWAYS the originating party and the target is ALWAYS the responding party for ALL security and operational keys. This is due to each key having either a default value(in case initiator chose to use the default and not send the key), or the key is mandated to be sent by initiator. Thanks, Santosh Julian Satran wrote: > > Santosh, > > We are getting nowhere. Even if requester is doing it's stuff - the > requester will have to check and be prepared for a mistake. The coding > will require a reject. > > Julo > > Santosh Rao > To: ips@ece.cmu.edu > Sent by: santoshr@cup.hp.com cc: "Sanjeev Bhagat > (TRIPACE/Zoetermeer)" > 01-10-01 20:37 , Julian > Please respond to Santosh Rao Satran/Haifa/IBM@IBMIL > Subject: Re: iscsi : > numerical negotiation wording is > ambiguous > > > > Julian & Sanjeev, > > Responding to both your mails...... > > Julian : > > I think you may have mis-interpreted my comments. I believe Sanjeev > has > clarified the intent of my suggestions. > > I am *not* suggesting that the responder send back its values and > these > be blindly imposed on the originator. On the contrary, my suggestion > is > that the computation of the result of the negotiation (higher or lower > of the 2 values) be only performed by the responder and sent back to > the > originator. > > The result of the negotiation is the same in both cases and there is > no > REJECT required in my case nor yours. The difference is the advantages > I've stated in my model. > > Sanjeev, in response to your comment : > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. " > > There is NO need for any REJECT in the above case. If the initiator > is'nt satisfied with the value returned by the originator and cannot > function with the negotiated values, it can simply close the TCP > connection. There is no need to send any REJECT. > > Thanks, > Santosh > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Thanks Julian, please find my further comments in the message > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Sunday, September 30, 2001 6:07 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : numerical negotiation wording is > > ambiguous > > > > 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > say it this way the responder computes the value with > > its own supported values and responds with a value y > > which the responder thinks is correct 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > but it is highly unlikely for the responder to reject > > the final result because the rule states that (lower or > > higher of two will be the result) and so the offering > > party should be able to accept the lower or higher > > range as defined by rule. In case the key is dependent > > upon some range of fixed values then the negotiation > > should be performed as list negotiation and not > > numerical negotiation. > > > > This might be what you "conventionally" do - I don't > > and that shows that convention like morals are a matter > > of geography :-) > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > The advantage of this set of rules is that it allows an > > external observer to know what was selected without > > knowing the rules > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > case, I guess that the external observer has to know > > the rules to double check the value is correct or not > > 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. > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. > > > > > > Sanjeev > > "Sanjeev Bhagat > > (TRIPACE/Zoetermeer)" To: "'Santosh > Rao'" > > , Julian > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > cc: > ips@ece.cmu.edu > > 30-09-01 16:32 Subject: RE: > iscsi : > > Please respond to "Sanjeev numerical negotiation wording > is > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > -- > ################################## > 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 ################################## --=_alternative 004376EDC2256ADA_= Content-Type: text/html; charset="us-ascii"
Santosh,

Yes we are getting nowhere.

You do not seem to accept the disadvantages of restricting the selection to the responder
and I will not agree to add a restriction unless it has unequivocal value.

Recall please that both sides have to effect the same computation anyhow and you add a reject state (and thus make the state machines more complex) only for having a clear result on the wire (internally the result is the same in all cases).

Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@cup.hp.com

01-10-01 23:52
Please respond to Santosh Rao

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        Re: iscsi : numerical negotiation wording is ambiguous

       


Julian,

It does appear that we are getting nowhere with this discussion :<. I
would like to re-iterate the advantages of the "responder computes
negotiation result" model vs. the "both sides compute negotiation
result" model again :

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. The originator only
needs to only check that the response it got back is acceptable.
Standard parsing technique in mass storage. (ex : FC PLOGI, FC PRLI,
SCSI Mode Sense parsing by initiator uses the same scheme.)

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.

6) Less protocol rules to be enforced. No need to call out the rules for
each side explicitly. The responder picks the result & sends it back to
originator.

Clearly, at least 3 developers read the draft to imply the negotiation
scheme in use is "responder picks the negotiation result". So, there is
room for mis-interpretation here. Based on the above advantages, I feel
it is a safer model, with no room for mis-interpretations. In addition,
it aids debugging & involves less code.

Lastly, I suggest that the draft call out explicitly that the initiator
is ALWAYS the originating party and the target is ALWAYS the responding
party for ALL security and operational keys. This is due to each key
having either a default value(in case initiator chose to use the default
and not send the key), or the key is mandated to be sent by initiator.

Thanks,
Santosh


Julian Satran wrote:
>
> Santosh,
>
> We are getting nowhere. Even if requester is doing it's stuff - the
> requester will have to check and be prepared for a mistake. The coding
> will require a reject.
>
> Julo
>
>   Santosh Rao
>   <santoshr@cup.hp.com>                 To:        ips@ece.cmu.edu
>   Sent by: santoshr@cup.hp.com          cc:        "Sanjeev Bhagat
>                                 (TRIPACE/Zoetermeer)"
>   01-10-01 20:37                <sbhagat@tripace.com>, Julian
>   Please respond to Santosh Rao Satran/Haifa/IBM@IBMIL
>                                         Subject:        Re: iscsi :
>                                 numerical negotiation wording is
>                                 ambiguous
>
>
>
> Julian & Sanjeev,
>
> Responding to both your mails......
>
> Julian :
>
> I think you may have mis-interpreted my comments. I believe Sanjeev
> has
> clarified the intent of my suggestions.
>
> I am *not* suggesting that the responder send back its values and
> these
> be blindly imposed on the originator. On the contrary, my suggestion
> is
> that the computation of the result of the negotiation (higher or lower
> of the 2 values) be only performed by the responder and sent back to
> the
> originator.
>
> The result of the negotiation is the same in both cases and there is
> no
> REJECT required in my case nor yours. The difference is the advantages
> I've stated in my model.
>
> Sanjeev, in response to your comment :
>
> " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> >  no reject , but it can be a problem in future .
> >  Consider your example of DataPDULength in your own
> >  message. Suppose offering party sends a value of 16,384
> >  (this is also lowest value it can send) and responding
> >  party responds with 8,192. In this case the offering
> >  party will have to reject the negotiation. So a reject
> >  message is needed in this case also. "
>
> There is NO need for any REJECT in the above case. If the initiator
> is'nt satisfied with the value returned by the originator and cannot
> function with the negotiated values, it can simply close the TCP
> connection. There is no need to send any REJECT.
>
> Thanks,
> Santosh
>
> > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> >
> > Thanks Julian, please find my further comments in the message
> >
> >      -----Original Message-----
> >      From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> >      Sent: Sunday, September 30, 2001 6:07 PM
> >      To: ips@ece.cmu.edu
> >      Subject: RE: iscsi : numerical negotiation wording is
> >      ambiguous
> >
> >      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
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather
> >           say it this way the responder computes the value with
> >           its own supported values and responds with a value y
> >           which the responder thinks is correct 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
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct,
> >           but it is highly unlikely for the responder to reject
> >           the final result because the rule states that (lower or
> >           higher of two will be the result) and so the offering
> >           party should be able to accept the lower or higher
> >           range as defined by rule. In case the key is dependent
> >           upon some range of fixed values then the negotiation
> >           should be performed as list negotiation and not
> >           numerical negotiation.
> >
> >           This might be what you "conventionally" do - I don't
> >           and that shows that convention like morals are a matter
> >           of geography :-)
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-)
> >
> >           The advantage of this set of rules is that it allows an
> >           external observer to know what was selected without
> >           knowing the rules
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this
> >           case, I guess that the external observer has to know
> >           the rules to double check the value is correct or not
> >           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.
> >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> >           no reject , but it can be a problem in future .
> >           Consider your example of DataPDULength in your own
> >           message. Suppose offering party sends a value of 16,384
> >           (this is also lowest value it can send) and responding
> >           party responds with 8,192. In this case the offering
> >           party will have to reject the negotiation. So a reject
> >           message is needed in this case also.
> >
> >
> >      Sanjeev
> >       "Sanjeev Bhagat
> >       (TRIPACE/Zoetermeer)"                    To:        "'Santosh
> Rao'"
> >       <sbhagat@tripace.com>            <santoshr@cup.hp.com>, Julian
> >       Sent by: owner-ips@ece.cmu.edu   Satran/Haifa/IBM@IBMIL
> >                                                cc:
>  ips@ece.cmu.edu
> >       30-09-01 16:32                           Subject:        RE:
> iscsi :
> >       Please respond to "Sanjeev       numerical negotiation wording
> is
> >       Bhagat (TRIPACE/Zoetermeer)"     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
> >
>
> --
> ##################################
> 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
##################################

--=_alternative 004376EDC2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 09:04: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 JAA12446 for ; Wed, 3 Oct 2001 09:04:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93CRCU01448 for ips-outgoing; Wed, 3 Oct 2001 08:27: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 f93CR8P01443 for ; Wed, 3 Oct 2001 08:27: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 OAA305788 for ; Wed, 3 Oct 2001 14:26: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.97.1) with ESMTP id f93CQxI142212 for ; Wed, 3 Oct 2001 14:26:59 +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: Wed, 3 Oct 2001 15:26:58 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 15:26:59, Serialize complete at 03/10/2001 15:26:59 Content-Type: multipart/alternative; boundary="=_alternative 00446DBCC2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00446DBCC2256ADA_= Content-Type: text/plain; charset="us-ascii" An example: 08.txt logic i->t DataPDULength=16k t->i DataPDULength= 24k Selected value is 16k i->t DataPDULength=16k t->i DataPDULength= 8k Selected value is 8k t->i DataPDULength=16k i->t DataPDULength= 24k Selected value is 16k t->i DataPDULength=16k i->t DataPDULength= 8k Selected value is 8k ----- Responder selects logic i->t DataPDULength=16k t->i DataPDULength= 24k Error - Initiator Reject - Closes connection i->t DataPDULength=16k t->i DataPDULength= 8k Selected value is 8k t->i DataPDULength=16k i->t DataPDULength= 24k Error Target has to terminate with parameter error t->i DataPDULength=16k i->t DataPDULength= 8k Selected value is 8k "Dev - Platys" 01-10-01 23:46 Please respond to "Dev - Platys" To: "Julian Satran" , cc: Subject: RE: iscsi : numerical negotiation wording is ambiguous Julian, I am not sure why a 'REJECT' is required. Can you please explain why is this required? I am with Santosh in this. >There is NO need for any REJECT in the above >case. If the initiator >is'nt satisfied with the value returned by the >originator and cannot >function with the negotiated values, it can simply >close the TCP >connection. There is no need to send any >REJECT. Thanks Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Monday, October 01, 2001 1:28 PM To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous Santosh, We are getting nowhere. Even if requester is doing it's stuff - the requester will have to check and be prepared for a mistake. The coding will require a reject. Julo Santosh Rao Sent by: santoshr@cup.hp.com 01-10-01 20:37 Please respond to Santosh Rao To: ips@ece.cmu.edu cc: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , Julian Satran/Haifa/IBM@IBMIL Subject: Re: iscsi : numerical negotiation wording is ambiguous Julian & Sanjeev, Responding to both your mails...... Julian : I think you may have mis-interpreted my comments. I believe Sanjeev has clarified the intent of my suggestions. I am *not* suggesting that the responder send back its values and these be blindly imposed on the originator. On the contrary, my suggestion is that the computation of the result of the negotiation (higher or lower of the 2 values) be only performed by the responder and sent back to the originator. The result of the negotiation is the same in both cases and there is no REJECT required in my case nor yours. The difference is the advantages I've stated in my model. Sanjeev, in response to your comment : " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. " There is NO need for any REJECT in the above case. If the initiator is'nt satisfied with the value returned by the originator and cannot function with the negotiated values, it can simply close the TCP connection. There is no need to send any REJECT. Thanks, Santosh > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > Thanks Julian, please find my further comments in the message > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Sunday, September 30, 2001 6:07 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : numerical negotiation wording is > ambiguous > > 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 > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > say it this way the responder computes the value with > its own supported values and responds with a value y > which the responder thinks is correct 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 > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > but it is highly unlikely for the responder to reject > the final result because the rule states that (lower or > higher of two will be the result) and so the offering > party should be able to accept the lower or higher > range as defined by rule. In case the key is dependent > upon some range of fixed values then the negotiation > should be performed as list negotiation and not > numerical negotiation. > > This might be what you "conventionally" do - I don't > and that shows that convention like morals are a matter > of geography :-) > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > The advantage of this set of rules is that it allows an > external observer to know what was selected without > knowing the rules > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > case, I guess that the external observer has to know > the rules to double check the value is correct or not > 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. > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. > > > Sanjeev > "Sanjeev Bhagat > (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" > , Julian > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > 30-09-01 16:32 Subject: RE: iscsi : > Please respond to "Sanjeev numerical negotiation wording is > Bhagat (TRIPACE/Zoetermeer)" 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 > -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## --=_alternative 00446DBCC2256ADA_= Content-Type: text/html; charset="us-ascii"
An example:
 08.txt logic
i->t DataPDULength=16k
t->i DataPDULength= 24k

Selected value is 16k

i->t DataPDULength=16k
t->i DataPDULength= 8k

Selected value is 8k

t->i DataPDULength=16k
i->t DataPDULength= 24k

Selected value is 16k

t->i DataPDULength=16k
i->t DataPDULength= 8k

Selected value is 8k

-----

Responder selects logic

i->t DataPDULength=16k
t->i DataPDULength= 24k

Error - Initiator Reject - Closes connection

i->t DataPDULength=16k
t->i DataPDULength= 8k

Selected value is 8k

t->i DataPDULength=16k
i->t DataPDULength= 24k

Error Target has to terminate with parameter error

t->i DataPDULength=16k
i->t DataPDULength= 8k

Selected value is 8k




"Dev - Platys" <deva@platys.com>

01-10-01 23:46
Please respond to "Dev - Platys"

       
        To:        "Julian Satran" <Julian_Satran@il.ibm.com>, <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: iscsi : numerical negotiation wording is ambiguous

       


Julian,
 
I am not sure why a 'REJECT' is required.
Can you please explain why is this required?
 
I am with Santosh in this.
 
>There is NO need for any REJECT in the above >case. If the initiator
>is'nt satisfied with the value returned by the >originator and cannot
>function with the negotiated values, it can simply >close the TCP
>connection. There is no need to send any >REJECT.

Thanks
 
Deva
Adaptec


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran
Sent: Monday, October 01, 2001 1:28 PM
To: ips@ece.cmu.edu
Subject: Re: iscsi : numerical negotiation wording is ambiguous

Santosh,

We are getting nowhere. Even if requester is doing it's stuff - the requester will have to check and be prepared for a mistake. The coding will require a reject.

Julo

Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@cup.hp.com

01-10-01 20:37
Please respond to Santosh Rao

       
       To:        ips@ece.cmu.edu
       cc:        "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>, Julian Satran/Haifa/IBM@IBMIL
       Subject:        Re: iscsi : numerical negotiation wording is ambiguous

     



Julian & Sanjeev,

Responding to both your mails......

Julian :

I think you may have mis-interpreted my comments. I believe Sanjeev has
clarified the intent of my suggestions.

I am *not* suggesting that the responder send back its values and these
be blindly imposed on the originator. On the contrary, my suggestion is
that the computation of the result of the negotiation (higher or lower
of the 2 values) be only performed by the responder and sent back to the
originator.

The result of the negotiation is the same in both cases and there is no
REJECT required in my case nor yours. The difference is the advantages
I've stated in my model.


Sanjeev, in response to your comment :

" [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
>  no reject , but it can be a problem in future .
>  Consider your example of DataPDULength in your own
>  message. Suppose offering party sends a value of 16,384
>  (this is also lowest value it can send) and responding
>  party responds with 8,192. In this case the offering
>  party will have to reject the negotiation. So a reject
>  message is needed in this case also. "


There is NO need for any REJECT in the above case. If the initiator
is'nt satisfied with the value returned by the originator and cannot
function with the negotiated values, it can simply close the TCP
connection. There is no need to send any REJECT.


Thanks,
Santosh


> "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
>
> Thanks Julian, please find my further comments in the message
>
>      -----Original Message-----
>      From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
>      Sent: Sunday, September 30, 2001 6:07 PM
>      To: ips@ece.cmu.edu
>      Subject: RE: iscsi : numerical negotiation wording is
>      ambiguous
>
>      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
>           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather
>           say it this way the responder computes the value with
>           its own supported values and responds with a value y
>           which the responder thinks is correct 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
>           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct,
>           but it is highly unlikely for the responder to reject
>           the final result because the rule states that (lower or
>           higher of two will be the result) and so the offering
>           party should be able to accept the lower or higher
>           range as defined by rule. In case the key is dependent
>           upon some range of fixed values then the negotiation
>           should be performed as list negotiation and not
>           numerical negotiation.
>
>           This might be what you "conventionally" do - I don't
>           and that shows that convention like morals are a matter
>           of geography :-)
>           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-)
>
>           The advantage of this set of rules is that it allows an
>           external observer to know what was selected without
>           knowing the rules
>           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this
>           case, I guess that the external observer has to know
>           the rules to double check the value is correct or not
>           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.
>           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
>           no reject , but it can be a problem in future .
>           Consider your example of DataPDULength in your own
>           message. Suppose offering party sends a value of 16,384
>           (this is also lowest value it can send) and responding
>           party responds with 8,192. In this case the offering
>           party will have to reject the negotiation. So a reject
>           message is needed in this case also.
>
>
>      Sanjeev
>       "Sanjeev Bhagat
>       (TRIPACE/Zoetermeer)"                    To:        "'Santosh Rao'"
>       <sbhagat@tripace.com>            <santoshr@cup.hp.com>, Julian
>       Sent by: owner-ips@ece.cmu.edu   Satran/Haifa/IBM@IBMIL
>                                                cc:        ips@ece.cmu.edu
>       30-09-01 16:32                           Subject:        RE: iscsi :
>       Please respond to "Sanjeev       numerical negotiation wording is
>       Bhagat (TRIPACE/Zoetermeer)"     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
>


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

--=_alternative 00446DBCC2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 11: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 LAA18007 for ; Wed, 3 Oct 2001 11:10:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93EFqO08065 for ips-outgoing; Wed, 3 Oct 2001 10:15: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 f93EFoP08060 for ; Wed, 3 Oct 2001 10:15: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 QAA37460 for ; Wed, 3 Oct 2001 16:15:42 +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 f93EFgI175750 for ; Wed, 3 Oct 2001 16:15:42 +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" Message-ID: Date: Wed, 3 Oct 2001 17:15:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 17:15:42, Serialize complete at 03/10/2001 17:15:42 Content-Type: multipart/alternative; boundary="=_alternative 004E61A3C2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004E61A3C2256ADA_= Content-Type: text/plain; charset="us-ascii" According to 08 to change from yes to no you need one ONE-WAY message - i.e. you are guranteed to end in one roundtrip (the function is AND). Going from no to yes you need 2-ONE WAY messages - i.e. if initiator starts the 2 are in one round trip if target starts there 2 round-trips. With this a default of yes is easier to handle on all defaults. Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 02-10-01 15:48 Please respond to "Eddy Quicksall" To: John Hufferd/San Jose/IBM@IBMUS, "'Dev - Platys'" cc: Subject: RE: iscsi : iscsi parameter default values First, realize I just want to give information as I see it from an objective standpoint. Regarding your reply below, login is not cached so the "immediate data" techniques used there are quite different then the techniques used during full feature phase in legacy cache. In another mail, I explained why some legacy cache implementations would have to be changed and cache is probably the last thing you would want to change if you are in a "time to market" crunch. Remember, this is not in the transport layer. The thing we should probably be looking at is "what requires the least number of round trips and are the round trips really significant". Eddy -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Monday, October 01, 2001 6:33 PM To: Dev - Platys Cc: Eddy Quicksall; ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values You will need the same type of Immediate Data handling code to handle the Login. The Login Parameters are in the extended Data Section of the PDU. So you have to have that code anyway. Given that you have to have the code anyway, in both cases ImmediateData=Yes and No -- Yes is the simplest, the best performing, and the lowest overhead, so Yes should be the default. . . . 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 "Dev - Platys" @ece.cmu.edu on 10/01/2001 02:39:57 PM Sent by: owner-ips@ece.cmu.edu To: "Eddy Quicksall" , cc: Subject: RE: iscsi : iscsi parameter default values Thats a good point. Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Eddy Quicksall Sent: Monday, October 01, 2001 2:11 PM To: ips@ece.cmu.edu Subject: RE: iscsi : iscsi parameter default values Looking at this from another view point ... Isn't support of R2T required anyway because the Expected Data Transfer Length may exceed the FirstBurstSize? So, wouldn't that make "no" the "lowest common denominator"? If so, I would think that "no" would therefore be the default. Just food for thought. Eddy --=_alternative 004E61A3C2256ADA_= Content-Type: text/html; charset="us-ascii"
According to 08 to change from yes to no you need one ONE-WAY message - i.e. you are guranteed to end in one roundtrip (the function is AND).
Going from no to yes you need 2-ONE WAY messages - i.e. if initiator starts the 2 are in one round trip if target starts there 2 round-trips.

With this a default of yes is easier to handle on all defaults.

Julo


"Eddy Quicksall" <Eddy_Quicksall@ivivity.com>
Sent by: owner-ips@ece.cmu.edu

02-10-01 15:48
Please respond to "Eddy Quicksall"

       
        To:        John Hufferd/San Jose/IBM@IBMUS, "'Dev - Platys'" <deva@platys.com>
        cc:        <ips@ece.cmu.edu>
        Subject:        RE: iscsi : iscsi parameter default values

       


First, realize I just want to give information as I see it from an objective
standpoint.

Regarding your reply below, login is not cached so the "immediate data"
techniques used there are quite different then the techniques used during
full feature phase in legacy cache.

In another mail, I explained why some legacy cache implementations would
have to be changed and cache is probably the last thing you would want to
change if you are in a "time to market" crunch. Remember, this is not in the
transport layer.

The thing we should probably be looking at is "what requires the least
number of round trips and are the round trips really significant".

Eddy

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Monday, October 01, 2001 6:33 PM
To: Dev - Platys
Cc: Eddy Quicksall; ips@ece.cmu.edu
Subject: RE: iscsi : iscsi parameter default values



You will need the same type of Immediate Data handling code to handle the
Login.  The Login Parameters are in the extended Data Section of the PDU.
So you have to have that code anyway.

Given that you have to have the code anyway, in both cases
ImmediateData=Yes and No -- Yes is the simplest, the best performing, and
the lowest overhead, so Yes should be the default.

.
.
.
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


"Dev - Platys" <deva@platys.com>@ece.cmu.edu on 10/01/2001 02:39:57 PM

Sent by:  owner-ips@ece.cmu.edu


To:   "Eddy Quicksall" <EQuicksall@mediaone.net>, <ips@ece.cmu.edu>
cc:
Subject:  RE: iscsi : iscsi parameter default values



Thats a good point.

Deva
Adaptec


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Eddy Quicksall
Sent: Monday, October 01, 2001 2:11 PM
To: ips@ece.cmu.edu
Subject: RE: iscsi : iscsi parameter default values


Looking at this from another view point ...

Isn't support of R2T required anyway because the Expected Data Transfer
Length may exceed the FirstBurstSize?

So, wouldn't that make "no" the "lowest common denominator"? If so, I would
think that "no" would therefore be the default.

Just food for thought.

Eddy

--=_alternative 004E61A3C2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 11:18: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 LAA18146 for ; Wed, 3 Oct 2001 11:18:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93EU0W09009 for ips-outgoing; Wed, 3 Oct 2001 10:30:00 -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 f93ETvP08999 for ; Wed, 3 Oct 2001 10:29:57 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Wed Oct 3 10:25:08 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Wed Oct 3 10:29:42 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 KAA03278 for ; Wed, 3 Oct 2001 10:29:01 -0400 (EDT) Message-ID: <3BBB20AD.F4FA549E@research.bell-labs.com> Date: Wed, 03 Oct 2001 10:29:01 -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 : 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 The first & third example below seem illogical. The responder should not be sending 24K if the initial sender has chosen a value of 16K, since there is no possibility of that 24K being accepted (unless we want three way exchanges for every negotiation??) The problem of a Reject message does not arise since the responder should only be choosing something less than 16K. So I guess this puts me in the "responder selects logic" camp. -Sandeep Julian Satran wrote: > > An example: > 08.txt logic > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Selected value is 16k > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Selected value is 16k > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k > > ----- > > Responder selects logic > > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Error - Initiator Reject - Closes connection > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Error Target has to terminate with parameter error > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k > > "Dev - Platys" > To: "Julian Satran" > , > 01-10-01 23:46 > Please respond to "Dev - cc: > Platys" Subject: RE: iscsi : > numerical negotiation wording is ambiguous > > > > Julian, > > I am not sure why a 'REJECT' is required. > Can you please explain why is this required? > > I am with Santosh in this. > > >There is NO need for any REJECT in the above >case. If the initiator > >is'nt satisfied with the value returned by the >originator and cannot > >function with the negotiated values, it can simply >close the TCP > >connection. There is no need to send any >REJECT. > > Thanks > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Monday, October 01, 2001 1:28 PM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > Santosh, > > We are getting nowhere. Even if requester is doing it's stuff - the > requester will have to check and be prepared for a mistake. The coding > will require a reject. > > Julo > > Santosh Rao > To: ips@ece.cmu.edu > Sent by: cc: "Sanjeev Bhagat > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > Julian Satran/Haifa/IBM@IBMIL > 01-10-01 20:37 Subject: Re: iscsi : numerical > Please respond to negotiation wording is ambiguous > Santosh Rao > > > Julian & Sanjeev, > > Responding to both your mails...... > > Julian : > > I think you may have mis-interpreted my comments. I believe Sanjeev > has > clarified the intent of my suggestions. > > I am *not* suggesting that the responder send back its values and > these > be blindly imposed on the originator. On the contrary, my suggestion > is > that the computation of the result of the negotiation (higher or lower > of the 2 values) be only performed by the responder and sent back to > the > originator. > > The result of the negotiation is the same in both cases and there is > no > REJECT required in my case nor yours. The difference is the advantages > I've stated in my model. > > Sanjeev, in response to your comment : > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. " > > There is NO need for any REJECT in the above case. If the initiator > is'nt satisfied with the value returned by the originator and cannot > function with the negotiated values, it can simply close the TCP > connection. There is no need to send any REJECT. > > Thanks, > Santosh > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Thanks Julian, please find my further comments in the message > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Sunday, September 30, 2001 6:07 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : numerical negotiation wording is > > ambiguous > > > > 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > say it this way the responder computes the value with > > its own supported values and responds with a value y > > which the responder thinks is correct 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > but it is highly unlikely for the responder to reject > > the final result because the rule states that (lower or > > higher of two will be the result) and so the offering > > party should be able to accept the lower or higher > > range as defined by rule. In case the key is dependent > > upon some range of fixed values then the negotiation > > should be performed as list negotiation and not > > numerical negotiation. > > > > This might be what you "conventionally" do - I don't > > and that shows that convention like morals are a matter > > of geography :-) > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > The advantage of this set of rules is that it allows an > > external observer to know what was selected without > > knowing the rules > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > case, I guess that the external observer has to know > > the rules to double check the value is correct or not > > 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. > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. > > > > > > Sanjeev > > "Sanjeev Bhagat > > (TRIPACE/Zoetermeer)" To: "'Santosh > Rao'" > > , Julian > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > cc: > ips@ece.cmu.edu > > 30-09-01 16:32 Subject: RE: > iscsi : > > Please respond to "Sanjeev numerical negotiation wording > is > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > -- > ################################## > 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 Wed Oct 3 12:30: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 MAA20598 for ; Wed, 3 Oct 2001 12:30:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93FWpf13693 for ips-outgoing; Wed, 3 Oct 2001 11:32:51 -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 f93FWoP13689 for ; Wed, 3 Oct 2001 11:32:50 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 11:29:52 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD809@CORPMX14> From: Black_David@emc.com To: lxing@Crossroads.com, ips@ece.cmu.edu Subject: iSCSI: Inquiry, Mode Sense, Read Capacity Date: Wed, 3 Oct 2001 11:24:54 -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 These are SCSI questions that are not specific to iSCSI. > 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. The answers are to be found in careful reading of the relevant SCSI specs - SAM2, SBC, and SBC2 in this case. The SCSI specs make specific distinctions among data, status, and response, and the T10 document editors are very good about making sure that such terms are well-defined and used only in the manner defined. INQUIRY, MODE SENSE, and READ CAPACITY are all defined to return data, and hence would use one or more iSCSI Data-in PDUs for that purpose. The Response PDU is there for dealing with command completion and the like. For example, if one of these commands starts to transfer data and then fails at the Target, one would see one or more Data-in PDUs followed by a Response PDU containing CHECK CONDITION or something like that, and the data field of the Response PDU would be needed for the sense data (AutoSense is mandatory for iSCSI) and the like. > 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.? See previous answer. Data-in transfers data for any SCSI command that has data to transfer. This includes all three of your examples. "READ" actually includes any SCSI command that transfers "data" (as that term is defined by SCSI) from Target to Initiator. This includes INQUIRY, MODE SENSE, and READ CAPACITY. > 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. The assumption following the "If" is incorrect, and IMHO, this is already sufficiently clear from the T10 SCSI specs, which MUST be read in conjunction with the iSCSI spec to completely understand how SCSI works over iSCSI. OTOH, Section 3.7 of the iSCSI draft could use a couple of sentences pointing out that the Data-in and Data-out PDUs are used for all SCSI data transfers, not just those associated with the READ and WRITE commands. 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 Oct 3 12:32: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 MAA20805 for ; Wed, 3 Oct 2001 12:32:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93Fref15202 for ips-outgoing; Wed, 3 Oct 2001 11:53: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 f93FrdP15197 for ; Wed, 3 Oct 2001 11:53:39 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 11:53:34 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD80A@CORPMX14> From: Black_David@emc.com To: tdineen@redswitch.com, ips@ece.cmu.edu Subject: IPS: shall, SHALL, must, MUST, etc. Date: Wed, 3 Oct 2001 11:45:40 -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 response to a couple of Thomas's comments on requirements terminology, let me offer some general guidance: First, "SHALL" is acceptable IETF terminology, and is equivalent to "MUST" - see RFC 2119. Second, let me try to explain the distinction between upper case lower case versions of these and other terms/phrases defined in RFC 2119. Upper case versions of MUST, SHOULD, MAY, etc. are used to specify requirements imposed upon implementations - as indicated by Section 6 of RFC 2119, they MUST be used only when necessary. Lower case versions of these terms are potentially ambiguous - they may indicate requirements or may be descriptive of what happens as a consequence of other requirements, constraints, etc. If the intent is to impose a requirement, the upper case versions are appropriate to avoid this ambiguity, as if it's possible to interpret a lower case version as not imposing a requirement, someone will interpret it in that fashion. As to Thomas's specific comments on iSCSI requirements: > Comment 6: > > Section 5.2 on Page 115: > > "If the security negotiation fails at the target then the target MUST > send the appropriate Login Response PDU. If the security negotiation > fails at the initiator, the initiator [shall] drop the connection." > > - Do you really mean "shall"? Shall is IEEE terminology do > you not mean > "MUST"? This is a recurring problem in many places in the draft, for > brevity I would suggest a text search and examination of each "shall". > > Comment 8: > > Section 6 on Page 116: > > "If the target responds to a text request with the F bit set to 1, > with a text response with the F bit set to 0, the initiator > [must] keep > sending the text request (even empty) with the F bit set to 1 until > it gets the text response with the F bit set to 1. Responding to a > text request with the F bit set to 1 with an empty (no key=value > pairs) is not an error but is discouraged." > > - "must" versus "MUST"! Do you not mean "MUST"? This is a recurring > problem in many places in the draft, for brevity I would suggest a > text search and examination of each "must'. For comment 6, upper case is in order, and "SHALL" is acceptable; this falls under the "limit behavior which has the potential to cause harm" language in Section 6 of RFC 2119. This particular instance needs to be checked to determine if "SHOULD" is more appropriate (i.e., an Initiator who proceeds with connection setup despite security negotiation failure gets what it deserves in the area of security properties, and hence a strong warning rather than an absolute prohibition may be in order). For comment 8, upper case is again in order for the "MUST", and "is discouraged" needs to be replaced by language containing either "SHOULD NOT" or "NOT RECOMMENDED". 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 Oct 3 12:34: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 MAA20831 for ; Wed, 3 Oct 2001 12:34:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93FSQ913309 for ips-outgoing; Wed, 3 Oct 2001 11:28:26 -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 f93FSOP13297 for ; Wed, 3 Oct 2001 11:28: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 LAA109472; Wed, 3 Oct 2001 11:25: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.97.1) with ESMTP id f93FRwC55472; Wed, 3 Oct 2001 09:27:58 -0600 Importance: Normal Subject: Re: iSCSI-08 Comments 11 (definition of portal group) To: Thomas Dineen , ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 3 Oct 2001 08:27:54 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/03/2001 08:27:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Thomas, You must have missed it. The definition of "portal group" is in the archecture model on page 43 of section 2.5.1. The definition is not specificallly for initiator or target. See the second paragraph of item (d) in that clause. The definitions are summarized in the "definitions" section 1, on page 19. There is no qualification in the defintion to "target" only. Jim Hafner Thomas Dineen @ece.cmu.edu on 10/02/2001 07:04:48 pm Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu, Thomas Dineen cc: Subject: iSCSI-08 Comments 11 though 18 Comment 11: Section 9.1.1 on Page 137: "For an iSCSI Initiator, the SID values used by the session coordinators should be configurable parameters and the SID name space should be partitioned among the Initiator Portal Groups. This allows each Initiator Portal Group to act independently of other portal groups when selecting an SID for a logic; this facilitates enforcement of the SID RULE (see 2.5.3) at the initiator." - I do not believe "Initiator Portal Groups" as been defined. Please define in the Architecture Section at the beginning of the document. Comment 12: Section 9.3 on Page 138: "A task management command may reach the target and, in the case [where] immediate delivery was requested, be executed before all of the tasks it was meant to act upon have been delivered or even reached the target." - Please add the [where]. Comment 13: Appendix C on page 180: "18 RFMarkInt" and section 19 "The receiver indicates the minimum to maximum interval (in 4-byte words) [that] the receiver wants the markers. In case the receiver wants only a specific value, only a single value has to be specified." - Please add the [that]. - Please add an example to this section, and section 19. Comment 14: Appendix c on page 181: "19 SFMarkInt" "Indicates at what interval (in 4-byte words) the sender [accepts, expects] to send the markers. The number MUST be within the range required by the receiver. 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)." - Please replace [accepts] with [expects]. Comment 15: Appendix C on Page 185: 28 DataPDUInOrder "No is used by iSCSI to indicate that the data PDUs [within sequences] can be in any order. Yes is used to indicate that data PDUs within sequences have to be at continuously increasing addresses and overlays are forbidden." - Do you really mean within sequences? I thought this refereed to the ordering of the transfer of one sequence relative to another, and not the PDUs within a sequence? Comment 16: Appendix E on Page 190: "iSCSI addresses belonging with the same portal group tag support spanning multiple-connection sessions across this set of addresses." - An english problem, I would suggest a rewording. Comment 17: Appendix F on page 192: "This clause defines the alias entry formats and codes used in these commands to designate iSCSI devices or ports. As noted in 1.1, the protocol identifier used in these formats shall be set to 0x05 (see [SPC3]) and the format code values are defined in the following table:" - The IEEE uses the term clause, do we really want to use it in this context? I would suggest replacing [clause] with [Appendix]. Comment 18: - The numbering of the sections seem to increase across all appendices. I would suggest renumbering of the sections local to each appendix. From owner-ips@ece.cmu.edu Wed Oct 3 13:11: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 NAA22717 for ; Wed, 3 Oct 2001 13:11:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93GJGe17039 for ips-outgoing; Wed, 3 Oct 2001 12:19:16 -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 f93GJEP17035 for ; Wed, 3 Oct 2001 12:19: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 89EA01F6FB; Wed, 3 Oct 2001 09:19:08 -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 JAA18538; Wed, 3 Oct 2001 09:19:04 -0700 (PDT) Message-ID: <3BBB3C1B.A96CCBB8@cup.hp.com> Date: Wed, 03 Oct 2001 09:26:04 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Sandeep Joshi , Julian Satran Cc: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous References: <3BBB20AD.F4FA549E@research.bell-labs.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, Another value-add of the "responder picks the negotiation result model" is that the initiator can use the following "query based" negotiation model to always use the values the target is capable of offering : I -> T : DataPDULength=? T -> I : DataPDULength=64K Both sides agree to use a DataPDULength of 64K. In the "both sides pick negotiation result" model, the above cannot be achieved, since the initiator has to always offer a value. Thus, in the "both sides pick negotiation result" model , the above example would be : I -> T : DataPDULength=8K T -> I : DataPDULength=64K I -> T : DataPDULength=64K T -> I : DataPDULength=64K Both sides settle at 64K. I suggest that we allow the above "query based model", since this is more efficient to use when an initiator has no key limitations and would like to use the value a target can offer. In order to allow the "query based model", you would need to state in the draft that a key value of "?" over-rides the default, implying the target offered value would be the result of the negotiation. In particular, the "query based model" is quite useful when an initiator wishes to function with the target's maximal supported values for keys like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T, LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any limitations on its own key value. Comments ? Thanks, Santosh Sandeep Joshi wrote: > > The first & third example below seem illogical. > > The responder should not be sending 24K if the initial > sender has chosen a value of 16K, since there is no > possibility of that 24K being accepted (unless we want > three way exchanges for every negotiation??) > > The problem of a Reject message does not arise since the > responder should only be choosing something less than 16K. > So I guess this puts me in the "responder selects logic" > camp. > > -Sandeep > > Julian Satran wrote: > > > > An example: > > 08.txt logic > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Selected value is 16k > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Selected value is 16k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > ----- > > > > Responder selects logic > > > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Error - Initiator Reject - Closes connection > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Error Target has to terminate with parameter error > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > "Dev - Platys" > > To: "Julian Satran" > > , > > 01-10-01 23:46 > > Please respond to "Dev - cc: > > Platys" Subject: RE: iscsi : > > numerical negotiation wording is ambiguous > > > > > > > > Julian, > > > > I am not sure why a 'REJECT' is required. > > Can you please explain why is this required? > > > > I am with Santosh in this. > > > > >There is NO need for any REJECT in the above >case. If the initiator > > >is'nt satisfied with the value returned by the >originator and cannot > > >function with the negotiated values, it can simply >close the TCP > > >connection. There is no need to send any >REJECT. > > > > Thanks > > > > Deva > > Adaptec > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Monday, October 01, 2001 1:28 PM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > Santosh, > > > > We are getting nowhere. Even if requester is doing it's stuff - the > > requester will have to check and be prepared for a mistake. The coding > > will require a reject. > > > > Julo > > > > Santosh Rao > > To: ips@ece.cmu.edu > > Sent by: cc: "Sanjeev Bhagat > > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > > Julian Satran/Haifa/IBM@IBMIL > > 01-10-01 20:37 Subject: Re: iscsi : numerical > > Please respond to negotiation wording is ambiguous > > Santosh Rao > > > > > > Julian & Sanjeev, > > > > Responding to both your mails...... > > > > Julian : > > > > I think you may have mis-interpreted my comments. I believe Sanjeev > > has > > clarified the intent of my suggestions. > > > > I am *not* suggesting that the responder send back its values and > > these > > be blindly imposed on the originator. On the contrary, my suggestion > > is > > that the computation of the result of the negotiation (higher or lower > > of the 2 values) be only performed by the responder and sent back to > > the > > originator. > > > > The result of the negotiation is the same in both cases and there is > > no > > REJECT required in my case nor yours. The difference is the advantages > > I've stated in my model. > > > > Sanjeev, in response to your comment : > > > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. " > > > > There is NO need for any REJECT in the above case. If the initiator > > is'nt satisfied with the value returned by the originator and cannot > > function with the negotiated values, it can simply close the TCP > > connection. There is no need to send any REJECT. > > > > Thanks, > > Santosh > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Thanks Julian, please find my further comments in the message > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Sunday, September 30, 2001 6:07 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iscsi : numerical negotiation wording is > > > ambiguous > > > > > > 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > > say it this way the responder computes the value with > > > its own supported values and responds with a value y > > > which the responder thinks is correct 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > > but it is highly unlikely for the responder to reject > > > the final result because the rule states that (lower or > > > higher of two will be the result) and so the offering > > > party should be able to accept the lower or higher > > > range as defined by rule. In case the key is dependent > > > upon some range of fixed values then the negotiation > > > should be performed as list negotiation and not > > > numerical negotiation. > > > > > > This might be what you "conventionally" do - I don't > > > and that shows that convention like morals are a matter > > > of geography :-) > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > > > The advantage of this set of rules is that it allows an > > > external observer to know what was selected without > > > knowing the rules > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > > case, I guess that the external observer has to know > > > the rules to double check the value is correct or not > > > 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. > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. > > > > > > > > > Sanjeev > > > "Sanjeev Bhagat > > > (TRIPACE/Zoetermeer)" To: "'Santosh > > Rao'" > > > , Julian > > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > > cc: > > ips@ece.cmu.edu > > > 30-09-01 16:32 Subject: RE: > > iscsi : > > > Please respond to "Sanjeev numerical negotiation wording > > is > > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > > > > -- > > ################################## > > 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 Wed Oct 3 13:12: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 NAA22731 for ; Wed, 3 Oct 2001 13:12:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93GgIr18711 for ips-outgoing; Wed, 3 Oct 2001 12:42: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 f93GgFP18701 for ; Wed, 3 Oct 2001 12:42:15 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 96F361F710 for ; Wed, 3 Oct 2001 09:42:08 -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 JAA19628 for ; Wed, 3 Oct 2001 09:42:04 -0700 (PDT) Message-ID: <3BBB4180.53CC928@cup.hp.com> Date: Wed, 03 Oct 2001 09:49:04 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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: [Fwd: iscsi : task mgmt response codes.] 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 the reply. Also, would you be adding the "Function Not Supported" response code to the list of task mgmt response codes, to indicate lack of support for certain task mgmt functions ? Regards, Santosh Julian Satran wrote: > > Santosh, > > Sorry for not answering explicitly - I was overwhelmed. The text in 08 > has an additional statement that might help clarify: > > For additional usage semantics, see section 8.1. > > Regards, > Julo > > Santosh Rao > To: Julian > Sent by: santoshr@cup.hp.com Satran/Haifa/IBM@IBMIL > cc: > 01-10-01 21:54 Subject: [Fwd: iscsi : > Please respond to Santosh Rao task mgmt response codes.] > > > > Julian, > > I did'nt hear back from you on the below issue. I look forward to your > comments on the same. > > Thanks, > Santosh > > Santosh Rao wrote: > > > > 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 > ################################## -- ################################## 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 Wed Oct 3 13:14: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 NAA22781 for ; Wed, 3 Oct 2001 13:14:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93G7cd16169 for ips-outgoing; Wed, 3 Oct 2001 12:07:38 -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 f93EgvP09856 for ; Wed, 3 Oct 2001 10:42:57 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f93EgZS31992; Wed, 3 Oct 2001 10:42:35 -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 f93EgZn09739; Wed, 3 Oct 2001 10:42:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15291.9217.545000.905841@gargle.gargle.HOWL> Date: Wed, 3 Oct 2001 10:43:13 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous 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 3 October 2001) by Julian Satran: > An example: > 08.txt logic > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Selected value is 16k > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Selected value is 16k > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k > > ----- > > Responder selects logic > > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Error - Initiator Reject - Closes connection > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Error Target has to terminate with parameter error > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k In most protocols, "responder selects" is used. And the rule is that the responder MUST respond with a value acceptable to both sides. Therefore, if the negotiation rule for DataPDULength is to pick the smaller of the two values preferred by the two sides, your first and third examples would be defective implementations. Often, protocol specs don't say what to do with defective implementations; a typical answer is to terminate the conversation, which is a sensible answer. Sending rejects is not that useful for defective implementations, since there is no reason to assume that they will all of a sudden start to act correctly. Also, it is useful to build in protocol mechanisms for bit errors, memory errors, dropped packets, etc. -- but it is generally NOT useful to build mechanisms that apply only when the other side has a software bug. I agree with Deva that the appropriate response to a protocol violation is to terminate the conversation. So for "responder selects" examples 1 and 3 should have read like this: i->t DataPDULength=16k t->i DataPDULength= 16k (t wants 24 but 16 is the agreed value) ... t->i DataPDULength=16k i->t DataPDULength= 16k (i wants 24 but 16 is the agreed value) paul From owner-ips@ece.cmu.edu Wed Oct 3 13:15: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 NAA22807 for ; Wed, 3 Oct 2001 13:15:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93G9jP16323 for ips-outgoing; Wed, 3 Oct 2001 12:09:45 -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 f93G9iP16319 for ; Wed, 3 Oct 2001 12:09:44 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 12:06:46 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD80B@CORPMX14> From: Black_David@emc.com To: sandeepj@research.bell-labs.com, ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Date: Wed, 3 Oct 2001 12:01: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 At the risk of complicating this further, I tend to agree with Sandeep - in the first and third examples, the second message in the negotiation contains a value that the sender already knows the other side will not accept (in both cases, the other side has already said that 16k is the max, and so sending 24k makes it look like the 16k was ignored). What's the harm in requiring that such unacceptable values never be sent? Under this requirement, the second value in both the first and third cases would be 16k, and there's a much easier rule to figure out the result - last value sent in either direction governs. --David > -----Original Message----- > From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] > Sent: Wednesday, October 03, 2001 10:29 AM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > The first & third example below seem illogical. > > The responder should not be sending 24K if the initial > sender has chosen a value of 16K, since there is no > possibility of that 24K being accepted (unless we want > three way exchanges for every negotiation??) > > The problem of a Reject message does not arise since the > responder should only be choosing something less than 16K. > So I guess this puts me in the "responder selects logic" > camp. > > -Sandeep > > > Julian Satran wrote: > > > > An example: > > 08.txt logic > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Selected value is 16k > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Selected value is 16k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > ----- > > > > Responder selects logic > > > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Error - Initiator Reject - Closes connection > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Error Target has to terminate with parameter error > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > "Dev - Platys" > > To: "Julian Satran" > > , > > 01-10-01 23:46 > > Please respond to "Dev - cc: > > Platys" Subject: RE: iscsi : > > numerical negotiation wording is > ambiguous > > > > > > > > Julian, > > > > I am not sure why a 'REJECT' is required. > > Can you please explain why is this required? > > > > I am with Santosh in this. > > > > >There is NO need for any REJECT in the above >case. If the > initiator > > >is'nt satisfied with the value returned by the >originator > and cannot > > >function with the negotiated values, it can simply >close the TCP > > >connection. There is no need to send any >REJECT. > > > > Thanks > > > > Deva > > Adaptec > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Monday, October 01, 2001 1:28 PM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > Santosh, > > > > We are getting nowhere. Even if requester is doing it's stuff - the > > requester will have to check and be prepared for a mistake. > The coding > > will require a reject. > > > > Julo > > > > Santosh Rao > > To: ips@ece.cmu.edu > > Sent by: cc: "Sanjeev Bhagat > > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > > Julian Satran/Haifa/IBM@IBMIL > > 01-10-01 20:37 Subject: Re: iscsi : numerical > > Please respond to negotiation wording is ambiguous > > Santosh Rao > > > > > > Julian & Sanjeev, > > > > Responding to both your mails...... > > > > Julian : > > > > I think you may have mis-interpreted my comments. I believe Sanjeev > > has > > clarified the intent of my suggestions. > > > > I am *not* suggesting that the responder send back its values and > > these > > be blindly imposed on the originator. On the contrary, my suggestion > > is > > that the computation of the result of the negotiation > (higher or lower > > of the 2 values) be only performed by the responder and sent back to > > the > > originator. > > > > The result of the negotiation is the same in both cases and there is > > no > > REJECT required in my case nor yours. The difference is the > advantages > > I've stated in my model. > > > > Sanjeev, in response to your comment : > > > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. " > > > > There is NO need for any REJECT in the above case. If the initiator > > is'nt satisfied with the value returned by the originator and cannot > > function with the negotiated values, it can simply close the TCP > > connection. There is no need to send any REJECT. > > > > Thanks, > > Santosh > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Thanks Julian, please find my further comments in the message > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Sunday, September 30, 2001 6:07 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iscsi : numerical negotiation wording is > > > ambiguous > > > > > > 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > > say it this way the responder computes the value with > > > its own supported values and responds with a value y > > > which the responder thinks is correct 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > > but it is highly unlikely for the responder to reject > > > the final result because the rule states that (lower or > > > higher of two will be the result) and so the offering > > > party should be able to accept the lower or higher > > > range as defined by rule. In case the key is dependent > > > upon some range of fixed values then the negotiation > > > should be performed as list negotiation and not > > > numerical negotiation. > > > > > > This might be what you "conventionally" do - I don't > > > and that shows that convention like morals are a matter > > > of geography :-) > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > > > The advantage of this set of rules is that it allows an > > > external observer to know what was selected without > > > knowing the rules > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > > case, I guess that the external observer has to know > > > the rules to double check the value is correct or not > > > 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. > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. > > > > > > > > > Sanjeev > > > "Sanjeev Bhagat > > > (TRIPACE/Zoetermeer)" To: > "'Santosh > > Rao'" > > > > , Julian > > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > > cc: > > ips@ece.cmu.edu > > > 30-09-01 16:32 Subject: RE: > > iscsi : > > > Please respond to "Sanjeev numerical > negotiation wording > > is > > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > > > > -- > > ################################## > > 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 Wed Oct 3 13:17: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 NAA22851 for ; Wed, 3 Oct 2001 13:17:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93G80g16203 for ips-outgoing; Wed, 3 Oct 2001 12:08:00 -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 f93G7uP16187 for ; Wed, 3 Oct 2001 12:07:56 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 61B7490B; Wed, 3 Oct 2001 09:07: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 JAA18099; Wed, 3 Oct 2001 09:07:50 -0700 (PDT) Message-ID: <3BBB397A.1052C9CD@cup.hp.com> Date: Wed, 03 Oct 2001 09:14:50 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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: iscsi : login key & stage negotiation proposal. 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 believe you may be [still] mis-interpreting my proposed change and that may be the basis for your rejecting the proposal. Let me re-iterate once again the clarification I made in : http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06924.html The "responder picks the negotiation result" scheme proposes just what the title states. The responder of a negotiation computes the result of a negotiation and sends back its computed redult as its response to the originator, instead of sending back its supported value. Note that the above proposal is also consistent with the manner in which list negotiation is performed today. With list negotiation, the responder picks a value from the originating party's offered list and sends this value back. I am proposing that a similar scheme be used for all negotiations, [numerical, list & binary]. In all types of negotiation, the responding party always send back the result of the negotiation based on its computation. I also suggest that the same model be applied to the negotiation of login stages. i.e. The target respond with its NSG set to the next stage both sides can switch to, instead of each side offering their NSG's and both sides picking the lower NSG. This keeps all forms of negotiation consistent in their model and simpler to understand. I have made corrections inline to the below examples. Further, I have a question about how/when a target would be originating ANY operational parameters ? Is it not the case that for all operational parameters, we have EITHER a default defined or mandated that the initiator send this key. Given the above, the target would never be originating a key. It would always be responding to an initiator's offered value for a key. This offered value may either be explicit or implicit thru a default specification. I hope I'm doing a little better at explaining myself :-) Or, are we still talking past each other. (?). More inline.... Thanks, Santosh Julian Satran wrote: > > An example: > 08.txt logic > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Selected value is 16k > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Selected value is 16k > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k > > ----- > > Responder selects logic > > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Error - Initiator Reject - Closes connection The above example is incorrect. It should read : i -> t : DataPDuLength=16K t -> i : DataPDULength=16K (target supports 24K, initiator supports 16K. lower of the 2 is sent back as the result of the negotiation.) > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Error Target has to terminate with parameter error Please see my note above on target always being the responder. Hence, the above example should actually read : i -> t : (no explicit value offered for DataPDULength. Default of 8K assumed). t -> i : DataPDULength=8K. (tgt supports 16k, initiator asks for 8K. result of 8K is sent back.) Thus, for all operational keys, the negotiation must end with a t->i exchange. Also, I suggest that a target ALWAYS respond to any key that the initiator explicitly send it. This keeps the negotiation result more explicitly known to both sides, as opposed to target silently dropping any binary negotiation key if it was offered as a "no". > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k > > "Dev - Platys" > To: "Julian Satran" > , > 01-10-01 23:46 > Please respond to "Dev - cc: > Platys" Subject: RE: iscsi : > numerical negotiation wording is ambiguous > > > > Julian, > > I am not sure why a 'REJECT' is required. > Can you please explain why is this required? > > I am with Santosh in this. > > >There is NO need for any REJECT in the above >case. If the initiator > >is'nt satisfied with the value returned by the >originator and cannot > >function with the negotiated values, it can simply >close the TCP > >connection. There is no need to send any >REJECT. > > Thanks > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Monday, October 01, 2001 1:28 PM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > Santosh, > > We are getting nowhere. Even if requester is doing it's stuff - the > requester will have to check and be prepared for a mistake. The coding > will require a reject. > > Julo > > Santosh Rao > To: ips@ece.cmu.edu > Sent by: cc: "Sanjeev Bhagat > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > Julian Satran/Haifa/IBM@IBMIL > 01-10-01 20:37 Subject: Re: iscsi : numerical > Please respond to negotiation wording is ambiguous > Santosh Rao > > > Julian & Sanjeev, > > Responding to both your mails...... > > Julian : > > I think you may have mis-interpreted my comments. I believe Sanjeev > has > clarified the intent of my suggestions. > > I am *not* suggesting that the responder send back its values and > these > be blindly imposed on the originator. On the contrary, my suggestion > is > that the computation of the result of the negotiation (higher or lower > of the 2 values) be only performed by the responder and sent back to > the > originator. > > The result of the negotiation is the same in both cases and there is > no > REJECT required in my case nor yours. The difference is the advantages > I've stated in my model. > > Sanjeev, in response to your comment : > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. " > > There is NO need for any REJECT in the above case. If the initiator > is'nt satisfied with the value returned by the originator and cannot > function with the negotiated values, it can simply close the TCP > connection. There is no need to send any REJECT. > > Thanks, > Santosh > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Thanks Julian, please find my further comments in the message > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Sunday, September 30, 2001 6:07 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : numerical negotiation wording is > > ambiguous > > > > 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > say it this way the responder computes the value with > > its own supported values and responds with a value y > > which the responder thinks is correct 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > but it is highly unlikely for the responder to reject > > the final result because the rule states that (lower or > > higher of two will be the result) and so the offering > > party should be able to accept the lower or higher > > range as defined by rule. In case the key is dependent > > upon some range of fixed values then the negotiation > > should be performed as list negotiation and not > > numerical negotiation. > > > > This might be what you "conventionally" do - I don't > > and that shows that convention like morals are a matter > > of geography :-) > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > The advantage of this set of rules is that it allows an > > external observer to know what was selected without > > knowing the rules > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > case, I guess that the external observer has to know > > the rules to double check the value is correct or not > > 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. > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. > > > > > > Sanjeev > > "Sanjeev Bhagat > > (TRIPACE/Zoetermeer)" To: "'Santosh > Rao'" > > , Julian > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > cc: > ips@ece.cmu.edu > > 30-09-01 16:32 Subject: RE: > iscsi : > > Please respond to "Sanjeev numerical negotiation wording > is > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > -- > ################################## > 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 Wed Oct 3 13:57: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 NAA24064 for ; Wed, 3 Oct 2001 13:57:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93Gm7R19109 for ips-outgoing; Wed, 3 Oct 2001 12:48:07 -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 f93Gm4P19102 for ; Wed, 3 Oct 2001 12:48:04 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail16.vwh1.net (RS ver 1.0.60s) with SMTP id 033848165; Wed, 3 Oct 2001 12:07:36 -0400 (EDT) From: "Dev - Platys" To: "Sandeep Joshi" , Subject: RE: iscsi : numerical negotiation wording is ambiguous Date: Wed, 3 Oct 2001 09:14:14 -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: <3BBB20AD.F4FA549E@research.bell-labs.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, The point is, if the target is not capable of supporting 16K (it is just an example that is being discussed), then it indicates that is what it wants. Initiator can close the connection. (No reject is necessary though). However, if the target knows it can support the initiator negotiated value, it could return it. Again, Yes, implicitly it becomes the responder selects logic. Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Sandeep Joshi Sent: Wednesday, October 03, 2001 7:29 AM To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous The first & third example below seem illogical. The responder should not be sending 24K if the initial sender has chosen a value of 16K, since there is no possibility of that 24K being accepted (unless we want three way exchanges for every negotiation??) The problem of a Reject message does not arise since the responder should only be choosing something less than 16K. So I guess this puts me in the "responder selects logic" camp. -Sandeep Julian Satran wrote: > > An example: > 08.txt logic > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Selected value is 16k > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Selected value is 16k > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k > > ----- > > Responder selects logic > > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Error - Initiator Reject - Closes connection > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Error Target has to terminate with parameter error > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k > > "Dev - Platys" > To: "Julian Satran" > , > 01-10-01 23:46 > Please respond to "Dev - cc: > Platys" Subject: RE: iscsi : > numerical negotiation wording is ambiguous > > > > Julian, > > I am not sure why a 'REJECT' is required. > Can you please explain why is this required? > > I am with Santosh in this. > > >There is NO need for any REJECT in the above >case. If the initiator > >is'nt satisfied with the value returned by the >originator and cannot > >function with the negotiated values, it can simply >close the TCP > >connection. There is no need to send any >REJECT. > > Thanks > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Monday, October 01, 2001 1:28 PM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > Santosh, > > We are getting nowhere. Even if requester is doing it's stuff - the > requester will have to check and be prepared for a mistake. The coding > will require a reject. > > Julo > > Santosh Rao > To: ips@ece.cmu.edu > Sent by: cc: "Sanjeev Bhagat > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > Julian Satran/Haifa/IBM@IBMIL > 01-10-01 20:37 Subject: Re: iscsi : numerical > Please respond to negotiation wording is ambiguous > Santosh Rao > > > Julian & Sanjeev, > > Responding to both your mails...... > > Julian : > > I think you may have mis-interpreted my comments. I believe Sanjeev > has > clarified the intent of my suggestions. > > I am *not* suggesting that the responder send back its values and > these > be blindly imposed on the originator. On the contrary, my suggestion > is > that the computation of the result of the negotiation (higher or lower > of the 2 values) be only performed by the responder and sent back to > the > originator. > > The result of the negotiation is the same in both cases and there is > no > REJECT required in my case nor yours. The difference is the advantages > I've stated in my model. > > Sanjeev, in response to your comment : > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. " > > There is NO need for any REJECT in the above case. If the initiator > is'nt satisfied with the value returned by the originator and cannot > function with the negotiated values, it can simply close the TCP > connection. There is no need to send any REJECT. > > Thanks, > Santosh > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Thanks Julian, please find my further comments in the message > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Sunday, September 30, 2001 6:07 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : numerical negotiation wording is > > ambiguous > > > > 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > say it this way the responder computes the value with > > its own supported values and responds with a value y > > which the responder thinks is correct 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > but it is highly unlikely for the responder to reject > > the final result because the rule states that (lower or > > higher of two will be the result) and so the offering > > party should be able to accept the lower or higher > > range as defined by rule. In case the key is dependent > > upon some range of fixed values then the negotiation > > should be performed as list negotiation and not > > numerical negotiation. > > > > This might be what you "conventionally" do - I don't > > and that shows that convention like morals are a matter > > of geography :-) > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > The advantage of this set of rules is that it allows an > > external observer to know what was selected without > > knowing the rules > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > case, I guess that the external observer has to know > > the rules to double check the value is correct or not > > 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. > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. > > > > > > Sanjeev > > "Sanjeev Bhagat > > (TRIPACE/Zoetermeer)" To: "'Santosh > Rao'" > > , Julian > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > cc: > ips@ece.cmu.edu > > 30-09-01 16:32 Subject: RE: > iscsi : > > Please respond to "Sanjeev numerical negotiation wording > is > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > -- > ################################## > 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 Wed Oct 3 13:59: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 NAA24161 for ; Wed, 3 Oct 2001 13:59:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93GsLY19562 for ips-outgoing; Wed, 3 Oct 2001 12:54: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 f93GsIP19556 for ; Wed, 3 Oct 2001 12:54: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 SAA39496 for ; Wed, 3 Oct 2001 18:54:11 +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 f93GsBI85328 for ; Wed, 3 Oct 2001 18:54:11 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI : default iSCSI mode page settings - Consensus call X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Oct 2001 19:54:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 19:54:10, Serialize complete at 03/10/2001 19:54:10 Content-Type: multipart/alternative; boundary="=_alternative 005BFCC4C2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005BFCC4C2256ADA_= Content-Type: text/plain; charset="us-ascii" Robert, I agree. Per LU parameters have little or no relation to iSCSI. Regards, Julo Robert Snively Sent by: owner-ips@ece.cmu.edu 02-10-01 17:36 Please respond to Robert Snively To: ips@ece.cmu.edu cc: Subject: RE: iSCSI : default iSCSI mode page settings - Consensus call Folks, In an offline discussion, we have picked at a thread central to this fabric. That is basically the view that one has of the structure of targets. ------------------ Note sent out a day ago --------------- Traditional network environments talk from one big host memory to another big host memory. In the storage space, the memory in the target is actually distributed between whatever caching and preprocessing space the target platform may have and the space held by each logical unit. In some cases (RAIDs) the distribution is heavily in favor of the target platform cache. In others (tapes), individual logical units may have 100s of Megabytes of buffering which are not available to other logical units. If you have mixed types of logical units or if you have the memory distributed unevenly among the logical units, different values are normal among different LUs. Different sessions to the same LU may also have different properties. In particular, the LU may give away resources freely for the first few sessions, but more sparingly for subsequent sessions. Alternatively, the LU may share the resources dynamically, providing UNIT ATTENTION indications if it must change the values. The iSCSI target is merely a handy portal to the logical units and device servers, which really run the show. While many targets are simplified, sharing parameters across LUs and sessions, there is no requirement for that. Sophisticated devices may have individual parameters for each LU and session. iSCSI is trying hard to ignore the differences between storage and networking devices, but the differences are justified and genuine. ---------------- Some of the questions that triggered the note ----- > Are you saying that these parameters need to be able to have different > values for each LU among several LUs of single target in a single > session? > > Also would different sessions to the same LU all need to use the same > value? --------------- And a succinct summary of the thoughts --------------- If I understand correctly, in your view, such parameter negotiations should be per initiator and per LU. Parameters which are unique per logical unit can be set (or "negotiated") *only* via mode pages. Whether or not changing the value for one logical unit changes it for others would be target end implementer's choice, subject to appropriate parameter change notifications to the initiator(s). The values negotiated during login would be per initiator and per target default/initial values to be used when per LU mode pages have not been subsequently modified by this initiator. I am not reading that you think these values should not be settable at the per session level. Only that you believe there is a real need to be able to change them at the per LU level so that the per session values can be over-ridden for specific LUs. Changing the value for one LU via the mode pages would not have to change it for other LUs in this session nor for other sessions to this LU. Is that about right? --------- My answer would be yes ------------------------------------- --=_alternative 005BFCC4C2256ADA_= Content-Type: text/html; charset="us-ascii"
Robert,

I agree. Per LU parameters have little or no relation to iSCSI.

Regards,
Julo


Robert Snively <rsnively@Brocade.COM>
Sent by: owner-ips@ece.cmu.edu

02-10-01 17:36
Please respond to Robert Snively

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI : default iSCSI mode page settings - Consensus call

       


Folks,

In an offline discussion, we have picked at a thread
central to this fabric.  That is basically the view that
one has of the structure of targets.

------------------   Note sent out a day ago  ---------------

Traditional network environments talk from one big host
memory to another big host memory.  In the storage space, the
memory in the target is actually distributed between whatever
caching and preprocessing space the target platform may have
and the space held by each logical unit.  In some cases (RAIDs)
the distribution is heavily in favor of the target platform
cache.  In others (tapes), individual logical units may have
100s of Megabytes of buffering which are not available to other
logical units.  If you have mixed types of logical units or
if you have the memory distributed unevenly among the logical
units, different values are normal among different LUs.

Different sessions to the same LU may also have different
properties.  In particular, the LU may give away resources
freely for the first few sessions, but more sparingly for
subsequent sessions.  Alternatively, the LU may share the
resources dynamically, providing UNIT ATTENTION indications
if it must change the values.

The iSCSI target is merely a handy portal to the logical
units and device servers, which really run the show.  While
many targets are simplified, sharing parameters across LUs
and sessions, there is no requirement for that.  Sophisticated
devices may have individual parameters for each LU and
session.  iSCSI is trying hard to ignore the differences
between storage and networking devices, but the differences
are justified and genuine.

----------------   Some of the questions that triggered the note  -----

> Are you saying that these parameters need to be able to have different
> values for each LU among several LUs of single target in a single
> session?
>
> Also would different sessions to the same LU all need to use the same
> value?

---------------  And a succinct summary of the thoughts  ---------------

If I understand correctly, in your view, such parameter negotiations
should be per initiator and per LU.  Parameters which are unique per
logical unit can be set (or "negotiated") *only* via mode pages.
Whether or not changing the value for one logical unit changes it for
others would be target end implementer's choice, subject to appropriate
parameter change notifications to the initiator(s).  The values
negotiated during login would be per initiator and per target
default/initial values to be used when per LU mode pages have not been
subsequently modified by this initiator.

I am not reading that you think these values should not be settable at
the per session level.  Only that you believe there is a real need to be
able to change them at the per LU level so that the per session values
can be over-ridden for specific LUs.  Changing the value for one LU via
the mode pages would not have to change it for other LUs in this session
nor for other sessions to this LU.

Is that about right?

---------  My answer would be yes  -------------------------------------

--=_alternative 005BFCC4C2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 14:16: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 OAA24802 for ; Wed, 3 Oct 2001 14:16:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93HOhQ21771 for ips-outgoing; Wed, 3 Oct 2001 13:24:43 -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 f93HOfP21767 for ; Wed, 3 Oct 2001 13:24:41 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id AC7991F777; Wed, 3 Oct 2001 10:24: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 KAA23912; Wed, 3 Oct 2001 10:24:31 -0700 (PDT) Message-ID: <3BBB4B73.26A695B8@cup.hp.com> Date: Wed, 03 Oct 2001 10:31:31 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Dev - Platys , Julian Satran Cc: Sandeep Joshi , ips@ece.cmu.edu Subject: iscsi : DataPDULength can differ in each direction. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Deva, Julian & All, I think we have a more fundamental problem here, that spans beyond the issue of which negotiation model should be used for numerical & binary key negotiation. This problem needs to be addressed seperately. The DataPDULength can and should be allowed to be different in each direction. I -> T direction PDUs should be allowed to use a different PDU Length than T -> I direction PDUs. Each side should be allowed to specify the DataPDULength it will be using and there should be no attempt to negotiate this value. Rather, the key is exchanged in either direction to inform the other side as to what sized PDUs it should expect. This is somwhat akin to a protocol's MTU definition or a max_frame_size definition (ex : FC PLOGI Receive Data Field Size in its common service parameters.). THese values are allowed to be different going in each direction, allowing for implementation specific quirks that restrict the use of certain values. (ex : some DMA bugs may require implementations to have their DataPDULength to be a cache line size shorter, etc.) I suggest the definition of the DataPDULength key be re-phrased taking the above into account. Regards, Santosh Dev - Platys wrote: > > Santosh, > > The point is, if the target is not capable of supporting 16K (it is just an > example that is being discussed), then it indicates that is what it wants. > Initiator can close the connection. (No reject is necessary though). > > However, if the target knows it can support the initiator negotiated value, > it could return it. > > Again, Yes, implicitly it becomes the responder selects logic. > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Sandeep Joshi > Sent: Wednesday, October 03, 2001 7:29 AM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > The first & third example below seem illogical. > > The responder should not be sending 24K if the initial > sender has chosen a value of 16K, since there is no > possibility of that 24K being accepted (unless we want > three way exchanges for every negotiation??) > > The problem of a Reject message does not arise since the > responder should only be choosing something less than 16K. > So I guess this puts me in the "responder selects logic" > camp. > > -Sandeep > > Julian Satran wrote: > > > > An example: > > 08.txt logic > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Selected value is 16k > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Selected value is 16k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > ----- > > > > Responder selects logic > > > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Error - Initiator Reject - Closes connection > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Error Target has to terminate with parameter error > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > "Dev - Platys" > > To: "Julian Satran" > > , > > 01-10-01 23:46 > > Please respond to "Dev - cc: > > Platys" Subject: RE: iscsi : > > numerical negotiation wording is ambiguous > > > > > > > > Julian, > > > > I am not sure why a 'REJECT' is required. > > Can you please explain why is this required? > > > > I am with Santosh in this. > > > > >There is NO need for any REJECT in the above >case. If the initiator > > >is'nt satisfied with the value returned by the >originator and cannot > > >function with the negotiated values, it can simply >close the TCP > > >connection. There is no need to send any >REJECT. > > > > Thanks > > > > Deva > > Adaptec > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Monday, October 01, 2001 1:28 PM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > Santosh, > > > > We are getting nowhere. Even if requester is doing it's stuff - the > > requester will have to check and be prepared for a mistake. The coding > > will require a reject. > > > > Julo > > > > Santosh Rao > > To: ips@ece.cmu.edu > > Sent by: cc: "Sanjeev Bhagat > > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > > Julian Satran/Haifa/IBM@IBMIL > > 01-10-01 20:37 Subject: Re: iscsi : numerical > > Please respond to negotiation wording is ambiguous > > Santosh Rao > > > > > > Julian & Sanjeev, > > > > Responding to both your mails...... > > > > Julian : > > > > I think you may have mis-interpreted my comments. I believe Sanjeev > > has > > clarified the intent of my suggestions. > > > > I am *not* suggesting that the responder send back its values and > > these > > be blindly imposed on the originator. On the contrary, my suggestion > > is > > that the computation of the result of the negotiation (higher or lower > > of the 2 values) be only performed by the responder and sent back to > > the > > originator. > > > > The result of the negotiation is the same in both cases and there is > > no > > REJECT required in my case nor yours. The difference is the advantages > > I've stated in my model. > > > > Sanjeev, in response to your comment : > > > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. " > > > > There is NO need for any REJECT in the above case. If the initiator > > is'nt satisfied with the value returned by the originator and cannot > > function with the negotiated values, it can simply close the TCP > > connection. There is no need to send any REJECT. > > > > Thanks, > > Santosh > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Thanks Julian, please find my further comments in the message > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Sunday, September 30, 2001 6:07 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iscsi : numerical negotiation wording is > > > ambiguous > > > > > > 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > > say it this way the responder computes the value with > > > its own supported values and responds with a value y > > > which the responder thinks is correct 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > > but it is highly unlikely for the responder to reject > > > the final result because the rule states that (lower or > > > higher of two will be the result) and so the offering > > > party should be able to accept the lower or higher > > > range as defined by rule. In case the key is dependent > > > upon some range of fixed values then the negotiation > > > should be performed as list negotiation and not > > > numerical negotiation. > > > > > > This might be what you "conventionally" do - I don't > > > and that shows that convention like morals are a matter > > > of geography :-) > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > > > The advantage of this set of rules is that it allows an > > > external observer to know what was selected without > > > knowing the rules > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > > case, I guess that the external observer has to know > > > the rules to double check the value is correct or not > > > 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. > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. > > > > > > > > > Sanjeev > > > "Sanjeev Bhagat > > > (TRIPACE/Zoetermeer)" To: "'Santosh > > Rao'" > > > , Julian > > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > > cc: > > ips@ece.cmu.edu > > > 30-09-01 16:32 Subject: RE: > > iscsi : > > > Please respond to "Sanjeev numerical negotiation wording > > is > > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > > > > -- > > ################################## > > 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 Wed Oct 3 14:19: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 OAA24865 for ; Wed, 3 Oct 2001 14:19:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93HPTn21831 for ips-outgoing; Wed, 3 Oct 2001 13:25:29 -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 f93HPKP21820; Wed, 3 Oct 2001 13:25: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 TAA78638; Wed, 3 Oct 2001 19:21: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.97.1) with ESMTP id f93HKvI47642; Wed, 3 Oct 2001 19:20:59 +0200 To: "ERICKSON,SHAWN (HP-Roseville,ex1)" Cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, santoshr@cup.hp.com MIME-Version: 1.0 Subject: RE: iSCSI: ISID issue X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Oct 2001 20:20:53 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 20:20:59, Serialize complete at 03/10/2001 20:20:59 Content-Type: multipart/alternative; boundary="=_alternative 005E76A1C2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005E76A1C2256ADA_= Content-Type: text/plain; charset="us-ascii" I agree that LU mapping might be tricky but topology mapping is not affected by ISID allocation. You have to get a consistent mapping of target ports (and the model does that) and Initiators that know how to reach targets. Initiators have to know the physical identity of the portal when they open the connection (or they can get it through a local service) and the ISID has no role in topology mapping. I would also say that for any practical purpose we may request the LU mapping - for iSCSI - be defined only by the InitiatorName part of the InitiatorPortName. Julo "ERICKSON,SHAWN (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 02-10-01 19:25 Please respond to "ERICKSON,SHAWN (HP-Roseville,ex1)" To: santoshr@cup.hp.com, ips@ece.cmu.edu cc: "'Black_David@emc.com'" Subject: RE: iSCSI: ISID issue > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, October 01, 2001 3:11 PM > To: santoshr@cup.hp.com; ips@ece.cmu.edu > Subject: RE: iSCSI: ISID issue > > > Santosh Rao wrote: > > > I think comparisions to FC's mess-up of the node WWN are > not fair to the > > current ISID rule, since, unlike in FC, the worst case > scenario with the > > ISID rule, is that each iscsi driver on the system will take up a > > different iscsi initiator name. > > At least FC had the Port WWN to fall back on. This is headed for a > situation > where the iSCSI Initiator Name is unusable for access control > configuration > because whether it corresponds to the network interface, the > HBA (e.g., > suppose > there are two interfaces on the HBA), the driver, or the OS image is > implementation-dependent. In FC it is completely unambiguous what the > Port WWN corresponds to, and that's why it's usually used for > LUN masking > and mapping solutions. We're at risk of screwing that up, e.g. ... I would like to second David's concern about not leaving targets with a deterministic way of knowing who/what the initiators identifier relates to. This is not only bad for access control mechanisms but it make topology mapping (and related concepts) more difficult for management software developers. -Shawn ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- ------------------------------------------------------- --=_alternative 005E76A1C2256ADA_= Content-Type: text/html; charset="us-ascii"
I agree that LU mapping might be tricky but topology mapping is not affected by ISID allocation. You have to get a consistent mapping of target ports (and the model does that) and Initiators that know how to reach targets. Initiators have to know the physical identity of the portal when they open the connection (or they can get it through a local service) and the ISID has no role in topology mapping.  

I would also say that for any practical purpose we may request the LU mapping - for  iSCSI - be defined only by the InitiatorName part of the InitiatorPortName.

Julo


"ERICKSON,SHAWN (HP-Roseville,ex1)" <shawn_erickson@hp.com>
Sent by: owner-ips@ece.cmu.edu

02-10-01 19:25
Please respond to "ERICKSON,SHAWN (HP-Roseville,ex1)"

       
        To:        santoshr@cup.hp.com, ips@ece.cmu.edu
        cc:        "'Black_David@emc.com'" <Black_David@emc.com>
        Subject:        RE: iSCSI: ISID issue

       


> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Monday, October 01, 2001 3:11 PM
> To: santoshr@cup.hp.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: ISID issue
>
>
> Santosh Rao wrote:
>
> > I think comparisions to FC's mess-up of the node WWN are
> not fair to the
> > current ISID rule, since, unlike in FC, the worst case
> scenario with the
> > ISID rule, is that each iscsi driver on the system will take up a
> > different iscsi initiator name.
>
> At least FC had the Port WWN to fall back on.  This is headed for a
> situation
> where the iSCSI Initiator Name is unusable for access control
> configuration
> because whether it corresponds to the network interface, the
> HBA (e.g.,
> suppose
> there are two interfaces on the HBA), the driver, or the OS image is
> implementation-dependent.  In FC it is completely unambiguous what the
> Port WWN corresponds to, and that's why it's usually used for
> LUN masking
> and mapping solutions.  We're at risk of screwing that up, e.g. ...

I would like to second David's concern about not leaving targets with a
deterministic way of knowing who/what the initiators identifier relates to.
This is not only bad for access control mechanisms but it make topology
mapping (and related concepts) more difficult for management software
developers.

-Shawn

-------------------------------------------------------
Shawn Carl Erickson           (805) 883-4319 [Telnet]
Hewlett Packard Company         OV NSSO Joint Venture
 Storage Resource Management R&D Lab (Santa Barbara)
-------------------------------------------------------
           <http://ecardfile.com/id/shawnce>
-------------------------------------------------------

--=_alternative 005E76A1C2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 14:36: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 OAA25390 for ; Wed, 3 Oct 2001 14:36:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93I1aT24307 for ips-outgoing; Wed, 3 Oct 2001 14:01: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 f93I1ZP24303 for ; Wed, 3 Oct 2001 14:01:35 -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 NAA13886 for ; Wed, 3 Oct 2001 13:59:11 -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 f93I0iC254076 for ; Wed, 3 Oct 2001 12:00:44 -0600 Importance: Normal Subject: RE: iSCSI: ISID issue To: ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 3 Oct 2001 11:00:41 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/03/2001 11:00:44 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 f93I1ZP24304 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit All, Let me just reiterate more strongly Julo's comment "we may request the LU mapping - for  iSCSI - be defined only by the InitiatorName". T10 has approved use of the iSCSI InitiatorName as the "TransportID" for SCSI access controls (lu mapping). The portnames have no direct function in this context for iSCSI (though they do have an indirect affect that isn't worth discussing here). Whether this standardized approach to lu mapping is adopted by vendors is a different question, but the standard is there. The issue of port name/identity is primarily an issue for persistent reservations (in all its current and future forms). Jim Hafner Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/03/2001 10:20:53 am Sent by: owner-ips@ece.cmu.edu To: "ERICKSON,SHAWN (HP-Roseville,ex1)" cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, owner-ips@ece.cmu.edu, santoshr@cup.hp.com Subject: RE: iSCSI: ISID issue I agree that LU mapping might be tricky but topology mapping is not affected by ISID allocation. You have to get a consistent mapping of target ports (and the model does that) and Initiators that know how to reach targets. Initiators have to know the physical identity of the portal when they open the connection (or they can get it through a local service) and the ISID has no role in topology mapping. I would also say that for any practical purpose we may request the LU mapping - for  iSCSI - be defined only by the InitiatorName part of the InitiatorPortName. Julo "ERICKSON,SHAWN (HP-Roseville,ex1)"         To: santoshr@cup.hp.com, Sent by: ips@ece.cmu.edu owner-ips@ece.cmu.edu         cc: "'Black_David@emc.com'" 02-10-01 19:25 Please respond to         Subject: "ERICKSON,SHAWN RE: iSCSI: ISID issue (HP-Roseville,ex1)" > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, October 01, 2001 3:11 PM > To: santoshr@cup.hp.com; ips@ece.cmu.edu > Subject: RE: iSCSI: ISID issue > > > Santosh Rao wrote: > > > I think comparisions to FC's mess-up of the node WWN are > not fair to the > > current ISID rule, since, unlike in FC, the worst case > scenario with the > > ISID rule, is that each iscsi driver on the system will take up a > > different iscsi initiator name. > > At least FC had the Port WWN to fall back on.  This is headed for a > situation > where the iSCSI Initiator Name is unusable for access control > configuration > because whether it corresponds to the network interface, the > HBA (e.g., > suppose > there are two interfaces on the HBA), the driver, or the OS image is > implementation-dependent.  In FC it is completely unambiguous what the > Port WWN corresponds to, and that's why it's usually used for > LUN masking > and mapping solutions.  We're at risk of screwing that up, e.g. ... I would like to second David's concern about not leaving targets with a deterministic way of knowing who/what the initiators identifier relates to. This is not only bad for access control mechanisms but it make topology mapping (and related concepts) more difficult for management software developers. -Shawn ------------------------------------------------------- Shawn Carl Erickson           (805) 883-4319 [Telnet] Hewlett Packard Company         OV NSSO Joint Venture  Storage Resource Management R&D Lab (Santa Barbara) -------------------------------------------------------             ------------------------------------------------------- From owner-ips@ece.cmu.edu Wed Oct 3 14: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 OAA25540 for ; Wed, 3 Oct 2001 14:38:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93I0Rb24226 for ips-outgoing; Wed, 3 Oct 2001 14:00:27 -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.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f93I0OP24214 for ; Wed, 3 Oct 2001 14:00:24 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id D1003-1400-7bae06; Wed, 3 Oct 2001 18:00:15 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 3 Oct 2001 13:00:14 -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: Inquiry, Mode Sense, Read Capacity Date: Wed, 3 Oct 2001 13:00:14 -0500 Message-ID: Thread-Topic: iSCSI: Inquiry, Mode Sense, Read Capacity Thread-Index: AcFMIKyBukOweXuYS5e9c9w+keU/2wAB6kyg From: "Lee Xing" To: , X-OriginalArrivalTime: 03 Oct 2001 18:00:14.0684 (UTC) FILETIME=[40C6E9C0:01C14C35] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f93I0PP24215 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit David, Thanks for the info. It helps. Please see my new question below. > Q2: > There are 10 target opcodes on page 43 of v.07, and two of > them are specified as: > (-snip) See previous answer. Data-in transfers data for any SCSI command that has data to transfer. This includes all three of your examples. "READ" actually includes any SCSI command that transfers "data" (as that term is defined by SCSI) from Target to Initiator. This includes INQUIRY, MODE SENSE, and READ CAPACITY. New Question: on page 23 of v.08, it says "For performance reasons, iSCSI allows a "phase-collapse". A command and its associated data may be shipped together from initiator to target and data and responses may be shipped together from targets." The question is if "Data-in transfers data for any SCSI command that has data to transfer" (see the answer to Q2) is a true statement, should we clear the above sentence (on page 23 of v.08) a bit? Thanks. Lee Crossroads Systems, Inc. From owner-ips@ece.cmu.edu Wed Oct 3 14:54: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 OAA26047 for ; Wed, 3 Oct 2001 14:54:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93IPRa26144 for ips-outgoing; Wed, 3 Oct 2001 14:25:27 -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 f93IPOP26135 for ; Wed, 3 Oct 2001 14:25:24 -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 LAA08609; Wed, 3 Oct 2001 11:15:12 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <411AG35Q>; Wed, 3 Oct 2001 11:15:11 -0700 Message-ID: From: Robert Snively To: "'Santosh Rao'" , Dev - Platys , Julian Satran Cc: Sandeep Joshi , ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Wed, 3 Oct 2001 11:15:10 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I would have thought that it was indicating the DataPDULength it was capable of accepting, committing the other port to not exceeding that value. > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, October 03, 2001 10:32 AM > To: Dev - Platys; Julian Satran > Cc: Sandeep Joshi; ips@ece.cmu.edu > Subject: iscsi : DataPDULength can differ in each direction. > > > Deva, Julian & All, > > I think we have a more fundamental problem here, that spans beyond the > issue of which negotiation model should be used for numerical & binary > key negotiation. This problem needs to be addressed seperately. > > The DataPDULength can and should be allowed to be different in each > direction. I -> T direction PDUs should be allowed to use a different > PDU Length than T -> I direction PDUs. > > Each side should be allowed to specify the DataPDULength it will be > using and there should be no attempt to negotiate this value. > From owner-ips@ece.cmu.edu Wed Oct 3 14:54: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 OAA26079 for ; Wed, 3 Oct 2001 14:54:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93INMJ25939 for ips-outgoing; Wed, 3 Oct 2001 14:23:22 -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 f93INFP25923 for ; Wed, 3 Oct 2001 14:23:15 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail16.vwh1.net (RS ver 1.0.60s) with SMTP id 033957144; Wed, 3 Oct 2001 13:53:06 -0400 (EDT) From: "Dev - Platys" To: , "Dev - Platys" , "Julian Satran" Cc: "Sandeep Joshi" , Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Wed, 3 Oct 2001 10:59:42 -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: <3BBB4B73.26A695B8@cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, I am NOT for this, as I feel that we are complicating the protocol which has to be simplistic. I understand where you are coming from (analogous to MTU) etc. I guess that the example you state is wrong as the evolution of protocol specification should not be centered around specific hardware implementations and should be the other way around. Deva -----Original Message----- From: santoshr@cup.hp.com [mailto:santoshr@cup.hp.com] Sent: Wednesday, October 03, 2001 10:32 AM To: Dev - Platys; Julian Satran Cc: Sandeep Joshi; ips@ece.cmu.edu Subject: iscsi : DataPDULength can differ in each direction. Deva, Julian & All, I think we have a more fundamental problem here, that spans beyond the issue of which negotiation model should be used for numerical & binary key negotiation. This problem needs to be addressed seperately. The DataPDULength can and should be allowed to be different in each direction. I -> T direction PDUs should be allowed to use a different PDU Length than T -> I direction PDUs. Each side should be allowed to specify the DataPDULength it will be using and there should be no attempt to negotiate this value. Rather, the key is exchanged in either direction to inform the other side as to what sized PDUs it should expect. This is somwhat akin to a protocol's MTU definition or a max_frame_size definition (ex : FC PLOGI Receive Data Field Size in its common service parameters.). THese values are allowed to be different going in each direction, allowing for implementation specific quirks that restrict the use of certain values. (ex : some DMA bugs may require implementations to have their DataPDULength to be a cache line size shorter, etc.) I suggest the definition of the DataPDULength key be re-phrased taking the above into account. Regards, Santosh Dev - Platys wrote: > > Santosh, > > The point is, if the target is not capable of supporting 16K (it is just an > example that is being discussed), then it indicates that is what it wants. > Initiator can close the connection. (No reject is necessary though). > > However, if the target knows it can support the initiator negotiated value, > it could return it. > > Again, Yes, implicitly it becomes the responder selects logic. > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Sandeep Joshi > Sent: Wednesday, October 03, 2001 7:29 AM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > The first & third example below seem illogical. > > The responder should not be sending 24K if the initial > sender has chosen a value of 16K, since there is no > possibility of that 24K being accepted (unless we want > three way exchanges for every negotiation??) > > The problem of a Reject message does not arise since the > responder should only be choosing something less than 16K. > So I guess this puts me in the "responder selects logic" > camp. > > -Sandeep > > Julian Satran wrote: > > > > An example: > > 08.txt logic > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Selected value is 16k > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Selected value is 16k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > ----- > > > > Responder selects logic > > > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Error - Initiator Reject - Closes connection > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Error Target has to terminate with parameter error > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > "Dev - Platys" > > To: "Julian Satran" > > , > > 01-10-01 23:46 > > Please respond to "Dev - cc: > > Platys" Subject: RE: iscsi : > > numerical negotiation wording is ambiguous > > > > > > > > Julian, > > > > I am not sure why a 'REJECT' is required. > > Can you please explain why is this required? > > > > I am with Santosh in this. > > > > >There is NO need for any REJECT in the above >case. If the initiator > > >is'nt satisfied with the value returned by the >originator and cannot > > >function with the negotiated values, it can simply >close the TCP > > >connection. There is no need to send any >REJECT. > > > > Thanks > > > > Deva > > Adaptec > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Monday, October 01, 2001 1:28 PM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > Santosh, > > > > We are getting nowhere. Even if requester is doing it's stuff - the > > requester will have to check and be prepared for a mistake. The coding > > will require a reject. > > > > Julo > > > > Santosh Rao > > To: ips@ece.cmu.edu > > Sent by: cc: "Sanjeev Bhagat > > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > > Julian Satran/Haifa/IBM@IBMIL > > 01-10-01 20:37 Subject: Re: iscsi : numerical > > Please respond to negotiation wording is ambiguous > > Santosh Rao > > > > > > Julian & Sanjeev, > > > > Responding to both your mails...... > > > > Julian : > > > > I think you may have mis-interpreted my comments. I believe Sanjeev > > has > > clarified the intent of my suggestions. > > > > I am *not* suggesting that the responder send back its values and > > these > > be blindly imposed on the originator. On the contrary, my suggestion > > is > > that the computation of the result of the negotiation (higher or lower > > of the 2 values) be only performed by the responder and sent back to > > the > > originator. > > > > The result of the negotiation is the same in both cases and there is > > no > > REJECT required in my case nor yours. The difference is the advantages > > I've stated in my model. > > > > Sanjeev, in response to your comment : > > > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. " > > > > There is NO need for any REJECT in the above case. If the initiator > > is'nt satisfied with the value returned by the originator and cannot > > function with the negotiated values, it can simply close the TCP > > connection. There is no need to send any REJECT. > > > > Thanks, > > Santosh > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Thanks Julian, please find my further comments in the message > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Sunday, September 30, 2001 6:07 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iscsi : numerical negotiation wording is > > > ambiguous > > > > > > 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > > say it this way the responder computes the value with > > > its own supported values and responds with a value y > > > which the responder thinks is correct 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > > but it is highly unlikely for the responder to reject > > > the final result because the rule states that (lower or > > > higher of two will be the result) and so the offering > > > party should be able to accept the lower or higher > > > range as defined by rule. In case the key is dependent > > > upon some range of fixed values then the negotiation > > > should be performed as list negotiation and not > > > numerical negotiation. > > > > > > This might be what you "conventionally" do - I don't > > > and that shows that convention like morals are a matter > > > of geography :-) > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > > > The advantage of this set of rules is that it allows an > > > external observer to know what was selected without > > > knowing the rules > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > > case, I guess that the external observer has to know > > > the rules to double check the value is correct or not > > > 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. > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. > > > > > > > > > Sanjeev > > > "Sanjeev Bhagat > > > (TRIPACE/Zoetermeer)" To: "'Santosh > > Rao'" > > > , Julian > > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > > cc: > > ips@ece.cmu.edu > > > 30-09-01 16:32 Subject: RE: > > iscsi : > > > Please respond to "Sanjeev numerical negotiation wording > > is > > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > > > > -- > > ################################## > > 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 Wed Oct 3 15:03: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 PAA26527 for ; Wed, 3 Oct 2001 15:03:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93ISRp26382 for ips-outgoing; Wed, 3 Oct 2001 14:28:27 -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 f93ISPP26377 for ; Wed, 3 Oct 2001 14:28:25 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 11:28:19 -0700 Message-ID: From: Charles Monia To: "Ips (E-mail)" Subject: iFCP: Rev 5 PDF with markups Date: Wed, 3 Oct 2001 11:28: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 Colleagues In addition to the recently announced .txt file, a PDF of iFCP revision 5 with markups enabled is available from: ftp://ftp.t11.org/t11/docs/01-495v1.pdf The text file may, of course, be obtained from the ietf archive at: http://www.ietf.org/internet-drafts/draft-ietf-ips-ifcp-05.txt Revision 5 contains the following edits based on the results of the 9/21 Co-author's review: Changes Incorporated: a) New security section contributed by Franco Travostino. b) Deleted appendix B (IP to FC connectivity) per co-author and IPS wg comments c) Stale frame detection -- Added text describing recommended policy for making a transition to the Unsynchronized state following loss of contact with SNTP server. d) Following reboot or cold start, added timed wait before the gateway may initiate TCP connections. Requested to prevent collisions with in-flight traffic from previous connections. e) Specified TCP RST as the means to abort a TCP connection when an error occurs. Requested changes that were deferred or not implemented : TPRLO frame size errors: During the 9/21 review, it was believed that additional text was needed describing the gateway response when a TPRLO frame was received that exceeded the N_PORT's max frame size. In the existing text, the sending and receiving gateways are required to ensure that the TPRLO frames they generate do not exceed this limit. Therefore such an error represents a gateway implementation error and no additional text is believed to be needed. PLOGI QoS Issues It was requested that some mechanism be provided to use QoS information in the PLOGI as a way of inferring SLA requirements. In reviewing FC-FS, I was unable to discover any information in the PLOGI ELS that could be reasonably used for this purpose. This change is deferred pending a concrete proposal. Charles From owner-ips@ece.cmu.edu Wed Oct 3 15:04: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 PAA26599 for ; Wed, 3 Oct 2001 15:04:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93IT8o26429 for ips-outgoing; Wed, 3 Oct 2001 14:29:08 -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 f93IT2P26415 for ; Wed, 3 Oct 2001 14:29:02 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 14:31:11 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD810@CORPMX14> From: Black_David@emc.com To: lxing@Crossroads.com, ips@ece.cmu.edu Subject: RE: iSCSI: Inquiry, Mode Sense, Read Capacity Date: Wed, 3 Oct 2001 14:21:04 -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 The governing text is the following from p.62 of -08 on the contents of the Response PDU: 3.4.6 Data Segment - Sense and Response Data Segment iSCSI targets MUST support and enable autosense. If Status is CHECK CONDITION (0x02), then the Data Segment contains sense data for the failed command. For some iSCSI responses, the response data segment MAY contain some response related information, (e.g., for a target failure it may contain a vendor specific detailed description of the failure). Julian may be able to shed more light on the intended meaning of "phase collapse" for the response case, but the above text makes it quite clear that data transferred by the action of a SCSI command (including Read, Inquiry, Mode Sense, and Read Capacity) cannot be put in the Response PDU. A target can send the Response PDU immediately following the last Data-In PDU for the associated command, which is similar to the ability of an Initiator to send unsolicited Data-Out PDUs. There is no Target analog to the Initiator's ability to send Immediate Data in the same PDU as the SCSI command. Thanks, --David > -----Original Message----- > From: Lee Xing [mailto:lxing@crossroads.com] > Sent: Wednesday, October 03, 2001 2:00 PM > To: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI: Inquiry, Mode Sense, Read Capacity > > > David, > > Thanks for the info. It helps. > Please see my new question below. > > > > Q2: > > There are 10 target opcodes on page 43 of v.07, and two of > > them are specified as: > > (-snip) > > See previous answer. Data-in transfers data for any SCSI command > that has data to transfer. This includes all three of your examples. > "READ" actually includes any SCSI command that transfers "data" (as > that term is defined by SCSI) from Target to Initiator. This includes > INQUIRY, MODE SENSE, and READ CAPACITY. > > > > New Question: > > on page 23 of v.08, it says "For performance reasons, iSCSI allows > a "phase-collapse". A command and its associated data may be > shipped together from initiator to target and data and responses > may be shipped together from targets." > > The question is if "Data-in transfers data for any SCSI command > that has data to transfer" (see the answer to Q2) is a true > statement, should we clear the above sentence (on page 23 of v.08) > a bit? > > Thanks. > > > > Lee > Crossroads Systems, Inc. > From owner-ips@ece.cmu.edu Wed Oct 3 15:48: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 PAA27430 for ; Wed, 3 Oct 2001 15:48:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93J9x529566 for ips-outgoing; Wed, 3 Oct 2001 15:09:59 -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 f93J9vP29560 for ; Wed, 3 Oct 2001 15:09:57 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Wed Oct 3 15:05:09 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 f93J92l72755 for ; Wed, 3 Oct 2001 15:09:02 -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 PAA24870 for ; Wed, 3 Oct 2001 15:09:02 -0400 (EDT) Message-ID: <3BBB624E.E5F0CBD@research.bell-labs.com> Date: Wed, 03 Oct 2001 15:09:02 -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: Inquiry, Mode Sense, Read Capacity References: <277DD60FB639D511AC0400B0D068B71ECAD810@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Just a small correction on this topic.. > There is no Target analog to the Initiator's ability to send > Immediate Data in the same PDU as the SCSI command. There is an analog, but its part of the Data-IN PDU See Section 3.7. > 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. -Sandeep Black_David@emc.com wrote: > > The governing text is the following from p.62 of -08 on the contents of > the Response PDU: > > 3.4.6 Data Segment - Sense and Response Data Segment > > iSCSI targets MUST support and enable autosense. If Status is CHECK > > CONDITION (0x02), then the Data Segment contains sense data for the > failed command. > > For some iSCSI responses, the response data segment MAY contain some > > response related information, (e.g., for a target failure it may > contain a vendor specific detailed description of the failure). > > Julian may be able to shed more light on the intended meaning of > "phase collapse" for the response case, but the above text makes > it quite clear that data transferred by the action of a SCSI command > (including Read, Inquiry, Mode Sense, and Read Capacity) cannot be > put in the Response PDU. A target can send the Response PDU immediately > following the last Data-In PDU for the associated command, which is > similar to the ability of an Initiator to send unsolicited Data-Out > PDUs. There is no Target analog to the Initiator's ability to send > Immediate Data in the same PDU as the SCSI command. > > Thanks, > --David > > > -----Original Message----- > > From: Lee Xing [mailto:lxing@crossroads.com] > > Sent: Wednesday, October 03, 2001 2:00 PM > > To: Black_David@emc.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: Inquiry, Mode Sense, Read Capacity > > > > > > David, > > > > Thanks for the info. It helps. > > Please see my new question below. > > > > > > > Q2: > > > There are 10 target opcodes on page 43 of v.07, and two of > > > them are specified as: > > > (-snip) > > > > See previous answer. Data-in transfers data for any SCSI command > > that has data to transfer. This includes all three of your examples. > > "READ" actually includes any SCSI command that transfers "data" (as > > that term is defined by SCSI) from Target to Initiator. This includes > > INQUIRY, MODE SENSE, and READ CAPACITY. > > > > > > > > New Question: > > > > on page 23 of v.08, it says "For performance reasons, iSCSI allows > > a "phase-collapse". A command and its associated data may be > > shipped together from initiator to target and data and responses > > may be shipped together from targets." > > > > The question is if "Data-in transfers data for any SCSI command > > that has data to transfer" (see the answer to Q2) is a true > > statement, should we clear the above sentence (on page 23 of v.08) > > a bit? > > > > Thanks. > > > > > > > > Lee > > Crossroads Systems, Inc. > > From owner-ips@ece.cmu.edu Wed Oct 3 15:49: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 PAA27460 for ; Wed, 3 Oct 2001 15:49:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93IsD328350 for ips-outgoing; Wed, 3 Oct 2001 14:54:13 -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 [217.17.136.66] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f93IsBP28346 for ; Wed, 3 Oct 2001 14:54:11 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 20:56:11 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B9884@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Robert Snively'" , "'Santosh Rao'" , Dev - Platys , Julian Satran Cc: Sandeep Joshi , ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Wed, 3 Oct 2001 20:56:10 +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, Yes, this is a much better solution unless the implementation has some problem in sending certain sizes of dataPduLength :-), so if initiator has problem in sending PDUs of 16K which is required dataPDULength of target then even this procedure will be a failure and it would be better to do LIST negotiation. Sanjeev -----Original Message----- From: Robert Snively [mailto:rsnively@Brocade.COM] Sent: Wednesday, October 03, 2001 8:15 PM To: 'Santosh Rao'; Dev - Platys; Julian Satran Cc: Sandeep Joshi; ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. I would have thought that it was indicating the DataPDULength it was capable of accepting, committing the other port to not exceeding that value. > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, October 03, 2001 10:32 AM > To: Dev - Platys; Julian Satran > Cc: Sandeep Joshi; ips@ece.cmu.edu > Subject: iscsi : DataPDULength can differ in each direction. > > > Deva, Julian & All, > > I think we have a more fundamental problem here, that spans beyond the > issue of which negotiation model should be used for numerical & binary > key negotiation. This problem needs to be addressed seperately. > > The DataPDULength can and should be allowed to be different in each > direction. I -> T direction PDUs should be allowed to use a different > PDU Length than T -> I direction PDUs. > > Each side should be allowed to specify the DataPDULength it will be > using and there should be no attempt to negotiate this value. > From owner-ips@ece.cmu.edu Wed Oct 3 15:49: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 PAA27472 for ; Wed, 3 Oct 2001 15:49:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93J1GA28934 for ips-outgoing; Wed, 3 Oct 2001 15:01:16 -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 f93J19P28922 for ; Wed, 3 Oct 2001 15:01:09 -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 VAA77022 for ; Wed, 3 Oct 2001 21:01: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 f93J12I148112 for ; Wed, 3 Oct 2001 21:01:02 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI : DataPDULength can differ in each direction. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Oct 2001 22:00:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 22:01:02, Serialize complete at 03/10/2001 22:01:02 Content-Type: multipart/alternative; boundary="=_alternative 00686FCCC2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00686FCCC2256ADA_= Content-Type: text/plain; charset="us-ascii" Santosh, From an academics point of view I tend to agree with you and I played with the of having 2 different negotiated values. On practical terms however those sizes are determined slightly by the connection characteristics and more by the buffering scheme used by most cache/buffer-managers. The later tend to use uniform sizes and a common pool. Moreover framing mechanisms will align them to MTU. It does not make too much sense to use 2 values. Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 03-10-01 19:31 Please respond to Santosh Rao To: Dev - Platys , Julian Satran/Haifa/IBM@IBMIL cc: Sandeep Joshi , ips@ece.cmu.edu Subject: iscsi : DataPDULength can differ in each direction. Deva, Julian & All, I think we have a more fundamental problem here, that spans beyond the issue of which negotiation model should be used for numerical & binary key negotiation. This problem needs to be addressed seperately. The DataPDULength can and should be allowed to be different in each direction. I -> T direction PDUs should be allowed to use a different PDU Length than T -> I direction PDUs. Each side should be allowed to specify the DataPDULength it will be using and there should be no attempt to negotiate this value. Rather, the key is exchanged in either direction to inform the other side as to what sized PDUs it should expect. This is somwhat akin to a protocol's MTU definition or a max_frame_size definition (ex : FC PLOGI Receive Data Field Size in its common service parameters.). THese values are allowed to be different going in each direction, allowing for implementation specific quirks that restrict the use of certain values. (ex : some DMA bugs may require implementations to have their DataPDULength to be a cache line size shorter, etc.) I suggest the definition of the DataPDULength key be re-phrased taking the above into account. Regards, Santosh Dev - Platys wrote: > > Santosh, > > The point is, if the target is not capable of supporting 16K (it is just an > example that is being discussed), then it indicates that is what it wants. > Initiator can close the connection. (No reject is necessary though). > > However, if the target knows it can support the initiator negotiated value, > it could return it. > > Again, Yes, implicitly it becomes the responder selects logic. > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Sandeep Joshi > Sent: Wednesday, October 03, 2001 7:29 AM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > The first & third example below seem illogical. > > The responder should not be sending 24K if the initial > sender has chosen a value of 16K, since there is no > possibility of that 24K being accepted (unless we want > three way exchanges for every negotiation??) > > The problem of a Reject message does not arise since the > responder should only be choosing something less than 16K. > So I guess this puts me in the "responder selects logic" > camp. > > -Sandeep > > Julian Satran wrote: > > > > An example: > > 08.txt logic > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Selected value is 16k > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Selected value is 16k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > ----- > > > > Responder selects logic > > > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Error - Initiator Reject - Closes connection > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Error Target has to terminate with parameter error > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > "Dev - Platys" > > To: "Julian Satran" > > , > > 01-10-01 23:46 > > Please respond to "Dev - cc: > > Platys" Subject: RE: iscsi : > > numerical negotiation wording is ambiguous > > > > > > > > Julian, > > > > I am not sure why a 'REJECT' is required. > > Can you please explain why is this required? > > > > I am with Santosh in this. > > > > >There is NO need for any REJECT in the above >case. If the initiator > > >is'nt satisfied with the value returned by the >originator and cannot > > >function with the negotiated values, it can simply >close the TCP > > >connection. There is no need to send any >REJECT. > > > > Thanks > > > > Deva > > Adaptec > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Monday, October 01, 2001 1:28 PM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > Santosh, > > > > We are getting nowhere. Even if requester is doing it's stuff - the > > requester will have to check and be prepared for a mistake. The coding > > will require a reject. > > > > Julo > > > > Santosh Rao > > To: ips@ece.cmu.edu > > Sent by: cc: "Sanjeev Bhagat > > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > > Julian Satran/Haifa/IBM@IBMIL > > 01-10-01 20:37 Subject: Re: iscsi : numerical > > Please respond to negotiation wording is ambiguous > > Santosh Rao > > > > > > Julian & Sanjeev, > > > > Responding to both your mails...... > > > > Julian : > > > > I think you may have mis-interpreted my comments. I believe Sanjeev > > has > > clarified the intent of my suggestions. > > > > I am *not* suggesting that the responder send back its values and > > these > > be blindly imposed on the originator. On the contrary, my suggestion > > is > > that the computation of the result of the negotiation (higher or lower > > of the 2 values) be only performed by the responder and sent back to > > the > > originator. > > > > The result of the negotiation is the same in both cases and there is > > no > > REJECT required in my case nor yours. The difference is the advantages > > I've stated in my model. > > > > Sanjeev, in response to your comment : > > > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. " > > > > There is NO need for any REJECT in the above case. If the initiator > > is'nt satisfied with the value returned by the originator and cannot > > function with the negotiated values, it can simply close the TCP > > connection. There is no need to send any REJECT. > > > > Thanks, > > Santosh > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Thanks Julian, please find my further comments in the message > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Sunday, September 30, 2001 6:07 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iscsi : numerical negotiation wording is > > > ambiguous > > > > > > 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > > say it this way the responder computes the value with > > > its own supported values and responds with a value y > > > which the responder thinks is correct 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > > but it is highly unlikely for the responder to reject > > > the final result because the rule states that (lower or > > > higher of two will be the result) and so the offering > > > party should be able to accept the lower or higher > > > range as defined by rule. In case the key is dependent > > > upon some range of fixed values then the negotiation > > > should be performed as list negotiation and not > > > numerical negotiation. > > > > > > This might be what you "conventionally" do - I don't > > > and that shows that convention like morals are a matter > > > of geography :-) > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > > > The advantage of this set of rules is that it allows an > > > external observer to know what was selected without > > > knowing the rules > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > > case, I guess that the external observer has to know > > > the rules to double check the value is correct or not > > > 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. > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. > > > > > > > > > Sanjeev > > > "Sanjeev Bhagat > > > (TRIPACE/Zoetermeer)" To: "'Santosh > > Rao'" > > > , Julian > > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > > cc: > > ips@ece.cmu.edu > > > 30-09-01 16:32 Subject: RE: > > iscsi : > > > Please respond to "Sanjeev numerical negotiation wording > > is > > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > > > > -- > > ################################## > > 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 ################################## --=_alternative 00686FCCC2256ADA_= Content-Type: text/html; charset="us-ascii"
Santosh,

From an academics point of view I tend to agree with you and I played with the of having 2 different negotiated values.
On practical terms however those sizes are determined slightly by the connection characteristics and more by the buffering scheme used by most cache/buffer-managers. The later tend to use uniform sizes and a common pool.  Moreover framing mechanisms will align them to MTU.   It does not make too much sense to use 2 values.

Julo




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

03-10-01 19:31
Please respond to Santosh Rao

       
        To:        Dev - Platys <deva@platys.com>, Julian Satran/Haifa/IBM@IBMIL
        cc:        Sandeep Joshi <sandeepj@research.bell-labs.com>, ips@ece.cmu.edu
        Subject:        iscsi : DataPDULength can differ in each direction.

       


Deva, Julian & All,

I think we have a more fundamental problem here, that spans beyond the
issue of which negotiation model should be used for numerical & binary
key negotiation. This problem needs to be addressed seperately.

The DataPDULength can and should be allowed to be different in each
direction. I -> T direction PDUs should be allowed to use a different
PDU Length than T -> I direction PDUs.

Each side should be allowed to specify the DataPDULength it will be
using and there should be no attempt to negotiate this value. Rather,
the key is exchanged in either direction to inform the other side as to
what sized PDUs it should expect.

This is somwhat akin to a protocol's MTU definition or a max_frame_size
definition (ex : FC PLOGI Receive Data Field Size in its common service
parameters.). THese values are allowed to be different going in each
direction, allowing for implementation specific quirks that restrict the
use of certain values. (ex : some DMA bugs may require implementations
to have their DataPDULength to be a cache line size shorter, etc.)

I suggest the definition of the DataPDULength key be re-phrased taking
the above into account.

Regards,
Santosh

Dev - Platys wrote:
>
> Santosh,
>
> The point is, if the target is not capable of supporting 16K (it is just an
> example that is being discussed), then it indicates that is what it wants.
> Initiator can close the connection. (No reject is necessary though).
>
> However, if the target knows it can support the initiator negotiated value,
> it could return it.
>
> Again, Yes, implicitly it becomes the responder selects logic.
>
> Deva
> Adaptec
>
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Sandeep Joshi
> Sent: Wednesday, October 03, 2001 7:29 AM
> To: ips@ece.cmu.edu
> Subject: Re: iscsi : numerical negotiation wording is ambiguous
>
> The first & third example below seem illogical.
>
> The responder should not be sending 24K if the initial
> sender has chosen a value of 16K, since there is no
> possibility of that 24K being accepted (unless we want
> three way exchanges for every negotiation??)
>
> The problem of a Reject message does not arise since the
> responder should only be choosing something less than 16K.
> So I guess this puts me in the "responder selects logic"
> camp.
>
> -Sandeep
>
> Julian Satran wrote:
> >
> > An example:
> >  08.txt logic
> > i->t DataPDULength=16k
> > t->i DataPDULength= 24k
> >
> > Selected value is 16k
> >
> > i->t DataPDULength=16k
> > t->i DataPDULength= 8k
> >
> > Selected value is 8k
> >
> > t->i DataPDULength=16k
> > i->t DataPDULength= 24k
> >
> > Selected value is 16k
> >
> > t->i DataPDULength=16k
> > i->t DataPDULength= 8k
> >
> > Selected value is 8k
> >
> > -----
> >
> > Responder selects logic
> >
> > i->t DataPDULength=16k
> > t->i DataPDULength= 24k
> >
> > Error - Initiator Reject - Closes connection
> >
> > i->t DataPDULength=16k
> > t->i DataPDULength= 8k
> >
> > Selected value is 8k
> >
> > t->i DataPDULength=16k
> > i->t DataPDULength= 24k
> >
> > Error Target has to terminate with parameter error
> >
> > t->i DataPDULength=16k
> > i->t DataPDULength= 8k
> >
> > Selected value is 8k
> >
> >   "Dev - Platys"
> >   <deva@platys.com>                To:        "Julian Satran"
> >                            <Julian_Satran@il.ibm.com>,
> >   01-10-01 23:46           <ips@ece.cmu.edu>
> >   Please respond to "Dev -         cc:
> >   Platys"                          Subject:        RE: iscsi :
> >                            numerical negotiation wording is ambiguous
> >
> >
> >
> > Julian,
> >
> > I am not sure why a 'REJECT' is required.
> > Can you please explain why is this required?
> >
> > I am with Santosh in this.
> >
> > >There is NO need for any REJECT in the above >case. If the initiator
> > >is'nt satisfied with the value returned by the >originator and cannot
> > >function with the negotiated values, it can simply >close the TCP
> > >connection. There is no need to send any >REJECT.
> >
> > Thanks
> >
> > Deva
> > Adaptec
> >
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Julian Satran
> > Sent: Monday, October 01, 2001 1:28 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iscsi : numerical negotiation wording is ambiguous
> >
> > Santosh,
> >
> > We are getting nowhere. Even if requester is doing it's stuff - the
> > requester will have to check and be prepared for a mistake. The coding
> > will require a reject.
> >
> > Julo
> >
> >   Santosh Rao
> >   <santoshr@cup.hp.com>        To:        ips@ece.cmu.edu
> >   Sent by:                     cc:        "Sanjeev Bhagat
> >   santoshr@cup.hp.com   (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>,
> >                         Julian Satran/Haifa/IBM@IBMIL
> >   01-10-01 20:37               Subject:        Re: iscsi : numerical
> >   Please respond to     negotiation wording is ambiguous
> >   Santosh Rao
> >
> >
> > Julian & Sanjeev,
> >
> > Responding to both your mails......
> >
> > Julian :
> >
> > I think you may have mis-interpreted my comments. I believe Sanjeev
> > has
> > clarified the intent of my suggestions.
> >
> > I am *not* suggesting that the responder send back its values and
> > these
> > be blindly imposed on the originator. On the contrary, my suggestion
> > is
> > that the computation of the result of the negotiation (higher or lower
> > of the 2 values) be only performed by the responder and sent back to
> > the
> > originator.
> >
> > The result of the negotiation is the same in both cases and there is
> > no
> > REJECT required in my case nor yours. The difference is the advantages
> > I've stated in my model.
> >
> > Sanjeev, in response to your comment :
> >
> > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> > >  no reject , but it can be a problem in future .
> > >  Consider your example of DataPDULength in your own
> > >  message. Suppose offering party sends a value of 16,384
> > >  (this is also lowest value it can send) and responding
> > >  party responds with 8,192. In this case the offering
> > >  party will have to reject the negotiation. So a reject
> > >  message is needed in this case also. "
> >
> > There is NO need for any REJECT in the above case. If the initiator
> > is'nt satisfied with the value returned by the originator and cannot
> > function with the negotiated values, it can simply close the TCP
> > connection. There is no need to send any REJECT.
> >
> > Thanks,
> > Santosh
> >
> > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> > >
> > > Thanks Julian, please find my further comments in the message
> > >
> > >      -----Original Message-----
> > >      From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > >      Sent: Sunday, September 30, 2001 6:07 PM
> > >      To: ips@ece.cmu.edu
> > >      Subject: RE: iscsi : numerical negotiation wording is
> > >      ambiguous
> > >
> > >      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
> > >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather
> > >           say it this way the responder computes the value with
> > >           its own supported values and responds with a value y
> > >           which the responder thinks is correct 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
> > >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct,
> > >           but it is highly unlikely for the responder to reject
> > >           the final result because the rule states that (lower or
> > >           higher of two will be the result) and so the offering
> > >           party should be able to accept the lower or higher
> > >           range as defined by rule. In case the key is dependent
> > >           upon some range of fixed values then the negotiation
> > >           should be performed as list negotiation and not
> > >           numerical negotiation.
> > >
> > >           This might be what you "conventionally" do - I don't
> > >           and that shows that convention like morals are a matter
> > >           of geography :-)
> > >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-)
> > >
> > >           The advantage of this set of rules is that it allows an
> > >           external observer to know what was selected without
> > >           knowing the rules
> > >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this
> > >           case, I guess that the external observer has to know
> > >           the rules to double check the value is correct or not
> > >           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.
> > >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> > >           no reject , but it can be a problem in future .
> > >           Consider your example of DataPDULength in your own
> > >           message. Suppose offering party sends a value of 16,384
> > >           (this is also lowest value it can send) and responding
> > >           party responds with 8,192. In this case the offering
> > >           party will have to reject the negotiation. So a reject
> > >           message is needed in this case also.
> > >
> > >
> > >      Sanjeev
> > >       "Sanjeev Bhagat
> > >       (TRIPACE/Zoetermeer)"                    To:        "'Santosh
> > Rao'"
> > >       <sbhagat@tripace.com>            <santoshr@cup.hp.com>, Julian
> > >       Sent by: owner-ips@ece.cmu.edu   Satran/Haifa/IBM@IBMIL
> > >                                                cc:
> >  ips@ece.cmu.edu
> > >       30-09-01 16:32                           Subject:        RE:
> > iscsi :
> > >       Please respond to "Sanjeev       numerical negotiation wording
> > is
> > >       Bhagat (TRIPACE/Zoetermeer)"     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
> > >
> >
> > --
> > ##################################
> > 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
##################################

--=_alternative 00686FCCC2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 16:03: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 QAA27832 for ; Wed, 3 Oct 2001 16:03:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93Jkwc02481 for ips-outgoing; Wed, 3 Oct 2001 15:46:58 -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 f93JkuP02476 for ; Wed, 3 Oct 2001 15:46: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 VAA190636 for ; Wed, 3 Oct 2001 21:46: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 f93JkmU31712 for ; Wed, 3 Oct 2001 21:46:48 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Inquiry, Mode Sense, Read Capacity X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Oct 2001 22:46:44 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 22:46:48, Serialize complete at 03/10/2001 22:46:48 Content-Type: multipart/alternative; boundary="=_alternative 006CB109C2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006CB109C2256ADA_= Content-Type: text/plain; charset="us-ascii" David is right. Response doe not contain data proper. Phase collapse is for the last DataPDU in which a target can fit a GOOD status (and thus avoid an additional response) and some residual counts (when those are not considered errors). Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 03-10-01 20:21 Please respond to Black_David To: lxing@Crossroads.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: Inquiry, Mode Sense, Read Capacity The governing text is the following from p.62 of -08 on the contents of the Response PDU: 3.4.6 Data Segment - Sense and Response Data Segment iSCSI targets MUST support and enable autosense. If Status is CHECK CONDITION (0x02), then the Data Segment contains sense data for the failed command. For some iSCSI responses, the response data segment MAY contain some response related information, (e.g., for a target failure it may contain a vendor specific detailed description of the failure). Julian may be able to shed more light on the intended meaning of "phase collapse" for the response case, but the above text makes it quite clear that data transferred by the action of a SCSI command (including Read, Inquiry, Mode Sense, and Read Capacity) cannot be put in the Response PDU. A target can send the Response PDU immediately following the last Data-In PDU for the associated command, which is similar to the ability of an Initiator to send unsolicited Data-Out PDUs. There is no Target analog to the Initiator's ability to send Immediate Data in the same PDU as the SCSI command. Thanks, --David > -----Original Message----- > From: Lee Xing [mailto:lxing@crossroads.com] > Sent: Wednesday, October 03, 2001 2:00 PM > To: Black_David@emc.com; ips@ece.cmu.edu > Subject: RE: iSCSI: Inquiry, Mode Sense, Read Capacity > > > David, > > Thanks for the info. It helps. > Please see my new question below. > > > > Q2: > > There are 10 target opcodes on page 43 of v.07, and two of > > them are specified as: > > (-snip) > > See previous answer. Data-in transfers data for any SCSI command > that has data to transfer. This includes all three of your examples. > "READ" actually includes any SCSI command that transfers "data" (as > that term is defined by SCSI) from Target to Initiator. This includes > INQUIRY, MODE SENSE, and READ CAPACITY. > > > > New Question: > > on page 23 of v.08, it says "For performance reasons, iSCSI allows > a "phase-collapse". A command and its associated data may be > shipped together from initiator to target and data and responses > may be shipped together from targets." > > The question is if "Data-in transfers data for any SCSI command > that has data to transfer" (see the answer to Q2) is a true > statement, should we clear the above sentence (on page 23 of v.08) > a bit? > > Thanks. > > > > Lee > Crossroads Systems, Inc. > --=_alternative 006CB109C2256ADA_= Content-Type: text/html; charset="us-ascii"
David is right. Response doe not contain data proper.
Phase collapse is for the last DataPDU in which a target can fit a GOOD status (and thus avoid an additional response) and some residual counts (when those are not considered errors).

Julo


Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu

03-10-01 20:21
Please respond to Black_David

       
        To:        lxing@Crossroads.com, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI: Inquiry, Mode Sense, Read Capacity

       


The governing text is the following from p.62 of -08 on the contents of
the Response PDU:

    3.4.6 Data Segment - Sense and Response Data Segment
       
       iSCSI targets MUST support and enable autosense.  If Status is CHECK

       CONDITION (0x02), then the Data Segment contains sense data for the
       failed command.  
       
       For some iSCSI responses, the response data segment MAY contain some

       response related information, (e.g., for a target failure it may
       contain a vendor specific detailed description of the failure).

Julian may be able to shed more light on the intended meaning of
"phase collapse" for the response case, but the above text makes
it quite clear that data transferred by the action of a SCSI command
(including Read, Inquiry, Mode Sense, and Read Capacity) cannot be
put in the Response PDU.  A target can send the Response PDU immediately
following the last Data-In PDU for the associated command, which is
similar to the ability of an Initiator to send unsolicited Data-Out
PDUs.  There is no Target analog to the Initiator's ability to send
Immediate Data in the same PDU as the SCSI command.

Thanks,
--David

> -----Original Message-----
> From: Lee Xing [mailto:lxing@crossroads.com]
> Sent: Wednesday, October 03, 2001 2:00 PM
> To: Black_David@emc.com; ips@ece.cmu.edu
> Subject: RE: iSCSI: Inquiry, Mode Sense, Read Capacity
>
>
> David,
>
> Thanks for the info.  It helps.  
> Please see my new question below.
>
>
> > Q2:
> > There are 10 target opcodes on page 43 of v.07, and two of
> > them are specified as:
> > (-snip)
>
> See previous answer.  Data-in transfers data for any SCSI command
> that has data to transfer.  This includes all three of your examples.
> "READ" actually includes any SCSI command that transfers "data" (as
> that term is defined by SCSI) from Target to Initiator.  This includes
> INQUIRY, MODE SENSE, and READ CAPACITY.
>
>
>
> New Question:
>
> on page 23 of v.08, it says "For performance reasons, iSCSI allows
> a "phase-collapse".  A command and its associated data may be
> shipped together from initiator to target and data and responses
> may be shipped together from targets."
>
> The question is if "Data-in transfers data for any SCSI command
> that has data to transfer" (see the answer to Q2) is a true
> statement, should we clear the above sentence (on page 23 of v.08)
> a bit?
>
> Thanks.
>
>
>
> Lee
> Crossroads Systems, Inc.
>


--=_alternative 006CB109C2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 16:06: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 QAA27905 for ; Wed, 3 Oct 2001 16:06:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93JTYl01152 for ips-outgoing; Wed, 3 Oct 2001 15:29: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 f93JTWP01145 for ; Wed, 3 Oct 2001 15:29:32 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-116.cisco.com [161.44.68.116]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA08516 for ; Wed, 3 Oct 2001 15:29:26 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Wed, 3 Oct 2001 14:28:39 -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 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 Well, the proposal says: Each side should be allowed to specify the DataPDULength it will be using and there should be no attempt to negotiate this value. Rather, the key is exchanged in either direction to inform the other side as to what sized PDUs it should expect. So, I understand that as if the initiator sends DataPDULength=reallyBigNumber, then it is informing the target that this is what it will be using, but the target should not attempt to negotiate it. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Buck Landry > Sent: Wednesday, October 03, 2001 2:13 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > It may add complexity, but, since DataPDULength is only a boundary on > the maximum number of bytes transmitted in a Data PDU (not the minimum), > "the first" *does* have a say about it. Right? > > -----Original Message----- > From: Ayman Ghanem [mailto:aghanem@cisco.com] > Sent: Wednesday, October 03, 2001 1:38 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > I think this will add unnecessary complexity, specially for data CRCs > having > to be calculated based on two different PDU sizes for Reads and Writes. > Also, one end may choose to do data digests in software. If the other > end > decides to use a really large PDU length (and the first doesn't have a > say > about it), this could be a problem. > > -Ayman > > > From owner-ips@ece.cmu.edu Wed Oct 3 16:13: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 QAA28111 for ; Wed, 3 Oct 2001 16:13:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93JDEu29854 for ips-outgoing; Wed, 3 Oct 2001 15:13:14 -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 f93JDCP29848 for ; Wed, 3 Oct 2001 15:13:13 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id M1003-1513-0d8600; Wed, 3 Oct 2001 19:13:08 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 3 Oct 2001 14:13:07 -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 : DataPDULength can differ in each direction. Date: Wed, 3 Oct 2001 14:13:07 -0500 Message-ID: Thread-Topic: iscsi : DataPDULength can differ in each direction. Thread-Index: AcFMPmuqy2tGBCeBRziYVacmV1T5KAAACmbw From: "Buck Landry" To: X-OriginalArrivalTime: 03 Oct 2001 19:13:07.0380 (UTC) FILETIME=[6F1B5F40:01C14C3F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f93JDDP29849 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit It may add complexity, but, since DataPDULength is only a boundary on the maximum number of bytes transmitted in a Data PDU (not the minimum), "the first" *does* have a say about it. Right? -----Original Message----- From: Ayman Ghanem [mailto:aghanem@cisco.com] Sent: Wednesday, October 03, 2001 1:38 PM To: ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. I think this will add unnecessary complexity, specially for data CRCs having to be calculated based on two different PDU sizes for Reads and Writes. Also, one end may choose to do data digests in software. If the other end decides to use a really large PDU length (and the first doesn't have a say about it), this could be a problem. -Ayman From owner-ips@ece.cmu.edu Wed Oct 3 16:13: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 QAA28122 for ; Wed, 3 Oct 2001 16:13:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93JVeZ01336 for ips-outgoing; Wed, 3 Oct 2001 15:31:40 -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 f93JVcP01332 for ; Wed, 3 Oct 2001 15:31:38 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 15:31:33 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD813@CORPMX14> From: Black_David@emc.com To: hafner@almaden.ibm.com Cc: ips@ece.cmu.edu Subject: RE: iSCSI: ISID issue Date: Wed, 3 Oct 2001 15:23:42 -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'm getting ready to give up on this due to lack of interest on the list. As near as I can tell the arguments in favor of ISIDs are: (1) They've been in the spec for a long time. (2) Provide symmetry in session identification and a clean mapping to SAM-2 concepts. (3) Accommodates possible future persistent reserve functionality. Of these, I regard (1) and (2) as weak, and will explain in a moment why (3) is incorrect as things currently stand. The arguments against are: (4) ISID existence is the direct cause of the Option A/Option B issue about whether setting up a connection with an existing ISID is supposed to blow away an existing connection with the same ISID. (5) The ISID rule does not appear to be uniformly implementable in practice on common OS platforms via means other than (error-prone) manual configuration. The whole notion that OS vendors will address this sort of allocation issue just because we think they should is an exercise in wishful thinking. (6) Argument (3) above is incorrect, as the possible future persistent reserve functionality will not work as expected when different ISID values are used by the same Initiator to access Targets or Target Portal Groups for which sharing of persistent reserves is desired. To correct the problem with (3), we would have to require that the same ISID values be used across all Targets that may share an LU, which in practice probably means all Targets as the LU sharing structure across Targets is unlikely to be visible to iSCSI. I hesitate to write such a rule into iSCSI now to anticipate functionality that is still in a "to be defined" state at T10, because it will impact implementations. Julian and Jim's comments on specification of LU mapping miss the point. The point is that really simple consistent rules for how things work at this basic level are necessary to get management that scales decently. To be specific, suppose I have a reasonable sized SMP machine that has 5 Ethernet ports that support iSCSI spread across 3 HBAs and two drivers - how many iSCSI Initiator Names have to be configured into a Target LUN masking implementation to give that machine access to its storage from all 5 ports? The iSCSI answer is a long version of "it depends" that starts with "find the iSCSI documentation for your host and each of the HBAs to see how each of them deal with iSCSI Initiator Names". The possible values probably range from 1-3. In contrast, the corresponding Fibre Channel answer of 5 (Port WWN for each FC port) is superior even though it's a larger number because it's the only possible answer and all the HBAs have to work the same way. The reason it's superior is that neither the management software programmers nor the system administrators have to spend any mental cycles having to think about instances of the same protocol that have to be administered differently. For iSCSI, the ideal answer to the above question is 1. IMHO, removing ISIDs visibly increases the likelihood of that actually being the case all the time in practice. Alternatively, if we leave ISIDs in, I'd want to see a hard look at how to toughen the current ISID rule to prevent the problem identified in (6), and even then, I think the result is still less likely to lead to the desired goal. I think part of the difference I have with Jim Hafner is that I think he wants to make it possible for the future target-spanning persistent reservation functionality to work without requiring that it work (i.e., it'd be ok to have initiators behave in a way that reservations never span targets, even when targets implement the new functionality). I don't think that's good enough - if we go to the trouble of enabling this, we should do so in a fashion that is guaranteed to work in the presence of target support for the feature. As I said, I'm getting ready to give up on this, because I don't see much in the way of appreciation of the importance of scalable management and the role of simplicity (in the extreme) in enabling it on the list. --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 --------------------------------------------------- > Let me just reiterate more strongly Julo's comment "we may request the LU > mapping - for  iSCSI - be defined only by the InitiatorName". > T10 has approved use of the iSCSI InitiatorName as the "TransportID" for > SCSI access controls (lu mapping). The portnames have no direct function > in this context for iSCSI (though they do have an indirect affect that > isn't worth discussing here). > > Whether this standardized approach to lu mapping is adopted by vendors is a > different question, but the standard is there. > > The issue of port name/identity is primarily an issue for persistent > reservations (in all its current and future forms). > > Jim Hafner > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/03/2001 10:20:53 am > > Sent by: owner-ips@ece.cmu.edu > > > To: "ERICKSON,SHAWN (HP-Roseville,ex1)" > cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, > owner-ips@ece.cmu.edu, santoshr@cup.hp.com > Subject: RE: iSCSI: ISID issue > > > > > I agree that LU mapping might be tricky but topology mapping is not > affected by ISID allocation. You have to get a consistent > mapping of target > ports (and the model does that) and Initiators that know how to reach > targets. Initiators have to know the physical identity of the > portal when > they open the connection (or they can get it through a local > service) and > the ISID has no role in topology mapping. > > I would also say that for any practical purpose we may request the LU > mapping - for  iSCSI - be defined only by the InitiatorName > part of the > InitiatorPortName. > > Julo > > > > > "ERICKSON,SHAWN > > (HP-Roseville,ex1)"         > To: > > santoshr@cup.hp.com, > Sent by: > ips@ece.cmu.edu > owner-ips@ece.cmu.edu         > cc: > > "'Black_David@emc.com'" > 02-10-01 19:25 > > Please respond to         > Subject: > "ERICKSON,SHAWN RE: > iSCSI: ISID issue > (HP-Roseville,ex1)" > > > > > > > > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Monday, October 01, 2001 3:11 PM > > To: santoshr@cup.hp.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: ISID issue > > > > > > Santosh Rao wrote: > > > > > I think comparisions to FC's mess-up of the node WWN are > > not fair to the > > > current ISID rule, since, unlike in FC, the worst case > > scenario with the > > > ISID rule, is that each iscsi driver on the system will take up a > > > different iscsi initiator name. > > > > At least FC had the Port WWN to fall back on.  This is headed for a > > situation > > where the iSCSI Initiator Name is unusable for access control > > configuration > > because whether it corresponds to the network interface, the > > HBA (e.g., > > suppose > > there are two interfaces on the HBA), the driver, or the OS image is > > implementation-dependent.  In FC it is completely > unambiguous what the > > Port WWN corresponds to, and that's why it's usually used for > > LUN masking > > and mapping solutions.  We're at risk of screwing that up, e.g. ... > > I would like to second David's concern about not leaving > targets with a > deterministic way of knowing who/what the initiators > identifier relates to. > This is not only bad for access control mechanisms but it > make topology > mapping (and related concepts) more difficult for management software > developers. > > -Shawn > > ------------------------------------------------------- > Shawn Carl Erickson           (805) 883-4319 [Telnet] > Hewlett Packard Company         OV NSSO Joint Venture >  Storage Resource Management R&D Lab (Santa Barbara) > ------------------------------------------------------- >             > ------------------------------------------------------- > > > > > > From owner-ips@ece.cmu.edu Wed Oct 3 16:25: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 QAA28527 for ; Wed, 3 Oct 2001 16:25:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93JhvI02228 for ips-outgoing; Wed, 3 Oct 2001 15:43: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 f93JhsP02219 for ; Wed, 3 Oct 2001 15:43:54 -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 VAA42288 for ; Wed, 3 Oct 2001 21:43:05 +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 f93Jh4I223248 for ; Wed, 3 Oct 2001 21:43:05 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: [Fwd: iscsi : task mgmt response codes.] X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 3 Oct 2001 22:42:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 03/10/2001 22:43:05, Serialize complete at 03/10/2001 22:43:05 Content-Type: multipart/alternative; boundary="=_alternative 006B37D2C2256ADA_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006B37D2C2256ADA_= Content-Type: text/plain; charset="us-ascii" I certainly should and I forgot (somebody already mentioned it before). It hase response code 5. Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 03-10-01 18:49 Please respond to Santosh Rao To: ips@ece.cmu.edu cc: Subject: Re: [Fwd: iscsi : task mgmt response codes.] Julian, Thanks for the reply. Also, would you be adding the "Function Not Supported" response code to the list of task mgmt response codes, to indicate lack of support for certain task mgmt functions ? Regards, Santosh Julian Satran wrote: > > Santosh, > > Sorry for not answering explicitly - I was overwhelmed. The text in 08 > has an additional statement that might help clarify: > > For additional usage semantics, see section 8.1. > > Regards, > Julo > > Santosh Rao > To: Julian > Sent by: santoshr@cup.hp.com Satran/Haifa/IBM@IBMIL > cc: > 01-10-01 21:54 Subject: [Fwd: iscsi : > Please respond to Santosh Rao task mgmt response codes.] > > > > Julian, > > I did'nt hear back from you on the below issue. I look forward to your > comments on the same. > > Thanks, > Santosh > > Santosh Rao wrote: > > > > 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 > ################################## -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## --=_alternative 006B37D2C2256ADA_= Content-Type: text/html; charset="us-ascii"
I certainly should and I forgot (somebody already mentioned it before).  It hase response code 5. Julo


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

03-10-01 18:49
Please respond to Santosh Rao

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        Re: [Fwd: iscsi : task mgmt response codes.]

       


Julian,

Thanks for the reply. Also, would you be adding the "Function Not
Supported" response code to the list of task mgmt response codes, to
indicate lack of support for certain task mgmt functions ?

Regards,
Santosh


Julian Satran wrote:
>
> Santosh,
>
> Sorry for not answering explicitly - I was overwhelmed. The text in 08
> has an additional statement that might help clarify:
>
> For additional usage semantics, see section 8.1.
>
> Regards,
> Julo
>
>   Santosh Rao
>   <santoshr@cup.hp.com>                 To:        Julian
>   Sent by: santoshr@cup.hp.com  Satran/Haifa/IBM@IBMIL
>                                         cc:
>   01-10-01 21:54                        Subject:        [Fwd: iscsi :
>   Please respond to Santosh Rao task mgmt response codes.]
>
>
>
> Julian,
>
> I did'nt hear back from you on the below issue. I look forward to your
> comments on the same.
>
> Thanks,
> Santosh
>
> Santosh Rao wrote:
> >
> > 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
> ##################################

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

--=_alternative 006B37D2C2256ADA_=-- From owner-ips@ece.cmu.edu Wed Oct 3 16:30: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 QAA28698 for ; Wed, 3 Oct 2001 16:30:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93IdJO27222 for ips-outgoing; Wed, 3 Oct 2001 14:39:19 -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 f93IdHP27215 for ; Wed, 3 Oct 2001 14:39:17 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-116.cisco.com [161.44.68.116]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id OAA03519 for ; Wed, 3 Oct 2001 14:39:11 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Wed, 3 Oct 2001 13:38:23 -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: <3BBB4B73.26A695B8@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 think this will add unnecessary complexity, specially for data CRCs having to be calculated based on two different PDU sizes for Reads and Writes. Also, one end may choose to do data digests in software. If the other end decides to use a really large PDU length (and the first doesn't have a say about it), this could be a problem. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Santosh Rao > Sent: Wednesday, October 03, 2001 12:32 PM > To: Dev - Platys; Julian Satran > Cc: Sandeep Joshi; ips@ece.cmu.edu > Subject: iscsi : DataPDULength can differ in each direction. > > > Deva, Julian & All, > > I think we have a more fundamental problem here, that spans beyond the > issue of which negotiation model should be used for numerical & binary > key negotiation. This problem needs to be addressed seperately. > > The DataPDULength can and should be allowed to be different in each > direction. I -> T direction PDUs should be allowed to use a different > PDU Length than T -> I direction PDUs. > > Each side should be allowed to specify the DataPDULength it will be > using and there should be no attempt to negotiate this value. Rather, > the key is exchanged in either direction to inform the other side as to > what sized PDUs it should expect. > > This is somwhat akin to a protocol's MTU definition or a max_frame_size > definition (ex : FC PLOGI Receive Data Field Size in its common service > parameters.). THese values are allowed to be different going in each > direction, allowing for implementation specific quirks that restrict the > use of certain values. (ex : some DMA bugs may require implementations > to have their DataPDULength to be a cache line size shorter, etc.) > > I suggest the definition of the DataPDULength key be re-phrased taking > the above into account. > > Regards, > Santosh > > Dev - Platys wrote: > > > > Santosh, > > > > The point is, if the target is not capable of supporting 16K > (it is just an > > example that is being discussed), then it indicates that is > what it wants. > > Initiator can close the connection. (No reject is necessary though). > > > > However, if the target knows it can support the initiator > negotiated value, > > it could return it. > > > > Again, Yes, implicitly it becomes the responder selects logic. > > > > Deva > > Adaptec > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Sandeep Joshi > > Sent: Wednesday, October 03, 2001 7:29 AM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > The first & third example below seem illogical. > > > > The responder should not be sending 24K if the initial > > sender has chosen a value of 16K, since there is no > > possibility of that 24K being accepted (unless we want > > three way exchanges for every negotiation??) > > > > The problem of a Reject message does not arise since the > > responder should only be choosing something less than 16K. > > So I guess this puts me in the "responder selects logic" > > camp. > > > > -Sandeep > > > > Julian Satran wrote: > > > > > > An example: > > > 08.txt logic > > > i->t DataPDULength=16k > > > t->i DataPDULength= 24k > > > > > > Selected value is 16k > > > > > > i->t DataPDULength=16k > > > t->i DataPDULength= 8k > > > > > > Selected value is 8k > > > > > > t->i DataPDULength=16k > > > i->t DataPDULength= 24k > > > > > > Selected value is 16k > > > > > > t->i DataPDULength=16k > > > i->t DataPDULength= 8k > > > > > > Selected value is 8k > > > > > > ----- > > > > > > Responder selects logic > > > > > > i->t DataPDULength=16k > > > t->i DataPDULength= 24k > > > > > > Error - Initiator Reject - Closes connection > > > > > > i->t DataPDULength=16k > > > t->i DataPDULength= 8k > > > > > > Selected value is 8k > > > > > > t->i DataPDULength=16k > > > i->t DataPDULength= 24k > > > > > > Error Target has to terminate with parameter error > > > > > > t->i DataPDULength=16k > > > i->t DataPDULength= 8k > > > > > > Selected value is 8k > > > > > > "Dev - Platys" > > > To: "Julian Satran" > > > , > > > 01-10-01 23:46 > > > Please respond to "Dev - cc: > > > Platys" Subject: RE: iscsi : > > > numerical negotiation wording is ambiguous > > > > > > > > > > > > Julian, > > > > > > I am not sure why a 'REJECT' is required. > > > Can you please explain why is this required? > > > > > > I am with Santosh in this. > > > > > > >There is NO need for any REJECT in the above >case. If the initiator > > > >is'nt satisfied with the value returned by the >originator and cannot > > > >function with the negotiated values, it can simply >close the TCP > > > >connection. There is no need to send any >REJECT. > > > > > > Thanks > > > > > > Deva > > > Adaptec > > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > Julian Satran > > > Sent: Monday, October 01, 2001 1:28 PM > > > To: ips@ece.cmu.edu > > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > > > Santosh, > > > > > > We are getting nowhere. Even if requester is doing it's stuff - the > > > requester will have to check and be prepared for a mistake. The coding > > > will require a reject. > > > > > > Julo > > > > > > Santosh Rao > > > To: ips@ece.cmu.edu > > > Sent by: cc: "Sanjeev Bhagat > > > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > > > Julian Satran/Haifa/IBM@IBMIL > > > 01-10-01 20:37 Subject: Re: iscsi : numerical > > > Please respond to negotiation wording is ambiguous > > > Santosh Rao > > > > > > > > > Julian & Sanjeev, > > > > > > Responding to both your mails...... > > > > > > Julian : > > > > > > I think you may have mis-interpreted my comments. I believe Sanjeev > > > has > > > clarified the intent of my suggestions. > > > > > > I am *not* suggesting that the responder send back its values and > > > these > > > be blindly imposed on the originator. On the contrary, my suggestion > > > is > > > that the computation of the result of the negotiation (higher or lower > > > of the 2 values) be only performed by the responder and sent back to > > > the > > > originator. > > > > > > The result of the negotiation is the same in both cases and there is > > > no > > > REJECT required in my case nor yours. The difference is the advantages > > > I've stated in my model. > > > > > > Sanjeev, in response to your comment : > > > > > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > > no reject , but it can be a problem in future . > > > > Consider your example of DataPDULength in your own > > > > message. Suppose offering party sends a value of 16,384 > > > > (this is also lowest value it can send) and responding > > > > party responds with 8,192. In this case the offering > > > > party will have to reject the negotiation. So a reject > > > > message is needed in this case also. " > > > > > > There is NO need for any REJECT in the above case. If the initiator > > > is'nt satisfied with the value returned by the originator and cannot > > > function with the negotiated values, it can simply close the TCP > > > connection. There is no need to send any REJECT. > > > > > > Thanks, > > > Santosh > > > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > > > Thanks Julian, please find my further comments in the message > > > > > > > > -----Original Message----- > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > Sent: Sunday, September 30, 2001 6:07 PM > > > > To: ips@ece.cmu.edu > > > > Subject: RE: iscsi : numerical negotiation wording is > > > > ambiguous > > > > > > > > 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 > > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > > > say it this way the responder computes the value with > > > > its own supported values and responds with a value y > > > > which the responder thinks is correct 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 > > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > > > but it is highly unlikely for the responder to reject > > > > the final result because the rule states that (lower or > > > > higher of two will be the result) and so the offering > > > > party should be able to accept the lower or higher > > > > range as defined by rule. In case the key is dependent > > > > upon some range of fixed values then the negotiation > > > > should be performed as list negotiation and not > > > > numerical negotiation. > > > > > > > > This might be what you "conventionally" do - I don't > > > > and that shows that convention like morals are a matter > > > > of geography :-) > > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > > > > > The advantage of this set of rules is that it allows an > > > > external observer to know what was selected without > > > > knowing the rules > > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > > > case, I guess that the external observer has to know > > > > the rules to double check the value is correct or not > > > > 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. > > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > > no reject , but it can be a problem in future . > > > > Consider your example of DataPDULength in your own > > > > message. Suppose offering party sends a value of 16,384 > > > > (this is also lowest value it can send) and responding > > > > party responds with 8,192. In this case the offering > > > > party will have to reject the negotiation. So a reject > > > > message is needed in this case also. > > > > > > > > > > > > Sanjeev > > > > "Sanjeev Bhagat > > > > (TRIPACE/Zoetermeer)" To: "'Santosh > > > Rao'" > > > > , Julian > > > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > > > cc: > > > ips@ece.cmu.edu > > > > 30-09-01 16:32 Subject: RE: > > > iscsi : > > > > Please respond to "Sanjeev numerical negotiation wording > > > is > > > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > > > > > > > -- > > > ################################## > > > 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 Wed Oct 3 17:12: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 RAA00034 for ; Wed, 3 Oct 2001 17:12:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93KNCF05421 for ips-outgoing; Wed, 3 Oct 2001 16:23:12 -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 f93KN9P05408 for ; Wed, 3 Oct 2001 16:23:10 -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 QAA38482; Wed, 3 Oct 2001 16:20:44 -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 f93KN6k220546; Wed, 3 Oct 2001 14:23:06 -0600 Importance: Normal Subject: RE: iSCSI: ISID issue To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 3 Oct 2001 13:23:04 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/03/2001 01:23:06 PM 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 f93KNCP05418 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit David, I think your list of why we want ISIDs is missing some things (or perhaps I've forgotten why they we're dropped from the list before). But I'll take a different tact. My point is not to fixate on the ISID itself. My point general point is that I believe we need to have an unambiguous identifier of the SCSI initiator port. This is for reasons of (a) persistent reserverations (as defined today) as well as for future extensions (b) there is an obligation today (I think) for the transport layer to present to the OS layers above a "picture" of the SCSI Initiator Ports (isn't that what you keep saying goes in /dev stuff?). Wedge drivers rely on this stuff too. (c) some access control stuff (as defined by T10) but this is not a hard requirement I don't find the "Target gives the ports names" as meeting the needs listed here (and I don't think it makes any sense from a model point of view either). One solution to this (which it sounds like you find acceptable) is the one I've tossed on the table before: every iSCSI Node is single ported and you're back in the FC management headache space for target access control configuration. But you argue this is acceptable because that's what FC does and as long as the implementation model is the same for everybody, it's easier. You argue that the direction we're going will make this much harder in iSCSI (you're 'that depends' remarks). But aren't we going to have that anyway, as not all systems will run HBAs of the same caliber? We'll have some purely software iSCSI drivers using generic nics, we'll have some purely software iSCSI drivers bound to specific nics, we'll have some SW/HW driver combos bound to TOEs, and some bound to iSCSI HBAs. Each will have a different infrastructure for even the iSCSI Names. It will be a very long time (if ever) where we have the "single instance of the protocol for management purposes" you allude to as good about FC. If you want to avoid the multiple 'names' management problem per OS image, then you have to have names for SCSI Ports derived from (by appending) something else. I frankly don't care what it is, but I've argued that the ISIDs are already there in the spec, so why not use them. However, perhaps because some feel that the ISID is closer to a dynamic pointer, we should move off it for the purposes of naming SCSI ports. It doesn't really matter. Given any name, it use has to be coordinated within the scope of the iSCSI node, period. In either case (one port per node OR many ports per node) you still have the OptionA/OptionB problem in that you still have to define a rule that says the same SCSI Initiator Port can't build more than one session to the same SCSI Target Port (Target portal group) AND you need an enforcement of that by the target (option A or B). Perhaps in the one port per node model, it is much less likely for this RULE to be broken, so the consequences are less severe. It looks to me like the trade offs boil down to (a) managing a complex set of iSCSI Names (both detection in the OS and for target access control configuration) [and I've argued that detection is not as simple as FC, where even there, discovery took many years just to get a common API to the drivers!] OR (b) finding a way to get name coordination (both iSCSI Name and Portname) within an OS [and you've argued that this isn't going to happen.] Does this encapsulate things more clearly (at least between us)? I have a few other nits on some of your comments below, but I don't think they'd help change any opinions. Jim Hafner Black_David@emc.com on 10/03/2001 12:23:42 pm To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iSCSI: ISID issue I'm getting ready to give up on this due to lack of interest on the list. As near as I can tell the arguments in favor of ISIDs are: (1) They've been in the spec for a long time. (2) Provide symmetry in session identification and a clean mapping to SAM-2 concepts. (3) Accommodates possible future persistent reserve functionality. Of these, I regard (1) and (2) as weak, and will explain in a moment why (3) is incorrect as things currently stand. The arguments against are: (4) ISID existence is the direct cause of the Option A/Option B issue about whether setting up a connection with an existing ISID is supposed to blow away an existing connection with the same ISID. (5) The ISID rule does not appear to be uniformly implementable in practice on common OS platforms via means other than (error-prone) manual configuration. The whole notion that OS vendors will address this sort of allocation issue just because we think they should is an exercise in wishful thinking. (6) Argument (3) above is incorrect, as the possible future persistent reserve functionality will not work as expected when different ISID values are used by the same Initiator to access Targets or Target Portal Groups for which sharing of persistent reserves is desired. To correct the problem with (3), we would have to require that the same ISID values be used across all Targets that may share an LU, which in practice probably means all Targets as the LU sharing structure across Targets is unlikely to be visible to iSCSI. I hesitate to write such a rule into iSCSI now to anticipate functionality that is still in a "to be defined" state at T10, because it will impact implementations. Julian and Jim's comments on specification of LU mapping miss the point. The point is that really simple consistent rules for how things work at this basic level are necessary to get management that scales decently. To be specific, suppose I have a reasonable sized SMP machine that has 5 Ethernet ports that support iSCSI spread across 3 HBAs and two drivers - how many iSCSI Initiator Names have to be configured into a Target LUN masking implementation to give that machine access to its storage from all 5 ports? The iSCSI answer is a long version of "it depends" that starts with "find the iSCSI documentation for your host and each of the HBAs to see how each of them deal with iSCSI Initiator Names". The possible values probably range from 1-3. In contrast, the corresponding Fibre Channel answer of 5 (Port WWN for each FC port) is superior even though it's a larger number because it's the only possible answer and all the HBAs have to work the same way. The reason it's superior is that neither the management software programmers nor the system administrators have to spend any mental cycles having to think about instances of the same protocol that have to be administered differently. For iSCSI, the ideal answer to the above question is 1. IMHO, removing ISIDs visibly increases the likelihood of that actually being the case all the time in practice. Alternatively, if we leave ISIDs in, I'd want to see a hard look at how to toughen the current ISID rule to prevent the problem identified in (6), and even then, I think the result is still less likely to lead to the desired goal. I think part of the difference I have with Jim Hafner is that I think he wants to make it possible for the future target-spanning persistent reservation functionality to work without requiring that it work (i.e., it'd be ok to have initiators behave in a way that reservations never span targets, even when targets implement the new functionality). I don't think that's good enough - if we go to the trouble of enabling this, we should do so in a fashion that is guaranteed to work in the presence of target support for the feature. As I said, I'm getting ready to give up on this, because I don't see much in the way of appreciation of the importance of scalable management and the role of simplicity (in the extreme) in enabling it on the list. --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 --------------------------------------------------- > Let me just reiterate more strongly Julo's comment "we may request the LU > mapping - for  iSCSI - be defined only by the InitiatorName". > T10 has approved use of the iSCSI InitiatorName as the "TransportID" for > SCSI access controls (lu mapping). The portnames have no direct function > in this context for iSCSI (though they do have an indirect affect that > isn't worth discussing here). > > Whether this standardized approach to lu mapping is adopted by vendors is a > different question, but the standard is there. > > The issue of port name/identity is primarily an issue for persistent > reservations (in all its current and future forms). > > Jim Hafner > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/03/2001 10:20:53 am > > Sent by: owner-ips@ece.cmu.edu > > > To: "ERICKSON,SHAWN (HP-Roseville,ex1)" > cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, > owner-ips@ece.cmu.edu, santoshr@cup.hp.com > Subject: RE: iSCSI: ISID issue > > > > > I agree that LU mapping might be tricky but topology mapping is not > affected by ISID allocation. You have to get a consistent > mapping of target > ports (and the model does that) and Initiators that know how to reach > targets. Initiators have to know the physical identity of the > portal when > they open the connection (or they can get it through a local > service) and > the ISID has no role in topology mapping. > > I would also say that for any practical purpose we may request the LU > mapping - for  iSCSI - be defined only by the InitiatorName > part of the > InitiatorPortName. > > Julo > > > > > "ERICKSON,SHAWN > > (HP-Roseville,ex1)" > To: > > santoshr@cup.hp.com, > Sent by: > ips@ece.cmu.edu > owner-ips@ece.cmu.edu > cc: > > "'Black_David@emc.com'" > 02-10-01 19:25 > > Please respond to > Subject: > "ERICKSON,SHAWN RE: > iSCSI: ISID issue > (HP-Roseville,ex1)" > > > > > > > > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Monday, October 01, 2001 3:11 PM > > To: santoshr@cup.hp.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: ISID issue > > > > > > Santosh Rao wrote: > > > > > I think comparisions to FC's mess-up of the node WWN are > > not fair to the > > > current ISID rule, since, unlike in FC, the worst case > > scenario with the > > > ISID rule, is that each iscsi driver on the system will take up a > > > different iscsi initiator name. > > > > At least FC had the Port WWN to fall back on.  This is headed for a > > situation > > where the iSCSI Initiator Name is unusable for access control > > configuration > > because whether it corresponds to the network interface, the > > HBA (e.g., > > suppose > > there are two interfaces on the HBA), the driver, or the OS image is > > implementation-dependent.  In FC it is completely > unambiguous what the > > Port WWN corresponds to, and that's why it's usually used for > > LUN masking > > and mapping solutions.  We're at risk of screwing that up, e.g. ... > > I would like to second David's concern about not leaving > targets with a > deterministic way of knowing who/what the initiators > identifier relates to. > This is not only bad for access control mechanisms but it > make topology > mapping (and related concepts) more difficult for management software > developers. > > -Shawn > > ------------------------------------------------------- > Shawn Carl Erickson           (805) 883-4319 [Telnet] > Hewlett Packard Company         OV NSSO Joint Venture >  Storage Resource Management R&D Lab (Santa Barbara) > ------------------------------------------------------- >             > ------------------------------------------------------- > > > > > > From owner-ips@ece.cmu.edu Wed Oct 3 17:12: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 RAA00058 for ; Wed, 3 Oct 2001 17:12:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93KZgm06353 for ips-outgoing; Wed, 3 Oct 2001 16:35:42 -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 f93KZeP06348 for ; Wed, 3 Oct 2001 16:35:40 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id NAA15029; Wed, 3 Oct 2001 13:35:19 -0700 (PDT) From: "Rod Harrison" To: "Ayman Ghanem" , Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Wed, 3 Oct 2001 21:37:39 +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: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Can someone give a tangible benefit to this that can outweigh the spec and implementation churn at this late stage of the game? From my point of view the benefit of asymmetric PDU sizes would have to be very large to make it worth the extra complexity in buffer management code alone. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ayman Ghanem Sent: Wednesday, October 03, 2001 8:29 PM To: ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. Well, the proposal says: Each side should be allowed to specify the DataPDULength it will be using and there should be no attempt to negotiate this value. Rather, the key is exchanged in either direction to inform the other side as to what sized PDUs it should expect. So, I understand that as if the initiator sends DataPDULength=reallyBigNumber, then it is informing the target that this is what it will be using, but the target should not attempt to negotiate it. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Buck Landry > Sent: Wednesday, October 03, 2001 2:13 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > It may add complexity, but, since DataPDULength is only a boundary on > the maximum number of bytes transmitted in a Data PDU (not the minimum), > "the first" *does* have a say about it. Right? > > -----Original Message----- > From: Ayman Ghanem [mailto:aghanem@cisco.com] > Sent: Wednesday, October 03, 2001 1:38 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > I think this will add unnecessary complexity, specially for data CRCs > having > to be calculated based on two different PDU sizes for Reads and Writes. > Also, one end may choose to do data digests in software. If the other > end > decides to use a really large PDU length (and the first doesn't have a > say > about it), this could be a problem. > > -Ayman > > > From owner-ips@ece.cmu.edu Wed Oct 3 17:12: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 RAA00071 for ; Wed, 3 Oct 2001 17:12:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93KNBo05415 for ips-outgoing; Wed, 3 Oct 2001 16:23:11 -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 f93KN8P05399 for ; Wed, 3 Oct 2001 16:23:08 -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 PAA50326; Wed, 3 Oct 2001 15:20:43 -0500 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 f93KN6k220544; Wed, 3 Oct 2001 14:23:06 -0600 Importance: Normal Subject: RE: iSCSI: ISID issue To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 3 Oct 2001 13:23:03 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/03/2001 01:23:05 PM 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 f93KN8P05401 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit David, I think your list of why we want ISIDs is missing some things (or perhaps I've forgotten why they we're dropped from the list before). But I'll take a different tact. My point is not to fixate on the ISID itself. My point general point is that I believe we need to have an unambiguous identifier of the SCSI initiator port. This is for reasons of (a) persistent reserverations (as defined today) as well as for future extensions (b) there is an obligation today (I think) for the transport layer to present to the OS layers above a "picture" of the SCSI Initiator Ports (isn't that what you keep saying goes in /dev stuff?). Wedge drivers rely on this stuff too. (c) some access control stuff (as defined by T10) but this is not a hard requirement I don't find the "Target gives the ports names" as meeting the needs listed here (and I don't think it makes any sense from a model point of view either). One solution to this (which it sounds like you find acceptable) is the one I've tossed on the table before: every iSCSI Node is single ported and you're back in the FC management headache space for target access control configuration. But you argue this is acceptable because that's what FC does and as long as the implementation model is the same for everybody, it's easier. You argue that the direction we're going will make this much harder in iSCSI (you're 'that depends' remarks). But aren't we going to have that anyway, as not all systems will run HBAs of the same caliber? We'll have some purely software iSCSI drivers using generic nics, we'll have some purely software iSCSI drivers bound to specific nics, we'll have some SW/HW driver combos bound to TOEs, and some bound to iSCSI HBAs. Each will have a different infrastructure for even the iSCSI Names. It will be a very long time (if ever) where we have the "single instance of the protocol for management purposes" you allude to as good about FC. If you want to avoid the multiple 'names' management problem per OS image, then you have to have names for SCSI Ports derived from (by appending) something else. I frankly don't care what it is, but I've argued that the ISIDs are already there in the spec, so why not use them. However, perhaps because some feel that the ISID is closer to a dynamic pointer, we should move off it for the purposes of naming SCSI ports. It doesn't really matter. Given any name, it use has to be coordinated within the scope of the iSCSI node, period. In either case (one port per node OR many ports per node) you still have the OptionA/OptionB problem in that you still have to define a rule that says the same SCSI Initiator Port can't build more than one session to the same SCSI Target Port (Target portal group) AND you need an enforcement of that by the target (option A or B). Perhaps in the one port per node model, it is much less likely for this RULE to be broken, so the consequences are less severe. It looks to me like the trade offs boil down to (a) managing a complex set of iSCSI Names (both detection in the OS and for target access control configuration) [and I've argued that detection is not as simple as FC, where even there, discovery took many years just to get a common API to the drivers!] OR (b) finding a way to get name coordination (both iSCSI Name and Portname) within an OS [and you've argued that this isn't going to happen.] Does this encapsulate things more clearly (at least between us)? I have a few other nits on some of your comments below, but I don't think they'd help change any opinions. Jim Hafner Black_David@emc.com on 10/03/2001 12:23:42 pm To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iSCSI: ISID issue I'm getting ready to give up on this due to lack of interest on the list. As near as I can tell the arguments in favor of ISIDs are: (1) They've been in the spec for a long time. (2) Provide symmetry in session identification and a clean mapping to SAM-2 concepts. (3) Accommodates possible future persistent reserve functionality. Of these, I regard (1) and (2) as weak, and will explain in a moment why (3) is incorrect as things currently stand. The arguments against are: (4) ISID existence is the direct cause of the Option A/Option B issue about whether setting up a connection with an existing ISID is supposed to blow away an existing connection with the same ISID. (5) The ISID rule does not appear to be uniformly implementable in practice on common OS platforms via means other than (error-prone) manual configuration. The whole notion that OS vendors will address this sort of allocation issue just because we think they should is an exercise in wishful thinking. (6) Argument (3) above is incorrect, as the possible future persistent reserve functionality will not work as expected when different ISID values are used by the same Initiator to access Targets or Target Portal Groups for which sharing of persistent reserves is desired. To correct the problem with (3), we would have to require that the same ISID values be used across all Targets that may share an LU, which in practice probably means all Targets as the LU sharing structure across Targets is unlikely to be visible to iSCSI. I hesitate to write such a rule into iSCSI now to anticipate functionality that is still in a "to be defined" state at T10, because it will impact implementations. Julian and Jim's comments on specification of LU mapping miss the point. The point is that really simple consistent rules for how things work at this basic level are necessary to get management that scales decently. To be specific, suppose I have a reasonable sized SMP machine that has 5 Ethernet ports that support iSCSI spread across 3 HBAs and two drivers - how many iSCSI Initiator Names have to be configured into a Target LUN masking implementation to give that machine access to its storage from all 5 ports? The iSCSI answer is a long version of "it depends" that starts with "find the iSCSI documentation for your host and each of the HBAs to see how each of them deal with iSCSI Initiator Names". The possible values probably range from 1-3. In contrast, the corresponding Fibre Channel answer of 5 (Port WWN for each FC port) is superior even though it's a larger number because it's the only possible answer and all the HBAs have to work the same way. The reason it's superior is that neither the management software programmers nor the system administrators have to spend any mental cycles having to think about instances of the same protocol that have to be administered differently. For iSCSI, the ideal answer to the above question is 1. IMHO, removing ISIDs visibly increases the likelihood of that actually being the case all the time in practice. Alternatively, if we leave ISIDs in, I'd want to see a hard look at how to toughen the current ISID rule to prevent the problem identified in (6), and even then, I think the result is still less likely to lead to the desired goal. I think part of the difference I have with Jim Hafner is that I think he wants to make it possible for the future target-spanning persistent reservation functionality to work without requiring that it work (i.e., it'd be ok to have initiators behave in a way that reservations never span targets, even when targets implement the new functionality). I don't think that's good enough - if we go to the trouble of enabling this, we should do so in a fashion that is guaranteed to work in the presence of target support for the feature. As I said, I'm getting ready to give up on this, because I don't see much in the way of appreciation of the importance of scalable management and the role of simplicity (in the extreme) in enabling it on the list. --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 --------------------------------------------------- > Let me just reiterate more strongly Julo's comment "we may request the LU > mapping - for  iSCSI - be defined only by the InitiatorName". > T10 has approved use of the iSCSI InitiatorName as the "TransportID" for > SCSI access controls (lu mapping). The portnames have no direct function > in this context for iSCSI (though they do have an indirect affect that > isn't worth discussing here). > > Whether this standardized approach to lu mapping is adopted by vendors is a > different question, but the standard is there. > > The issue of port name/identity is primarily an issue for persistent > reservations (in all its current and future forms). > > Jim Hafner > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/03/2001 10:20:53 am > > Sent by: owner-ips@ece.cmu.edu > > > To: "ERICKSON,SHAWN (HP-Roseville,ex1)" > cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, > owner-ips@ece.cmu.edu, santoshr@cup.hp.com > Subject: RE: iSCSI: ISID issue > > > > > I agree that LU mapping might be tricky but topology mapping is not > affected by ISID allocation. You have to get a consistent > mapping of target > ports (and the model does that) and Initiators that know how to reach > targets. Initiators have to know the physical identity of the > portal when > they open the connection (or they can get it through a local > service) and > the ISID has no role in topology mapping. > > I would also say that for any practical purpose we may request the LU > mapping - for  iSCSI - be defined only by the InitiatorName > part of the > InitiatorPortName. > > Julo > > > > > "ERICKSON,SHAWN > > (HP-Roseville,ex1)" > To: > > santoshr@cup.hp.com, > Sent by: > ips@ece.cmu.edu > owner-ips@ece.cmu.edu > cc: > > "'Black_David@emc.com'" > 02-10-01 19:25 > > Please respond to > Subject: > "ERICKSON,SHAWN RE: > iSCSI: ISID issue > (HP-Roseville,ex1)" > > > > > > > > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Monday, October 01, 2001 3:11 PM > > To: santoshr@cup.hp.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: ISID issue > > > > > > Santosh Rao wrote: > > > > > I think comparisions to FC's mess-up of the node WWN are > > not fair to the > > > current ISID rule, since, unlike in FC, the worst case > > scenario with the > > > ISID rule, is that each iscsi driver on the system will take up a > > > different iscsi initiator name. > > > > At least FC had the Port WWN to fall back on.  This is headed for a > > situation > > where the iSCSI Initiator Name is unusable for access control > > configuration > > because whether it corresponds to the network interface, the > > HBA (e.g., > > suppose > > there are two interfaces on the HBA), the driver, or the OS image is > > implementation-dependent.  In FC it is completely > unambiguous what the > > Port WWN corresponds to, and that's why it's usually used for > > LUN masking > > and mapping solutions.  We're at risk of screwing that up, e.g. ... > > I would like to second David's concern about not leaving > targets with a > deterministic way of knowing who/what the initiators > identifier relates to. > This is not only bad for access control mechanisms but it > make topology > mapping (and related concepts) more difficult for management software > developers. > > -Shawn > > ------------------------------------------------------- > Shawn Carl Erickson           (805) 883-4319 [Telnet] > Hewlett Packard Company         OV NSSO Joint Venture >  Storage Resource Management R&D Lab (Santa Barbara) > ------------------------------------------------------- >             > ------------------------------------------------------- > > > > > > From owner-ips@ece.cmu.edu Wed Oct 3 17:13: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 RAA00095 for ; Wed, 3 Oct 2001 17:13:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93KgC806772 for ips-outgoing; Wed, 3 Oct 2001 16:42:12 -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 [217.17.136.66] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f93Kg9P06765 for ; Wed, 3 Oct 2001 16:42:09 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 22:44:09 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B9885@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Dev - Platys'" , Sandeep Joshi , ips@ece.cmu.edu Subject: iscsi : numerical negotiation offering party based computaion vs responder based Date: Wed, 3 Oct 2001 22:44:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C14C4C.26C64CC0" 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_01C14C4C.26C64CC0 Content-Type: text/plain; charset="iso-8859-1" Hello all, i just changed the name of the thread, because the thread is now taking different directions. I am attaching an excel file here in which i have taken 7 different cases to show how there could be some mis interpretation when offering party computes the individual results. I have taken the example of dataPDuSize because i started making my table with this although there is a different thread going on to it whether it should be kept in numerical negotiation or not. In the table I have tried to take cases where the initiator and target may not support some PDU sizes which are lower than the maximum PDU size they support. Deva: it also tells when a reject might be needed. Regards, Sanjeev -----Original Message----- From: Dev - Platys [mailto:deva@platys.com] Sent: Wednesday, October 03, 2001 6:14 PM To: Sandeep Joshi; ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Santosh, The point is, if the target is not capable of supporting 16K (it is just an example that is being discussed), then it indicates that is what it wants. Initiator can close the connection. (No reject is necessary though). However, if the target knows it can support the initiator negotiated value, it could return it. Again, Yes, implicitly it becomes the responder selects logic. Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Sandeep Joshi Sent: Wednesday, October 03, 2001 7:29 AM To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous The first & third example below seem illogical. The responder should not be sending 24K if the initial sender has chosen a value of 16K, since there is no possibility of that 24K being accepted (unless we want three way exchanges for every negotiation??) The problem of a Reject message does not arise since the responder should only be choosing something less than 16K. So I guess this puts me in the "responder selects logic" camp. -Sandeep Julian Satran wrote: > > An example: > 08.txt logic > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Selected value is 16k > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Selected value is 16k > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k > > ----- > > Responder selects logic > > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Error - Initiator Reject - Closes connection > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Error Target has to terminate with parameter error > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k > > "Dev - Platys" > To: "Julian Satran" > , > 01-10-01 23:46 > Please respond to "Dev - cc: > Platys" Subject: RE: iscsi : > numerical negotiation wording is ambiguous > > > > Julian, > > I am not sure why a 'REJECT' is required. > Can you please explain why is this required? > > I am with Santosh in this. > > >There is NO need for any REJECT in the above >case. If the initiator > >is'nt satisfied with the value returned by the >originator and cannot > >function with the negotiated values, it can simply >close the TCP > >connection. There is no need to send any >REJECT. > > Thanks > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Monday, October 01, 2001 1:28 PM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > Santosh, > > We are getting nowhere. Even if requester is doing it's stuff - the > requester will have to check and be prepared for a mistake. The coding > will require a reject. > > Julo > > Santosh Rao > To: ips@ece.cmu.edu > Sent by: cc: "Sanjeev Bhagat > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > Julian Satran/Haifa/IBM@IBMIL > 01-10-01 20:37 Subject: Re: iscsi : numerical > Please respond to negotiation wording is ambiguous > Santosh Rao > > > Julian & Sanjeev, > > Responding to both your mails...... > > Julian : > > I think you may have mis-interpreted my comments. I believe Sanjeev > has > clarified the intent of my suggestions. > > I am *not* suggesting that the responder send back its values and > these > be blindly imposed on the originator. On the contrary, my suggestion > is > that the computation of the result of the negotiation (higher or lower > of the 2 values) be only performed by the responder and sent back to > the > originator. > > The result of the negotiation is the same in both cases and there is > no > REJECT required in my case nor yours. The difference is the advantages > I've stated in my model. > > Sanjeev, in response to your comment : > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. " > > There is NO need for any REJECT in the above case. If the initiator > is'nt satisfied with the value returned by the originator and cannot > function with the negotiated values, it can simply close the TCP > connection. There is no need to send any REJECT. > > Thanks, > Santosh > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Thanks Julian, please find my further comments in the message > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Sunday, September 30, 2001 6:07 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : numerical negotiation wording is > > ambiguous > > > > 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > say it this way the responder computes the value with > > its own supported values and responds with a value y > > which the responder thinks is correct 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > but it is highly unlikely for the responder to reject > > the final result because the rule states that (lower or > > higher of two will be the result) and so the offering > > party should be able to accept the lower or higher > > range as defined by rule. In case the key is dependent > > upon some range of fixed values then the negotiation > > should be performed as list negotiation and not > > numerical negotiation. > > > > This might be what you "conventionally" do - I don't > > and that shows that convention like morals are a matter > > of geography :-) > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > The advantage of this set of rules is that it allows an > > external observer to know what was selected without > > knowing the rules > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > case, I guess that the external observer has to know > > the rules to double check the value is correct or not > > 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. > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. > > > > > > Sanjeev > > "Sanjeev Bhagat > > (TRIPACE/Zoetermeer)" To: "'Santosh > Rao'" > > , Julian > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > cc: > ips@ece.cmu.edu > > 30-09-01 16:32 Subject: RE: > iscsi : > > Please respond to "Sanjeev numerical negotiation wording > is > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > -- > ################################## > Santosh Rao > Software Design Engineer, > HP-UX iSCSI Driver Team, > Hewlett Packard, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################## ------_=_NextPart_000_01C14C4C.26C64CC0 Content-Type: application/vnd.ms-excel; name="numnego.xls" Content-Disposition: attachment; filename="numnego.xls" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAGwAAAAAAAAAA EAAA/v///wAAAAD+////AAAAABoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFAP4czQfBQAAABgEAAOEAAgCwBMEAAgAAAOIAAABcAHAABwAAc2JoYWdhdCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAMABAAA9AQYA AQACAAMAnAACAA4AGQACAAAAEgACAAAAEwACAAAArwECAAAAvAECAAAAPQASAOABDwCMKI0YOAAA AAAAAQBYAkAAAgAAAI0AAgAAACIAAgAAAA4AAgABALcBAgAAANoAAgAAADEAGgDIAAAA/3+QAQAA AAAAAAUBQQByAGkAYQBsADEAGgDIAAAA/3+QAQAAAAAAAAUBQQByAGkAYQBsADEAGgDIAAAA/3+Q AQAAAAAAAAUBQQByAGkAYQBsADEAGgDIAAAA/3+QAQAAAAAAAAUBQQByAGkAYQBsADEAGgDIAAQA DACQAQAAAQAAAAUBQQByAGkAYQBsADEAGgDIAAQAJACQAQAAAQAAAAUBQQByAGkAYQBsAB4EHAAF ABcAACIkIiMsIyMwXyk7XCgiJCIjLCMjMFwpHgQhAAYAHAAAIiQiIywjIzBfKTtbUmVkXVwoIiQi IywjIzBcKR4EIgAHAB0AACIkIiMsIyMwLjAwXyk7XCgiJCIjLCMjMC4wMFwpHgQnAAgAIgAAIiQi IywjIzAuMDBfKTtbUmVkXVwoIiQiIywjIzAuMDBcKR4ENwAqADIAAF8oIiQiKiAjLCMjMF8pO18o IiQiKiBcKCMsIyMwXCk7XygiJCIqICItIl8pO18oQF8pHgQuACkAKQAAXygqICMsIyMwXyk7Xygq IFwoIywjIzBcKTtfKCogIi0iXyk7XyhAXykeBD8ALAA6AABfKCIkIiogIywjIzAuMDBfKTtfKCIk IiogXCgjLCMjMC4wMFwpO18oIiQiKiAiLSI/P18pO18oQF8pHgQ2ACsAMQAAXygqICMsIyMwLjAw Xyk7XygqIFwoIywjIzAuMDBcKTtfKCogIi0iPz9fKTtfKEBfKeAAFAAAAAAA9f8gAAAAAAAAAAAA AADAIOAAFAABAAAA9f8gAAD0AAAAAAAAAADAIOAAFAABAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAC AAAA9f8gAAD0AAAAAAAAAADAIOAAFAACAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0 AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADA IOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA 9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAA AAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAAFAAAAAAA9f8gAAD0AAAAAAAAAADAIOAA FAAAAAAAAQAgAAAAAAAAAAAAAADAIOAAFAABACsA9f8gAAD4AAAAAAAAAADAIOAAFAABACkA9f8g AAD4AAAAAAAAAADAIOAAFAABACwA9f8gAAD4AAAAAAAAAADAIOAAFAABACoA9f8gAAD4AAAAAAAA AADAIOAAFAAGAAAA9P8AAAD0AAAAAAAAAADAIOAAFAAFAAAA9P8AAAD0AAAAAAAAAADAIOAAFAAB AAkA9f8gAAD4AAAAAAAAAADAIJMCBAAQgAP/kwIEABGABv+TAgQAEoAE/5MCBAATgAf/kwIEABSA Cf+TAgQAFYAI/5MCBAAAgAD/kwIEABaABf9gAQIAAACFAA4A1ggAAAAABgBTaGVldDGFAA4AZREA AAAABgBTaGVldDKFAA4AbBIAAAAABgBTaGVldDOMAAQAAQABAMEBCADBAQAAYGkBAPwApAJWAAAA IgAAAA4AAE9mZmVyaW5nIHBhcnR5EgAAIHN1cHBvcnRpbmcgdmFsdWVzEQAAUmVzcG9uZGluZyBw YXJ0eSAbAABTZXF1ZW5jZSBpZiBPZmZlcmluZyBwYXJ0eSATAABjb21wdXRlcyB0aGUgcmVzdWx0 HQAAU2VxdWVuY2UgaWYgUmVzcG9uZGluZyBwYXJ0eSAFAABGaW5hbAYAAFJlc3VsdAwAADhLLCAy NEssIDMySxYAAGktPnQgRGF0YVBEVUxlbmd0aD0xNmsWAABpLT50IERhdGFQRFVMZW5ndGg9MzJr FgAAdC0+aSBEYXRhUERVTGVuZ3RoPTE2SxYAAHQtPmkgRGF0YVBEVUxlbmd0aD00OEsDAAAzMksM AAA4SywgMTZLLCA0OEsRAAA4SywgMTZLLCAyNEssIDMySxYAAHQtPmkgRGF0YVBEVUxlbmd0aD0z MksHAAA4SywgMTZLDAAAOEssIDE2aywgMjRLFgAAdC0+aSBEYXRhUERVTGVuZ3RoPTI0SwMAADE2 SxYAAGktPnQgRGF0YVBEVUxlbmd0aD0yNGsQAAA4SywxNkssIDI0SywgNDhLAwAAMjRLFwAAV3Jv bmcgaW50ZXJwcmV0YWlvbiBieSAWAABpLT50IERhdGFQRFVMZW5ndGg9NDhrFQAAaW5pdGlhdG9y IGFuZCB0YXJnZXQgFQABZABvAGUAcwBuABkgdAAgAGsAbgBvAHcAIABhAGIAbwB1AHQAIABpAHQA EQAAY29uZGl0aW9uIGF2b2lkZWQVAABSZW5vZ28gdG8gbG93ZXIgdmFsdWUJAABvciByZWplY3QV AABOdW1lcmljYWwgTmVnb3RpYXRpb24MAAA4SywgMTZLLCAzMksEAABTLk5v/wAqAAgACAYAAAwA AACnBgAAqwAAAEMHAABHAQAAxgcAAMoBAACOCAAAkgIAAAoAAAAJCBAAAAYQAP4czQfBQAAABgEA AAsCGAAAAAAAAAAAACEAAACWCQAApBAAACQRAAANAAIAAQAMAAIAZAAPAAIAAQARAAIAAAAQAAgA /Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIAAQCAAAgAAAAAAAAAAAAlAgQAAAD/AIEAAgDB BBQAAAAVAAAAgwACAAAAhAACAAAAoQAiAAAA/wABAAEAAQAEAAAAAAAAAAAAAADgPwAAAAAAAOA/ AABVAAIACAB9AAwAAQABANsaDwACAAQAfQAMAAIAAgC2Gw8AAgAEAH0ADAADAAMAJBgPAAIABAB9 AAwABAAEAG0TDwACAAQAfQAMAAUABQBtHA8AAgAEAH0ADAAGAAYAJBEPAAIABAAAAg4AAAAAACEA AAAAAAcAAAAIAhAAAAAAAAcA/wAAAAAAAAEPAAgCEAACAAAABwD/AAAAAAAAAQ8ACAIQAAMAAAAH AP8AAAAAAAABDwAIAhAABQAAAAcA/wAAAAAAAAEPAAgCEAAGAAAABwD/AAAAAAAAAQ8ACAIQAAgA AAAHAP8AAAAAAAABDwAIAhAACQAAAAcA/wAAAAAAAAEPAAgCEAALAAAABwD/AAAAAAAAAQ8ACAIQ AAwAAAAHAP8AAAAAAAABDwAIAhAADQAAAAcA/wAAAAAAAAEPAAgCEAAOAAAABwD/AAAAAAAAAQ8A CAIQABAAAAAHAP8AAAAAAAABDwAIAhAAEQAAAAcA/wAAAAAAAAEPAAgCEAAVAAAABwD/AAAAAAAA AQ8ACAIQABYAAAAHAP8AAAAAAAABDwAIAhAAFwAAAAcA/wAAAAAAAAEPAAgCEAAYAAAABwD/AAAA AAAAAQ8ACAIQABoAAAAHAP8AAAAAAAABDwAIAhAAGwAAAAcA/wAAAAAAAAEPAAgCEAAcAAAABwD/ AAAAAAAAAQ8ACAIQAB0AAAAHAP8AAAAAAAABDwAIAhAAHwAAAAcA/wAAAAAAAAEPAP0ACgAAAAIA DwAfAAAA/QAKAAIAAAAPACEAAAD9AAoAAgABAA8AAAAAAP0ACgACAAIADwACAAAA/QAKAAIAAwAP AAMAAAD9AAoAAgAEAA8ABgAAAP0ACgACAAUADwAFAAAA/QAKAAIABgAPAAYAAAD9AAoAAwABAA8A AQAAAP0ACgADAAIADwABAAAA/QAKAAMAAwAPAAQAAAD9AAoAAwAEAA8ABwAAAP0ACgADAAUADwAE AAAA/QAKAAMABgAPAAcAAAB+AgoABQAAAA8AAADwP/0ACgAFAAEADwARAAAA/QAKAAUAAgAPABIA AAD9AAoABQADAA8ACQAAAP0ACgAFAAQADwAUAAAA/QAKAAUABQAPAAkAAAD9AAoABQAGAA8AFAAA AP0ACgAGAAMADwATAAAA/QAKAAYABQAPAAsAAAB+AgoACAAAAA8AAAAAQP0ACgAIAAEADwASAAAA /QAKAAgAAgAPABEAAAD9AAoACAADAA8AFQAAAP0ACgAIAAQADwAUAAAA/QAKAAgABQAPABUAAAD9 AAoACAAGAA8AFAAAAP0ACgAJAAMADwALAAAA/QAKAAkABQAPAAsAAAB+AgoACwAAAA8AAAAIQP0A CgALAAEADwAPAAAA/QAKAAsAAgAPABYAAAD9AAoACwADAA8ACgAAAP0ACgALAAQADwANAAAA/QAK AAsABQAPAAoAAAD9AAoACwAGAA8AFwAAAP0ACgAMAAMADwAMAAAA/QAKAAwABAAPABgAAAD9AAoA DAAFAA8AEwAAAP0ACgAMAAYADwAcAAAA/QAKAA0ABAAPABoAAAD9AAoADgAEAA8AGwAAAH4CCgAQ AAAADwAAABBA/QAKABAAAQAPABYAAAD9AAoAEAACAA8ADwAAAP0ACgAQAAMADwAZAAAA/QAKABAA BAAPAB0AAAD9AAoAEAAFAA8AGQAAAP0ACgAQAAYADwAdAAAA/QAKABEAAwAPABAAAAD9AAoAEQAE AA8AHgAAAP0ACgARAAUADwAQAAAA/QAKABEABgAPAB4AAAB+AgoAFQAAAA8AAAAUQP0ACgAVAAEA DwAIAAAA/QAKABUAAgAPAA4AAAD9AAoAFQADAA8ACgAAAP0ACgAVAAQADwANAAAA/QAKABUABQAP AAoAAAD9AAoAFQAGAA8AHQAAAP0ACgAWAAMADwAMAAAA/QAKABYABAAPABgAAAD9AAoAFgAFAA8A CwAAAP0ACgAWAAYADwAeAAAA/QAKABcABAAPABoAAAD9AAoAGAAEAA8AGwAAAH4CCgAaAAAADwAA ABhA/QAKABoAAQAPACAAAAD9AAoAGgACAA8AFgAAAP0ACgAaAAMADwAKAAAA/QAKABoABAAPAA0A AAD9AAoAGgAFAA8ACgAAAP0ACgAaAAYADwAdAAAA/QAKABsAAwAPAAwAAAD9AAoAGwAEAA8AGAAA AP0ACgAbAAUADwATAAAA/QAKABsABgAPAB4AAAD9AAoAHAAEAA8AGgAAAP0ACgAdAAQADwAbAAAA fgIKAB8AAAAPAAAAHED9AAoAHwABAA8AFgAAAP0ACgAfAAIADwAgAAAA/QAKAB8AAwAPABkAAAD9 AAoAHwAEAA8AHQAAAP0ACgAfAAUADwAZAAAA/QAKAB8ABgAPAB0AAADXADAAlgYAAKQBDgBiAFQA YgAcAGIAHABiADgADgAOAGIAOABiADgADgAOAGIAOAAOAA4ACAIQACAAAwAHAP8AAAAAAAABDwD9 AAoAIAADAA8AEAAAAP0ACgAgAAQADwAeAAAA/QAKACAABQAPABAAAAD9AAoAIAAGAA8AHgAAANcA BgBMAAAAAAA+AhIAtgYAAAEAQAAAAAAAAAAAAAAAHQAPAAMRAAEAAAABABEAEQABAe8ABgAAADcA AAAKAAAACQgQAAAGEAD+HM0HwUAAAAYBAAALAhAAAAAAAAAAAAAAAAAAHRIAAA0AAgABAAwAAgBk AA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgABACoAAgAAACsAAgAAAIIAAgABAIAACAAAAAAA AAAAACUCBAAAAP8AgQACAMEEFAAAABUAAACDAAIAAACEAAIAAAChACIAAAD/AAEAAQABAAQBAAEB AQAAAAAAAOA/AAAAAAAA4D8AAFUAAgAIAAACDgAAAAAAAAAAAAAAAAAAAD4CEgC2AAAAAABAAAAA AAAAAAAAAAAdAA8AAwAAAAAAAAEAAAAAAAAA7wAGAAAANwAAAAoAAAAJCBAAAAYQAP4czQfBQAAA BgEAAAsCEAAAAAAAAAAAAAAAAAAkEwAADQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJN YlA/XwACAAEAKgACAAAAKwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAA/wCBAAIAwQQUAAAA FQAAAIMAAgAAAIQAAgAAAKEAIgAAAP8AAQABAAEABAAAAAAAAAAAAAAA4D8AAAAAAADgPwAAVQAC AAgAAAIOAAAAAAAAAAAAAAAAAAAAPgISALYAAAAAAEAAAAAAAAAAAAAAAB0ADwADAAAAAAAAAQAA AAAAAADvAAYAAAA3AAAACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAA AAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAKAAAAAHAAAAAQAAAEAAAAAEAAAA SAAAAAgAAABYAAAAEgAAAGgAAAAMAAAAgAAAAA0AAACMAAAAEwAAAJgAAAACAAAA5AQAAB4AAAAI AAAAc2JoYWdhdAAeAAAACAAAAHNiaGFnYXQAHgAAABAAAABNaWNyb3NvZnQgRXhjZWwAQAAAAIDH DasxTMEBQAAAAACnunU8TMEBAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQACAAAAAAAAAAAAAAAA AAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAADcAAAACQAAAAEAAABQAAAADwAAAFgAAAAXAAAA aAAAAAsAAABwAAAAEAAAAHgAAAATAAAAgAAAABYAAACIAAAADQAAAJAAAAAMAAAAuQAAAAIAAADk BAAAHgAAAAgAAABUcmlwYWNlAAMAAADtDgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAAeEAAAAwAAAAcAAABTaGVldDEABwAAAFNoZWV0MgAHAAAAU2hlZXQzAAwQAAACAAAAHgAAAAsA AABXb3Jrc2hlZXRzAAMAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAA AAgAAAAJAAAA/v///wsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAD+////EwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAAP7////9/////v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AgAAACAIAgAA AAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAwY/X+SkzBAf7///8AAAAAAAAAAFcAbwByAGsAYgBvAG8A awAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHMTAAAAAAAA BQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACgAAgEBAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAKAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt AGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABIAAAAAEAAAAAAAAA== ------_=_NextPart_000_01C14C4C.26C64CC0-- From owner-ips@ece.cmu.edu Wed Oct 3 17:48: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 RAA00837 for ; Wed, 3 Oct 2001 17:48:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93KwJg08028 for ips-outgoing; Wed, 3 Oct 2001 16:58:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f93KwHP08022 for ; Wed, 3 Oct 2001 16:58:17 -0400 (EDT) Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id UAA04955 for ; Wed, 3 Oct 2001 20:58:16 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001100313573428596 for ; Wed, 03 Oct 2001 13:57:34 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 13:59:29 -0700 Message-ID: <5D2136DF3DD5D311AE89009027C67FB00368A7CF@FMSMSX96> From: "Sharma, Suman" To: ips@ece.cmu.edu Subject: questions/suggestions on Date: Wed, 3 Oct 2001 13:58:15 -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 Hi, I am new member of this group. I just now went thru the FCIP draft. Have some questions and suggestions about. I am very new to this so please correct me if I have written anything wrong. 1. section 4->4) Class 1 FC frames( and some signals) are not transmitted across an FCIP link. Since purpose of FCIP is to replace end-to-end fiber. So, how these frames will be transfered ? 2. section 5.2 , fig.2 FCIP Link Model is little bit confusing. Instead of writing FCIP on one side and Link on other side, it will be good if FCIP Link is written both side. 3. section 5.6.2.1 and 5.6.2.2. If someone is doing TCP checksum validation, is it required to do 5.6.2.2 checks ? At least test j) is not required ? 4. Once TCP payload will have only one FC frame or it can have multiple FC frame ? Its not mentioned anywhere, but from the section 5.6.2.2 and 5.6.2.3 it seems to me that it can have multiple FC frame ? -suman ==================================== Suman Sharma Sr. Network Software Engineer Access & Switching Processor Division (ASPD) Intel Corporation Phone: (408)545-6287 mailto:suman.sharma@intel.com From owner-ips@ece.cmu.edu Wed Oct 3 17:48: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 RAA00848 for ; Wed, 3 Oct 2001 17:48:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93LH9J09333 for ips-outgoing; Wed, 3 Oct 2001 17:17: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 f93LH7P09329 for ; Wed, 3 Oct 2001 17:17: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 179761F8DF; Wed, 3 Oct 2001 14:17: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 OAA10095; Wed, 3 Oct 2001 14:16:57 -0700 (PDT) Message-ID: <3BBB81ED.5931C4D1@cup.hp.com> Date: Wed, 03 Oct 2001 14:23:57 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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 : originating & responding parties in login. 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 Satran wrote: > Julian Satran wrote: > > > As negotiations can start at either initiator or target the > originator > > the one that starts the negotiation. > > Julian, > > OTOH, since the initiator did offer a value (the default value), is'nt > it always the originator ? In which case [other than a target vendor > specific proprietary key] would an operational negotiation start at > the > target ? > +++ offering a value is an active thing. Defaults and previous values > don't count. +++ This is intriguing. If an initiator explicitly sent a key value (albeit, with the key initialized to the default), the initiator is considered the originator. However, if the initiator chose to not send the key explicitly, but use the default, it then becomes the responder. [if target does not accept the default.] This leads to different on-the-wire login behaviour if the initiator chose to use defaults instead of sending those same key values explicitly. It also causes an additional dummy login hand-shake for no purpose. Thus, in the case where initiator wants to use, say, FirstBurstSize=128 & target allows FirstBurstSize to be 8, then, the behaviour on the wire is different depending on whether the initiator used the default or explicitly sent the key. Case 1) Initiator sends the default value as an explicit offering ------------------------------------------------------------------ I -> T : FirstBurstSize=128 (initiator is the originator) (CSG=Operational, NSG=FFP). T=1 T -> I : FirstBurstSize=8 (target responds with lower value it supports.) (CSG=Operational, NSG=FFP). T=1 Negotiation ends at initiator with both sides picking FirstBurstSize=8. Single login handshake. Case 2) Initiator does not send the key. (default is in use). ------------------------------------------------------------- I -> T : (no key sent). (defaults to 128.) (CSG=Operational , NSG=FFP). T=1 T -> I : FirstBurstSize=8 (CSG=Operational, NSG=Operational). T=0 I -> T : FirstBurstSize=128 (initiator explicitly resends the default !). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent. but a dummy login response to conclude login is sent). (CSG=Operational, NSG=FFP). T=1 Negotiation ends at the target, with both sides settling at FirstBurstSize=8 Login phase ends at the initiator. 2 login handshakes. Julian : What is the benefit of the above behaviour ? It results in inconsistent login behaviour and will only cause initiators to send login keys explicitly, defeating the purpose of defining defaults. I would rather the spec state that the initiator is the originator of the key when it uses default values, so that the login behaviour is the same in both scenarios above. Thanks, Santosh > > > > Julian, > > > > I've YET another login question for you : > > > > Please refer the following text in Section 2.2.4 of the Rev 08 draft > : > > > > "For numerical negotiations, the responding party MUST respond with > > the > > required key." > > > > When the initiator uses the default settings for a login key (i.e. > > does > > not send the key) and a target does not support that default, it has > > to > > originate the key in its login response to notify the initiator that > > it > > does not support the default. > > > > In the above example, who is the originating party & responding > party > > ? > > Is the initiator always considered an originating party for all the > > operational and security keys, even if it did not explicitly send > that > > key in its login ? > > > > If the target originated a login key, say DataPDULength, (and is > > therefore, to be considered as the originating party ?), based on > your > > rule quoted above, the exchange would be : > > > > I -> T : (no key is sent for DataPDULength. Assumes default of 16 > > units. > > (8K).) > > > > T -> I : DataPDULength=8 > > > > I -> T : DataPDULength=8 (See quoted rule above.) > > > > The definition of originating & responding party is not clear when > > defaults are used by the initiator and can lead to [mis- > > ?]interpretations such as the above. > > > > The above response from I -> T seems redundant to me. I suggest that > > the > > draft clearly state who the originating & responding party are when > > defaults are used, so as to avoid confusion along the above lines. > > > > 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 Wed Oct 3 18:28: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 SAA01778 for ; Wed, 3 Oct 2001 18:28:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93Ld3c11056 for ips-outgoing; Wed, 3 Oct 2001 17:39:03 -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 f93Ld1P11048 for ; Wed, 3 Oct 2001 17:39:01 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 481ED805; Wed, 3 Oct 2001 14:39: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 OAA12313; Wed, 3 Oct 2001 14:38:55 -0700 (PDT) Message-ID: <3BBB8714.8E24FC20@cup.hp.com> Date: Wed, 03 Oct 2001 14:45:56 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Rod Harrison Cc: Ayman Ghanem , ips@ece.cmu.edu Subject: Re: iscsi : DataPDULength can differ in each direction. 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, The issue came up as a result of Deva pointing out that an initiator may not be able to function with the minimal of the 2 DataPDULengths (initiator's & target's) in the case where the value chosen was not its value. In order to allow for such implementations that had issues with the DataPDULength, I raised this question. The benefit of both sides being allowed different DataPDULengths is : a) Each side can specify its max supported value which the other side would not exceed. The sender & receiver would be able to function with different DataPDULengths, with the guarantee that their advertised receive pdu length will not be exceeded, thus, allowing more flexible interoperability of implementations. (btw, the proposal should have read : Each side is allowed to advertise its maximum receive pdu length.) b) It may also allow 2 parties with differing PDU lengths to send larger sized PDUs in one direction to the party that advertised a higher receive pdu length. However, I do admit there's a cost to making this change, given we are so late in the draft rev and several implementations have already been made. If this is not an issue of concern to the majority of implementations, I am ok with the current definition, although it is more limiting on implementations. Thanks, Santosh Rod Harrison wrote: > > Can someone give a tangible benefit to this that can outweigh the > spec and implementation churn at this late stage of the game? > > From my point of view the benefit of asymmetric PDU sizes would have > to be very large to make it worth the extra complexity in buffer > management code alone. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Ayman Ghanem > Sent: Wednesday, October 03, 2001 8:29 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : DataPDULength can differ in each direction. > > Well, the proposal says: > > Each side should be allowed to specify the DataPDULength it will be > using and there should be no attempt to negotiate this value. Rather, > the key is exchanged in either direction to inform the other side as > to > what sized PDUs it should expect. > > So, I understand that as if the initiator sends > DataPDULength=reallyBigNumber, then it is informing the target that > this is > what it will be using, but the target should not attempt to negotiate > it. > > -Ayman > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf > Of > > Buck Landry > > Sent: Wednesday, October 03, 2001 2:13 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > > > It may add complexity, but, since DataPDULength is only a boundary > on > > the maximum number of bytes transmitted in a Data PDU (not the > minimum), > > "the first" *does* have a say about it. Right? > > > > -----Original Message----- > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > Sent: Wednesday, October 03, 2001 1:38 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > > > I think this will add unnecessary complexity, specially for data > CRCs > > having > > to be calculated based on two different PDU sizes for Reads and > Writes. > > Also, one end may choose to do data digests in software. If the > other > > end > > decides to use a really large PDU length (and the first doesn't have > a > > say > > about it), this could be a problem. > > > > -Ayman > > > > > > -- ################################## 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 Wed Oct 3 19:09: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 TAA02990 for ; Wed, 3 Oct 2001 19:09:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93MPLq14542 for ips-outgoing; Wed, 3 Oct 2001 18:25:21 -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 [217.17.136.66] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f93MPIP14534 for ; Wed, 3 Oct 2001 18:25:19 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 00:27:19 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B988A@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Dev - Platys'" , Sandeep Joshi , ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation offering party based computaion vs responder based Date: Thu, 4 Oct 2001 00:27:19 +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, Sorry for those who cannot view Excel sheet. you can view the file at the link http://www.radhekrishna.org/iSCSI/numeric_nego_comparison.htm Please dont blame me for my ugly site. It was a very half hearted attempt from me long ago. And I am sorry I cant put it on the company website now because our system guy has left for the day. Sanjeev -----Original Message----- From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] Sent: Wednesday, October 03, 2001 10:44 PM To: 'Dev - Platys'; Sandeep Joshi; ips@ece.cmu.edu Subject: iscsi : numerical negotiation offering party based computaion vs responder based Hello all, i just changed the name of the thread, because the thread is now taking different directions. I am attaching an excel file here in which i have taken 7 different cases to show how there could be some mis interpretation when offering party computes the individual results. I have taken the example of dataPDuSize because i started making my table with this although there is a different thread going on to it whether it should be kept in numerical negotiation or not. In the table I have tried to take cases where the initiator and target may not support some PDU sizes which are lower than the maximum PDU size they support. Deva: it also tells when a reject might be needed. Regards, Sanjeev -----Original Message----- From: Dev - Platys [mailto:deva@platys.com] Sent: Wednesday, October 03, 2001 6:14 PM To: Sandeep Joshi; ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Santosh, The point is, if the target is not capable of supporting 16K (it is just an example that is being discussed), then it indicates that is what it wants. Initiator can close the connection. (No reject is necessary though). However, if the target knows it can support the initiator negotiated value, it could return it. Again, Yes, implicitly it becomes the responder selects logic. Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Sandeep Joshi Sent: Wednesday, October 03, 2001 7:29 AM To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous The first & third example below seem illogical. The responder should not be sending 24K if the initial sender has chosen a value of 16K, since there is no possibility of that 24K being accepted (unless we want three way exchanges for every negotiation??) The problem of a Reject message does not arise since the responder should only be choosing something less than 16K. So I guess this puts me in the "responder selects logic" camp. -Sandeep Julian Satran wrote: > > An example: > 08.txt logic > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Selected value is 16k > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Selected value is 16k > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k > > ----- > > Responder selects logic > > i->t DataPDULength=16k > t->i DataPDULength= 24k > > Error - Initiator Reject - Closes connection > > i->t DataPDULength=16k > t->i DataPDULength= 8k > > Selected value is 8k > > t->i DataPDULength=16k > i->t DataPDULength= 24k > > Error Target has to terminate with parameter error > > t->i DataPDULength=16k > i->t DataPDULength= 8k > > Selected value is 8k > > "Dev - Platys" > To: "Julian Satran" > , > 01-10-01 23:46 > Please respond to "Dev - cc: > Platys" Subject: RE: iscsi : > numerical negotiation wording is ambiguous > > > > Julian, > > I am not sure why a 'REJECT' is required. > Can you please explain why is this required? > > I am with Santosh in this. > > >There is NO need for any REJECT in the above >case. If the initiator > >is'nt satisfied with the value returned by the >originator and cannot > >function with the negotiated values, it can simply >close the TCP > >connection. There is no need to send any >REJECT. > > Thanks > > Deva > Adaptec > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Monday, October 01, 2001 1:28 PM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > Santosh, > > We are getting nowhere. Even if requester is doing it's stuff - the > requester will have to check and be prepared for a mistake. The coding > will require a reject. > > Julo > > Santosh Rao > To: ips@ece.cmu.edu > Sent by: cc: "Sanjeev Bhagat > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > Julian Satran/Haifa/IBM@IBMIL > 01-10-01 20:37 Subject: Re: iscsi : numerical > Please respond to negotiation wording is ambiguous > Santosh Rao > > > Julian & Sanjeev, > > Responding to both your mails...... > > Julian : > > I think you may have mis-interpreted my comments. I believe Sanjeev > has > clarified the intent of my suggestions. > > I am *not* suggesting that the responder send back its values and > these > be blindly imposed on the originator. On the contrary, my suggestion > is > that the computation of the result of the negotiation (higher or lower > of the 2 values) be only performed by the responder and sent back to > the > originator. > > The result of the negotiation is the same in both cases and there is > no > REJECT required in my case nor yours. The difference is the advantages > I've stated in my model. > > Sanjeev, in response to your comment : > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. " > > There is NO need for any REJECT in the above case. If the initiator > is'nt satisfied with the value returned by the originator and cannot > function with the negotiated values, it can simply close the TCP > connection. There is no need to send any REJECT. > > Thanks, > Santosh > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Thanks Julian, please find my further comments in the message > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Sunday, September 30, 2001 6:07 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : numerical negotiation wording is > > ambiguous > > > > 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > say it this way the responder computes the value with > > its own supported values and responds with a value y > > which the responder thinks is correct 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > but it is highly unlikely for the responder to reject > > the final result because the rule states that (lower or > > higher of two will be the result) and so the offering > > party should be able to accept the lower or higher > > range as defined by rule. In case the key is dependent > > upon some range of fixed values then the negotiation > > should be performed as list negotiation and not > > numerical negotiation. > > > > This might be what you "conventionally" do - I don't > > and that shows that convention like morals are a matter > > of geography :-) > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > The advantage of this set of rules is that it allows an > > external observer to know what was selected without > > knowing the rules > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > case, I guess that the external observer has to know > > the rules to double check the value is correct or not > > 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. > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. > > > > > > Sanjeev > > "Sanjeev Bhagat > > (TRIPACE/Zoetermeer)" To: "'Santosh > Rao'" > > , Julian > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > cc: > ips@ece.cmu.edu > > 30-09-01 16:32 Subject: RE: > iscsi : > > Please respond to "Sanjeev numerical negotiation wording > is > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > -- > ################################## > 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 Wed Oct 3 19:12: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 TAB03061 for ; Wed, 3 Oct 2001 19:12:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93MOUE14444 for ips-outgoing; Wed, 3 Oct 2001 18:24:30 -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 [217.17.136.66] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f93MOSP14439 for ; Wed, 3 Oct 2001 18:24:28 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 00:26:28 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B9889@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Santosh Rao'" , Rod Harrison Cc: Ayman Ghanem , ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Thu, 4 Oct 2001 00:26:28 +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 think making DataPDULength different on two side will bring complexity in implementation. Calculation of CRC, handling unknown and very high value of DataPDUlength, change in buffer management code etc etc and above all.. a radical change so late in the specs chould be avoided. In my view we rather can choose for either of the two ways 1. Either make DataPDULength as list negotiation, which makes sure that the computing party choses a result which other party will definitley support or 2. keep it like numeric negotiation with result being computed by responding party and double checked by the offering party. In case there is still any error when the offering party gets the result, they may either go for reject or re-nogotiation. Sanjeev -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, October 03, 2001 11:46 PM To: Rod Harrison Cc: Ayman Ghanem; ips@ece.cmu.edu Subject: Re: iscsi : DataPDULength can differ in each direction. Rod, The issue came up as a result of Deva pointing out that an initiator may not be able to function with the minimal of the 2 DataPDULengths (initiator's & target's) in the case where the value chosen was not its value. In order to allow for such implementations that had issues with the DataPDULength, I raised this question. The benefit of both sides being allowed different DataPDULengths is : a) Each side can specify its max supported value which the other side would not exceed. The sender & receiver would be able to function with different DataPDULengths, with the guarantee that their advertised receive pdu length will not be exceeded, thus, allowing more flexible interoperability of implementations. (btw, the proposal should have read : Each side is allowed to advertise its maximum receive pdu length.) b) It may also allow 2 parties with differing PDU lengths to send larger sized PDUs in one direction to the party that advertised a higher receive pdu length. However, I do admit there's a cost to making this change, given we are so late in the draft rev and several implementations have already been made. If this is not an issue of concern to the majority of implementations, I am ok with the current definition, although it is more limiting on implementations. Thanks, Santosh Rod Harrison wrote: > > Can someone give a tangible benefit to this that can outweigh the > spec and implementation churn at this late stage of the game? > > From my point of view the benefit of asymmetric PDU sizes would have > to be very large to make it worth the extra complexity in buffer > management code alone. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Ayman Ghanem > Sent: Wednesday, October 03, 2001 8:29 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : DataPDULength can differ in each direction. > > Well, the proposal says: > > Each side should be allowed to specify the DataPDULength it will be > using and there should be no attempt to negotiate this value. Rather, > the key is exchanged in either direction to inform the other side as > to > what sized PDUs it should expect. > > So, I understand that as if the initiator sends > DataPDULength=reallyBigNumber, then it is informing the target that > this is > what it will be using, but the target should not attempt to negotiate > it. > > -Ayman > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf > Of > > Buck Landry > > Sent: Wednesday, October 03, 2001 2:13 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > > > It may add complexity, but, since DataPDULength is only a boundary > on > > the maximum number of bytes transmitted in a Data PDU (not the > minimum), > > "the first" *does* have a say about it. Right? > > > > -----Original Message----- > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > Sent: Wednesday, October 03, 2001 1:38 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > > > I think this will add unnecessary complexity, specially for data > CRCs > > having > > to be calculated based on two different PDU sizes for Reads and > Writes. > > Also, one end may choose to do data digests in software. If the > other > > end > > decides to use a really large PDU length (and the first doesn't have > a > > say > > about it), this could be a problem. > > > > -Ayman > > > > > > -- ################################## 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 Wed Oct 3 20:15: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 UAA04377 for ; Wed, 3 Oct 2001 20:15:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93N8Rc18906 for ips-outgoing; Wed, 3 Oct 2001 19:08: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 f93N8PP18901 for ; Wed, 3 Oct 2001 19:08:25 -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 TAA00242 for ; Wed, 3 Oct 2001 19:08:19 -0400 (EDT) Message-ID: <3BBB9A43.CCF5A838@cisco.com> Date: Wed, 03 Oct 2001 18:07:47 -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: Question on reject and none Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, 1. Are "reject" and "none" valid only for "list" negotiations? My understanding of draft -08 is yes. 2. Are the only currently defined "list" negotiation keys AuthMethod, HeaderDigest and DataDigest? My understanding of draft -08 is yes. Regards, Steve Senum From owner-ips@ece.cmu.edu Wed Oct 3 20:21: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 UAA04549 for ; Wed, 3 Oct 2001 20:21:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93NkYm22499 for ips-outgoing; Wed, 3 Oct 2001 19:46:34 -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 f93NkXP22494 for ; Wed, 3 Oct 2001 19:46:33 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id 437661F5E9 for ; Wed, 3 Oct 2001 19:44:25 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 4FA191F51B for ; Wed, 3 Oct 2001 19:46:27 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Oct 2001 19:46:27 -0400 Message-ID: <499DC368E25AD411B3F100902740AD6508E99AA7@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Date: Wed, 3 Oct 2001 19:46: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 > The first & third example below seem illogical. I agree. > So I guess this puts me in the "responder selects logic" > camp. Same here. -Shawn ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- ------------------------------------------------------- > -----Original Message----- > From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] > Sent: Wednesday, October 03, 2001 7:29 AM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > The first & third example below seem illogical. > > The responder should not be sending 24K if the initial > sender has chosen a value of 16K, since there is no > possibility of that 24K being accepted (unless we want > three way exchanges for every negotiation??) > > The problem of a Reject message does not arise since the > responder should only be choosing something less than 16K. > So I guess this puts me in the "responder selects logic" > camp. > > -Sandeep > > > Julian Satran wrote: > > > > An example: > > 08.txt logic > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Selected value is 16k > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Selected value is 16k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > ----- > > > > Responder selects logic > > > > i->t DataPDULength=16k > > t->i DataPDULength= 24k > > > > Error - Initiator Reject - Closes connection > > > > i->t DataPDULength=16k > > t->i DataPDULength= 8k > > > > Selected value is 8k > > > > t->i DataPDULength=16k > > i->t DataPDULength= 24k > > > > Error Target has to terminate with parameter error > > > > t->i DataPDULength=16k > > i->t DataPDULength= 8k > > > > Selected value is 8k > > > > "Dev - Platys" > > To: "Julian Satran" > > , > > 01-10-01 23:46 > > Please respond to "Dev - cc: > > Platys" Subject: RE: iscsi : > > numerical negotiation wording is > ambiguous > > > > > > > > Julian, > > > > I am not sure why a 'REJECT' is required. > > Can you please explain why is this required? > > > > I am with Santosh in this. > > > > >There is NO need for any REJECT in the above >case. If the > initiator > > >is'nt satisfied with the value returned by the >originator > and cannot > > >function with the negotiated values, it can simply >close the TCP > > >connection. There is no need to send any >REJECT. > > > > Thanks > > > > Deva > > Adaptec > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Monday, October 01, 2001 1:28 PM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > Santosh, > > > > We are getting nowhere. Even if requester is doing it's stuff - the > > requester will have to check and be prepared for a mistake. > The coding > > will require a reject. > > > > Julo > > > > Santosh Rao > > To: ips@ece.cmu.edu > > Sent by: cc: "Sanjeev Bhagat > > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > > Julian Satran/Haifa/IBM@IBMIL > > 01-10-01 20:37 Subject: Re: iscsi : numerical > > Please respond to negotiation wording is ambiguous > > Santosh Rao > > > > > > Julian & Sanjeev, > > > > Responding to both your mails...... > > > > Julian : > > > > I think you may have mis-interpreted my comments. I believe Sanjeev > > has > > clarified the intent of my suggestions. > > > > I am *not* suggesting that the responder send back its values and > > these > > be blindly imposed on the originator. On the contrary, my suggestion > > is > > that the computation of the result of the negotiation > (higher or lower > > of the 2 values) be only performed by the responder and sent back to > > the > > originator. > > > > The result of the negotiation is the same in both cases and there is > > no > > REJECT required in my case nor yours. The difference is the > advantages > > I've stated in my model. > > > > Sanjeev, in response to your comment : > > > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. " > > > > There is NO need for any REJECT in the above case. If the initiator > > is'nt satisfied with the value returned by the originator and cannot > > function with the negotiated values, it can simply close the TCP > > connection. There is no need to send any REJECT. > > > > Thanks, > > Santosh > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Thanks Julian, please find my further comments in the message > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Sunday, September 30, 2001 6:07 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iscsi : numerical negotiation wording is > > > ambiguous > > > > > > 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > > say it this way the responder computes the value with > > > its own supported values and responds with a value y > > > which the responder thinks is correct 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > > but it is highly unlikely for the responder to reject > > > the final result because the rule states that (lower or > > > higher of two will be the result) and so the offering > > > party should be able to accept the lower or higher > > > range as defined by rule. In case the key is dependent > > > upon some range of fixed values then the negotiation > > > should be performed as list negotiation and not > > > numerical negotiation. > > > > > > This might be what you "conventionally" do - I don't > > > and that shows that convention like morals are a matter > > > of geography :-) > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > > > The advantage of this set of rules is that it allows an > > > external observer to know what was selected without > > > knowing the rules > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > > case, I guess that the external observer has to know > > > the rules to double check the value is correct or not > > > 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. > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. > > > > > > > > > Sanjeev > > > "Sanjeev Bhagat > > > (TRIPACE/Zoetermeer)" To: > "'Santosh > > Rao'" > > > > , Julian > > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > > cc: > > ips@ece.cmu.edu > > > 30-09-01 16:32 Subject: RE: > > iscsi : > > > Please respond to "Sanjeev numerical > negotiation wording > > is > > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > > > > -- > > ################################## > > 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 Wed Oct 3 20:22: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 UAA04571 for ; Wed, 3 Oct 2001 20:22:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f93NmFn22676 for ips-outgoing; Wed, 3 Oct 2001 19:48:15 -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 f93NmEP22672 for ; Wed, 3 Oct 2001 19:48:14 -0400 (EDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel6.hp.com (Postfix) with ESMTP id 0E2741F9D2; Wed, 3 Oct 2001 19:48:08 -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 F194B1F51F; Wed, 3 Oct 2001 19:48:04 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id <41CFXT43>; Wed, 3 Oct 2001 19:48:04 -0400 Message-ID: <499DC368E25AD411B3F100902740AD6508E99AA8@xrose03.rose.hp.com> From: "ERICKSON,SHAWN (HP-Roseville,ex1)" To: "'Santosh Rao'" , Sandeep Joshi , Julian Satran Cc: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Date: Wed, 3 Oct 2001 19:48:01 -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 > Another value-add of the "responder picks the negotiation > result model" > is that the initiator can use the following "query based" negotiation > model to always use the values the target is capable of offering : > > I -> T : DataPDULength=? > T -> I : DataPDULength=64K > > Both sides agree to use a DataPDULength of 64K. I like the idea! ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- ------------------------------------------------------- From owner-ips@ece.cmu.edu Wed Oct 3 21: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 VAA06091 for ; Wed, 3 Oct 2001 21:24:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f940YKD26820 for ips-outgoing; Wed, 3 Oct 2001 20:34:20 -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 f940YHP26809 for ; Wed, 3 Oct 2001 20:34:17 -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 53A03232D for ; Wed, 3 Oct 2001 18:34:16 -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 077D815E for ; Wed, 3 Oct 2001 18:34:16 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id RAA06984 for ips@ece.cmu.edu; Wed, 3 Oct 2001 17:33:16 -0700 (PDT) From: Dave Sheehy Message-Id: <200110040033.RAA06984@acropora.rose.agilent.com> Subject: RE: iscsi : DataPDULength can differ in each direction. To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Wed, 03 Oct 2001 17:33:15 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > Can someone give a tangible benefit to this that can outweigh the > spec and implementation churn at this late stage of the game? It would allow iSCSI HBAs to interact more efficiently with SW iSCSI implementations and vice versa. > From my point of view the benefit of asymmetric PDU sizes would have > to be very large to make it worth the extra complexity in buffer > management code alone. From the vantage point of an iSCSI HBA it doesn't seem all that hard. Dave From owner-ips@ece.cmu.edu Thu Oct 4 00: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 AAA12260 for ; Thu, 4 Oct 2001 00:13:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f943MmZ07002 for ips-outgoing; Wed, 3 Oct 2001 23:22:48 -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 f943MkP06997 for ; Wed, 3 Oct 2001 23:22:47 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail16.vwh1.net (RS ver 1.0.60s) with SMTP id 034354237; Wed, 3 Oct 2001 23:22:24 -0400 (EDT) From: "Dev - Platys" To: "Santosh Rao" , "Julian Satran" Cc: "IPS Reflector" Subject: RE: iscsi : originating & responding parties in login. Date: Wed, 3 Oct 2001 20:28:58 -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: <3BBB81ED.5931C4D1@cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh- I agree with you. The initiator will (should) always be the originator either by explicitly sending the key value or not sending and thereby implicitly negotiating for the default value. This simplifies a lot, in my opinion. Julian- is there any specific reason, why would an initiator explicity a value even if it is default? Can the target not determine that by sending no keys, initiator is actually sending a default value? Am I missing something otherwise? Thanks Deva -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Santosh Rao Sent: Wednesday, October 03, 2001 2:24 PM To: Julian Satran Cc: IPS Reflector Subject: Re: iscsi : originating & responding parties in login. Julian Satran wrote: > Julian Satran wrote: > > > As negotiations can start at either initiator or target the > originator > > the one that starts the negotiation. > > Julian, > > OTOH, since the initiator did offer a value (the default value), is'nt > it always the originator ? In which case [other than a target vendor > specific proprietary key] would an operational negotiation start at > the > target ? > +++ offering a value is an active thing. Defaults and previous values > don't count. +++ This is intriguing. If an initiator explicitly sent a key value (albeit, with the key initialized to the default), the initiator is considered the originator. However, if the initiator chose to not send the key explicitly, but use the default, it then becomes the responder. [if target does not accept the default.] This leads to different on-the-wire login behaviour if the initiator chose to use defaults instead of sending those same key values explicitly. It also causes an additional dummy login hand-shake for no purpose. Thus, in the case where initiator wants to use, say, FirstBurstSize=128 & target allows FirstBurstSize to be 8, then, the behaviour on the wire is different depending on whether the initiator used the default or explicitly sent the key. Case 1) Initiator sends the default value as an explicit offering ------------------------------------------------------------------ I -> T : FirstBurstSize=128 (initiator is the originator) (CSG=Operational, NSG=FFP). T=1 T -> I : FirstBurstSize=8 (target responds with lower value it supports.) (CSG=Operational, NSG=FFP). T=1 Negotiation ends at initiator with both sides picking FirstBurstSize=8. Single login handshake. Case 2) Initiator does not send the key. (default is in use). ------------------------------------------------------------- I -> T : (no key sent). (defaults to 128.) (CSG=Operational , NSG=FFP). T=1 T -> I : FirstBurstSize=8 (CSG=Operational, NSG=Operational). T=0 I -> T : FirstBurstSize=128 (initiator explicitly resends the default !). (CSG=Operational, NSG=FFP). T=1 T -> I : (no key sent. but a dummy login response to conclude login is sent). (CSG=Operational, NSG=FFP). T=1 Negotiation ends at the target, with both sides settling at FirstBurstSize=8 Login phase ends at the initiator. 2 login handshakes. Julian : What is the benefit of the above behaviour ? It results in inconsistent login behaviour and will only cause initiators to send login keys explicitly, defeating the purpose of defining defaults. I would rather the spec state that the initiator is the originator of the key when it uses default values, so that the login behaviour is the same in both scenarios above. Thanks, Santosh > > > > Julian, > > > > I've YET another login question for you : > > > > Please refer the following text in Section 2.2.4 of the Rev 08 draft > : > > > > "For numerical negotiations, the responding party MUST respond with > > the > > required key." > > > > When the initiator uses the default settings for a login key (i.e. > > does > > not send the key) and a target does not support that default, it has > > to > > originate the key in its login response to notify the initiator that > > it > > does not support the default. > > > > In the above example, who is the originating party & responding > party > > ? > > Is the initiator always considered an originating party for all the > > operational and security keys, even if it did not explicitly send > that > > key in its login ? > > > > If the target originated a login key, say DataPDULength, (and is > > therefore, to be considered as the originating party ?), based on > your > > rule quoted above, the exchange would be : > > > > I -> T : (no key is sent for DataPDULength. Assumes default of 16 > > units. > > (8K).) > > > > T -> I : DataPDULength=8 > > > > I -> T : DataPDULength=8 (See quoted rule above.) > > > > The definition of originating & responding party is not clear when > > defaults are used by the initiator and can lead to [mis- > > ?]interpretations such as the above. > > > > The above response from I -> T seems redundant to me. I suggest that > > the > > draft clearly state who the originating & responding party are when > > defaults are used, so as to avoid confusion along the above lines. > > > > 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 Oct 4 02:59: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 CAA29388 for ; Thu, 4 Oct 2001 02:59:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f945wW519326 for ips-outgoing; Thu, 4 Oct 2001 01:58: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 f945wUl19322 for ; Thu, 4 Oct 2001 01:58: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 BAA38062 for ; Thu, 4 Oct 2001 01:56:06 -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 f945wSk175448 for ; Wed, 3 Oct 2001 23:58:28 -0600 Importance: Normal Subject: RE: iscsi : numerical negotiation wording is ambiguous 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: Wed, 3 Oct 2001 22:57:20 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/03/2001 11:58:28 PM 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 f945wVl19323 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, I find your response troubling, perhaps I did not understand what you intended to say. Comments below. . . . 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 10/03/2001 05:26:58 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iscsi : numerical negotiation wording is ambiguous An example:  08.txt logic i->t DataPDULength=16k t->i DataPDULength= 24k Selected value is 16k [Huff] If target knows that the Initiator wants 16k, and therefore that its 24k is not going to be accepted, why did the Target send 24K? [/Huff] i->t DataPDULength=16k t->i DataPDULength= 8k Selected value is 8k t->i DataPDULength=16k i->t DataPDULength= 24k Selected value is 16k [Huff] If Initiator knows that the target wants 16k, and therefore that its 24k is not going to be accepted, why did the Initiator send 24K? [/Huff] t->i DataPDULength=16k i->t DataPDULength= 8k Selected value is 8k ----- Responder selects logic i->t DataPDULength=16k t->i DataPDULength= 24k Error - Initiator Reject - Closes connection i->t DataPDULength=16k t->i DataPDULength= 8k Selected value is 8k t->i DataPDULength=16k i->t DataPDULength= 24k Error Target has to terminate with parameter error t->i DataPDULength=16k i->t DataPDULength= 8k Selected value is 8k "Dev - Platys"         To: "Julian Satran" 01-10-01 23:46 , "Dev - Platys"         cc:         Subject: RE: iscsi : numerical negotiation wording is ambiguous Julian, I am not sure why a 'REJECT' is required. Can you please explain why is this required? I am with Santosh in this. >There is NO need for any REJECT in the above >case. If the initiator >is'nt satisfied with the value returned by the >originator and cannot >function with the negotiated values, it can simply >close the TCP >connection. There is no need to send any >REJECT. Thanks Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Monday, October 01, 2001 1:28 PM To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous Santosh, We are getting nowhere. Even if requester is doing it's stuff - the requester will have to check and be prepared for a mistake. The coding will require a reject. Julo Santosh Rao        cc:        "Sanjeev Bhagat Sent by: (TRIPACE/Zoetermeer)" santoshr@cup.hp.co , Julian m Satran/Haifa/IBM@IBMIL        Subject:        Re: iscsi : 01-10-01 20:37 numerical negotiation wording is ambiguous Please respond to Santosh Rao Julian & Sanjeev, Responding to both your mails...... Julian : I think you may have mis-interpreted my comments. I believe Sanjeev has clarified the intent of my suggestions. I am *not* suggesting that the responder send back its values and these be blindly imposed on the originator. On the contrary, my suggestion is that the computation of the result of the negotiation (higher or lower of the 2 values) be only performed by the responder and sent back to the originator. The result of the negotiation is the same in both cases and there is no REJECT required in my case nor yours. The difference is the advantages I've stated in my model. Sanjeev, in response to your comment : " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is >  no reject , but it can be a problem in future . >  Consider your example of DataPDULength in your own >  message. Suppose offering party sends a value of 16,384 >  (this is also lowest value it can send) and responding >  party responds with 8,192. In this case the offering >  party will have to reject the negotiation. So a reject >  message is needed in this case also. " There is NO need for any REJECT in the above case. If the initiator is'nt satisfied with the value returned by the originator and cannot function with the negotiated values, it can simply close the TCP connection. There is no need to send any REJECT. Thanks, Santosh > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > Thanks Julian, please find my further comments in the message > >      -----Original Message----- >      From: Julian Satran [mailto:Julian_Satran@il.ibm.com] >      Sent: Sunday, September 30, 2001 6:07 PM >      To: ips@ece.cmu.edu >      Subject: RE: iscsi : numerical negotiation wording is >      ambiguous > >      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 >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather >           say it this way the responder computes the value with >           its own supported values and responds with a value y >           which the responder thinks is correct 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 >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, >           but it is highly unlikely for the responder to reject >           the final result because the rule states that (lower or >           higher of two will be the result) and so the offering >           party should be able to accept the lower or higher >           range as defined by rule. In case the key is dependent >           upon some range of fixed values then the negotiation >           should be performed as list negotiation and not >           numerical negotiation. > >           This might be what you "conventionally" do - I don't >           and that shows that convention like morals are a matter >           of geography :-) >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > >           The advantage of this set of rules is that it allows an >           external observer to know what was selected without >           knowing the rules >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this >           case, I guess that the external observer has to know >           the rules to double check the value is correct or not >           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. >           [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is >           no reject , but it can be a problem in future . >           Consider your example of DataPDULength in your own >           message. Suppose offering party sends a value of 16,384 >           (this is also lowest value it can send) and responding >           party responds with 8,192. In this case the offering >           party will have to reject the negotiation. So a reject >           message is needed in this case also. > > >      Sanjeev >       "Sanjeev Bhagat >       (TRIPACE/Zoetermeer)"                    To:        "'Santosh Rao'" >                  , Julian >       Sent by: owner-ips@ece.cmu.edu   Satran/Haifa/IBM@IBMIL >                                                cc:        ips@ece.cmu.edu >       30-09-01 16:32                           Subject:        RE: iscsi : >       Please respond to "Sanjeev       numerical negotiation wording is >       Bhagat (TRIPACE/Zoetermeer)"     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 > -- ################################## 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 Oct 4 05:05: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 FAA02614 for ; Thu, 4 Oct 2001 05:05:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9481QQ25280 for ips-outgoing; Thu, 4 Oct 2001 04:01:26 -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 f9481Pl25275 for ; Thu, 4 Oct 2001 04:01: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 DAA86350; Thu, 4 Oct 2001 03:59: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 f9481Nk18998; Thu, 4 Oct 2001 02:01:23 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: ISID issue To: Black_David@emc.com Cc: ips@ece.cmu.edu, "Jim Hafner" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 4 Oct 2001 01:00:31 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/04/2001 02:01:23 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 f9481Pl25276 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit David, We spent a lot of time yesterday at the end of the Naming and Discovery Team (NDT) meeting, trying to rectify everything that you and Jim had been sending notes about. We tried to see if we could fully understand the various positions. I even argued your position regarding the Target handling out the ISID but the group beat me back with their logic. And that Logic was included in Jim's latest Note. Sorry I could not do a better Job of representing your position. However, there were some other things that we batted around that I will cover here. First, the Name which you want to work with in the iSCSI ACLs is the iSCSI Initiator Node Name. That should be the same for ALL iSCSI Initiators in a Host Node. If vendors attempt to use anything else, I think they are not following the spec. And should be sent to Singapore for Caning :-) If you accept that HBAs should get the iSCSI Initiator Node Name passed to it in some manner from the OS, then we did not see why it can not get the ISID at the same time also. If one were to argue that the HBA can not get the iSCSI Initiator Node Name, I think this is a bit strange, since almost every thing I install in systems, has to go through some type of Wizard, or vendor install routine that actually installs the support driver, etc. (This is all set when the OS is fully up and the Registry etc. is clearly available.) I would expect that with current OSs, this would be a normal approach. In the future, I suppose it might be possible that the OSs might have a more dynamic routine to hand out the iSCSI Initiator Node Name and ISID so that Hot Swap HBAs could come up without effort. However, until then, I am not sure it is unreasonable for a vendor to require the customer to run an update routine, even after performing an HBA Hot Swap. There is of course, the first up boot situation. I think it should be possible to have a default, first time HBA boot Name that uses the iqn form of the iSCSI Name, and an ISID of 0. This should be enough to bring up a "first time up boot", since after the OS is started, the approprate install routine should be kicked off, and the real iSCSI Initiator Node Name and real ISID set in the Flash for that, and any other iSCSI HBAs. So based on the above, I do not think requiring the HBAs to have an install/update routine (which sets its Flash) is even a problem. This means that a Single iSCSI Initiator Node Name should be easy to obtain and will apply for all the iSCSI Initiators, whether HW or SW. When Jim talked about the new SCSI idea that would have Persistent Reserves being tied to the Initiator Node, it seemed clear to me, and I think to the others on the team, that the iSCSI Initiator Node Name was ideal to be used for that purpose. Jim pointed out, again to us, that this name was NOT part of any other Nexus meaning, it is only to be used with Persistent Reserves. All other Nexus meanings are against the iSCSI Initiator's FULL NAME which is the iSCSI initiator Node Name and the 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 10/03/2001 12:23:42 PM Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: RE: iSCSI: ISID issue I'm getting ready to give up on this due to lack of interest on the list. As near as I can tell the arguments in favor of ISIDs are: (1) They've been in the spec for a long time. (2) Provide symmetry in session identification and a clean mapping to SAM-2 concepts. (3) Accommodates possible future persistent reserve functionality. Of these, I regard (1) and (2) as weak, and will explain in a moment why (3) is incorrect as things currently stand. The arguments against are: (4) ISID existence is the direct cause of the Option A/Option B issue about whether setting up a connection with an existing ISID is supposed to blow away an existing connection with the same ISID. (5) The ISID rule does not appear to be uniformly implementable in practice on common OS platforms via means other than (error-prone) manual configuration. The whole notion that OS vendors will address this sort of allocation issue just because we think they should is an exercise in wishful thinking. (6) Argument (3) above is incorrect, as the possible future persistent reserve functionality will not work as expected when different ISID values are used by the same Initiator to access Targets or Target Portal Groups for which sharing of persistent reserves is desired. To correct the problem with (3), we would have to require that the same ISID values be used across all Targets that may share an LU, which in practice probably means all Targets as the LU sharing structure across Targets is unlikely to be visible to iSCSI. I hesitate to write such a rule into iSCSI now to anticipate functionality that is still in a "to be defined" state at T10, because it will impact implementations. Julian and Jim's comments on specification of LU mapping miss the point. The point is that really simple consistent rules for how things work at this basic level are necessary to get management that scales decently. To be specific, suppose I have a reasonable sized SMP machine that has 5 Ethernet ports that support iSCSI spread across 3 HBAs and two drivers - how many iSCSI Initiator Names have to be configured into a Target LUN masking implementation to give that machine access to its storage from all 5 ports? The iSCSI answer is a long version of "it depends" that starts with "find the iSCSI documentation for your host and each of the HBAs to see how each of them deal with iSCSI Initiator Names". The possible values probably range from 1-3. In contrast, the corresponding Fibre Channel answer of 5 (Port WWN for each FC port) is superior even though it's a larger number because it's the only possible answer and all the HBAs have to work the same way. The reason it's superior is that neither the management software programmers nor the system administrators have to spend any mental cycles having to think about instances of the same protocol that have to be administered differently. For iSCSI, the ideal answer to the above question is 1. IMHO, removing ISIDs visibly increases the likelihood of that actually being the case all the time in practice. Alternatively, if we leave ISIDs in, I'd want to see a hard look at how to toughen the current ISID rule to prevent the problem identified in (6), and even then, I think the result is still less likely to lead to the desired goal. I think part of the difference I have with Jim Hafner is that I think he wants to make it possible for the future target-spanning persistent reservation functionality to work without requiring that it work (i.e., it'd be ok to have initiators behave in a way that reservations never span targets, even when targets implement the new functionality). I don't think that's good enough - if we go to the trouble of enabling this, we should do so in a fashion that is guaranteed to work in the presence of target support for the feature. As I said, I'm getting ready to give up on this, because I don't see much in the way of appreciation of the importance of scalable management and the role of simplicity (in the extreme) in enabling it on the list. --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 --------------------------------------------------- > Let me just reiterate more strongly Julo's comment "we may request the LU > mapping - for  iSCSI - be defined only by the InitiatorName". > T10 has approved use of the iSCSI InitiatorName as the "TransportID" for > SCSI access controls (lu mapping). The portnames have no direct function > in this context for iSCSI (though they do have an indirect affect that > isn't worth discussing here). > > Whether this standardized approach to lu mapping is adopted by vendors is a > different question, but the standard is there. > > The issue of port name/identity is primarily an issue for persistent > reservations (in all its current and future forms). > > Jim Hafner > > > Julian Satran/Haifa/IBM@IBMIL@ece.cmu.edu on 10/03/2001 10:20:53 am > > Sent by: owner-ips@ece.cmu.edu > > > To: "ERICKSON,SHAWN (HP-Roseville,ex1)" > cc: "'Black_David@emc.com'" , ips@ece.cmu.edu, > owner-ips@ece.cmu.edu, santoshr@cup.hp.com > Subject: RE: iSCSI: ISID issue > > > > > I agree that LU mapping might be tricky but topology mapping is not > affected by ISID allocation. You have to get a consistent > mapping of target > ports (and the model does that) and Initiators that know how to reach > targets. Initiators have to know the physical identity of the > portal when > they open the connection (or they can get it through a local > service) and > the ISID has no role in topology mapping. > > I would also say that for any practical purpose we may request the LU > mapping - for  iSCSI - be defined only by the InitiatorName > part of the > InitiatorPortName. > > Julo > > > > > "ERICKSON,SHAWN > > (HP-Roseville,ex1)" > To: > > santoshr@cup.hp.com, > Sent by: > ips@ece.cmu.edu > owner-ips@ece.cmu.edu > cc: > > "'Black_David@emc.com'" > 02-10-01 19:25 > > Please respond to > Subject: > "ERICKSON,SHAWN RE: > iSCSI: ISID issue > (HP-Roseville,ex1)" > > > > > > > > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Monday, October 01, 2001 3:11 PM > > To: santoshr@cup.hp.com; ips@ece.cmu.edu > > Subject: RE: iSCSI: ISID issue > > > > > > Santosh Rao wrote: > > > > > I think comparisions to FC's mess-up of the node WWN are > > not fair to the > > > current ISID rule, since, unlike in FC, the worst case > > scenario with the > > > ISID rule, is that each iscsi driver on the system will take up a > > > different iscsi initiator name. > > > > At least FC had the Port WWN to fall back on.  This is headed for a > > situation > > where the iSCSI Initiator Name is unusable for access control > > configuration > > because whether it corresponds to the network interface, the > > HBA (e.g., > > suppose > > there are two interfaces on the HBA), the driver, or the OS image is > > implementation-dependent.  In FC it is completely > unambiguous what the > > Port WWN corresponds to, and that's why it's usually used for > > LUN masking > > and mapping solutions.  We're at risk of screwing that up, e.g. ... > > I would like to second David's concern about not leaving > targets with a > deterministic way of knowing who/what the initiators > identifier relates to. > This is not only bad for access control mechanisms but it > make topology > mapping (and related concepts) more difficult for management software > developers. > > -Shawn > > ------------------------------------------------------- > Shawn Carl Erickson           (805) 883-4319 [Telnet] > Hewlett Packard Company         OV NSSO Joint Venture >  Storage Resource Management R&D Lab (Santa Barbara) > ------------------------------------------------------- >             > ------------------------------------------------------- > > > > > > From owner-ips@ece.cmu.edu Thu Oct 4 07:14: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 HAA05693 for ; Thu, 4 Oct 2001 07:14:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94AO5i12757 for ips-outgoing; Thu, 4 Oct 2001 06:24:05 -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 f94AO3l12750 for ; Thu, 4 Oct 2001 06:24:03 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id DAA17441; Thu, 4 Oct 2001 03:23:48 -0700 (PDT) From: "Rod Harrison" To: "Dave Sheehy" , "IETF IP SAN Reflector" Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Thu, 4 Oct 2001 11:26:11 +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: <200110040033.RAA06984@acropora.rose.agilent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Comments below. - Rod > -----Original Message----- > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Dave Sheehy > Sent: Thursday, October 04, 2001 1:33 AM > To: IETF IP SAN Reflector > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > > Can someone give a tangible benefit to this that can > outweigh the > > spec and implementation churn at this late stage of the game? > > It would allow iSCSI HBAs to interact more efficiently > with SW iSCSI > implementations and vice versa. > I don't believe it would in practice. Consider the following. The max PDU size sent during login is more that just that, it is in fact the senders maximum supportable max PDU size. If one side sends 64k and the other side 8k although it is technically indicating it can't receive more than 8k in a single PDU, for all practical purposes it is also indicating it can't handle, and therefore can't send PDUs bigger than 8k. I believe if we go this route we'll simply see the side with the lower DataPDULength sending its "natural" size PDUs and never sending the larger size wanted by the other side. More on this below ... > > From my point of view the benefit of asymmetric PDU > sizes would have > > to be very large to make it worth the extra complexity > in buffer > > management code alone. > > >From the vantage point of an iSCSI HBA it doesn't seem > all that hard. > Well, it seems to me faced with a peer with a different max PDU size there are relatively few ways to proceed. If the peer has a lower max PDU size there are 2 choices. Use 2 buffer pools, one for receive set to the local Max PDU size, and one for send set to the peer Max PDU size. This is where the extra buffer management complexity comes in. Or, use one buffer pool and simply part fill the buffers for sending. This is the easy case. If the peer has a larger max PDU size then either only send up to the local PDU size, as I mentioned above, or chain buffers together to build larger than the local max PDU size. Again, this is where the extra buffer management complexity comes in. Remember that by definition these chains will need to be bigger than the largest chain size the implementation can handle. Unless for some reason the DataPDULength sent was chosen at some arbitrary size smaller than the implementations maximum. None of this is required in the current model where there are 2 simple choices. Either create buffer pools after login and set them to the negotiated max PDU size, or use the "natural" local size and part fill them if it larger than the peer size. > Dave > From owner-ips@ece.cmu.edu Thu Oct 4 08:02: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 IAA07246 for ; Thu, 4 Oct 2001 08:02:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94BEJi14965 for ips-outgoing; Thu, 4 Oct 2001 07:14:19 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imo-r06.mx.aol.com (imo-r06.mx.aol.com [152.163.225.102]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f94BEHl14959 for ; Thu, 4 Oct 2001 07:14:17 -0400 (EDT) Received: from VAHUJA@aol.com by imo-r06.mx.aol.com (mail_out_v31_r1.7.) id 3.16e.1df6762 (3974) for ; Thu, 4 Oct 2001 07:14:14 -0400 (EDT) From: VAHUJA@aol.com Message-ID: <16e.1df6762.28ed9e86@aol.com> Date: Thu, 4 Oct 2001 07:14:14 EDT Subject: SRP sample code To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Is any one aware of a sample code or public code for SRP as defined in RFC 2945? Any suggestions are welcome. Thanks From owner-ips@ece.cmu.edu Thu Oct 4 10:00: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 KAA13104 for ; Thu, 4 Oct 2001 10:00:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94D4qc20708 for ips-outgoing; Thu, 4 Oct 2001 09:04: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 f94D4ml20704 for ; Thu, 4 Oct 2001 09:04: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 PAA70130 for ; Thu, 4 Oct 2001 15:04: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.97.1) with ESMTP id f94D4Y1292436 for ; Thu, 4 Oct 2001 15:04:40 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI-08 Comments 11 though 18 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 4 Oct 2001 16:04:33 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 04/10/2001 16:04:40, Serialize complete at 04/10/2001 16:04:40 Content-Type: multipart/alternative; boundary="=_alternative 0047DF44C2256ADB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0047DF44C2256ADB_= Content-Type: text/plain; charset="us-ascii" Comments in text - Thanks, Julo Thomas Dineen Sent by: owner-ips@ece.cmu.edu 03-10-01 04:04 Please respond to Thomas Dineen To: ips@ece.cmu.edu, Thomas Dineen cc: Subject: iSCSI-08 Comments 11 though 18 Comment 11: Section 9.1.1 on Page 137: "For an iSCSI Initiator, the SID values used by the session coordinators should be configurable parameters and the SID name space should be partitioned among the Initiator Portal Groups. This allows each Initiator Portal Group to act independently of other portal groups when selecting an SID for a logic; this facilitates enforcement of the SID RULE (see 2.5.3) at the initiator." - I do not believe "Initiator Portal Groups" as been defined. Please define in the Architecture Section at the beginning of the document. +++ See 2.5.1 +++ Comment 12: Section 9.3 on Page 138: "A task management command may reach the target and, in the case [where] immediate delivery was requested, be executed before all of the tasks it was meant to act upon have been delivered or even reached the target." - Please add the [where]. +++ will fix +++ Comment 13: Appendix C on page 180: "18 RFMarkInt" and section 19 "The receiver indicates the minimum to maximum interval (in 4-byte words) [that] the receiver wants the markers. In case the receiver wants only a specific value, only a single value has to be specified." - Please add the [that]. - Please add an example to this section, and section 19. +++ will fix +++ Comment 14: Appendix c on page 181: "19 SFMarkInt" "Indicates at what interval (in 4-byte words) the sender [accepts, expects] to send the markers. The number MUST be within the range required by the receiver. 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)." - Please replace [accepts] with [expects]. +++ I think the word can be "agrees" +++ Comment 15: Appendix C on Page 185: 28 DataPDUInOrder "No is used by iSCSI to indicate that the data PDUs [within sequences] can be in any order. Yes is used to indicate that data PDUs within sequences have to be at continuously increasing addresses and overlays are forbidden." - Do you really mean within sequences? I thought this refereed to the ordering of the transfer of one sequence relative to another, and not the PDUs within a sequence? +++ That is within sequence +++ Comment 16: Appendix E on Page 190: "iSCSI addresses belonging with the same portal group tag support spanning multiple-connection sessions across this set of addresses." - An english problem, I would suggest a rewording. +++ I will attempt the following wording: Multiple-connection sessions can span iSCSI addresses belonging to the same portal group. Multiple-connection sessions cannot span iSCSI addresses belonging to different portal groups. ++++ Comment 17: Appendix F on page 192: "This clause defines the alias entry formats and codes used in these commands to designate iSCSI devices or ports. As noted in 1.1, the protocol identifier used in these formats shall be set to 0x05 (see [SPC3]) and the format code values are defined in the following table:" - The IEEE uses the term clause, do we really want to use it in this context? I would suggest replacing [clause] with [Appendix]. +++ will fix +++ Comment 18: - The numbering of the sections seem to increase across all appendices. I would suggest renumbering of the sections local to each appendix. +++ as soon as I get to a better tool (on 09)+++ --=_alternative 0047DF44C2256ADB_= Content-Type: text/html; charset="us-ascii"

Comments in text - Thanks, Julo




Thomas Dineen <tdineen@redswitch.com>
Sent by: owner-ips@ece.cmu.edu

03-10-01 04:04
Please respond to Thomas Dineen

       
        To:        ips@ece.cmu.edu, Thomas Dineen <tdineen@redswitch.com>
        cc:        
        Subject:        iSCSI-08 Comments 11 though 18

       


Comment 11:

Section 9.1.1 on Page 137:

"For an iSCSI Initiator, the SID values used by the session
coordinators should be configurable parameters and the SID name space
should be partitioned among the Initiator Portal Groups. This allows
each Initiator Portal Group to act independently of other portal
groups when selecting an SID for a logic; this facilitates
enforcement of the SID RULE (see 2.5.3) at the initiator."

- I do not believe "Initiator Portal Groups" as been defined. Please
define in the Architecture Section at the beginning of the document.
+++ See 2.5.1 +++

Comment 12:

Section 9.3 on Page 138:

"A task management command may reach the target and, in the case [where]
immediate delivery was requested, be executed before all of the tasks
it was meant to act upon have been delivered or even reached the
target."

- Please add the [where].
+++ will fix +++

Comment 13:

Appendix C on page 180:

"18 RFMarkInt" and section 19

"The receiver indicates the minimum to maximum interval (in 4-byte
words) [that] the receiver wants the markers. In case the receiver wants
only a specific value, only a single value has to be specified."

- Please add the [that].

- Please add an example to this section, and section 19.
+++ will fix +++

Comment 14:

Appendix c on page 181:

"19 SFMarkInt"

"Indicates at what interval (in 4-byte words) the sender [accepts,
expects] to
send the markers. The number MUST be within the range required by the
receiver. 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)."

- Please replace [accepts] with [expects].
+++ I think the word can be "agrees" +++

Comment 15:

Appendix C on Page 185:

28 DataPDUInOrder

"No is used by iSCSI to indicate that the data PDUs [within sequences]
can be in any order. Yes is used to indicate that data PDUs within
sequences have to be at continuously increasing addresses and
overlays are forbidden."

- Do you really mean within sequences? I thought this refereed to the
ordering of the transfer of one sequence relative to another, and not
the PDUs within a sequence?

+++ That is within sequence +++
Comment 16:

Appendix E on Page 190:

"iSCSI addresses belonging with the same portal group tag support
spanning multiple-connection sessions across this set of addresses."

- An english problem, I would suggest a rewording.

+++
I will attempt the following wording:

Multiple-connection sessions can span iSCSI addresses belonging to the same portal group.

Multiple-connection sessions cannot span iSCSI addresses belonging to different portal groups.

++++
Comment 17:

Appendix F on page 192:

"This clause defines the alias entry formats and codes used in these
commands to designate iSCSI devices or ports. As noted in 1.1, the
protocol identifier used in these formats shall be set to 0x05 (see
[SPC3]) and the format code values are defined in the following
table:"
- The IEEE uses the term clause, do we really want to use it in this
context?
I would suggest replacing [clause] with [Appendix].
+++ will fix +++

Comment 18:

- The numbering of the sections seem to increase across all appendices.
I would suggest renumbering of the sections local to each appendix.

+++ as soon as I get to a better tool (on 09)+++

--=_alternative 0047DF44C2256ADB_=-- From owner-ips@ece.cmu.edu Thu Oct 4 10:00: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 KAA13115 for ; Thu, 4 Oct 2001 10:00:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94D5Qa20742 for ips-outgoing; Thu, 4 Oct 2001 09:05:26 -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 f94D5Nl20737 for ; Thu, 4 Oct 2001 09:05:23 -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 PAA15794 for ; Thu, 4 Oct 2001 15:05: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 f94D5FW73278 for ; Thu, 4 Oct 2001 15:05:15 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI-08 Comments 1 through 10 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 4 Oct 2001 16:05:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 04/10/2001 16:05:15, Serialize complete at 04/10/2001 16:05:15 Content-Type: multipart/alternative; boundary="=_alternative 0047EF3AC2256ADB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0047EF3AC2256ADB_= Content-Type: text/plain; charset="us-ascii" Comments in text. Thanx, Julo Thomas Dineen Sent by: owner-ips@ece.cmu.edu 03-10-01 03:15 Please respond to Thomas Dineen To: ips@ece.cmu.edu, Thomas Dineen cc: Subject: iSCSI-08 Comments 1 through 10 Comment 1: Section 3.17 Page 101: "Reject is used to indicate an iSCSI error condition (protocol, unsupported option etc.)." - Please enhance the description of the Reject PDU. Please specify exactly what it is used for, when, and why. I realize that there is a forward reference on the following page, but feel that a more robust definition of the reject functionality also belongs here. +++ The next revision is also an editorial "redo". However if you have something specific in mind please feel free to forward an Internet Draft for consideration by the list or a short text here if you feel this is more appropriate +++ Comment 2: Section 3.18 on Page 104: - Please add a definition of the I Bit. I assume it is the same meaning as the previous definition in other PDUs of I and Immediate. I feel these fields should be specified for each PDU. +++ Common fields are specified once +++ Comment 3: Section 3.19.1 on Page "3.19.1 Target Transfer Tag" "Whenever the NOP-In is not issued in response to a NOP-Out the StatSN field will contain as usual the next StatSN but StatSN for this connection is not advanced." - Why is the above text in a section titled "3.19.1 Target Transfer Tag"? - It almost appears the this text belongs in NOP-Out? - Please elaborate on the meaning and proper placement for this text. +++ StatSN belongs to Nop-IN +++ Comment 4: Section 5.1 on Page 112: "-Login Response with Login Accept as a final response (T bit set to 1 and the NSG in both command [and] response are set to FullFeaturePhase). The response includes the protocol version supported by the target and the session ID and may include iSCSI operational or security parameters (depending on the current stage)." Change "a' to "and". +++ will do +++ Comment 5: Section 5.2 on Page 115: "If security is established in the login phase then after the security negotiation is complete, each iSCSI PDU MUST include the appropriate digest field if any." "All PDUs sent after the security negotiation stage MUST be built using the agreed security." - The two sets of quoted text shown above are a bit redundant, or at least could be combined into a single paragraph. By the way I do realize there are two distinct phases here. - Could we be a little more specific in the second statement? Something like "MUST be composed of the fields or tuples specified by the agreed upon protocol specification". +++ I will combine them into: If security is established in the login phase then after the security negotiation is complete, each iSCSI PDU MUST be built using the agreed security and include the appropriate integrity digest fields if any. +++ Comment 6: Section 5.2 on Page 115: "If the security negotiation fails at the target then the target MUST send the appropriate Login Response PDU. If the security negotiation fails at the initiator, the initiator [shall] drop the connection." - Do you really mean "shall"? Shall is IEEE terminology do you not mean "MUST"? This is a recurring problem in many places in the draft, for brevity I would suggest a text search and examination of each "shall". +++ SHALL is also IETF - I will make it uppercase where needed +++ Comment 7: Section 5.3 on Page 115: "Session specific parameters can be specified only during the login phase begun by a login command [containing a null TSID] (e.g., the maximum number of connections that can be used for this session). Connection specific parameters, if any, can be specified during the login phase begun by any login command. Thus, a session is operational once it has at least one connection." - Do you not mean the first or leading login? If true please add this terminology. +++ will try +++ Comment 8: Section 6 on Page 116: "If the target responds to a text request with the F bit set to 1, with a text response with the F bit set to 0, the initiator [must] keep sending the text request (even empty) with the F bit set to 1 until it gets the text response with the F bit set to 1. Responding to a text request with the F bit set to 1 with an empty (no key=value pairs) is not an error but is discouraged." - "must" versus "MUST"! Do you not mean "MUST"? This is a recurring problem in many places in the draft, for brevity I would suggest a text search and examination of each "must'. +++ Not every must is a MUST. The selection is sometimes intentional (like in the example) +++ Comment 9: Section 8.11 on Page 131: "Usage of within a connection and within a command recovery classes MUST NOT be attempted before the connection is in full feature phase." - I think there is a english problem here, or maybe dropped words. +++ will fix +++ Comment 10: Section 8.11.4 on Page 134: "Session recovery implies closing of all [the] TCP connections, aborting at target all executing and queued tasks for the given initiator, terminating at initiator all [the] outstanding SCSI commands with an appropriate SCSI service response and restarting a session on a new connection set (TCP connection establishment and login on all new connections)." - Minor english suggest adding "the" in two places. +++ sounds right in my English but will see what our technical writers have to say about it :-) +++ --=_alternative 0047EF3AC2256ADB_= Content-Type: text/html; charset="us-ascii"
Comments in text.  Thanx, Julo


Thomas Dineen <tdineen@redswitch.com>
Sent by: owner-ips@ece.cmu.edu

03-10-01 03:15
Please respond to Thomas Dineen

       
        To:        ips@ece.cmu.edu, Thomas Dineen <tdineen@redswitch.com>
        cc:        
        Subject:        iSCSI-08 Comments 1 through 10

       


Comment 1:

Section 3.17 Page 101:

"Reject is used to indicate an iSCSI error condition (protocol,
unsupported option etc.)."

- Please enhance the description of the Reject PDU. Please specify
exactly what it is used for, when, and why. I realize that there is
a forward reference on the following page, but feel that a more
robust definition of the reject functionality also belongs here.
+++ The next revision is also an editorial "redo".  However if you have something specific in mind please feel free to forward an Internet Draft for consideration by the list or a short text here if you feel this is more appropriate +++
Comment 2:

Section 3.18 on Page 104:

- Please add a definition of the I Bit. I assume it is the same meaning
as the previous definition in other PDUs of I and Immediate. I feel
these fields should be specified for each PDU.

+++ Common fields are specified once +++

Comment 3:

Section 3.19.1 on Page

"3.19.1 Target Transfer Tag"

"Whenever the NOP-In is not issued in response to a NOP-Out the StatSN
field will contain as usual the next StatSN but StatSN for this
connection is not advanced."

- Why is the above text in a section titled "3.19.1 Target Transfer
Tag"?
- It almost appears the this text belongs in NOP-Out?
- Please elaborate on the meaning and proper placement for this text.
+++ StatSN belongs to Nop-IN +++

Comment 4:

Section 5.1 on Page 112:

"-Login Response with Login Accept as a final response (T bit
set to 1 and the NSG in both command [and] response are set to
FullFeaturePhase). The response includes the protocol version
supported by the target and the session ID and may include
iSCSI operational or security parameters (depending on the
current stage)."

Change "a' to "and".
+++ will do +++

Comment 5:

Section 5.2 on Page 115:

"If security is established in the login phase then after the security
negotiation is complete, each iSCSI PDU MUST include the appropriate
digest field if any."

"All PDUs sent after the security negotiation stage MUST be built
using the agreed security."

- The two sets of quoted text shown above are a bit redundant, or at
least could be combined into a single paragraph. By the way I do realize
there are two distinct phases here.

- Could we be a little more specific in the second statement? Something
like "MUST be composed of the fields or tuples specified by the agreed
upon protocol specification".

+++ I will combine them into:
If security is established in the login phase then after the security negotiation is complete, each iSCSI PDU MUST be built using the agreed security and include the appropriate integrity digest fields if any.
+++
Comment 6:

Section 5.2 on Page 115:

"If the security negotiation fails at the target then the target MUST
send the appropriate Login Response PDU. If the security negotiation
fails at the initiator, the initiator [shall] drop the connection."

- Do you really mean "shall"? Shall is IEEE terminology do you not mean
"MUST"? This is a recurring problem in many places in the draft, for
brevity I would suggest a text search and examination of each "shall".

+++ SHALL is also IETF - I will make it uppercase where needed +++

Comment 7:

Section 5.3 on Page 115:
"Session specific parameters can be specified only during the login
phase begun by a login command [containing a null TSID] (e.g., the
maximum number of connections that can be used for this session).
Connection specific parameters, if any, can be specified during the
login phase begun by any login command. Thus, a session is
operational once it has at least one connection."

- Do you not mean the first or leading login? If true please add this
terminology.
+++ will try +++
Comment 8:

Section 6 on Page 116:

"If the target responds to a text request with the F bit set to 1,
with a text response with the F bit set to 0, the initiator [must] keep
sending the text request (even empty) with the F bit set to 1 until
it gets the text response with the F bit set to 1. Responding to a
text request with the F bit set to 1 with an empty (no key=value
pairs) is not an error but is discouraged."

- "must" versus "MUST"! Do you not mean "MUST"? This is a recurring
problem in many places in the draft, for brevity I would suggest a
text search and examination of each "must'.
+++ Not every must is a MUST. The selection is sometimes intentional (like in the example) +++
Comment 9:

Section 8.11 on Page 131:

"Usage of within a connection and within a command recovery classes
MUST NOT be attempted before the connection is in full feature phase."

- I think there is a english problem here, or maybe dropped words.
+++ will fix +++
Comment 10:

Section 8.11.4 on Page 134:
"Session recovery implies closing of all [the] TCP connections, aborting
at
target all executing and queued tasks for the given initiator,
terminating at initiator all [the] outstanding SCSI commands with an
appropriate SCSI service response and restarting a session on a new
connection set (TCP connection establishment and login on all new
connections)."

- Minor english suggest adding "the" in two places.
+++ sounds right in my English but will see what our technical writers have to say about it :-) +++


--=_alternative 0047EF3AC2256ADB_=-- From owner-ips@ece.cmu.edu Thu Oct 4 10: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 KAA13153 for ; Thu, 4 Oct 2001 10:00:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94D56T20724 for ips-outgoing; Thu, 4 Oct 2001 09:05: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 f94D53l20719 for ; Thu, 4 Oct 2001 09:05:03 -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 PAA64892 for ; Thu, 4 Oct 2001 15:04: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 f94D4sW209696 for ; Thu, 4 Oct 2001 15:04:54 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI-08 Comments 11 though 18 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 4 Oct 2001 16:04:53 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 04/10/2001 16:04:54, Serialize complete at 04/10/2001 16:04:54 Content-Type: multipart/alternative; boundary="=_alternative 0047E6ABC2256ADB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0047E6ABC2256ADB_= Content-Type: text/plain; charset="us-ascii" - Comments in text - Thanks, Julo Thomas Dineen Sent by: owner-ips@ece.cmu.edu 03-10-01 04:04 Please respond to Thomas Dineen To: ips@ece.cmu.edu, Thomas Dineen cc: Subject: iSCSI-08 Comments 11 though 18 Comment 11: Section 9.1.1 on Page 137: "For an iSCSI Initiator, the SID values used by the session coordinators should be configurable parameters and the SID name space should be partitioned among the Initiator Portal Groups. This allows each Initiator Portal Group to act independently of other portal groups when selecting an SID for a logic; this facilitates enforcement of the SID RULE (see 2.5.3) at the initiator." - I do not believe "Initiator Portal Groups" as been defined. Please define in the Architecture Section at the beginning of the document. +++ See 2.5.1 +++ Comment 12: Section 9.3 on Page 138: "A task management command may reach the target and, in the case [where] immediate delivery was requested, be executed before all of the tasks it was meant to act upon have been delivered or even reached the target." - Please add the [where]. +++ will fix +++ Comment 13: Appendix C on page 180: "18 RFMarkInt" and section 19 "The receiver indicates the minimum to maximum interval (in 4-byte words) [that] the receiver wants the markers. In case the receiver wants only a specific value, only a single value has to be specified." - Please add the [that]. - Please add an example to this section, and section 19. +++ will fix +++ Comment 14: Appendix c on page 181: "19 SFMarkInt" "Indicates at what interval (in 4-byte words) the sender [accepts, expects] to send the markers. The number MUST be within the range required by the receiver. 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)." - Please replace [accepts] with [expects]. +++ I think the word can be "agrees" +++ Comment 15: Appendix C on Page 185: 28 DataPDUInOrder "No is used by iSCSI to indicate that the data PDUs [within sequences] can be in any order. Yes is used to indicate that data PDUs within sequences have to be at continuously increasing addresses and overlays are forbidden." - Do you really mean within sequences? I thought this refereed to the ordering of the transfer of one sequence relative to another, and not the PDUs within a sequence? +++ That is within sequence +++ Comment 16: Appendix E on Page 190: "iSCSI addresses belonging with the same portal group tag support spanning multiple-connection sessions across this set of addresses." - An english problem, I would suggest a rewording. +++ I will attempt the following wording: Multiple-connection sessions can span iSCSI addresses belonging to the same portal group. Multiple-connection sessions cannot span iSCSI addresses belonging to different portal groups. ++++ Comment 17: Appendix F on page 192: "This clause defines the alias entry formats and codes used in these commands to designate iSCSI devices or ports. As noted in 1.1, the protocol identifier used in these formats shall be set to 0x05 (see [SPC3]) and the format code values are defined in the following table:" - The IEEE uses the term clause, do we really want to use it in this context? I would suggest replacing [clause] with [Appendix]. +++ will fix +++ Comment 18: - The numbering of the sections seem to increase across all appendices. I would suggest renumbering of the sections local to each appendix. +++ as soon as I get to a better tool (on 09)+++ --=_alternative 0047E6ABC2256ADB_= Content-Type: text/html; charset="us-ascii"
-
Comments in text - Thanks, Julo




Thomas Dineen <tdineen@redswitch.com>
Sent by: owner-ips@ece.cmu.edu

03-10-01 04:04
Please respond to Thomas Dineen

       
        To:        ips@ece.cmu.edu, Thomas Dineen <tdineen@redswitch.com>
        cc:        
        Subject:        iSCSI-08 Comments 11 though 18

       


Comment 11:

Section 9.1.1 on Page 137:

"For an iSCSI Initiator, the SID values used by the session
coordinators should be configurable parameters and the SID name space
should be partitioned among the Initiator Portal Groups. This allows
each Initiator Portal Group to act independently of other portal
groups when selecting an SID for a logic; this facilitates
enforcement of the SID RULE (see 2.5.3) at the initiator."

- I do not believe "Initiator Portal Groups" as been defined. Please
define in the Architecture Section at the beginning of the document.
+++ See 2.5.1 +++

Comment 12:

Section 9.3 on Page 138:

"A task management command may reach the target and, in the case [where]
immediate delivery was requested, be executed before all of the tasks
it was meant to act upon have been delivered or even reached the
target."

- Please add the [where].
+++ will fix +++

Comment 13:

Appendix C on page 180:

"18 RFMarkInt" and section 19

"The receiver indicates the minimum to maximum interval (in 4-byte
words) [that] the receiver wants the markers. In case the receiver wants
only a specific value, only a single value has to be specified."

- Please add the [that].

- Please add an example to this section, and section 19.
+++ will fix +++

Comment 14:

Appendix c on page 181:

"19 SFMarkInt"

"Indicates at what interval (in 4-byte words) the sender [accepts,
expects] to
send the markers. The number MUST be within the range required by the
receiver. 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)."

- Please replace [accepts] with [expects].
+++ I think the word can be "agrees" +++

Comment 15:

Appendix C on Page 185:

28 DataPDUInOrder

"No is used by iSCSI to indicate that the data PDUs [within sequences]
can be in any order. Yes is used to indicate that data PDUs within
sequences have to be at continuously increasing addresses and
overlays are forbidden."

- Do you really mean within sequences? I thought this refereed to the
ordering of the transfer of one sequence relative to another, and not
the PDUs within a sequence?

+++ That is within sequence +++
Comment 16:

Appendix E on Page 190:

"iSCSI addresses belonging with the same portal group tag support
spanning multiple-connection sessions across this set of addresses."

- An english problem, I would suggest a rewording.

+++
I will attempt the following wording:

Multiple-connection sessions can span iSCSI addresses belonging to the same portal group.

Multiple-connection sessions cannot span iSCSI addresses belonging to different portal groups.

++++
Comment 17:

Appendix F on page 192:

"This clause defines the alias entry formats and codes used in these
commands to designate iSCSI devices or ports. As noted in 1.1, the
protocol identifier used in these formats shall be set to 0x05 (see
[SPC3]) and the format code values are defined in the following
table:"
- The IEEE uses the term clause, do we really want to use it in this
context?
I would suggest replacing [clause] with [Appendix].
+++ will fix +++

Comment 18:

- The numbering of the sections seem to increase across all appendices.
I would suggest renumbering of the sections local to each appendix.

+++ as soon as I get to a better tool (on 09)+++

--=_alternative 0047E6ABC2256ADB_=-- From owner-ips@ece.cmu.edu Thu Oct 4 12:46: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 MAA18779 for ; Thu, 4 Oct 2001 12:46:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94FifW01570 for ips-outgoing; Thu, 4 Oct 2001 11:44:41 -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 f94Fiel01566 for ; Thu, 4 Oct 2001 11:44:40 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-116.cisco.com [161.44.68.116]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA06287 for ; Thu, 4 Oct 2001 11:43:43 -0400 (EDT) From: "Ayman Ghanem" To: Subject: iSCSI: ImmediateData & InitialR2T Date: Thu, 4 Oct 2001 10:42:57 -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, The use of these two keys is currently set to "Use: ALL". I think they should be allowed only on the leading connection, so a second connection can not change them on the first. -Ayman From owner-ips@ece.cmu.edu Thu Oct 4 13: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 NAA20236 for ; Thu, 4 Oct 2001 13:37:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94Gw1g06844 for ips-outgoing; Thu, 4 Oct 2001 12:58:01 -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 f94Gvxl06840 for ; Thu, 4 Oct 2001 12:57:59 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Oct 4 12:52:03 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 f94Gtul56346; Thu, 4 Oct 2001 12:55:56 -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 MAA17879; Thu, 4 Oct 2001 12:55:56 -0400 (EDT) Message-ID: <3BBC949C.9B8E3269@research.bell-labs.com> Date: Thu, 04 Oct 2001 12:55:56 -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: VAHUJA@aol.com CC: ips@ece.cmu.edu Subject: Re: SRP sample code References: <16e.1df6762.28ed9e86@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit VAHUJA@aol.com wrote: > > Is any one aware of a sample code or public code for SRP as defined in RFC > 2945? Any suggestions are welcome. Thanks I believe the standard distribution from ftp://srp.stanford.edu/pub/srp/ includes telnet source, which was modified to use SRP. -Sandeep From owner-ips@ece.cmu.edu Thu Oct 4 13:42: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 NAA20329 for ; Thu, 4 Oct 2001 13:42:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94Gm9P06199 for ips-outgoing; Thu, 4 Oct 2001 12:48:09 -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 f94Gm8l06195 for ; Thu, 4 Oct 2001 12:48:08 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 12:32:38 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD824@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISID issue Date: Thu, 4 Oct 2001 12:24:38 -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, Lacking additional visible support, I'm going to give up on this issue, but I think a serious mistake is being made. Two portions of your message reinforce my opinion: > However, there were some other things that we batted around that I will > cover here. First, the Name which you want to work with in the iSCSI ACLs > is the iSCSI Initiator Node Name. That should be the same for ALL iSCSI > Initiators in a Host Node. If vendors attempt to use anything else, I > think they are not following the spec. And should be sent to Singapore for > Caning :-) Not :-), rather an unrealistic exercise in wishful thinking. I have yet to see a coherent explanation of why this will not repeat the Fibre Channel Node WWN experience (which started out with the same intention and the same "not following the spec" notion for use of different Node WWNs on the same Platform - nonetheless, that's what happened). I expect problems to arise not so much in iSCSI ACLs (a new mechanism), but in the adaptation of existing SCSI LU access control mechanisms to iSCSI. > When Jim talked about the new SCSI idea that would have Persistent Reserves > being tied to the Initiator Node, it seemed clear to me, and I think to > the others on the team, that the iSCSI Initiator Node Name was ideal to be > used for that purpose. Jim pointed out, again to us, that this name was > NOT part of any other Nexus meaning, it is only to be used with Persistent > Reserves. All other Nexus meanings are against the iSCSI Initiator's FULL > NAME which is the iSCSI initiator Node Name and the ISID. That is a change from what Jim has described on the list, which required a persistent name for the iSCSI Initiator Port (not Node); what you have described in the above paragraph does not. Given that this sort of change is possible in what T10 is considering, I think we should cease trying to anticipate and provide for what T10 might (or might not) do, and instead deal with the results of what T10 does after it happens. The upshot is that ISIDs now serve no visible purpose, aside from complicating session setup - nonetheless, they're apparently going to stay in the specification ... did the N&D folks really intend this result? --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 Oct 4 15:01: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 PAA22503 for ; Thu, 4 Oct 2001 15:01:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94I4Ml12208 for ips-outgoing; Thu, 4 Oct 2001 14:04: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 f94I4Jl12203 for ; Thu, 4 Oct 2001 14:04: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 OAA120932 for ; Thu, 4 Oct 2001 14:01:55 -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 f94I4GH216714 for ; Thu, 4 Oct 2001 12:04:17 -0600 Subject: Data Digest Error question To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Prasenjit Sarkar" Date: Thu, 4 Oct 2001 11:04:24 -0700 X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/04/2001 11:04:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk This question relates to how the target handles data digest errors for data pdus. The spec says the target has to send a reject pdu with the attached pdu header + (recovery R2T OR delivery subsystem failure status) Why do we need two mechanisms? Wouldnt the pdu header indicate what needed to be transmitted? Maybe a word of motivation might help. Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose From owner-ips@ece.cmu.edu Thu Oct 4 15:02: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 PAA22526 for ; Thu, 4 Oct 2001 15:02:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94IaRO14769 for ips-outgoing; Thu, 4 Oct 2001 14:36:27 -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 f94IaNl14763 for ; Thu, 4 Oct 2001 14:36: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 OAA120902 for ; Thu, 4 Oct 2001 14:33:58 -0400 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f94IaGH226932 for ; Thu, 4 Oct 2001 12:36:16 -0600 Importance: Normal Subject: RE: iSCSI: ISID issue To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jim Hafner" Date: Thu, 4 Oct 2001 19:36:14 +0100 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/04/2001 11:36:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, You ask: >The upshot is that ISIDs now serve no visible purpose, aside from >complicating session setup - nonetheless, they're apparently going to >stay in the specification ... did the N&D folks really intend this result? The N&D folks never had any input to the creation or defintion or specification of the ISID itself (that was in the main draft long before we ever formed as a team). Nor as a team were they involved directly with how ISIDs are used in the current model. I'll take almost sole responsibility for that, with appreciation to some individuals of the N&D team for their useful discussions and support. So, don't blame the team, blame me and by association a few others who were involved (and happen to be also on the N&D team). However, all I/we did was take the defined existence of the ISID in the protocol and give it an additional role in the SCSI model. As I said in my last note, I'm willing to abandon use of the ISID for the purposes of naming SCSI Initiator Ports and replace that with some text key (so that ISIDs are removed from the dual role of identifying sessions AND SCSI initiator ports). But I haven't seen any specific proposal to that effect and that addresses all the issues involved (as outlined also in my last note). In fact, if we do find an alternative to the ISID for naming SCSI Initiator Ports, then the ISID would be irrelevant to the SCSI model (as the TSID is now) and we won't need the ISID rule anymore (we'd need another rule for port names, however). We can then ask if there is any value in the iSCSI protocol for either the ISID or the TSID (as I did many many months ago prior to this dicussion). Jim Hafner Black_David@emc.com@ece.cmu.edu on 10/04/2001 05:24:38 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, Lacking additional visible support, I'm going to give up on this issue, but I think a serious mistake is being made. Two portions of your message reinforce my opinion: > However, there were some other things that we batted around that I will > cover here. First, the Name which you want to work with in the iSCSI ACLs > is the iSCSI Initiator Node Name. That should be the same for ALL iSCSI > Initiators in a Host Node. If vendors attempt to use anything else, I > think they are not following the spec. And should be sent to Singapore for > Caning :-) Not :-), rather an unrealistic exercise in wishful thinking. I have yet to see a coherent explanation of why this will not repeat the Fibre Channel Node WWN experience (which started out with the same intention and the same "not following the spec" notion for use of different Node WWNs on the same Platform - nonetheless, that's what happened). I expect problems to arise not so much in iSCSI ACLs (a new mechanism), but in the adaptation of existing SCSI LU access control mechanisms to iSCSI. > When Jim talked about the new SCSI idea that would have Persistent Reserves > being tied to the Initiator Node, it seemed clear to me, and I think to > the others on the team, that the iSCSI Initiator Node Name was ideal to be > used for that purpose. Jim pointed out, again to us, that this name was > NOT part of any other Nexus meaning, it is only to be used with Persistent > Reserves. All other Nexus meanings are against the iSCSI Initiator's FULL > NAME which is the iSCSI initiator Node Name and the ISID. That is a change from what Jim has described on the list, which required a persistent name for the iSCSI Initiator Port (not Node); what you have described in the above paragraph does not. Given that this sort of change is possible in what T10 is considering, I think we should cease trying to anticipate and provide for what T10 might (or might not) do, and instead deal with the results of what T10 does after it happens. The upshot is that ISIDs now serve no visible purpose, aside from complicating session setup - nonetheless, they're apparently going to stay in the specification ... did the N&D folks really intend this result? --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 Oct 4 15:07: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 PAA22682 for ; Thu, 4 Oct 2001 15:07:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94Hv4x11531 for ips-outgoing; Thu, 4 Oct 2001 13:57: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 f94Huml11489 for ; Thu, 4 Oct 2001 13:56: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 TAA27790 for ; Thu, 4 Oct 2001 19:56: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.97.1) with ESMTP id f94Hua1237994 for ; Thu, 4 Oct 2001 19:56:37 +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: Thu, 4 Oct 2001 20:56:30 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 04/10/2001 20:56:36, Serialize complete at 04/10/2001 20:56:36 Content-Type: multipart/alternative; boundary="=_alternative 006299F1C2256ADB_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 006299F1C2256ADB_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well - even I got fed-up with this long thread. Here the new text I am suggesting for the negotiations ("vox populi"): In numerical negotiations, the offering and responding party state a=20 numerical value. The result of the negotiation is key dependent;=20 frequently the lower or the higher of the two values is used.=20 For numerical negotiations, the responding party MUST respond with the=20 required key and the value it selects, based on the selection rule=20 specific to the key, becomes the negotiation result. Selection of a value = not admissible under the selection rules is considered a protocol error=20 and handled accordingly.=20 For Boolean negotiations (keys taking the values yes or no), the result is = a key dependent Boolean function of the two inputs. The negotiation MAY=20 proceed only up to the point where both parties can unequivocally compute=20 the result; continuing beyond this point is OPTIONAL (e.g., if the=20 function is AND and one of the parties says "no" then this may end the=20 negotiation). Both requestor and responder MUST to compute the negotiated=20 value based on the new value(s) exchanged The value "?" with any key has the meaning of enquiry and should be=20 answered with the current value or "NotUnderstood". The target may offer key=3Dvalue pairs of its own. Target requests are not = limited to matching key=3Dvalue pairs as offered by the initiator. However= ,=20 only the initiator can initiate the negotiation start (through the first=20 Text request) and completion (by setting to 1 and keeping to 1 the F bit=20 in a Text request). Unless specified otherwise the negotiation process is stateless (based=20 only on newly presented values). Comments? Julo ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 ----- Paul Koning 03-10-01 16:43 Please respond to Paul Koning =20 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambigu= ous =20 Excerpt of message (sent 3 October 2001) by Julian Satran: > An example: > 08.txt logic > i->t DataPDULength=3D16k > t->i DataPDULength=3D 24k >=20 > Selected value is 16k=20 >=20 > i->t DataPDULength=3D16k > t->i DataPDULength=3D 8k >=20 > Selected value is 8k >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 24k >=20 > Selected value is 16k=20 >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 8k >=20 > Selected value is 8k >=20 > ----- >=20 > Responder selects logic >=20 > i->t DataPDULength=3D16k > t->i DataPDULength=3D 24k >=20 > Error - Initiator Reject - Closes connection >=20 > i->t DataPDULength=3D16k > t->i DataPDULength=3D 8k >=20 > Selected value is 8k >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 24k >=20 > Error Target has to terminate with parameter error >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 8k >=20 > Selected value is 8k In most protocols, "responder selects" is used. And the rule is that the responder MUST respond with a value acceptable to both sides. Therefore, if the negotiation rule for DataPDULength is to pick the smaller of the two values preferred by the two sides, your first and third examples would be defective implementations. Often, protocol specs don't say what to do with defective implementations; a typical answer is to terminate the conversation, which is a sensible answer. Sending rejects is not that useful for defective implementations, since there is no reason to assume that they will all of a sudden start to act correctly. Also, it is useful to build in protocol mechanisms for bit errors, memory errors, dropped packets, etc. -- but it is generally NOT useful to build mechanisms that apply only when the other side has a software bug. I agree with Deva that the appropriate response to a protocol violation is to terminate the conversation.=20 So for "responder selects" examples 1 and 3 should have read like this: i->t DataPDULength=3D16k t->i DataPDULength=3D 16k (t wants 24 but 16 is th= e=20 agreed value) ... t->i DataPDULength=3D16k i->t DataPDULength=3D 16k (i wants 24 but 16 is th= e=20 agreed value) paul ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 ----- Paul Koning Sent by: owner-ips@ece.cmu.edu 03-10-01 16:43 Please respond to Paul Koning =20 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambigu= ous =20 Excerpt of message (sent 3 October 2001) by Julian Satran: > An example: > 08.txt logic > i->t DataPDULength=3D16k > t->i DataPDULength=3D 24k >=20 > Selected value is 16k=20 >=20 > i->t DataPDULength=3D16k > t->i DataPDULength=3D 8k >=20 > Selected value is 8k >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 24k >=20 > Selected value is 16k=20 >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 8k >=20 > Selected value is 8k >=20 > ----- >=20 > Responder selects logic >=20 > i->t DataPDULength=3D16k > t->i DataPDULength=3D 24k >=20 > Error - Initiator Reject - Closes connection >=20 > i->t DataPDULength=3D16k > t->i DataPDULength=3D 8k >=20 > Selected value is 8k >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 24k >=20 > Error Target has to terminate with parameter error >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 8k >=20 > Selected value is 8k In most protocols, "responder selects" is used. And the rule is that the responder MUST respond with a value acceptable to both sides. Therefore, if the negotiation rule for DataPDULength is to pick the smaller of the two values preferred by the two sides, your first and third examples would be defective implementations. Often, protocol specs don't say what to do with defective implementations; a typical answer is to terminate the conversation, which is a sensible answer. Sending rejects is not that useful for defective implementations, since there is no reason to assume that they will all of a sudden start to act correctly. Also, it is useful to build in protocol mechanisms for bit errors, memory errors, dropped packets, etc. -- but it is generally NOT useful to build mechanisms that apply only when the other side has a software bug. I agree with Deva that the appropriate response to a protocol violation is to terminate the conversation.=20 So for "responder selects" examples 1 and 3 should have read like this: i->t DataPDULength=3D16k t->i DataPDULength=3D 16k (t wants 24 but 16 is th= e=20 agreed value) ... t->i DataPDULength=3D16k i->t DataPDULength=3D 16k (i wants 24 but 16 is th= e=20 agreed value) paul ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 ----- Santosh Rao Sent by: santoshr@cup.hp.com 03-10-01 18:26 Please respond to Santosh Rao =20 To: Sandeep Joshi , Julian=20 Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambigu= ous =20 Julian, Another value-add of the "responder picks the negotiation result model" is that the initiator can use the following "query based" negotiation model to always use the values the target is capable of offering : I -> T : DataPDULength=3D? T -> I : DataPDULength=3D64K Both sides agree to use a DataPDULength of 64K.=20 In the "both sides pick negotiation result" model, the above cannot be achieved, since the initiator has to always offer a value. Thus, in the "both sides pick negotiation result" model , the above example would be : I -> T : DataPDULength=3D8K T -> I : DataPDULength=3D64K I -> T : DataPDULength=3D64K T -> I : DataPDULength=3D64K Both sides settle at 64K. I suggest that we allow the above "query based model", since this is more efficient to use when an initiator has no key limitations and would like to use the value a target can offer. In order to allow the "query based model", you would need to state in the draft that a key value of "?" over-rides the default, implying the target offered value would be the result of the negotiation. In particular, the "query based model" is quite useful when an initiator wishes to function with the target's maximal supported values for keys like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T, LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any limitations on its own key value. Comments ? Thanks, Santosh Sandeep Joshi wrote: >=20 > The first & third example below seem illogical. >=20 > The responder should not be sending 24K if the initial > sender has chosen a value of 16K, since there is no > possibility of that 24K being accepted (unless we want > three way exchanges for every negotiation??) >=20 > The problem of a Reject message does not arise since the > responder should only be choosing something less than 16K. > So I guess this puts me in the "responder selects logic" > camp. >=20 > -Sandeep >=20 > Julian Satran wrote: > > > > An example: > > 08.txt logic > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 24k > > > > Selected value is 16k > > > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 8k > > > > Selected value is 8k > > > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 24k > > > > Selected value is 16k > > > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 8k > > > > Selected value is 8k > > > > ----- > > > > Responder selects logic > > > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 24k > > > > Error - Initiator Reject - Closes connection > > > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 8k > > > > Selected value is 8k > > > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 24k > > > > Error Target has to terminate with parameter error > > > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 8k > > > > Selected value is 8k > > > > "Dev - Platys" > > To: "Julian Satran" > > , > > 01-10-01 23:46 > > Please respond to "Dev - cc: > > Platys" Subject: RE: iscsi : > > numerical negotiation wording is ambiguous > > > > > > > > Julian, > > > > I am not sure why a 'REJECT' is required. > > Can you please explain why is this required? > > > > I am with Santosh in this. > > > > >There is NO need for any REJECT in the above >case. If the initiator > > >is'nt satisfied with the value returned by the >originator and cannot > > >function with the negotiated values, it can simply >close the TCP > > >connection. There is no need to send any >REJECT. > > > > Thanks > > > > Deva > > Adaptec > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Monday, October 01, 2001 1:28 PM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > Santosh, > > > > We are getting nowhere. Even if requester is doing it's stuff - the > > requester will have to check and be prepared for a mistake. The coding > > will require a reject. > > > > Julo > > > > Santosh Rao > > To: ips@ece.cmu.edu > > Sent by: cc: "Sanjeev Bhagat > > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > > Julian Satran/Haifa/IBM@IBMIL > > 01-10-01 20:37 Subject: Re: iscsi : numerical > > Please respond to negotiation wording is ambiguous > > Santosh Rao > > > > > > Julian & Sanjeev, > > > > Responding to both your mails...... > > > > Julian : > > > > I think you may have mis-interpreted my comments. I believe Sanjeev > > has > > clarified the intent of my suggestions. > > > > I am *not* suggesting that the responder send back its values and > > these > > be blindly imposed on the originator. On the contrary, my suggestion > > is > > that the computation of the result of the negotiation (higher or lower > > of the 2 values) be only performed by the responder and sent back to > > the > > originator. > > > > The result of the negotiation is the same in both cases and there is > > no > > REJECT required in my case nor yours. The difference is the advantages > > I've stated in my model. > > > > Sanjeev, in response to your comment : > > > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. " > > > > There is NO need for any REJECT in the above case. If the initiator > > is'nt satisfied with the value returned by the originator and cannot > > function with the negotiated values, it can simply close the TCP > > connection. There is no need to send any REJECT. > > > > Thanks, > > Santosh > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Thanks Julian, please find my further comments in the message > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] > > > Sent: Sunday, September 30, 2001 6:07 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iscsi : numerical negotiation wording is > > > ambiguous > > > > > > 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=3Dvaluex > > > 2. a responder sends B=3Dvaluey > > > 3. the responder assumes that the value y is the correct > > > value and so does an external observer > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > > say it this way the responder computes the value with > > > its own supported values and responds with a value y > > > which the responder thinks is correct 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > > but it is highly unlikely for the responder to reject > > > the final result because the rule states that (lower or > > > higher of two will be the result) and so the offering > > > party should be able to accept the lower or higher > > > range as defined by rule. In case the key is dependent > > > upon some range of fixed values then the negotiation > > > should be performed as list negotiation and not > > > numerical negotiation. > > > > > > This might be what you "conventionally" do - I don't > > > and that shows that convention like morals are a matter > > > of geography :-) > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > > > The advantage of this set of rules is that it allows an > > > external observer to know what was selected without > > > knowing the rules > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > > case, I guess that the external observer has to know > > > the rules to double check the value is correct or not > > > 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=3Dvaluex > > > 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. > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. > > > > > > > > > Sanjeev > > > "Sanjeev Bhagat > > > (TRIPACE/Zoetermeer)" To: "'Santosh > > Rao'" > > > , Julian > > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > > cc: > > ips@ece.cmu.edu > > > 30-09-01 16:32 Subject: RE: > > iscsi : > > > Please respond to "Sanjeev numerical negotiation wording > > is > > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > > > > -- > > ################################## > > Santosh Rao > > Software Design Engineer, > > HP-UX iSCSI Driver Team, > > Hewlett Packard, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################## --=20 ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 ----- Santosh Rao Sent by: owner-ips@ece.cmu.edu 03-10-01 18:26 Please respond to Santosh Rao =20 To: Sandeep Joshi , Julian=20 Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambigu= ous =20 Julian, Another value-add of the "responder picks the negotiation result model" is that the initiator can use the following "query based" negotiation model to always use the values the target is capable of offering : I -> T : DataPDULength=3D? T -> I : DataPDULength=3D64K Both sides agree to use a DataPDULength of 64K.=20 In the "both sides pick negotiation result" model, the above cannot be achieved, since the initiator has to always offer a value. Thus, in the "both sides pick negotiation result" model , the above example would be : I -> T : DataPDULength=3D8K T -> I : DataPDULength=3D64K I -> T : DataPDULength=3D64K T -> I : DataPDULength=3D64K Both sides settle at 64K. I suggest that we allow the above "query based model", since this is more efficient to use when an initiator has no key limitations and would like to use the value a target can offer. In order to allow the "query based model", you would need to state in the draft that a key value of "?" over-rides the default, implying the target offered value would be the result of the negotiation. In particular, the "query based model" is quite useful when an initiator wishes to function with the target's maximal supported values for keys like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T, LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any limitations on its own key value. Comments ? Thanks, Santosh Sandeep Joshi wrote: >=20 > The first & third example below seem illogical. >=20 > The responder should not be sending 24K if the initial > sender has chosen a value of 16K, since there is no > possibility of that 24K being accepted (unless we want > three way exchanges for every negotiation??) >=20 > The problem of a Reject message does not arise since the > responder should only be choosing something less than 16K. > So I guess this puts me in the "responder selects logic" > camp. >=20 > -Sandeep >=20 > Julian Satran wrote: > > > > An example: > > 08.txt logic > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 24k > > > > Selected value is 16k > > > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 8k > > > > Selected value is 8k > > > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 24k > > > > Selected value is 16k > > > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 8k > > > > Selected value is 8k > > > > ----- > > > > Responder selects logic > > > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 24k > > > > Error - Initiator Reject - Closes connection > > > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 8k > > > > Selected value is 8k > > > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 24k > > > > Error Target has to terminate with parameter error > > > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 8k > > > > Selected value is 8k > > > > "Dev - Platys" > > To: "Julian Satran" > > , > > 01-10-01 23:46 > > Please respond to "Dev - cc: > > Platys" Subject: RE: iscsi : > > numerical negotiation wording is ambiguous > > > > > > > > Julian, > > > > I am not sure why a 'REJECT' is required. > > Can you please explain why is this required? > > > > I am with Santosh in this. > > > > >There is NO need for any REJECT in the above >case. If the initiator > > >is'nt satisfied with the value returned by the >originator and cannot > > >function with the negotiated values, it can simply >close the TCP > > >connection. There is no need to send any >REJECT. > > > > Thanks > > > > Deva > > Adaptec > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Monday, October 01, 2001 1:28 PM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > Santosh, > > > > We are getting nowhere. Even if requester is doing it's stuff - the > > requester will have to check and be prepared for a mistake. The coding > > will require a reject. > > > > Julo > > > > Santosh Rao > > To: ips@ece.cmu.edu > > Sent by: cc: "Sanjeev Bhagat > > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > > Julian Satran/Haifa/IBM@IBMIL > > 01-10-01 20:37 Subject: Re: iscsi : numerical > > Please respond to negotiation wording is ambiguous > > Santosh Rao > > > > > > Julian & Sanjeev, > > > > Responding to both your mails...... > > > > Julian : > > > > I think you may have mis-interpreted my comments. I believe Sanjeev > > has > > clarified the intent of my suggestions. > > > > I am *not* suggesting that the responder send back its values and > > these > > be blindly imposed on the originator. On the contrary, my suggestion > > is > > that the computation of the result of the negotiation (higher or lower > > of the 2 values) be only performed by the responder and sent back to > > the > > originator. > > > > The result of the negotiation is the same in both cases and there is > > no > > REJECT required in my case nor yours. The difference is the advantages > > I've stated in my model. > > > > Sanjeev, in response to your comment : > > > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. " > > > > There is NO need for any REJECT in the above case. If the initiator > > is'nt satisfied with the value returned by the originator and cannot > > function with the negotiated values, it can simply close the TCP > > connection. There is no need to send any REJECT. > > > > Thanks, > > Santosh > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Thanks Julian, please find my further comments in the message > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] > > > Sent: Sunday, September 30, 2001 6:07 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iscsi : numerical negotiation wording is > > > ambiguous > > > > > > 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=3Dvaluex > > > 2. a responder sends B=3Dvaluey > > > 3. the responder assumes that the value y is the correct > > > value and so does an external observer > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > > say it this way the responder computes the value with > > > its own supported values and responds with a value y > > > which the responder thinks is correct 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > > but it is highly unlikely for the responder to reject > > > the final result because the rule states that (lower or > > > higher of two will be the result) and so the offering > > > party should be able to accept the lower or higher > > > range as defined by rule. In case the key is dependent > > > upon some range of fixed values then the negotiation > > > should be performed as list negotiation and not > > > numerical negotiation. > > > > > > This might be what you "conventionally" do - I don't > > > and that shows that convention like morals are a matter > > > of geography :-) > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > > > The advantage of this set of rules is that it allows an > > > external observer to know what was selected without > > > knowing the rules > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > > case, I guess that the external observer has to know > > > the rules to double check the value is correct or not > > > 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=3Dvaluex > > > 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. > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. > > > > > > > > > Sanjeev > > > "Sanjeev Bhagat > > > (TRIPACE/Zoetermeer)" To: "'Santosh > > Rao'" > > > , Julian > > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > > cc: > > ips@ece.cmu.edu > > > 30-09-01 16:32 Subject: RE: > > iscsi : > > > Please respond to "Sanjeev numerical negotiation wording > > is > > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > > > > -- > > ################################## > > Santosh Rao > > Software Design Engineer, > > HP-UX iSCSI Driver Team, > > Hewlett Packard, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################## --=20 ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 ----- "Sanjeev Bhagat (TRIPACE/Zoetermeer)" Sent by: owner-ips@ece.cmu.edu 04-10-01 00:27 Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)" =20 To: "'Dev - Platys'" , Sandeep Joshi=20 , ips@ece.cmu.edu cc:=20 Subject: RE: iscsi : numerical negotiation offering party ba= sed computaion vs=20 responder based =20 All, Sorry for those who cannot view Excel sheet. you can view the file at the link http://www.radhekrishna.org/iSCSI/numeric=5Fnego=5Fcomparison.htm Please dont blame me for my ugly site. It was a very half hearted attempt from me long ago. And I am sorry I cant put it on the company website now because our system guy has left for the day. Sanjeev -----Original Message----- From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] Sent: Wednesday, October 03, 2001 10:44 PM To: 'Dev - Platys'; Sandeep Joshi; ips@ece.cmu.edu Subject: iscsi : numerical negotiation offering party based computaion vs responder based Hello all, i just changed the name of the thread, because the thread is now taking different directions. I am attaching an excel file here in which i have taken 7 different cases=20 to show how there could be some mis interpretation when offering party=20 computes the individual results. I have taken the example of dataPDuSize because i started making my table with this although there is a different thread=20 going on to it whether it should be kept in numerical negotiation or not.=20 In the table I have tried to take cases where the initiator and target may not support some PDU sizes which are lower than the maximum PDU size they support. Deva: it also tells when a reject might be needed. Regards, Sanjeev -----Original Message----- From: Dev - Platys [mailto:deva@platys.com] Sent: Wednesday, October 03, 2001 6:14 PM To: Sandeep Joshi; ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Santosh, The point is, if the target is not capable of supporting 16K (it is just=20 an example that is being discussed), then it indicates that is what it wants. Initiator can close the connection. (No reject is necessary though). However, if the target knows it can support the initiator negotiated=20 value, it could return it. Again, Yes, implicitly it becomes the responder selects logic.=20 Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Sandeep Joshi Sent: Wednesday, October 03, 2001 7:29 AM To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous The first & third example below seem illogical.=20 The responder should not be sending 24K if the initial sender has chosen a value of 16K, since there is no possibility of that 24K being accepted (unless we want three way exchanges for every negotiation??)=20 The problem of a Reject message does not arise since the=20 responder should only be choosing something less than 16K. So I guess this puts me in the "responder selects logic"=20 camp. -Sandeep Julian Satran wrote: >=20 > An example: > 08.txt logic > i->t DataPDULength=3D16k > t->i DataPDULength=3D 24k >=20 > Selected value is 16k >=20 > i->t DataPDULength=3D16k > t->i DataPDULength=3D 8k >=20 > Selected value is 8k >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 24k >=20 > Selected value is 16k >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 8k >=20 > Selected value is 8k >=20 > ----- >=20 > Responder selects logic >=20 > i->t DataPDULength=3D16k > t->i DataPDULength=3D 24k >=20 > Error - Initiator Reject - Closes connection >=20 > i->t DataPDULength=3D16k > t->i DataPDULength=3D 8k >=20 > Selected value is 8k >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 24k >=20 > Error Target has to terminate with parameter error >=20 > t->i DataPDULength=3D16k > i->t DataPDULength=3D 8k >=20 > Selected value is 8k >=20 > "Dev - Platys" > To: "Julian Satran" > , > 01-10-01 23:46 > Please respond to "Dev - cc: > Platys" Subject: RE: iscsi : > numerical negotiation wording is ambiguous >=20 >=20 >=20 > Julian, >=20 > I am not sure why a 'REJECT' is required. > Can you please explain why is this required? >=20 > I am with Santosh in this. >=20 > >There is NO need for any REJECT in the above >case. If the initiator > >is'nt satisfied with the value returned by the >originator and cannot > >function with the negotiated values, it can simply >close the TCP > >connection. There is no need to send any >REJECT. >=20 > Thanks >=20 > Deva > Adaptec >=20 > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Monday, October 01, 2001 1:28 PM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous >=20 > Santosh, >=20 > We are getting nowhere. Even if requester is doing it's stuff - the > requester will have to check and be prepared for a mistake. The coding > will require a reject. >=20 > Julo >=20 > Santosh Rao > To: ips@ece.cmu.edu > Sent by: cc: "Sanjeev Bhagat > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > Julian Satran/Haifa/IBM@IBMIL > 01-10-01 20:37 Subject: Re: iscsi : numerical > Please respond to negotiation wording is ambiguous > Santosh Rao >=20 >=20 > Julian & Sanjeev, >=20 > Responding to both your mails...... >=20 > Julian : >=20 > I think you may have mis-interpreted my comments. I believe Sanjeev > has > clarified the intent of my suggestions. >=20 > I am *not* suggesting that the responder send back its values and > these > be blindly imposed on the originator. On the contrary, my suggestion > is > that the computation of the result of the negotiation (higher or lower > of the 2 values) be only performed by the responder and sent back to > the > originator. >=20 > The result of the negotiation is the same in both cases and there is > no > REJECT required in my case nor yours. The difference is the advantages > I've stated in my model. >=20 > Sanjeev, in response to your comment : >=20 > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. " >=20 > There is NO need for any REJECT in the above case. If the initiator > is'nt satisfied with the value returned by the originator and cannot > function with the negotiated values, it can simply close the TCP > connection. There is no need to send any REJECT. >=20 > Thanks, > Santosh >=20 > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Thanks Julian, please find my further comments in the message > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] > > Sent: Sunday, September 30, 2001 6:07 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : numerical negotiation wording is > > ambiguous > > > > 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=3Dvaluex > > 2. a responder sends B=3Dvaluey > > 3. the responder assumes that the value y is the correct > > value and so does an external observer > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > say it this way the responder computes the value with > > its own supported values and responds with a value y > > which the responder thinks is correct 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 > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > but it is highly unlikely for the responder to reject > > the final result because the rule states that (lower or > > higher of two will be the result) and so the offering > > party should be able to accept the lower or higher > > range as defined by rule. In case the key is dependent > > upon some range of fixed values then the negotiation > > should be performed as list negotiation and not > > numerical negotiation. > > > > This might be what you "conventionally" do - I don't > > and that shows that convention like morals are a matter > > of geography :-) > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > The advantage of this set of rules is that it allows an > > external observer to know what was selected without > > knowing the rules > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > case, I guess that the external observer has to know > > the rules to double check the value is correct or not > > 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=3Dvaluex > > 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. > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > no reject , but it can be a problem in future . > > Consider your example of DataPDULength in your own > > message. Suppose offering party sends a value of 16,384 > > (this is also lowest value it can send) and responding > > party responds with 8,192. In this case the offering > > party will have to reject the negotiation. So a reject > > message is needed in this case also. > > > > > > Sanjeev > > "Sanjeev Bhagat > > (TRIPACE/Zoetermeer)" To: "'Santosh > Rao'" > > , Julian > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > cc: > ips@ece.cmu.edu > > 30-09-01 16:32 Subject: RE: > iscsi : > > Please respond to "Sanjeev numerical negotiation wording > is > > Bhagat (TRIPACE/Zoetermeer)" 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 > > >=20 > -- > ################################## > Santosh Rao > Software Design Engineer, > HP-UX iSCSI Driver Team, > Hewlett Packard, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################## ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 ----- "ERICKSON,SHAWN (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 04-10-01 01:48 Please respond to "ERICKSON,SHAWN (HP-Roseville,ex1)" =20 To: "'Santosh Rao'" , Sandeep Joshi=20 , Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambigu= ous =20 > Another value-add of the "responder picks the negotiation=20 > result model" > is that the initiator can use the following "query based" negotiation > model to always use the values the target is capable of offering : >=20 > I -> T : DataPDULength=3D? > T -> I : DataPDULength=3D64K >=20 > Both sides agree to use a DataPDULength of 64K.=20 I like the idea! ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- ------------------------------------------------------- ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 ----- "ERICKSON,SHAWN (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 04-10-01 01:46 Please respond to "ERICKSON,SHAWN (HP-Roseville,ex1)" =20 To: ips@ece.cmu.edu cc:=20 Subject: RE: iscsi : numerical negotiation wording is ambigu= ous =20 > The first & third example below seem illogical. I agree. > So I guess this puts me in the "responder selects logic"=20 > camp. Same here. -Shawn ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- ------------------------------------------------------- > -----Original Message----- > From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] > Sent: Wednesday, October 03, 2001 7:29 AM > To: ips@ece.cmu.edu > Subject: Re: iscsi : numerical negotiation wording is ambiguous >=20 >=20 >=20 > The first & third example below seem illogical.=20 >=20 > The responder should not be sending 24K if the initial > sender has chosen a value of 16K, since there is no > possibility of that 24K being accepted (unless we want > three way exchanges for every negotiation??)=20 >=20 > The problem of a Reject message does not arise since the=20 > responder should only be choosing something less than 16K. > So I guess this puts me in the "responder selects logic"=20 > camp. >=20 > -Sandeep >=20 >=20 > Julian Satran wrote: > >=20 > > An example: > > 08.txt logic > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 24k > >=20 > > Selected value is 16k > >=20 > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 8k > >=20 > > Selected value is 8k > >=20 > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 24k > >=20 > > Selected value is 16k > >=20 > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 8k > >=20 > > Selected value is 8k > >=20 > > ----- > >=20 > > Responder selects logic > >=20 > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 24k > >=20 > > Error - Initiator Reject - Closes connection > >=20 > > i->t DataPDULength=3D16k > > t->i DataPDULength=3D 8k > >=20 > > Selected value is 8k > >=20 > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 24k > >=20 > > Error Target has to terminate with parameter error > >=20 > > t->i DataPDULength=3D16k > > i->t DataPDULength=3D 8k > >=20 > > Selected value is 8k > >=20 > > "Dev - Platys" > > To: "Julian Satran" > > , > > 01-10-01 23:46 > > Please respond to "Dev - cc: > > Platys" Subject: RE: iscsi : > > numerical negotiation wording is=20 > ambiguous > >=20 > >=20 > >=20 > > Julian, > >=20 > > I am not sure why a 'REJECT' is required. > > Can you please explain why is this required? > >=20 > > I am with Santosh in this. > >=20 > > >There is NO need for any REJECT in the above >case. If the=20 > initiator > > >is'nt satisfied with the value returned by the >originator=20 > and cannot > > >function with the negotiated values, it can simply >close the TCP > > >connection. There is no need to send any >REJECT. > >=20 > > Thanks > >=20 > > Deva > > Adaptec > >=20 > > -----Original Message----- > > From: owner-ips@ece.cmu.edu=20 > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Monday, October 01, 2001 1:28 PM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > >=20 > > Santosh, > >=20 > > We are getting nowhere. Even if requester is doing it's stuff - the > > requester will have to check and be prepared for a mistake.=20 > The coding > > will require a reject. > >=20 > > Julo > >=20 > > Santosh Rao > > To: ips@ece.cmu.edu > > Sent by: cc: "Sanjeev Bhagat > > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > > Julian Satran/Haifa/IBM@IBMIL > > 01-10-01 20:37 Subject: Re: iscsi : numerical > > Please respond to negotiation wording is ambiguous > > Santosh Rao > >=20 > >=20 > > Julian & Sanjeev, > >=20 > > Responding to both your mails...... > >=20 > > Julian : > >=20 > > I think you may have mis-interpreted my comments. I believe Sanjeev > > has > > clarified the intent of my suggestions. > >=20 > > I am *not* suggesting that the responder send back its values and > > these > > be blindly imposed on the originator. On the contrary, my suggestion > > is > > that the computation of the result of the negotiation=20 > (higher or lower > > of the 2 values) be only performed by the responder and sent back to > > the > > originator. > >=20 > > The result of the negotiation is the same in both cases and there is > > no > > REJECT required in my case nor yours. The difference is the=20 > advantages > > I've stated in my model. > >=20 > > Sanjeev, in response to your comment : > >=20 > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. " > >=20 > > There is NO need for any REJECT in the above case. If the initiator > > is'nt satisfied with the value returned by the originator and cannot > > function with the negotiated values, it can simply close the TCP > > connection. There is no need to send any REJECT. > >=20 > > Thanks, > > Santosh > >=20 > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Thanks Julian, please find my further comments in the message > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] > > > Sent: Sunday, September 30, 2001 6:07 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iscsi : numerical negotiation wording is > > > ambiguous > > > > > > 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=3Dvaluex > > > 2. a responder sends B=3Dvaluey > > > 3. the responder assumes that the value y is the correct > > > value and so does an external observer > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > > say it this way the responder computes the value with > > > its own supported values and responds with a value y > > > which the responder thinks is correct 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 > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > > but it is highly unlikely for the responder to reject > > > the final result because the rule states that (lower or > > > higher of two will be the result) and so the offering > > > party should be able to accept the lower or higher > > > range as defined by rule. In case the key is dependent > > > upon some range of fixed values then the negotiation > > > should be performed as list negotiation and not > > > numerical negotiation. > > > > > > This might be what you "conventionally" do - I don't > > > and that shows that convention like morals are a matter > > > of geography :-) > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > > > The advantage of this set of rules is that it allows an > > > external observer to know what was selected without > > > knowing the rules > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > > case, I guess that the external observer has to know > > > the rules to double check the value is correct or not > > > 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=3Dvaluex > > > 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. > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > no reject , but it can be a problem in future . > > > Consider your example of DataPDULength in your own > > > message. Suppose offering party sends a value of 16,384 > > > (this is also lowest value it can send) and responding > > > party responds with 8,192. In this case the offering > > > party will have to reject the negotiation. So a reject > > > message is needed in this case also. > > > > > > > > > Sanjeev > > > "Sanjeev Bhagat > > > (TRIPACE/Zoetermeer)" To:=20 > "'Santosh > > Rao'" > > > =20 > , Julian > > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > > cc: > > ips@ece.cmu.edu > > > 30-09-01 16:32 Subject: RE: > > iscsi : > > > Please respond to "Sanjeev numerical=20 > negotiation wording > > is > > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > >=20 > > -- > > ################################## > > Santosh Rao > > Software Design Engineer, > > HP-UX iSCSI Driver Team, > > Hewlett Packard, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################## >=20 ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 ----- "ERICKSON,SHAWN (HP-Roseville,ex1)" 04-10-01 01:48 Please respond to "ERICKSON,SHAWN (HP-Roseville,ex1)" =20 To: "'Santosh Rao'" , Sandeep Joshi=20 , Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambigu= ous =20 > Another value-add of the "responder picks the negotiation=20 > result model" > is that the initiator can use the following "query based" negotiation > model to always use the values the target is capable of offering : >=20 > I -> T : DataPDULength=3D? > T -> I : DataPDULength=3D64K >=20 > Both sides agree to use a DataPDULength of 64K.=20 I like the idea! ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [Telnet] Hewlett Packard Company OV NSSO Joint Venture Storage Resource Management R&D Lab (Santa Barbara) ------------------------------------------------------- ------------------------------------------------------- ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 ----- John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 04-10-01 07:57 Please respond to John Hufferd =20 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambigu= ous =20 Julian, I find your response troubling, perhaps I did not understand what you intended to say. Comments below. . . . 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 10/03/2001 05:26:58 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iscsi : numerical negotiation wording is ambiguous An example: =A008.txt logic i->t DataPDULength=3D16k t->i DataPDULength=3D 24k Selected value is 16k [Huff] If target knows that the Initiator wants 16k, and therefore that=20 its 24k is not going to be accepted, why did the Target send 24K? [/Huff] i->t DataPDULength=3D16k t->i DataPDULength=3D 8k Selected value is 8k t->i DataPDULength=3D16k i->t DataPDULength=3D 24k Selected value is 16k [Huff] If Initiator knows that the target wants 16k, and therefore that=20 its 24k is not going to be accepted, why did the Initiator send 24K? [/Huff] t->i DataPDULength=3D16k i->t DataPDULength=3D 8k Selected value is 8k ----- Responder selects logic i->t DataPDULength=3D16k t->i DataPDULength=3D 24k Error - Initiator Reject - Closes connection i->t DataPDULength=3D16k t->i DataPDULength=3D 8k Selected value is 8k t->i DataPDULength=3D16k i->t DataPDULength=3D 24k Error Target has to terminate with parameter error t->i DataPDULength=3D16k i->t DataPDULength=3D 8k Selected value is 8k =20 "Dev - Platys" =20 =A0 =A0 =A0 =A0 To: = "Julian Satran" =20 01-10-01 23:46 , =20 "Dev - Platys" =20 =A0 =A0 =A0 =A0 cc: = =A0 =A0 =A0 =A0 Subje= ct: =20 RE: iscsi :=20 numerical=20 negotiation wording = is ambiguous =20 =20 =20 =20 Julian, I am not sure why a 'REJECT' is required. Can you please explain why is this required? I am with Santosh in this. >There is NO need for any REJECT in the above >case. If the initiator >is'nt satisfied with the value returned by the >originator and cannot >function with the negotiated values, it can simply >close the TCP >connection. There is no need to send any >REJECT. Thanks Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Monday, October 01, 2001 1:28 PM To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous Santosh, We are getting nowhere. Even if requester is doing it's stuff - the requester will have to check and be prepared for a mistake. The coding=20 will require a reject. Julo =20 Santosh Rao=20 =A0 =A0 =A0 =A0cc: =A0 =A0 =A0 =A0"Sanjeev B= hagat=20 Sent by: (TRIPACE/Zoetermeer)"=20 santoshr@cup.hp.co , Julian=20 m Satran/Haifa/IBM@IBMIL=20 =A0 =A0 =A0 =A0Subject: =A0 =A0 =A0 =A0Re: i= scsi :=20 01-10-01 20:37 numerical negotiation wording is ambiguous=20 Please respond to=20 Santosh Rao=20 =20 Julian & Sanjeev, Responding to both your mails...... Julian : I think you may have mis-interpreted my comments. I believe Sanjeev has clarified the intent of my suggestions. I am *not* suggesting that the responder send back its values and these be blindly imposed on the originator. On the contrary, my suggestion is that the computation of the result of the negotiation (higher or lower of the 2 values) be only performed by the responder and sent back to the originator. The result of the negotiation is the same in both cases and there is no REJECT required in my case nor yours. The difference is the advantages I've stated in my model. Sanjeev, in response to your comment : " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > =A0no reject , but it can be a problem in future . > =A0Consider your example of DataPDULength in your own > =A0message. Suppose offering party sends a value of 16,384 > =A0(this is also lowest value it can send) and responding > =A0party responds with 8,192. In this case the offering > =A0party will have to reject the negotiation. So a reject > =A0message is needed in this case also. " There is NO need for any REJECT in the above case. If the initiator is'nt satisfied with the value returned by the originator and cannot function with the negotiated values, it can simply close the TCP connection. There is no need to send any REJECT. Thanks, Santosh > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > Thanks Julian, please find my further comments in the message > > =A0 =A0 =A0-----Original Message----- > =A0 =A0 =A0From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] > =A0 =A0 =A0Sent: Sunday, September 30, 2001 6:07 PM > =A0 =A0 =A0To: ips@ece.cmu.edu > =A0 =A0 =A0Subject: RE: iscsi : numerical negotiation wording is > =A0 =A0 =A0ambiguous > > =A0 =A0 =A0Sanjeev, > > =A0 =A0 =A0I am not sure clear I made the tiny diference between what I > =A0 =A0 =A0say and what Santosh said: > > =A0 =A0 =A0Santosh says: > > =A0 =A0 =A0 =A01. a requester sends A=3Dvaluex > =A0 =A0 =A0 =A02. a responder sends B=3Dvaluey > =A0 =A0 =A0 =A03. the responder assumes that the value y is the correct > =A0 =A0 =A0 =A0 =A0 value and so does an external observer > =A0 =A0 =A0 =A0 =A0 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > =A0 =A0 =A0 =A0 =A0 say it this way the responder computes the value with > =A0 =A0 =A0 =A0 =A0 its own supported values and responds with a value y > =A0 =A0 =A0 =A0 =A0 which the responder thinks is correct and so does an > =A0 =A0 =A0 =A0 =A0 external observer > =A0 =A0 =A0 =A04. the requester checks that valuey is conformant (he will > =A0 =A0 =A0 =A0 =A0 not believe it) and will reject it if not conformant > =A0 =A0 =A0 =A0 =A0 else it will accept it > =A0 =A0 =A0 =A0 =A0 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correc= t, > =A0 =A0 =A0 =A0 =A0 but it is highly unlikely for the responder to reject > =A0 =A0 =A0 =A0 =A0 the final result because the rule states that (lower = or > =A0 =A0 =A0 =A0 =A0 higher of two will be the result) and so the offering > =A0 =A0 =A0 =A0 =A0 party should be able to accept the lower or higher > =A0 =A0 =A0 =A0 =A0 range as defined by rule. In case the key is dependent > =A0 =A0 =A0 =A0 =A0 upon some range of fixed values then the negotiation > =A0 =A0 =A0 =A0 =A0 should be performed as list negotiation and not > =A0 =A0 =A0 =A0 =A0 numerical negotiation. > > =A0 =A0 =A0 =A0 =A0 This might be what you "conventionally" do - I don't > =A0 =A0 =A0 =A0 =A0 and that shows that convention like morals are a matt= er > =A0 =A0 =A0 =A0 =A0 of geography :-) > =A0 =A0 =A0 =A0 =A0 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > =A0 =A0 =A0 =A0 =A0 The advantage of this set of rules is that it allows = an > =A0 =A0 =A0 =A0 =A0 external observer to know what was selected without > =A0 =A0 =A0 =A0 =A0 knowing the rules > =A0 =A0 =A0 =A0 =A0 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > =A0 =A0 =A0 =A0 =A0 case, I guess that the external observer has to know > =A0 =A0 =A0 =A0 =A0 the rules to double check the value is correct or not > =A0 =A0 =A0 =A0 =A0 The disadvantage is that messages have to be "built", > =A0 =A0 =A0 =A0 =A0 an additional reject states exists and MOST IMPORTANT > =A0 =A0 =A0 =A0 =A0 you need both messages > > =A0 =A0 =A0 =A0 =A0 In what I said: > > =A0 =A0 =A0 =A0 =A0 1. The requester sends A=3Dvaluex > =A0 =A0 =A0 =A0 =A0 2. The Responder has to send either nothing (if valuex > =A0 =A0 =A0 =A0 =A0 is enough on both sides to compute the result like in > =A0 =A0 =A0 =A0 =A0 the case in which the function is a Boolean AND and t= he > =A0 =A0 =A0 =A0 =A0 value is NO) or valuey > =A0 =A0 =A0 =A0 =A0 3. Both the requestor and responder have to compute t= he > =A0 =A0 =A0 =A0 =A0 value (they have to know the rules anyhow) and so does > =A0 =A0 =A0 =A0 =A0 the external observer > > =A0 =A0 =A0 =A0 =A0 The disadvantage is that the external observer has to > =A0 =A0 =A0 =A0 =A0 know the rules > =A0 =A0 =A0 =A0 =A0 The advantage is that there is no reject, in binary > =A0 =A0 =A0 =A0 =A0 negotiations you can go away with shorter negotiations > =A0 =A0 =A0 =A0 =A0 and you can set strings at fixed values. > =A0 =A0 =A0 =A0 =A0 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there = is > =A0 =A0 =A0 =A0 =A0 no reject , but it can be a problem in future . > =A0 =A0 =A0 =A0 =A0 Consider your example of DataPDULength in your own > =A0 =A0 =A0 =A0 =A0 message. Suppose offering party sends a value of 16,3= 84 > =A0 =A0 =A0 =A0 =A0 (this is also lowest value it can send) and responding > =A0 =A0 =A0 =A0 =A0 party responds with 8,192. In this case the offering > =A0 =A0 =A0 =A0 =A0 party will have to reject the negotiation. So a reject > =A0 =A0 =A0 =A0 =A0 message is needed in this case also. > > > =A0 =A0 =A0Sanjeev > =A0 =A0 =A0 "Sanjeev Bhagat > =A0 =A0 =A0 (TRIPACE/Zoetermeer)" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= To: =A0 =A0 =A0 =A0"'Santosh=20 Rao'" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0, Julian > =A0 =A0 =A0 Sent by: owner-ips@ece.cmu.edu =A0 Satran/Haifa/IBM@IBMIL > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0cc: =A0 =A0 =A0=20 =A0ips@ece.cmu.edu > =A0 =A0 =A0 30-09-01 16:32 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Subject: =A0 =A0 =A0 =A0RE: iscsi : > =A0 =A0 =A0 Please respond to "Sanjeev =A0 =A0 =A0 numerical negotiation = wording is > =A0 =A0 =A0 Bhagat (TRIPACE/Zoetermeer)" =A0 =A0 ambiguous > > > > =A0 =A0 =A0All, > > =A0 =A0 =A0I agree with Santosh that the responding party must respond > =A0 =A0 =A0the result of > =A0 =A0 =A0the negotiation as compared with the value from offering > =A0 =A0 =A0party. All > =A0 =A0 =A0negotiations in SCSI like (sync, disconnect etc) are also > =A0 =A0 =A0done the same way. > =A0 =A0 =A0I also object to Julian's reason of a simple minded target > =A0 =A0 =A0which wants to > =A0 =A0 =A0send certain fixed values only. In case a simple minded > =A0 =A0 =A0target identifies a > =A0 =A0 =A0value which it cannot support or is less than the value a > =A0 =A0 =A0target can > =A0 =A0 =A0support, then there should be a method for target to reject > =A0 =A0 =A0such a > =A0 =A0 =A0negotiation and the default values be accepted on both side > =A0 =A0 =A0as a result of > =A0 =A0 =A0negotiation. > > =A0 =A0 =A01 Because even if simple minded target sends its fixed value > =A0 =A0 =A0which is > =A0 =A0 =A0greater than the value sent by offering party then the final > =A0 =A0 =A0result of > =A0 =A0 =A0negotiation will be taken as ( lesser of the two) and in > =A0 =A0 =A0this case target > =A0 =A0 =A0which which cannot support the lower value will produce some > =A0 =A0 =A0illegal > =A0 =A0 =A0results. > > =A0 =A0 =A02. if simple minded target wants to send its own value and > =A0 =A0 =A0wants it to be > =A0 =A0 =A0accpeted then the responding party is not negotiating but > =A0 =A0 =A0forcing the result > =A0 =A0 =A0on initiator(this method should not be allowed unless > =A0 =A0 =A0explicitly mentioned). > > =A0 =A0 =A0however if there is another proposal of numeric negotiation > =A0 =A0 =A0in which the > =A0 =A0 =A0responding party can force its result to be over ridden by > =A0 =A0 =A0the offering > =A0 =A0 =A0party's result then it is acceptable for offering party and > =A0 =A0 =A0responding party > =A0 =A0 =A0to send there own supported key-value result and it can then > =A0 =A0 =A0be computed at > =A0 =A0 =A0offering party's end. > > =A0 =A0 =A0IMP: (May be I am missing something here) I do not see how a > =A0 =A0 =A0numeric > =A0 =A0 =A0negotiation can be rejected. Is it possible to reject such > =A0 =A0 =A0kind of > =A0 =A0 =A0negotiaion? > > =A0 =A0 =A0Sanjeev > > =A0 =A0 =A0-----Original Message----- > =A0 =A0 =A0From: Santosh Rao [mailto:santoshr@cup.hp.com] > =A0 =A0 =A0Sent: Friday, September 28, 2001 11:15 PM > =A0 =A0 =A0To: Julian Satran > =A0 =A0 =A0Cc: ips@ece.cmu.edu > =A0 =A0 =A0Subject: Re: iscsi : numerical negotiation wording is > =A0 =A0 =A0ambiguous > > =A0 =A0 =A0Julian & All, > > =A0 =A0 =A0I request the group to take a close look at this negotiation > =A0 =A0 =A0process > =A0 =A0 =A0again and [re-]evaluate the alternative being proposed. > > =A0 =A0 =A0Further, it appears that the login stage negotiation =A0is > =A0 =A0 =A0also following > =A0 =A0 =A0the same algorithm as the login key negotiation, wherein > =A0 =A0 =A0originator & > =A0 =A0 =A0responder offer their respective values and both sides need > =A0 =A0 =A0to determine > =A0 =A0 =A0the result of the negotiation. i.e. both initiator and > =A0 =A0 =A0target need to > =A0 =A0 =A0compare their NSG with the other party's NSG and pick the > =A0 =A0 =A0lower of the > =A0 =A0 =A02. > > =A0 =A0 =A0I suggest that both the login key negotiation and the login > =A0 =A0 =A0stage > =A0 =A0 =A0negotiation follow the policy that the originator offers a > =A0 =A0 =A0value and the > =A0 =A0 =A0responder picks the result of the negotiation based on (the > =A0 =A0 =A0offered > =A0 =A0 =A0value & its own value). The value picked by the responder is > =A0 =A0 =A0sent back > =A0 =A0 =A0to the originator. > > =A0 =A0 =A0This model has the following advantages : > > =A0 =A0 =A01) Only one side picks the result of the negotiaton. Hence, > =A0 =A0 =A0the 2 sides > =A0 =A0 =A0cannot go out of sync on the value picked. > > =A0 =A0 =A02) The originator knows the negotiated result at the the > =A0 =A0 =A0responder since > =A0 =A0 =A0the responder sends back the result of the negotiation. > > =A0 =A0 =A03) This model is easier to debug because of (1) & (2). > > =A0 =A0 =A04) Less code since only 1 party (responder) needs to perform > =A0 =A0 =A0the > =A0 =A0 =A0computation to pick the result of the negotiation. > > =A0 =A0 =A05) This scheme leaves less room for interop problems and > =A0 =A0 =A0mis-interpretation since it is the more familiar negotiation > =A0 =A0 =A0technique > =A0 =A0 =A0that is in use in most other mass storage protocols. (ex : > =A0 =A0 =A0FC PLOGI, FC > =A0 =A0 =A0PRLI, etc). From a first reading of the current negotiation > =A0 =A0 =A0scheme, it > =A0 =A0 =A0is'nt readily apparent that the currently defined model is > =A0 =A0 =A0different > =A0 =A0 =A0from the above and requires both sides to be picking the > =A0 =A0 =A0result of the > =A0 =A0 =A0negotiation, instead of just the responder. > > =A0 =A0 =A0Comments ? > > =A0 =A0 =A0Thanks, > =A0 =A0 =A0Santosh > -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## ----- Forwarded by Julian Satran/Haifa/IBM on 04-10-01 18:56 ----- John Hufferd@IBMUS 04-10-01 07:57 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: RE: iscsi : numerical negotiation wording is ambigu= ous =20 Julian, I find your response troubling, perhaps I did not understand what you=20 intended to say. Comments below. . . . 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 Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc:=20 Subject: RE: iscsi : numerical negotiation wording is ambiguous An example:=20 08.txt logic=20 i->t DataPDULength=3D16k=20 t->i DataPDULength=3D 24k=20 Selected value is 16k=20 [Huff] If target knows that the Initiator wants 16k, and therefore that=20 its 24k is not going to be accepted, why did the Target send 24K? [/Huff] i->t DataPDULength=3D16k=20 t->i DataPDULength=3D 8k=20 Selected value is 8k=20 t->i DataPDULength=3D16k=20 i->t DataPDULength=3D 24k=20 Selected value is 16k=20 [Huff] If Initiator knows that the target wants 16k, and therefore that=20 its 24k is not going to be accepted, why did the Initiator send 24K?=20 [/Huff] t->i DataPDULength=3D16k=20 i->t DataPDULength=3D 8k=20 Selected value is 8k=20 -----=20 Responder selects logic=20 i->t DataPDULength=3D16k=20 t->i DataPDULength=3D 24k=20 Error - Initiator Reject - Closes connection=20 i->t DataPDULength=3D16k=20 t->i DataPDULength=3D 8k=20 Selected value is 8k=20 t->i DataPDULength=3D16k=20 i->t DataPDULength=3D 24k=20 Error Target has to terminate with parameter error=20 t->i DataPDULength=3D16k=20 i->t DataPDULength=3D 8k=20 Selected value is 8k=20 "Dev - Platys" =20 01-10-01 23:46=20 Please respond to "Dev - Platys"=20 =20 To: "Julian Satran" ,=20 =20 cc: =20 Subject: RE: iscsi : numerical negotiation wording is=20 ambiguous=20 =20 Julian,=20 =20 I am not sure why a 'REJECT' is required.=20 Can you please explain why is this required?=20 =20 I am with Santosh in this.=20 =20 >There is NO need for any REJECT in the above >case. If the initiator >is'nt satisfied with the value returned by the >originator and cannot >function with the negotiated values, it can simply >close the TCP >connection. There is no need to send any >REJECT. Thanks=20 =20 Deva=20 Adaptec=20 -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Juli= an Satran Sent: Monday, October 01, 2001 1:28 PM To: ips@ece.cmu.edu Subject: Re: iscsi : numerical negotiation wording is ambiguous =20 Santosh,=20 We are getting nowhere. Even if requester is doing it's stuff - the=20 requester will have to check and be prepared for a mistake. The coding=20 will require a reject.=20 Julo=20 Santosh Rao =20 Sent by: santoshr@cup.hp.com=20 01-10-01 20:37=20 Please respond to Santosh Rao=20 =20 To: ips@ece.cmu.edu=20 cc: "Sanjeev Bhagat (TRIPACE/Zoetermeer)"=20 , Julian Satran/Haifa/IBM@IBMIL=20 Subject: Re: iscsi : numerical negotiation wording is=20 ambiguous=20 =20 Julian & Sanjeev, Responding to both your mails...... Julian : I think you may have mis-interpreted my comments. I believe Sanjeev has clarified the intent of my suggestions.=20 I am *not* suggesting that the responder send back its values and these be blindly imposed on the originator. On the contrary, my suggestion is that the computation of the result of the negotiation (higher or lower of the 2 values) be only performed by the responder and sent back to the originator. The result of the negotiation is the same in both cases and there is no REJECT required in my case nor yours. The difference is the advantages I've stated in my model.=20 Sanjeev, in response to your comment : " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. " There is NO need for any REJECT in the above case. If the initiator is'nt satisfied with the value returned by the originator and cannot function with the negotiated values, it can simply close the TCP connection. There is no need to send any REJECT. Thanks, Santosh > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: >=20 > Thanks Julian, please find my further comments in the message >=20 > -----Original Message----- > From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com] > Sent: Sunday, September 30, 2001 6:07 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : numerical negotiation wording is > ambiguous >=20 > Sanjeev, >=20 > I am not sure clear I made the tiny diference between what I > say and what Santosh said: >=20 > Santosh says: >=20 > 1. a requester sends A=3Dvaluex > 2. a responder sends B=3Dvaluey > 3. the responder assumes that the value y is the correct > value and so does an external observer > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > say it this way the responder computes the value with > its own supported values and responds with a value y > which the responder thinks is correct 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 > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > but it is highly unlikely for the responder to reject > the final result because the rule states that (lower or > higher of two will be the result) and so the offering > party should be able to accept the lower or higher > range as defined by rule. In case the key is dependent > upon some range of fixed values then the negotiation > should be performed as list negotiation and not=20 > numerical negotiation. >=20 > This might be what you "conventionally" do - I don't > and that shows that convention like morals are a matter > of geography :-) > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) >=20 > The advantage of this set of rules is that it allows an > external observer to know what was selected without > knowing the rules > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > case, I guess that the external observer has to know > the rules to double check the value is correct or not > The disadvantage is that messages have to be "built", > an additional reject states exists and MOST IMPORTANT > you need both messages >=20 > In what I said: >=20 > 1. The requester sends A=3Dvaluex > 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 >=20 > 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. > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > no reject , but it can be a problem in future . > Consider your example of DataPDULength in your own > message. Suppose offering party sends a value of 16,384 > (this is also lowest value it can send) and responding > party responds with 8,192. In this case the offering > party will have to reject the negotiation. So a reject > message is needed in this case also. >=20 >=20 > Sanjeev > "Sanjeev Bhagat=20 > (TRIPACE/Zoetermeer)" To: "'Santosh=20 Rao'" > , Julian > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > cc: =20 ips@ece.cmu.edu > 30-09-01 16:32 Subject: RE: iscsi = : > Please respond to "Sanjeev numerical negotiation wording is > Bhagat (TRIPACE/Zoetermeer)" ambiguous >=20 >=20 >=20 > All, >=20 > 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. >=20 > 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. >=20 > 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). >=20 > 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. >=20 > 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? >=20 > Sanjeev >=20 > -----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 >=20 > Julian & All, >=20 > I request the group to take a close look at this negotiation > process > again and [re-]evaluate the alternative being proposed. >=20 > 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. >=20 > 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. >=20 > This model has the following advantages : >=20 > 1) Only one side picks the result of the negotiaton. Hence, > the 2 sides > cannot go out of sync on the value picked. >=20 > 2) The originator knows the negotiated result at the the > responder since > the responder sends back the result of the negotiation. >=20 > 3) This model is easier to debug because of (1) & (2). >=20 > 4) Less code since only 1 party (responder) needs to perform > the > computation to pick the result of the negotiation. >=20 > 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. >=20 > Comments ? >=20 > Thanks, > Santosh >=20 --=20 ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team,=20 Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## =20 --=_alternative 006299F1C2256ADB_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Well - even I got fed-up with this l= ong thread.

Here the new text I am suggesting fo= r the negotiations ("vox populi"):

In numerical negotiations, the offe= ring and responding party state a numerical value. The result of the negoti= ation is key dependent; frequently the lower or the higher of the two value= s is used.

For numerical negotiations, the res= ponding party MUST respond with the required key and the value it selects, = based on the selection rule specific to the key, becomes the negotiation re= sult.  Selection of a value not admissible under the selection rules i= s considered a protocol error and handled accordingly.

For Boolean negotiations (keys taki= ng the values yes or no), the result is a key dependent Boolean function of= the two inputs. The negotiation MAY proceed only up to the point where bot= h parties can unequivocally compute the result; continuing beyond this poin= t is OPTIONAL (e.g., if the function is AND and one of the parties says &qu= ot;no" then this may end the negotiation). Both requestor and responde= r MUST to compute the negotiated value based on the new value(s) exchanged<= /font>

The value "?" with any ke= y has the meaning of enquiry and should be answered with the current value = or "NotUnderstood".

The target may offer key=3Dvalue pa= irs of its own. Target requests are not limited to matching key=3Dvalue pai= rs as offered by the initiator.  However, only the initiator can initi= ate the negotiation start (through the first Text request) and completion (= by setting to 1 and keeping to 1 the F bit in a Text request).

Unless specified otherwise the nego= tiation process is stateless (based only on newly presented values).


Comments?
Julo


----- Forwarded by J= ulian Satran/Haifa/IBM on 04-10-01 18:56 -----
Paul Koning <pkoning@jlc.net&g= t;

03-10-01 16:43
Please respond to Paul Koning

       
        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      ips@ece.cmu.edu
        Subject:=        RE: iscsi : numerical negotiation wording is am= biguous

       


Excerpt of message (sent 3 October = 2001) by Julian Satran:
> An example:
>  08.txt logic
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 24k
>
> Selected value is 16k
>
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 8k
>
> Selected value is 8k
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 24k
>
> Selected value is 16k
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 8k
>
> Selected value is 8k
>
> -----
>
> Responder selects logic
>
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 24k
>
> Error - Initiator Reject - Closes connection
>
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 8k
>
> Selected value is 8k
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 24k
>
> Error Target has to terminate with parameter error
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 8k
>
> Selected value is 8k

In most protocols, "responder selects" is used.  And the rul= e is that
the responder MUST respond with a value acceptable to both sides.

Therefore, if the negotiation rule for DataPDULength is to pick the
smaller of the two values preferred by the two sides, your first and
third examples would be defective implementations.  Often, protocol
specs don't say what to do with defective implementations; a typical
answer is to terminate the conversation, which is a sensible answer.
Sending rejects is not that useful for defective implementations,
since there is no reason to assume that they will all of a sudden
start to act correctly.  Also, it is useful to build in protocol
mechanisms for bit errors, memory errors, dropped packets, etc. -- but
it is generally NOT useful to build mechanisms that apply only when
the other side has a software bug.  I agree with Deva that the
appropriate response to a protocol violation is to terminate the
conversation.

So for "responder selects" examples 1 and 3 should have read like=
this:

i->t DataPDULength=3D16k
t->i DataPDULength=3D 16k             &nbs= p;                    (t = wants 24 but 16 is the agreed value)

...

t->i DataPDULength=3D16k
i->t DataPDULength=3D 16k             &nbs= p;                    (i = wants 24 but 16 is the agreed value)

    paul
----- Forwarded by J= ulian Satran/Haifa/IBM on 04-10-01 18:56 -----
Paul Koning <pkoning@jlc.net&g= t;
Sent by: owner-ips@ece.cmu.edu

03-10-01 16:43
Please respond to Paul Koning

       
        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      ips@ece.cmu.edu
        Subject:=        RE: iscsi : numerical negotiation wording is am= biguous

       


Excerpt of message (sent 3 October = 2001) by Julian Satran:
> An example:
>  08.txt logic
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 24k
>
> Selected value is 16k
>
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 8k
>
> Selected value is 8k
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 24k
>
> Selected value is 16k
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 8k
>
> Selected value is 8k
>
> -----
>
> Responder selects logic
>
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 24k
>
> Error - Initiator Reject - Closes connection
>
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 8k
>
> Selected value is 8k
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 24k
>
> Error Target has to terminate with parameter error
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 8k
>
> Selected value is 8k

In most protocols, "responder selects" is used.  And the rul= e is that
the responder MUST respond with a value acceptable to both sides.

Therefore, if the negotiation rule for DataPDULength is to pick the
smaller of the two values preferred by the two sides, your first and
third examples would be defective implementations.  Often, protocol
specs don't say what to do with defective implementations; a typical
answer is to terminate the conversation, which is a sensible answer.
Sending rejects is not that useful for defective implementations,
since there is no reason to assume that they will all of a sudden
start to act correctly.  Also, it is useful to build in protocol
mechanisms for bit errors, memory errors, dropped packets, etc. -- but
it is generally NOT useful to build mechanisms that apply only when
the other side has a software bug.  I agree with Deva that the
appropriate response to a protocol violation is to terminate the
conversation.

So for "responder selects" examples 1 and 3 should have read like=
this:

i->t DataPDULength=3D16k
t->i DataPDULength=3D 16k             &nbs= p;                    (t = wants 24 but 16 is the agreed value)

...

t->i DataPDULength=3D16k
i->t DataPDULength=3D 16k             &nbs= p;                    (i = wants 24 but 16 is the agreed value)

    paul
----- Forwarded by J= ulian Satran/Haifa/IBM on 04-10-01 18:56 -----
Santosh Rao <santoshr@cup.hp.c= om>
Sent by: santoshr@cup.hp.com

03-10-01 18:26
Please respond to Santosh Rao

       
        To: &nbs= p;      Sandeep Joshi <sandeepj@research.bell-labs.com>= ;, Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      ips@ece.cmu.edu
        Subject:=        Re: iscsi : numerical negotiation wording is am= biguous

       


Julian,

Another value-add of the "responder picks the negotiation result model= "
is that the initiator can use the following "query based" negotia= tion
model to always use the values the target is capable of offering :

I -> T : DataPDULength=3D?
T -> I : DataPDULength=3D64K

Both sides agree to use a DataPDULength of 64K.

In the "both sides pick negotiation result" model, the above cann= ot be
achieved, since the initiator has to always offer a value.

Thus, in the "both sides pick negotiation result" model , the abo= ve
example would be :
I -> T : DataPDULength=3D8K
T -> I : DataPDULength=3D64K
I -> T : DataPDULength=3D64K
T -> I : DataPDULength=3D64K

Both sides settle at 64K.

I suggest that we allow the above "query based model", since this= is
more efficient to use when an initiator has no key limitations and would
like to use the value a target can offer. In order to allow the "query=
based model", you would need to state in the draft that a key value of=
"?" over-rides the default, implying the target offered value wou= ld be
the result of the negotiation.

In particular, the "query based model" is quite useful when an in= itiator
wishes to function with the target's maximal supported values for keys
like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T,
LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any
limitations on its own key value.

Comments ?

Thanks,
Santosh



Sandeep Joshi wrote:
>
> The first & third example below seem illogical.
>
> The responder should not be sending 24K if the initial
> sender has chosen a value of 16K, since there is no
> possibility of that 24K being accepted (unless we want
> three way exchanges for every negotiation??)
>
> The problem of a Reject message does not arise since the
> responder should only be choosing something less than 16K.
> So I guess this puts me in the "responder selects logic"
> camp.
>
> -Sandeep
>
> Julian Satran wrote:
> >
> > An example:
> >  08.txt logic
> > i->t DataPDULength=3D16k
> > t->i DataPDULength=3D 24k
> >
> > Selected value is 16k
> >
> > i->t DataPDULength=3D16k
> > t->i DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 24k
> >
> > Selected value is 16k
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> > -----
> >
> > Responder selects logic
> >
> > i->t DataPDULength=3D16k
> > t->i DataPDULength=3D 24k
> >
> > Error - Initiator Reject - Closes connection
> >
> > i->t DataPDULength=3D1= 6k
> > t->i DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 24k
> >
> > Error Target has to terminate with parameter error
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> >   "Dev - Platys"
> >   <deva@platys.com>          =      To:        "Julian Satran&quo= t;
> >                   &n= bsp;        <Julian=5FSatran@il.ibm.com>,
> >   01-10-01 23:46           <ips@= ece.cmu.edu>
> >   Please respond to "Dev -         = cc:
> >   Platys"             &nb= sp;            Subject:       =  RE: iscsi :
> >                   &n= bsp;        numerical negotiation wording is ambiguous<= br> > >
> >
> >
> > Julian,
> >
> > I am not sure why a 'REJECT' is required.
> > Can you please explain why is this required?
> >
> > I am with Santosh in this.
> >
> > >There is NO need for any REJECT in the above >case. If the= initiator
> > >is'nt satisfied with the value returned by the >originator= and cannot
> > >function with the negotiated values, it can simply >close = the TCP
> > >connection. There is no need to send any >REJECT.
> >
> > Thanks
> >
> > Deva
> > Adaptec
> >
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Beha= lf Of
> > Julian Satran
> > Sent: Monday, October 01, 2001 1:28 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iscsi : numerical negotiation wording is ambiguous > >
> > Santosh,
> >
> > We are getting nowhere. Even if requester is doing it's stuff - t= he
> > requester will have to check and be prepared for a mistake. The c= oding
> > will require a reject.
> >
> > Julo
> >
> >   Santosh Rao
> >   <santoshr@cup.hp.com>        To:=        ips@ece.cmu.edu
> >   Sent by:               =       cc:        "Sanjeev Bhagat
> >   santoshr@cup.hp.com   (TRIPACE/Zoetermeer)" <= sbhagat@tripace.com>,
> >                   &n= bsp;     Julian Satran/Haifa/IBM@IBMIL
> >   01-10-01 20:37             &= nbsp; Subject:        Re: iscsi : numerical
> >   Please respond to     negotiation wording is amb= iguous
> >   Santosh Rao
> >
> >
> > Julian & Sanjeev,
> >
> > Responding to both your mails......
> >
> > Julian :
> >
> > I think you may have mis-interpreted my comments. I believe Sanje= ev
> > has
> > clarified the intent of my suggestions.
> >
> > I am *not* suggesting that the responder send back its values and=
> > these
> > be blindly imposed on the originator. On the contrary, my suggest= ion
> > is
> > that the computation of the result of the negotiation (higher or = lower
> > of the 2 values) be only performed by the responder and sent back= to
> > the
> > originator.
> >
> > The result of the negotiation is the same in both cases and there= is
> > no
> > REJECT required in my case nor yours. The difference is the advan= tages
> > I've stated in my model.
> >
> > Sanjeev, in response to your comment :
> >
> > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> > >  no reject , but it can be a problem in future .
> > >  Consider your example of DataPDULength in your own
> > >  message. Suppose offering party sends a value of 16,38= 4
> > >  (this is also lowest value it can send) and responding=
> > >  party responds with 8,192. In this case the offering > > >  party will have to reject the negotiation. So a reject=
> > >  message is needed in this case also. "
> >
> > There is NO need for any REJECT in the above case. If the initiat= or
> > is'nt satisfied with the value returned by the originator and can= not
> > function with the negotiated values, it can simply close the TCP<= br> > > connection. There is no need to send any REJECT.
> >
> > Thanks,
> > Santosh
> >
> > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> > >
> > > Thanks Julian, please find my further comments in the messag= e
> > >
> > >      -----Original Message-----
> > >      From: Julian Satran [mailto:Julian=5FSat= ran@il.ibm.com]
> > >      Sent: Sunday, September 30, 2001 6:07 PM=
> > >      To: ips@ece.cmu.edu
> > >      Subject: RE: iscsi : numerical negotiati= on wording is
> > >      ambiguous
> > >
> > >      Sanjeev,
> > >
> > >      I am not sure clear I made the tiny dife= rence between what I
> > >      say and what Santosh said:
> > >
> > >      Santosh says:
> > >
> > >        1. a requester sends A=3Dvaluex > > >        2. a responder sends B=3Dvaluey > > >        3. the responder assumes that the= value y is the correct
> > >           value and so does an exte= rnal observer
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] I would rather
> > >           say it this way the respo= nder computes the value with
> > >           its own supported values = and responds with a value y
> > >           which the responder think= s is correct and so does an
> > >           external observer
> > >        4. the requester checks that valu= ey is conformant (he will
> > >           not believe it) and will = reject it if not conformant
> > >           else it will accept it
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] Although correct,
> > >           but it is highly unlikely= for the responder to reject
> > >           the final result because = the rule states that (lower or
> > >           higher of two will be the= result) and so the offering
> > >           party should be able to a= ccept the lower or higher
> > >           range as defined by rule.= In case the key is dependent
> > >           upon some range of fixed = values then the negotiation
> > >           should be performed as li= st negotiation and not
> > >           numerical negotiation.
> > >
> > >           This might be what you &q= uot;conventionally" do - I don't
> > >           and that shows that conve= ntion like morals are a matter
> > >           of geography :-)
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] :-)
> > >
> > >           The advantage of this set= of rules is that it allows an
> > >           external observer to know= what was selected without
> > >           knowing the rules
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] Even in this
> > >           case, I guess that the ex= ternal observer has to know
> > >           the rules to double check= the value is correct or not
> > >           The disadvantage is that = messages have to be "built",
> > >           an additional reject stat= es exists and MOST IMPORTANT
> > >           you need both messages
> > >
> > >           In what I said:
> > >
> > >           1. The requester sends A= =3Dvaluex
> > >           2. The Responder has to s= end either nothing (if valuex
> > >           is enough on both sides t= o compute the result like in
> > >           the case in which the fun= ction 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 the= re is no reject, in binary
> > >           negotiations you can go a= way with shorter negotiations
> > >           and you can set strings a= t fixed values.
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] Although there is
> > >           no reject , but it can be= a problem in future .
> > >           Consider your example of = DataPDULength in your own
> > >           message. Suppose offering= party sends a value of 16,384
> > >           (this is also lowest valu= e it can send) and responding
> > >           party responds with 8,192= . In this case the offering
> > >           party will have to reject= the negotiation. So a reject
> > >           message is needed in this= case also.
> > >
> > >
> > >      Sanjeev
> > >       "Sanjeev Bhagat
> > >       (TRIPACE/Zoetermeer)"    = ;                To:     =    "'Santosh
> > Rao'"
> > >       <sbhagat@tripace.com>   &nbs= p;        <santoshr@cup.hp.com>, Julian
> > >       Sent by: owner-ips@ece.cmu.edu   S= atran/Haifa/IBM@IBMIL
> > >                 &nbs= p;                     &n= bsp;        cc:
> >  ips@ece.cmu.edu
> > >       30-09-01 16:32       &nb= sp;                   Subject:=        RE:
> > iscsi :
> > >       Please respond to "Sanjeev   =     numerical negotiation wording
> > is
> > >       Bhagat (TRIPACE/Zoetermeer)"  = ;   ambiguous
> > >
> > >
> > >
> > >      All,
> > >
> > >      I agree with Santosh that the responding= party must respond
> > >      the result of
> > >      the negotiation as compared with the val= ue from offering
> > >      party. All
> > >      negotiations in SCSI like (sync, disconn= ect etc) are also
> > >      done the same way.
> > >      I also object to Julian's reason of a si= mple 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 f= or target to reject
> > >      such a
> > >      negotiation and the default values be ac= cepted on both side
> > >      as a result of
> > >      negotiation.
> > >
> > >      1 Because even if simple minded target s= ends 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 val= ue 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 no= t negotiating but
> > >      forcing the result
> > >      on initiator(this method should not be a= llowed 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 re= sult 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 possi= ble to reject such
> > >      kind of
> > >      negotiaion?
> > >
> > >      Sanjeev
> > >
> > >      -----Original Message-----
> > >      From: Santosh Rao [mailto:santoshr@cup.h= p.com]
> > >      Sent: Friday, September 28, 2001 11:15 P= M
> > >      To: Julian Satran
> > >      Cc: ips@ece.cmu.edu
> > >      Subject: Re: iscsi : numerical negotiati= on 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 nego= tiation, 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 negoti= ation and the login
> > >      stage
> > >      negotiation follow the policy that the o= riginator offers a
> > >      value and the
> > >      responder picks the result of the negoti= ation based on (the
> > >      offered
> > >      value & its own value). The value pi= cked 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 picke= d.
> > >
> > >      2) The originator knows the negotiated r= esult at the the
> > >      responder since
> > >      the responder sends back the result of t= he negotiation.
> > >
> > >      3) This model is easier to debug because= of (1) & (2).
> > >
> > >      4) Less code since only 1 party (respond= er) needs to perform
> > >      the
> > >      computation to pick the result of the ne= gotiation.
> > >
> > >      5) This scheme leaves less room for inte= rop problems and
> > >      mis-interpretation since it is the more = familiar negotiation
> > >      technique
> > >      that is in use in most other mass storag= e protocols. (ex :
> > >      FC PLOGI, FC
> > >      PRLI, etc). From a first reading of the = current negotiation
> > >      scheme, it
> > >      is'nt readily apparent that the currentl= y defined model is
> > >      different
> > >      from the above and requires both sides t= o be picking the
> > >      result of the
> > >      negotiation, instead of just the respond= er.
> > >
> > >      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
> > ##################################

--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################
----- Forwarded by J= ulian Satran/Haifa/IBM on 04-10-01 18:56 -----
Santosh Rao <santoshr@cup.hp.c= om>
Sent by: owner-ips@ece.cmu.edu

03-10-01 18:26
Please respond to Santosh Rao

       
        To: &nbs= p;      Sandeep Joshi <sandeepj@research.bell-labs.com>= ;, Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      ips@ece.cmu.edu
        Subject:=        Re: iscsi : numerical negotiation wording is am= biguous

       


Julian,

Another value-add of the "responder picks the negotiation result model= "
is that the initiator can use the following "query based" negotia= tion
model to always use the values the target is capable of offering :

I -> T : DataPDULength=3D?
T -> I : DataPDULength=3D64K

Both sides agree to use a DataPDULength of 64K.

In the "both sides pick negotiation result" model, the above cann= ot be
achieved, since the initiator has to always offer a value.

Thus, in the "both sides pick negotiation result" model , the abo= ve
example would be :
I -> T : DataPDULength=3D8K
T -> I : DataPDULength=3D64K
I -> T : DataPDULength=3D64K
T -> I : DataPDULength=3D64K

Both sides settle at 64K.

I suggest that we allow the above "query based model", since this= is
more efficient to use when an initiator has no key limitations and would
like to use the value a target can offer. In order to allow the "query=
based model", you would need to state in the draft that a key value of=
"?" over-rides the default, implying the target offered value wou= ld be
the result of the negotiation.

In particular, the "query based model" is quite useful when an in= itiator
wishes to function with the target's maximal supported values for keys
like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T,
LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any
limitations on its own key value.

Comments ?

Thanks,
Santosh



Sandeep Joshi wrote:
>
> The first & third example below seem illogical.
>
> The responder should not be sending 24K if the initial
> sender has chosen a value of 16K, since there is no
> possibility of that 24K being accepted (unless we want
> three way exchanges for every negotiation??)
>
> The problem of a Reject message does not arise since the
> responder should only be choosing something less than 16K.
> So I guess this puts me in the "responder selects logic"
> camp.
>
> -Sandeep
>
> Julian Satran wrote:
> >
> > An example:
> >  08.txt logic
> > i->t DataPDULength=3D16k
> > t->i DataPDULength=3D 24k
> >
> > Selected value is 16k
> >
> > i->t DataPDULength=3D16k
> > t->i DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 24k
> >
> > Selected value is 16k
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> > -----
> >
> > Responder selects logic
> >
> > i->t DataPDULength=3D16k
> > t->i DataPDULength=3D 24k
> >
> > Error - Initiator Reject - Closes connection
> >
> > i->t DataPDULength=3D1= 6k
> > t->i DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 24k
> >
> > Error Target has to terminate with parameter error
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> >   "Dev - Platys"
> >   <deva@platys.com>          =      To:        "Julian Satran&quo= t;
> >                   &n= bsp;        <Julian=5FSatran@il.ibm.com>,
> >   01-10-01 23:46           <ips@= ece.cmu.edu>
> >   Please respond to "Dev -         = cc:
> >   Platys"             &nb= sp;            Subject:       =  RE: iscsi :
> >                   &n= bsp;        numerical negotiation wording is ambiguous<= br> > >
> >
> >
> > Julian,
> >
> > I am not sure why a 'REJECT' is required.
> > Can you please explain why is this required?
> >
> > I am with Santosh in this.
> >
> > >There is NO need for any REJECT in the above >case. If the= initiator
> > >is'nt satisfied with the value returned by the >originator= and cannot
> > >function with the negotiated values, it can simply >close = the TCP
> > >connection. There is no need to send any >REJECT.
> >
> > Thanks
> >
> > Deva
> > Adaptec
> >
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Beha= lf Of
> > Julian Satran
> > Sent: Monday, October 01, 2001 1:28 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iscsi : numerical negotiation wording is ambiguous > >
> > Santosh,
> >
> > We are getting nowhere. Even if requester is doing it's stuff - t= he
> > requester will have to check and be prepared for a mistake. The c= oding
> > will require a reject.
> >
> > Julo
> >
> >   Santosh Rao
> >   <santoshr@cup.hp.com>        To:=        ips@ece.cmu.edu
> >   Sent by:               =       cc:        "Sanjeev Bhagat
> >   santoshr@cup.hp.com   (TRIPACE/Zoetermeer)" <= sbhagat@tripace.com>,
> >                   &n= bsp;     Julian Satran/Haifa/IBM@IBMIL
> >   01-10-01 20:37             &= nbsp; Subject:        Re: iscsi : numerical
> >   Please respond to     negotiation wording is amb= iguous
> >   Santosh Rao
> >
> >
> > Julian & Sanjeev,
> >
> > Responding to both your mails......
> >
> > Julian :
> >
> > I think you may have mis-interpreted my comments. I believe Sanje= ev
> > has
> > clarified the intent of my suggestions.
> >
> > I am *not* suggesting that the responder send back its values and=
> > these
> > be blindly imposed on the originator. On the contrary, my suggest= ion
> > is
> > that the computation of the result of the negotiation (higher or = lower
> > of the 2 values) be only performed by the responder and sent back= to
> > the
> > originator.
> >
> > The result of the negotiation is the same in both cases and there= is
> > no
> > REJECT required in my case nor yours. The difference is the advan= tages
> > I've stated in my model.
> >
> > Sanjeev, in response to your comment :
> >
> > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> > >  no reject , but it can be a problem in future .
> > >  Consider your example of DataPDULength in your own
> > >  message. Suppose offering party sends a value of 16,38= 4
> > >  (this is also lowest value it can send) and responding=
> > >  party responds with 8,192. In this case the offering > > >  party will have to reject the negotiation. So a reject=
> > >  message is needed in this case also. "
> >
> > There is NO need for any REJECT in the above case. If the initiat= or
> > is'nt satisfied with the value returned by the originator and can= not
> > function with the negotiated values, it can simply close the TCP<= br> > > connection. There is no need to send any REJECT.
> >
> > Thanks,
> > Santosh
> >
> > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> > >
> > > Thanks Julian, please find my further comments in the messag= e
> > >
> > >      -----Original Message-----
> > >      From: Julian Satran [mailto:Julian=5FSat= ran@il.ibm.com]
> > >      Sent: Sunday, September 30, 2001 6:07 PM=
> > >      To: ips@ece.cmu.edu
> > >      Subject: RE: iscsi : numerical negotiati= on wording is
> > >      ambiguous
> > >
> > >      Sanjeev,
> > >
> > >      I am not sure clear I made the tiny dife= rence between what I
> > >      say and what Santosh said:
> > >
> > >      Santosh says:
> > >
> > >        1. a requester sends A=3Dvaluex > > >        2. a responder sends B=3Dvaluey > > >        3. the responder assumes that the= value y is the correct
> > >           value and so does an exte= rnal observer
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] I would rather
> > >           say it this way the respo= nder computes the value with
> > >           its own supported values = and responds with a value y
> > >           which the responder think= s is correct and so does an
> > >           external observer
> > >        4. the requester checks that valu= ey is conformant (he will
> > >           not believe it) and will = reject it if not conformant
> > >           else it will accept it
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] Although correct,
> > >           but it is highly unlikely= for the responder to reject
> > >           the final result because = the rule states that (lower or
> > >           higher of two will be the= result) and so the offering
> > >           party should be able to a= ccept the lower or higher
> > >           range as defined by rule.= In case the key is dependent
> > >           upon some range of fixed = values then the negotiation
> > >           should be performed as li= st negotiation and not
> > >           numerical negotiation.
> > >
> > >           This might be what you &q= uot;conventionally" do - I don't
> > >           and that shows that conve= ntion like morals are a matter
> > >           of geography :-)
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] :-)
> > >
> > >           The advantage of this set= of rules is that it allows an
> > >           external observer to know= what was selected without
> > >           knowing the rules
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] Even in this
> > >           case, I guess that the ex= ternal observer has to know
> > >           the rules to double check= the value is correct or not
> > >           The disadvantage is that = messages have to be "built",
> > >           an additional reject stat= es exists and MOST IMPORTANT
> > >           you need both messages
> > >
> > >           In what I said:
> > >
> > >           1. The requester sends A= =3Dvaluex
> > >           2. The Responder has to s= end either nothing (if valuex
> > >           is enough on both sides t= o compute the result like in
> > >           the case in which the fun= ction 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 the= re is no reject, in binary
> > >           negotiations you can go a= way with shorter negotiations
> > >           and you can set strings a= t fixed values.
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] Although there is
> > >           no reject , but it can be= a problem in future .
> > >           Consider your example of = DataPDULength in your own
> > >           message. Suppose offering= party sends a value of 16,384
> > >           (this is also lowest valu= e it can send) and responding
> > >           party responds with 8,192= . In this case the offering
> > >           party will have to reject= the negotiation. So a reject
> > >           message is needed in this= case also.
> > >
> > >
> > >      Sanjeev
> > >       "Sanjeev Bhagat
> > >       (TRIPACE/Zoetermeer)"    = ;                To:     =    "'Santosh
> > Rao'"
> > >       <sbhagat@tripace.com>   &nbs= p;        <santoshr@cup.hp.com>, Julian
> > >       Sent by: owner-ips@ece.cmu.edu   S= atran/Haifa/IBM@IBMIL
> > >                 &nbs= p;                     &n= bsp;        cc:
> >  ips@ece.cmu.edu
> > >       30-09-01 16:32       &nb= sp;                   Subject:=        RE:
> > iscsi :
> > >       Please respond to "Sanjeev   =     numerical negotiation wording
> > is
> > >       Bhagat (TRIPACE/Zoetermeer)"  = ;   ambiguous
> > >
> > >
> > >
> > >      All,
> > >
> > >      I agree with Santosh that the responding= party must respond
> > >      the result of
> > >      the negotiation as compared with the val= ue from offering
> > >      party. All
> > >      negotiations in SCSI like (sync, disconn= ect etc) are also
> > >      done the same way.
> > >      I also object to Julian's reason of a si= mple 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 f= or target to reject
> > >      such a
> > >      negotiation and the default values be ac= cepted on both side
> > >      as a result of
> > >      negotiation.
> > >
> > >      1 Because even if simple minded target s= ends 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 val= ue 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 no= t negotiating but
> > >      forcing the result
> > >      on initiator(this method should not be a= llowed 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 re= sult 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 possi= ble to reject such
> > >      kind of
> > >      negotiaion?
> > >
> > >      Sanjeev
> > >
> > >      -----Original Message-----
> > >      From: Santosh Rao [mailto:santoshr@cup.h= p.com]
> > >      Sent: Friday, September 28, 2001 11:15 P= M
> > >      To: Julian Satran
> > >      Cc: ips@ece.cmu.edu
> > >      Subject: Re: iscsi : numerical negotiati= on 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 nego= tiation, 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 negoti= ation and the login
> > >      stage
> > >      negotiation follow the policy that the o= riginator offers a
> > >      value and the
> > >      responder picks the result of the negoti= ation based on (the
> > >      offered
> > >      value & its own value). The value pi= cked 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 picke= d.
> > >
> > >      2) The originator knows the negotiated r= esult at the the
> > >      responder since
> > >      the responder sends back the result of t= he negotiation.
> > >
> > >      3) This model is easier to debug because= of (1) & (2).
> > >
> > >      4) Less code since only 1 party (respond= er) needs to perform
> > >      the
> > >      computation to pick the result of the ne= gotiation.
> > >
> > >      5) This scheme leaves less room for inte= rop problems and
> > >      mis-interpretation since it is the more = familiar negotiation
> > >      technique
> > >      that is in use in most other mass storag= e protocols. (ex :
> > >      FC PLOGI, FC
> > >      PRLI, etc). From a first reading of the = current negotiation
> > >      scheme, it
> > >      is'nt readily apparent that the currentl= y defined model is
> > >      different
> > >      from the above and requires both sides t= o be picking the
> > >      result of the
> > >      negotiation, instead of just the respond= er.
> > >
> > >      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
> > ##################################

--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################
----- Forwarded by J= ulian Satran/Haifa/IBM on 04-10-01 18:56 -----
"Sanjeev Bhagat (TRIPACE/Zoe= termeer)" <sbhagat@tripace.com>
Sent by: owner-ips@ece.cmu.edu

04-10-01 00:27
Please respond to "Sanjeev Bhag= at (TRIPACE/Zoetermeer)"

       
        To: &nbs= p;      "'Dev - Platys'" <deva@platys.com>, = Sandeep Joshi <sandeepj@research.bell-labs.com>, ips@ece.cmu.edu
        cc: &nbs= p;      
        Subject:=        RE: iscsi : numerical negotiation offering part= y based computaion         vs  responder based

       


All,

Sorry for those who cannot view Excel sheet. you can view the file at the link
http://www.radhekrishna.org/iSCSI/numeric=5Fnego=5Fcomparison.htm

Please dont blame me for my ugly site. It was a very half hearted attempt from me long ago. And I am sorry I cant put it on the company website now because our system guy has left for the day.

Sanjeev

-----Original Message-----
From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com]
Sent: Wednesday, October 03, 2001 10:44 PM
To: 'Dev - Platys'; Sandeep Joshi; ips@ece.cmu.edu
Subject: iscsi : numerical negotiation offering party based computaion
vs responder based


Hello all,

i just changed the name of the thread, because the thread is now taking
different directions.

I am attaching an excel file here in which i have taken 7 different cases t= o
show how there could be some mis interpretation when offering party compute= s
the individual results. I have taken the example of dataPDuSize because i started making my table with this although there is a different thread goin= g
on to it whether it should be kept in numerical negotiation or not.

In the table I have tried to take cases where the initiator and target may<= br> not support some PDU sizes which are lower than the maximum PDU size they support.

Deva: it also tells when a reject might be needed.

Regards,
Sanjeev

-----Original Message-----
From: Dev - Platys [mailto:deva@platys.com]
Sent: Wednesday, October 03, 2001 6:14 PM
To: Sandeep Joshi; ips@ece.cmu.edu
Subject: RE: iscsi : numerical negotiation wording is ambiguous


Santosh,

The point is, if the target is not capable of supporting 16K (it is just an=
example that is being discussed), then it indicates that is what it wants.<= br> Initiator can close the connection. (No reject is necessary though).

However, if the target knows it can support the initiator negotiated value,=
it could return it.

Again, Yes, implicitly it becomes the responder selects logic.

Deva
Adaptec


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Sandeep Joshi
Sent: Wednesday, October 03, 2001 7:29 AM
To: ips@ece.cmu.edu
Subject: Re: iscsi : numerical negotiation wording is ambiguous



The first & third example below seem illogical.

The responder should not be sending 24K if the initial
sender has chosen a value of 16K, since there is no
possibility of that 24K being accepted (unless we want
three way exchanges for every negotiation??)  

The problem of a Reject message doe= s not arise since the
responder should only be choosing something less than 16K.
So I guess this puts me in the "responder selects logic"
camp.

-Sandeep


Julian Satran wrote:
>
> An example:
>  08.txt logic
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 24k
>
> Selected value is 16k
>
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 8k
>
> Selected value is 8k
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 24k
>
> Selected value is 16k
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 8k
>
> Selected value is 8k
>
> -----
>
> Responder selects logic
>
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 24k
>
> Error - Initiator Reject - Closes connection
>
> i->t DataPDULength=3D16k
> t->i DataPDULength=3D 8k
>
> Selected value is 8k
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 24k
>
> Error Target has to terminate with parameter error
>
> t->i DataPDULength=3D16k
> i->t DataPDULength=3D 8k
>
> Selected value is 8k
>
>   "Dev - Platys"
>   <deva@platys.com>           &nbs= p;    To:        "Julian Satran"
>                     =        <Julian=5FSatran@il.ibm.com>,
>   01-10-01 23:46           <ips@ece.c= mu.edu>
>   Please respond to "Dev -         cc: >   Platys"               &= nbsp;          Subject:        = ;RE: iscsi :
>                     =        numerical negotiation wording is ambiguous
>
>
>
> Julian,
>
> I am not sure why a 'REJECT' is required.
> Can you please explain why is this required?
>
> I am with Santosh in this.
>
> >There is NO need for any REJECT in the above >case. If the init= iator
> >is'nt satisfied with the value returned by the >originator and = cannot
> >function with the negotiated values, it can simply >close the T= CP
> >connection. There is no need to send any >REJECT.
>
> Thanks
>
> Deva
> Adaptec
>
> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of=
> Julian Satran
> Sent: Monday, October 01, 2001 1:28 PM
> To: ips@ece.cmu.edu
> Subject: Re: iscsi : numerical negotiation wording is ambiguous
>
> Santosh,
>
> We are getting nowhere. Even if requester is doing it's stuff - the
> requester will have to check and be prepared for a mistake. The coding=
> will require a reject.
>
> Julo
>
>   Santosh Rao
>   <santoshr@cup.hp.com>        To: &nbs= p;      ips@ece.cmu.edu
>   Sent by:                = ;     cc:        "Sanjeev Bhagat
>   santoshr@cup.hp.com   (TRIPACE/Zoetermeer)" <sbhag= at@tripace.com>,
>                     =     Julian Satran/Haifa/IBM@IBMIL
>   01-10-01 20:37              = Subject:        Re: iscsi : numerical
>   Please respond to     negotiation wording is ambiguou= s
>   Santosh Rao
>
>
> Julian & Sanjeev,
>
> Responding to both your mails......
>
> Julian :
>
> I think you may have mis-interpreted my comments. I believe Sanjeev
> has
> clarified the intent of my suggestions.
>
> I am *not* suggesting that the responder send back its values and
> these
> be blindly imposed on the originator. On the contrary, my suggestion > is
> that the computation of the result of the negotiation (higher or lower=
> of the 2 values) be only performed by the responder and sent back to > the
> originator.
>
> The result of the negotiation is the same in both cases and there is > no
> REJECT required in my case nor yours. The difference is the advantages=
> I've stated in my model.
>
> Sanjeev, in response to your comment :
>
> " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> >  no reject , but it can be a problem in future .
> >  Consider your example of DataPDULength in your own
> >  message. Suppose offering party sends a value of 16,384
> >  (this is also lowest value it can send) and responding
> >  party responds with 8,192. In this case the offering
> >  party will have to reject the negotiation. So a reject
> >  message is needed in this case also. "
>
> There is NO need for any REJECT in the above case. If the initiator
> is'nt satisfied with the value returned by the originator and cannot > function with the negotiated values, it can simply close the TCP
> connection. There is no need to send any REJECT.
>
> Thanks,
> Santosh
>
> > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> >
> > Thanks Julian, please find my further comments in the message
> >
> >      -----Original Message-----
> >      From: Julian Satran [mailto:Julian=5FSatran@i= l.ibm.com]
> >      Sent: Sunday, September 30, 2001 6:07 PM
> >      To: ips@ece.cmu.edu
> >      Subject: RE: iscsi : numerical negotiation wo= rding is
> >      ambiguous
> >
> >      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=3Dvaluex
> >        2. a responder sends B=3Dvaluey
> >        3. the responder assumes that the valu= e y is the correct
> >           value and so does an external = observer
> >           [Sanjeev Bhagat (TRIPACE/Zoete= rmeer)] I would rather
> >           say it this way the responder = computes the value with
> >           its own supported values and r= esponds with a value y
> >           which the responder thinks is = correct and so does an
> >           external observer
> >        4. the requester checks that valuey is= conformant (he will
> >           not believe it) and will rejec= t it if not conformant
> >           else it will accept it
> >           [Sanjeev Bhagat (TRIPACE/Zoete= rmeer)] Although correct,
> >           but it is highly unlikely for = the responder to reject
> >           the final result because the r= ule states that (lower or
> >           higher of two will be the resu= lt) and so the offering
> >           party should be able to accept= the lower or higher
> >           range as defined by rule. In c= ase the key is dependent
> >           upon some range of fixed value= s then the negotiation
> >           should be performed as list ne= gotiation and not
> >           numerical negotiation.
> >
> >           This might be what you "c= onventionally" do - I don't
> >           and that shows that convention= like morals are a matter
> >           of geography :-)
> >           [Sanjeev Bhagat (TRIPACE/Zoete= rmeer)] :-)
> >
> >           The advantage of this set of r= ules is that it allows an
> >           external observer to know what= was selected without
> >           knowing the rules
> >           [Sanjeev Bhagat (TRIPACE/Zoete= rmeer)] Even in this
> >           case, I guess that the externa= l observer has to know
> >           the rules to double check the = value is correct or not
> >           The disadvantage is that messa= ges have to be "built",
> >           an additional reject states ex= ists and MOST IMPORTANT
> >           you need both messages
> >
> >           In what I said:
> >
> >           1. The requester sends A=3Dval= uex
> >           2. The Responder has to send e= ither nothing (if valuex
> >           is enough on both sides to com= pute 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 resp= onder have to compute the
> >           value (they have to know the r= ules anyhow) and so does
> >           the external observer
> >
> >           The disadvantage is that the e= xternal observer has to
> >           know the rules
> >           The advantage is that there is= no reject, in binary
> >           negotiations you can go away w= ith shorter negotiations
> >           and you can set strings at fix= ed values.
> >           [Sanjeev Bhagat (TRIPACE/Zoete= rmeer)] Although there is
> >           no reject , but it can be a pr= oblem in future .
> >           Consider your example of DataP= DULength in your own
> >           message. Suppose offering part= y sends a value of 16,384
> >           (this is also lowest value it = can send) and responding
> >           party responds with 8,192. In = this case the offering
> >           party will have to reject the = negotiation. So a reject
> >           message is needed in this case= also.
> >
> >
> >      Sanjeev
> >       "Sanjeev Bhagat
> >       (TRIPACE/Zoetermeer)"     &nb= sp;              To:      = ;  "'Santosh
> Rao'"
> >       <sbhagat@tripace.com>     &n= bsp;      <santoshr@cup.hp.com>, Julian
> >       Sent by: owner-ips@ece.cmu.edu   Satran= /Haifa/IBM@IBMIL
> >                   &n= bsp;                     =        cc:
>  ips@ece.cmu.edu
> >       30-09-01 16:32         &= nbsp;                 Subject: &nbs= p;      RE:
> iscsi :
> >       Please respond to "Sanjeev    = ;   numerical negotiation wording
> is
> >       Bhagat (TRIPACE/Zoetermeer)"   &nb= sp; ambiguous
> >
> >
> >
> >      All,
> >
> >      I agree with Santosh that the responding part= y must respond
> >      the result of
> >      the negotiation as compared with the value fr= om offering
> >      party. All
> >      negotiations in SCSI like (sync, disconnect e= tc) 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 sim= ple 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 ta= rget to reject
> >      such a
> >      negotiation and the default values be accepte= d 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 wi= ll 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 neg= otiating but
> >      forcing the result
> >      on initiator(this method should not be allowe= d unless
> >      explicitly mentioned).
> >
> >      however if there is another proposal of numer= ic negotiation
> >      in which the
> >      responding party can force its result to be o= ver ridden by
> >      the offering
> >      party's result then it is acceptable for offe= ring 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 d= o not see how a
> >      numeric
> >      negotiation can be rejected. Is it possible t= o 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 wo= rding is
> >      ambiguous
> >
> >      Julian & All,
> >
> >      I request the group to take a close look at t= his negotiation
> >      process
> >      again and [re-]evaluate the alternative being= proposed.
> >
> >      Further, it appears that the login stage nego= tiation  is
> >      also following
> >      the same algorithm as the login key negotiati= on, wherein
> >      originator &
> >      responder offer their respective values and b= oth sides need
> >      to determine
> >      the result of the negotiation. i.e. both init= iator 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 origin= ator 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 nego= tiaton. 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 ne= gotiation.
> >
> >      3) This model is easier to debug because of (= 1) & (2).
> >
> >      4) Less code since only 1 party (responder) n= eeds to perform
> >      the
> >      computation to pick the result of the negotia= tion.
> >
> >      5) This scheme leaves less room for interop p= roblems and
> >      mis-interpretation since it is the more famil= iar negotiation
> >      technique
> >      that is in use in most other mass storage pro= tocols. (ex :
> >      FC PLOGI, FC
> >      PRLI, etc). From a first reading of the curre= nt negotiation
> >      scheme, it
> >      is'nt readily apparent that the currently def= ined 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
> >
>
> --
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : santoshr@cup.hp.com
> Phone : 408-447-3751
> ##################################
----- Forwarded by J= ulian Satran/Haifa/IBM on 04-10-01 18:56 -----
"ERICKSON,SHAWN (HP-Rosevill= e,ex1)" <shawn=5Ferickson@hp.com>
Sent by: owner-ips@ece.cmu.edu

04-10-01 01:48
Please respond to "ERICKSON,SHA= WN (HP-Roseville,ex1)"

       
        To: &nbs= p;      "'Santosh Rao'" <santoshr@cup.hp.com>= ;, Sandeep Joshi <sandeepj@research.bell-labs.com>, Julian Satran/Hai= fa/IBM@IBMIL
        cc: &nbs= p;      ips@ece.cmu.edu
        Subject:=        RE: iscsi : numerical negotiation wording is am= biguous

       


> Another value-add of the "= ;responder picks the negotiation
> result model"
> is that the initiator can use the following "query based" ne= gotiation
> model to always use the values the target is capable of offering :
>
> I -> T : DataPDULength=3D?
> T -> I : DataPDULength=3D64K
>
> Both sides agree to use a DataPDULength of 64K.

I like the idea!


-------------------------------------------------------
Shawn Carl Erickson           (805) 883-4319 [Tel= net]
Hewlett Packard Company         OV NSSO Joint Venture<= br>  Storage Resource Management R&D Lab (Santa Barbara)
-------------------------------------------------------
           <http://ecardfile.com/id/shawn= ce>
-------------------------------------------------------
----- Forwarded by J= ulian Satran/Haifa/IBM on 04-10-01 18:56 -----
"ERICKSON,SHAWN (HP-Rosevill= e,ex1)" <shawn=5Ferickson@hp.com>
Sent by: owner-ips@ece.cmu.edu

04-10-01 01:46
Please respond to "ERICKSON,SHA= WN (HP-Roseville,ex1)"

       
        To: &nbs= p;      ips@ece.cmu.edu
        cc: &nbs= p;      
        Subject:=        RE: iscsi : numerical negotiation wording is am= biguous

       


> The first & third example = below seem illogical.

I agree.

> So I guess this puts me in the "responder selects logic"
> camp.

Same here.

-Shawn

-------------------------------------------------------
Shawn Carl Erickson           (805) 883-4319 [Tel= net]
Hewlett Packard Company         OV NSSO Joint Venture<= br>  Storage Resource Management R&D Lab (Santa Barbara)
-------------------------------------------------------
           <http://ecardfile.com/id/shawn= ce>
-------------------------------------------------------



> -----Original Message-----
> From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com]
> Sent: Wednesday, October 03, 2001 7:29 AM
> To: ips@ece.cmu.edu
> Subject: Re: iscsi : numerical negotiation wording is ambiguous
>
>
>
> The first & third example below seem illogical.
>
> The responder should not be sending 24K if the initial
> sender has chosen a value of 16K, since there is no
> possibility of that 24K being accepted (unless we want
> three way exchanges for every negotiation??)  
>
> The problem of a Reject message does not arise since the
> responder should only be choosing something less than 16K.
> So I guess this puts me in the "responder selects logic"
> camp.
>
> -Sandeep
>
>
> Julian Satran wrote:
> >
> > An example:
> >  08.txt logic
> > i->t DataPDULength=3D16k
> > t->i DataPDULength=3D 24k
> >
> > Selected value is 16k
> >
> > i->t DataPDULength=3D16k
> > t->i DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 24k
> >
> > Selected value is 16k
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> > -----
> >
> > Responder selects logic
> >
> > i->t DataPDULength=3D16k
> > t->i DataPDULength=3D 24k
> >
> > Error - Initiator Reject - Closes connection
> >
> > i->t DataPDULength=3D16k
> > t->i DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 24k
> >
> > Error Target has to terminate with parameter error
> >
> > t->i DataPDULength=3D16k
> > i->t DataPDULength=3D 8k
> >
> > Selected value is 8k
> >
> >   "Dev - Platys"
> >   <deva@platys.com>          =      To:        "Julian Satran&quo= t;
> >       &nbs= p;                    <= ;Julian=5FSatran@il.ibm.com>,
> >   01-10-01 23:46           <ips@= ece.cmu.edu>
> >   Please respond to "Dev -         = cc:
> >   Platys"             &nb= sp;            Subject:       =  RE: iscsi :
> >                   &n= bsp;        numerical negotiation wording is
> ambiguous
> >
> >
> >
> > Julian,
> >
> > I am not sure why a 'REJECT' is required.
> > Can you please explain why is this required?
> >
> > I am with Santosh in this.
> >
> > >There is NO need for any REJECT in the above >case. If the=
> initiator
> > >is'nt satisfied with the value returned by the >originator=
> and cannot
> > >function with the negotiated values, it can simply >close = the TCP
> > >connection. There is no need to send any >REJECT.
> >
> > Thanks
> >
> > Deva
> > Adaptec
> >
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu
> [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Julian Satran
> > Sent: Monday, October 01, 2001 1:28 PM
> > To: ips@ece.cmu.edu
> > Subject: Re: iscsi : numerical negotiation wording is ambiguous > >
> > Santosh,
> >
> > We are getting nowhere. Even if requester is doing it's stuff - t= he
> > requester will have to check and be prepared for a mistake.
> The coding
> > will require a reject.
> >
> > Julo
> >
> >   Santosh Rao
> >   <santoshr@cup.hp.com>        To:=        ips@ece.cmu.edu
> >   Sent by:               =       cc:        "Sanjeev Bhagat
> >   santoshr@cup.hp.com   (TRIPACE/Zoetermeer)" <= sbhagat@tripace.com>,
> >                   &n= bsp;     Julian Satran/Haifa/IBM@IBMIL
> >   01-10-01 20:37             &= nbsp; Subject:        Re: iscsi : numerical
> >   Please respond to     negotiation wording is amb= iguous
> >   Santosh Rao
> >
> >
> > Julian & Sanjeev,
> >
> > Responding to both your mails......
> >
> > Julian :
> >
> > I think you may have mis-interpreted my comments. I believe Sanje= ev
> > has
> > clarified the intent of my suggestions.
> >
> > I am *not* suggesting that the responder send back its values and=
> > these
> > be blindly imposed on the originator. On the contrary, my suggest= ion
> > is
> > that the computation of the result of the negotiation
> (higher or lower
> > of the 2 values) be only performed by the responder and sent back= to
> > the
> > originator.
> >
> > The result of the negotiation is the same in both cases and there= is
> > no
> > REJECT required in my case nor yours. The difference is the
> advantages
> > I've stated in my model.
> >
> > Sanjeev, in response to your comment :
> >
> > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> > >  no reject , but it can be a problem in future .
> > >  Consider your example of DataPDULength in your own
> > >  message. Suppose offering party sends a value of 16,38= 4
> > >  (this is also lowest value it can send) and responding=
> > >  party responds with 8,192. In this case the offering > > >  party will have to reject the negotiation. So a reject=
> > >  message is needed in this case also. "
> >
> > There is NO need for any REJECT in the above case. If the initiat= or
> > is'nt satisfied with the value returned by the originator and can= not
> > function with the negotiated values, it can simply close the TCP<= br> > > connection. There is no need to send any REJECT.
> >
> > Thanks,
> > Santosh
> >
> > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> > >
> > > Thanks Julian, please find my further comments in the messag= e
> > >
> > >      -----Original Message-----
> > >      From: Julian Satran [mailto:Julian=5FSat= ran@il.ibm.com]
> > >      Sent: Sunday, September 30, 2001 6:07 PM=
> > >      To: ips@ece.cmu.edu
> > >      Subject: RE: iscsi : numerical negotiati= on wording is
> > >      ambiguous
> > >
> > >      Sanjeev,
> > >
> > >      I am not sure clear I made the tiny dife= rence between what I
> > >      say and what Santosh said:
> > >
> > >      Santosh says:
> > >
> > >        1. a requester sends A=3Dvaluex > > >        2. a responder sends B=3Dvaluey > > >        3. the responder assumes that the= value y is the correct
> > >           value and so does an exte= rnal observer
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] I would rather
> > >           say it this way the respo= nder computes the value with
> > >           its own supported values = and responds with a value y
> > >           which the responder think= s is correct and so does an
> > >           external observer
> > >        4. the requester checks that valu= ey is conformant (he will
> > >           not believe it) and will = reject it if not conformant
> > >           else it will accept it
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] Although correct,
> > >           but it is highly unlikely= for the responder to reject
> > >           the final result because = the rule states that (lower or
> > >           higher of two will be the= result) and so the offering
> > >           party should be able to a= ccept the lower or higher
> > >           range as defined by rule.= In case the key is dependent
> > >           upon some range of fixed = values then the negotiation
> > >           should be performed as li= st negotiation and not
> > >           numerical negotiation.
> > >
> > >           This might be what you &q= uot;conventionally" do - I don't
> > >           and that shows that conve= ntion like morals are a matter
> > >           of geography :-)
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] :-)
> > >
> > >           The advantage of this set= of rules is that it allows an
> > >           external observer to know= what was selected without
> > >           knowing the rules
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] Even in this
> > >           case, I guess that the ex= ternal observer has to know
> > >           the rules to double check= the value is correct or not
> > >           The disadvantage is that = messages have to be "built",
> > >           an additional reject stat= es exists and MOST IMPORTANT
> > >           you need both messages
> > >
> > >           In what I said:
> > >
> > >           1. The requester sends A= =3Dvaluex
> > >           2. The Responder has to s= end either nothing (if valuex
> > >           is enough on both sides t= o compute the result like in
> > >           the case in which the fun= ction 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 the= re is no reject, in binary
> > >           negotiations you can go a= way with shorter negotiations
> > >           and you can set strings a= t fixed values.
> > >           [Sanjeev Bhagat (TRIPACE/= Zoetermeer)] Although there is
> > >           no reject , but it can be= a problem in future .
> > >           Consider your example of = DataPDULength in your own
> > >           message. Suppose offering= party sends a value of 16,384
> > >           (this is also lowest valu= e it can send) and responding
> > >           party responds with 8,192= . In this case the offering
> > >           party will have to reject= the negotiation. So a reject
> > >           message is needed in this= case also.
> > >
> > >
> > >      Sanjeev
> > >       "Sanjeev Bhagat
> > >       (TRIPACE/Zoetermeer)"    = ;                To:     =    
> "'Santosh
> > Rao'"
> > >       <sbhagat@tripace.com>   &nbs= p;        
> <santoshr@cup.hp.com>, Julian
> > >       Sent by: owner-ips@ece.cmu.edu   S= atran/Haifa/IBM@IBMIL
> > >                 &nbs= p;                     &n= bsp;        cc:
> >  ips@ece.cmu.edu
> > >       30-09-01 16:32       &nb= sp;                   Subject:=        RE:
> > iscsi :
> > >       Please respond to "Sanjeev   =     numerical
> negotiation wording
> > is
> > >       Bhagat (TRIPACE/Zoetermeer)"  = ;   ambiguous
> > >
> > >
> > >
> > >      All,
> > >
> > >      I agree with Santosh that the responding= party must respond
> > >      the result of
> > >      the negotiation as compared with the val= ue from offering
> > >      party. All
> > >      negotiations in SCSI like (sync, disconn= ect etc) are also
> > >      done the same way.
> > >      I also object to Julian's reason of a si= mple 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 f= or target to reject
> > >      such a
> > >      negotiation and the default values be ac= cepted on both side
> > >      as a result of
> > >      negotiation.
> > >
> > >      1 Because even if simple minded target s= ends 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 val= ue 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 no= t negotiating but
> > >      forcing the result
> > >      on initiator(this method should not be a= llowed 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 re= sult 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 possi= ble to reject such
> > >      kind of
> > >      negotiaion?
> > >
> > >      Sanjeev
> > >
> > >      -----Original Message-----
> > >      From: Santosh Rao [mailto:santoshr@cup.h= p.com]
> > >      Sent: Friday, September 28, 2001 11:15 P= M
> > >      To: Julian Satran
> > >      Cc: ips@ece.cmu.edu
> > >      Subject: Re: iscsi : numerical negotiati= on 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 nego= tiation, 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 negoti= ation and the login
> > >      stage
> > >      negotiation follow the policy that the o= riginator offers a
> > >      value and the
> > >      responder picks the result of the negoti= ation based on (the
> > >      offered
> > >      value & its own value). The value pi= cked 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 picke= d.
> > >
> > >      2) The originator knows the negotiated r= esult at the the
> > >      responder since
> > >      the responder sends back the result of t= he negotiation.
> > >
> > >      3) This model is easier to debug because= of (1) & (2).
> > >
> > >      4) Less code since only 1 party (respond= er) needs to perform
> > >      the
> > >      computation to pick the result of the ne= gotiation.
> > >
> > >      5) This scheme leaves less room for inte= rop problems and
> > >      mis-interpretation since it is the more = familiar negotiation
> > >      technique
> > >      that is in use in most other mass storag= e protocols. (ex :
> > >      FC PLOGI, FC
> > >      PRLI, etc). From a first reading of the = current negotiation
> > >      scheme, it
> > >      is'nt readily apparent that the currentl= y defined model is
> > >      different
> > >      from the above and requires both sides t= o be picking the
> > >      result of the
> > >      negotiation, instead of just the respond= er.
> > >
> > >      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
> > ##################################
>

----- Forwarded by J= ulian Satran/Haifa/IBM on 04-10-01 18:56 -----
"ERICKSON,SHAWN (HP-Rosevill= e,ex1)" <shawn=5Ferickson@hp.com>

04-10-01 01:48
Please respond to "ERICKSON,SHA= WN (HP-Roseville,ex1)"

       
        To: &nbs= p;      "'Santosh Rao'" <santoshr@cup.hp.com>= ;, Sandeep Joshi <sandeepj@research.bell-labs.com>, Julian Satran/Hai= fa/IBM@IBMIL
        cc: &nbs= p;      ips@ece.cmu.edu
        Subject:=        RE: iscsi : numerical negotiation wording is am= biguous

       


> Another value-add of the "= ;responder picks the negotiation
> result model"
> is that the initiator can use the following "query based" ne= gotiation
> model to always use the values the target is capable of offering :
>
> I -> T : DataPDULength=3D?
> T -> I : DataPDULength=3D64K
>
> Both sides agree to use a DataPDULength of 64K.

I like the idea!


-------------------------------------------------------
Shawn Carl Erickson           (805) 883-4319 [Tel= net]
Hewlett Packard Company         OV NSSO Joint Venture<= br>  Storage Resource Management R&D Lab (Santa Barbara)
-------------------------------------------------------
           <http://ecardfile.com/id/shawn= ce>
-------------------------------------------------------
----- Forwarded by J= ulian Satran/Haifa/IBM on 04-10-01 18:56 -----
John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

04-10-01 07:57
Please respond to John Hufferd

       
        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      ips@ece.cmu.edu
        Subject:=        RE: iscsi : numerical negotiation wording is am= biguous

       



Julian,
I find your response troubling, perhaps I did not understand what you
intended to say.  Comments below.


.
.
.
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 10/03/2001 05:26:58 AM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iscsi : numerical negotiation wording is ambiguous




An example:
=A008.txt logic
i->t DataPDULength=3D16k
t->i DataPDULength=3D 24k

Selected value is 16k

[Huff] If target knows that the Initiator wants 16k, and therefore that its=
24k is not going to be accepted, why did the Target send 24K? [/Huff]

i->t DataPDULength=3D16k
t->i DataPDULength=3D 8k

Selected value is 8k

t->i DataPDULength=3D16k
i->t DataPDULength=3D 24k

Selected value is 16k

[Huff] If Initiator knows that the target wants 16k, and therefore that its=
24k is not going to be accepted, why did the Initiator send 24K? [/Huff]


t->i DataPDULength=3D16k
i->t DataPDULength=3D 8k

Selected value is 8k

-----

Responder selects logic

i->t DataPDULength=3D16k
t->i DataPDULength=3D 24k

Error - Initiator Reject - Closes connection

i->t DataPDULength=3D16k
t->i DataPDULength=3D 8k

Selected value is 8k

t->i DataPDULength=3D16k
i->t DataPDULength=3D 24k

Error Target has to terminate with parameter error

t->i DataPDULength=3D16k
i->t DataPDULength=3D 8k

Selected value is 8k




                    &nbs= p;                     &n= bsp;                     =            
                    &nbs= p;       "Dev - Platys"        = ;                     &nb= sp;  
                    &nbs= p;       <deva@platys.com>        = =A0 =A0 =A0 =A0 To:          
                    &nbs= p;                     &n= bsp;          "Julian Satran"   &nb= sp;  
                    &nbs= p;       01-10-01 23:46           &= lt;Julian=5FSatran@il.ibm
                    &nbs= p;       Please respond to        .com&g= t;,                
                    &nbs= p;       "Dev - Platys"        = ;   <ips@ece.cmu.edu>    
                    &nbs= p;                     &n= bsp;          =A0 =A0 =A0 =A0 cc:     &n= bsp;    
                    &nbs= p;                     &n= bsp;          =A0 =A0 =A0 =A0 Subject:   &nbs= p;  
                    &nbs= p;                     &n= bsp;          RE: iscsi : numerical
          =                      = ;                     &nb= sp; negotiation wording  
                    &nbs= p;                     &n= bsp;          is ambiguous       &n= bsp;  
                    &nbs= p;                     &n= bsp;                     =            
                    &nbs= p;                     &n= bsp;                     =            
                    &nbs= p;                     &n= bsp;                     =            



Julian,

I am not sure why a 'REJECT' is required.
Can you please explain why is this required?

I am with Santosh in this.

>There is NO need for any REJECT in the above >case. If the initiator=
>is'nt satisfied with the value returned by the >originator and canno= t
>function with the negotiated values, it can simply >close the TCP
>connection. There is no need to send any >REJECT.

Thanks

Deva
Adaptec


-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Monday, October 01, 2001 1:28 PM
To: ips@ece.cmu.edu
Subject: Re: iscsi : numerical negotiation wording is ambiguous


Santosh,

We are getting nowhere. Even if requester is doing it's stuff - the
requester will have to check and be prepared for a mistake. The coding will=
require a reject.

Julo

                    &nbs= p;                     &n= bsp;                     =          
     Santosh Rao             =                      = ;                     &nb= sp;  
     <santoshr@cup.hp.c       =A0 =A0 =A0= =A0To: =A0 =A0 =A0 =A0ips@ece.cmu.edu           <= br>      om>              = ;        =A0 =A0 =A0 =A0cc: =A0 =A0 =A0 =A0"Sanjee= v Bhagat          
     Sent by:             &nb= sp;   (TRIPACE/Zoetermeer)"           &n= bsp;          
     santoshr@cup.hp.co       <sbhagat@tr= ipace.com>, Julian              
     m               &nb= sp;        Satran/Haifa/IBM@IBMIL       =                
                    &nbs= p;         =A0 =A0 =A0 =A0Subject: =A0 =A0 =A0 =A0Re: i= scsi :          
     01-10-01 20:37           nume= rical negotiation wording is ambiguous  
     Please respond to           &= nbsp;                    =                    
     Santosh Rao             =                      = ;                     &nb= sp;  
                    &nbs= p;                     &n= bsp;                     =          




Julian & Sanjeev,

Responding to both your mails......

Julian :

I think you may have mis-interpreted my comments. I believe Sanjeev has
clarified the intent of my suggestions.

I am *not* suggesting that the responder send back its values and these
be blindly imposed on the originator. On the contrary, my suggestion is
that the computation of the result of the negotiation (higher or lower
of the 2 values) be only performed by the responder and sent back to the
originator.

The result of the negotiation is the same in both cases and there is no
REJECT required in my case nor yours. The difference is the advantages
I've stated in my model.


Sanjeev, in response to your comment :

" [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
> =A0no reject , but it can be a problem in future .
> =A0Consider your example of DataPDULength in your own
> =A0message. Suppose offering party sends a value of 16,384
> =A0(this is also lowest value it can send) and responding
> =A0party responds with 8,192. In this case the offering
> =A0party will have to reject the negotiation. So a reject
> =A0message is needed in this case also. "


There is NO need for any REJECT in the above case. If the initiator
is'nt satisfied with the value returned by the originator and cannot
function with the negotiated values, it can simply close the TCP
connection. There is no need to send any REJECT.


Thanks,
Santosh


> "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
>
> Thanks Julian, please find my further comments in the message
>
> =A0 =A0 =A0-----Original Message-----
> =A0 =A0 =A0From: Julian Satran [mailto:Julian=5FSatran@il.ibm.com]
> =A0 =A0 =A0Sent: Sunday, September 30, 2001 6:07 PM
> =A0 =A0 =A0To: ips@ece.cmu.edu
> =A0 =A0 =A0Subject: RE: iscsi : numerical negotiation wording is
> =A0 =A0 =A0ambiguous
>
> =A0 =A0 =A0Sanjeev,
>
> =A0 =A0 =A0I am not sure clear I made the tiny diference between what = I
> =A0 =A0 =A0say and what Santosh said:
>
> =A0 =A0 =A0Santosh says:
>
> =A0 =A0 =A0 =A01. a requester sends A=3Dvaluex
> =A0 =A0 =A0 =A02. a responder sends B=3Dvaluey
> =A0 =A0 =A0 =A03. the responder assumes that the value y is the correc= t
> =A0 =A0 =A0 =A0 =A0 value and so does an external observer
> =A0 =A0 =A0 =A0 =A0 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rath= er
> =A0 =A0 =A0 =A0 =A0 say it this way the responder computes the value w= ith
> =A0 =A0 =A0 =A0 =A0 its own supported values and responds with a value= y
> =A0 =A0 =A0 =A0 =A0 which the responder thinks is correct and so does = an
> =A0 =A0 =A0 =A0 =A0 external observer
> =A0 =A0 =A0 =A04. the requester checks that valuey is conformant (he w= ill
> =A0 =A0 =A0 =A0 =A0 not believe it) and will reject it if not conforma= nt
> =A0 =A0 =A0 =A0 =A0 else it will accept it
> =A0 =A0 =A0 =A0 =A0 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although cor= rect,
> =A0 =A0 =A0 =A0 =A0 but it is highly unlikely for the responder to rej= ect
> =A0 =A0 =A0 =A0 =A0 the final result because the rule states that (low= er or
> =A0 =A0 =A0 =A0 =A0 higher of two will be the result) and so the offer= ing
> =A0 =A0 =A0 =A0 =A0 party should be able to accept the lower or higher=
> =A0 =A0 =A0 =A0 =A0 range as defined by rule. In case the key is depen= dent
> =A0 =A0 =A0 =A0 =A0 upon some range of fixed values then the negotiati= on
> =A0 =A0 =A0 =A0 =A0 should be performed as list negotiation and not
> =A0 =A0 =A0 =A0 =A0 numerical negotiation.
>
> =A0 =A0 =A0 =A0 =A0 This might be what you "conventionally" = do - I don't
> =A0 =A0 =A0 =A0 =A0 and that shows that convention like morals are a m= atter
> =A0 =A0 =A0 =A0 =A0 of geography :-)
> =A0 =A0 =A0 =A0 =A0 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-)
>
> =A0 =A0 =A0 =A0 =A0 The advantage of this set of rules is that it allo= ws an
> =A0 =A0 =A0 =A0 =A0 external observer to know what was selected withou= t
> =A0 =A0 =A0 =A0 =A0 knowing the rules
> =A0 =A0 =A0 =A0 =A0 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this=
> =A0 =A0 =A0 =A0 =A0 case, I guess that the external observer has to kn= ow
> =A0 =A0 =A0 =A0 =A0 the rules to double check the value is correct or = not
> =A0 =A0 =A0 =A0 =A0 The disadvantage is that messages have to be "= ;built",
> =A0 =A0 =A0 =A0 =A0 an additional reject states exists and MOST IMPORT= ANT
> =A0 =A0 =A0 =A0 =A0 you need both messages
>
> =A0 =A0 =A0 =A0 =A0 In what I said:
>
> =A0 =A0 =A0 =A0 =A0 1. The requester sends A=3Dvaluex
> =A0 =A0 =A0 =A0 =A0 2. The Responder has to send either nothing (if va= luex
> =A0 =A0 =A0 =A0 =A0 is enough on both sides to compute the result like= in
> =A0 =A0 =A0 =A0 =A0 the case in which the function is a Boolean AND an= d the
> =A0 =A0 =A0 =A0 =A0 value is NO) or valuey
> =A0 =A0 =A0 =A0 =A0 3. Both the requestor and responder have to comput= e the
> =A0 =A0 =A0 =A0 =A0 value (they have to know the rules anyhow) and so = does
> =A0 =A0 =A0 =A0 =A0 the external observer
>
> =A0 =A0 =A0 =A0 =A0 The disadvantage is that the external observer has= to
> =A0 =A0 =A0 =A0 =A0 know the rules
> =A0 =A0 =A0 =A0 =A0 The advantage is that there is no reject, in binar= y
> =A0 =A0 =A0 =A0 =A0 negotiations you can go away with shorter negotiat= ions
> =A0 =A0 =A0 =A0 =A0 and you can set strings at fixed values.
> =A0 =A0 =A0 =A0 =A0 [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although the= re is
> =A0 =A0 =A0 =A0 =A0 no reject , but it can be a problem in future .
> =A0 =A0 =A0 =A0 =A0 Consider your example of DataPDULength in your own=
> =A0 =A0 =A0 =A0 =A0 message. Suppose offering party sends a value of 1= 6,384
> =A0 =A0 =A0 =A0 =A0 (this is also lowest value it can send) and respon= ding
> =A0 =A0 =A0 =A0 =A0 party responds with 8,192. In this case the offeri= ng
> =A0 =A0 =A0 =A0 =A0 party will have to reject the negotiation. So a re= ject
> =A0 =A0 =A0 =A0 =A0 message is needed in this case also.
>
>
> =A0 =A0 =A0Sanjeev
> =A0 =A0 =A0 "Sanjeev Bhagat
> =A0 =A0 =A0 (TRIPACE/Zoetermeer)" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0To: =A0 =A0 =A0 =A0"'Santosh Rao'"
> =A0 =A0 =A0 <sbhagat@tripace.com> =A0 =A0 =A0 =A0 =A0 =A0<san= toshr@cup.hp.com>, Julian
> =A0 =A0 =A0 Sent by: owner-ips@ece.cmu.edu =A0 Satran/Haifa/IBM@IBMIL<= br> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0cc: =A0 =A0 =A0 =A0ips@ece.cmu.edu
> =A0 =A0 =A0 30-09-01 16:32 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 Subject: =A0 =A0 =A0 =A0RE: iscsi
:
> =A0 =A0 =A0 Please respond to "Sanjeev =A0 =A0 =A0 numerical nego= tiation wording is
> =A0 =A0 =A0 Bhagat (TRIPACE/Zoetermeer)" =A0 =A0 ambiguous
>
>
>
> =A0 =A0 =A0All,
>
> =A0 =A0 =A0I agree with Santosh that the responding party must respond=
> =A0 =A0 =A0the result of
> =A0 =A0 =A0the negotiation as compared with the value from offering
> =A0 =A0 =A0party. All
> =A0 =A0 =A0negotiations in SCSI like (sync, disconnect etc) are also > =A0 =A0 =A0done the same way.
> =A0 =A0 =A0I also object to Julian's reason of a simple minded target<= br> > =A0 =A0 =A0which wants to
> =A0 =A0 =A0send certain fixed values only. In case a simple minded
> =A0 =A0 =A0target identifies a
> =A0 =A0 =A0value which it cannot support or is less than the value a > =A0 =A0 =A0target can
> =A0 =A0 =A0support, then there should be a method for target to reject=
> =A0 =A0 =A0such a
> =A0 =A0 =A0negotiation and the default values be accepted on both side=
> =A0 =A0 =A0as a result of
> =A0 =A0 =A0negotiation.
>
> =A0 =A0 =A01 Because even if simple minded target sends its fixed valu= e
> =A0 =A0 =A0which is
> =A0 =A0 =A0greater than the value sent by offering party then the fina= l
> =A0 =A0 =A0result of
> =A0 =A0 =A0negotiation will be taken as ( lesser of the two) and in
> =A0 =A0 =A0this case target
> =A0 =A0 =A0which which cannot = support the lower value will produce some
> =A0 =A0 =A0illegal
> =A0 =A0 =A0results.
>
> =A0 =A0 =A02. if simple minded target wants to send its own value and<= br> > =A0 =A0 =A0wants it to be
> =A0 =A0 =A0accpeted then the responding party is not negotiating but > =A0 =A0 =A0forcing the result
> =A0 =A0 =A0on initiator(this method should not be allowed unless
> =A0 =A0 =A0explicitly mentioned).
>
> =A0 =A0 =A0however if there is another proposal of numeric negotiation=
> =A0 =A0 =A0in which the
> =A0 =A0 =A0responding party can force its result to be over ridden by<= br> > =A0 =A0 =A0the offering
> =A0 =A0 =A0party's result then it is acceptable for offering party and=
> =A0 =A0 =A0responding party
> =A0 =A0 =A0to send there own supported key-value result and it can the= n
> =A0 =A0 =A0be computed at
> =A0 =A0 =A0offering party's end.
>
> =A0 =A0 =A0IMP: (May be I am missing something here) I do not see how = a
> =A0 =A0 =A0numeric
> =A0 =A0 =A0negotiation can be rejected. Is it possible to reject such<= br> > =A0 =A0 =A0kind of
> =A0 =A0 =A0negotiaion?
>
> =A0 =A0 =A0Sanjeev
>
> =A0 =A0 =A0-----Original Message-----
> =A0 =A0 =A0From: Santosh Rao [mailto:santoshr@cup.hp.com]
> =A0 =A0 =A0Sent: Friday, September 28, 2001 11:15 PM
> =A0 =A0 =A0To: Julian Satran
> =A0 =A0 =A0Cc: ips@ece.cmu.edu
> =A0 =A0 =A0Subject: Re: iscsi : numerical negotiation wording is
> =A0 =A0 =A0ambiguous
>
> =A0 =A0 =A0Julian & All,
>
> =A0 =A0 =A0I request the group to take a close look at this negotiatio= n
> =A0 =A0 =A0process
> =A0 =A0 =A0again and [re-]evaluate the alternative being proposed.
>
> =A0 =A0 =A0Further, it appears that the login stage negotiation =A0is<= br> > =A0 =A0 =A0also following
> =A0 =A0 =A0the same algorithm as the login key negotiation, wherein
> =A0 =A0 =A0originator &
> =A0 =A0 =A0responder offer their respective values and both sides need=
> =A0 =A0 =A0to determine
> =A0 =A0 =A0the result of the negotiation. i.e. both initiator and
> =A0 =A0 =A0target need to
> =A0 =A0 =A0compare their NSG with the other party's NSG and pick the > =A0 =A0 =A0lower of the
> =A0 =A0 =A02.
>
> =A0 =A0 =A0I suggest that both the login key negotiation and the login=
> =A0 =A0 =A0stage
> =A0 =A0 =A0negotiation follow the policy that the originator offers a<= br> > =A0 =A0 =A0value and the
> =A0 =A0 =A0responder picks the result of the negotiation based on (the=
> =A0 =A0 =A0offered
> =A0 =A0 =A0value & its own value). The value picked by the respond= er is
> =A0 =A0 =A0sent back
> =A0 =A0 =A0to the originator.
>
> =A0 =A0 =A0This model has the following advantages :
>
> =A0 =A0 =A01) Only one side picks the result of the negotiaton. Hence,=
> =A0 =A0 =A0the 2 sides
> =A0 =A0 =A0cannot go out of sync on the value picked.
>
> =A0 =A0 =A02) The originator knows the negotiated result at the the
> =A0 =A0 =A0responder since
> =A0 =A0 =A0the responder sends back the result of the negotiation.
>
> =A0 =A0 =A03) This model is easier to debug because of (1) & (2).<= br> >
> =A0 =A0 =A04) Less code since only 1 party (responder) needs to perfor= m
> =A0 =A0 =A0the
> =A0 =A0 =A0computation to pick the result of the negotiation.
>
> =A0 =A0 =A05) This scheme leaves less room for interop problems and
> =A0 =A0 =A0mis-interpretation since it is the more familiar negotiatio= n
> =A0 =A0 =A0technique
> =A0 =A0 =A0that is in use in most other mass storage protocols. (ex :<= br> > =A0 =A0 =A0FC PLOGI, FC
> =A0 =A0 =A0PRLI, etc). From a first reading of the current negotiation=
> =A0 =A0 =A0scheme, it
> =A0 =A0 =A0is'nt readily apparent that the currently defined model is<= br> > =A0 =A0 =A0different
> =A0 =A0 =A0from the above and requires both sides to be picking the
> =A0 =A0 =A0result of the
> =A0 =A0 =A0negotiation, instead of just the responder.
>
> =A0 =A0 =A0Comments ?
>
> =A0 =A0 =A0Thanks,
> =A0 =A0 =A0Santosh
>


--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################
----- Forwarded by J= ulian Satran/Haifa/IBM on 04-10-01 18:56 -----
John Hufferd@IBMUS

04-10-01 07:57


        To: &nbs= p;      Julian Satran/Haifa/IBM@IBMIL
        cc: &nbs= p;      ips@ece.cmu.edu
        From: &n= bsp;      John Hufferd/San Jose/IBM@IBMUS
        Subject:=        RE: iscsi : numerical negotiation wording is am= biguousLink
 





Julian,
I find your response troubling, perh= aps I did not understand what you intended to say.  Comments below.


.
.
.
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

Sent by:    = ;    owner-ips@ece.cmu.edu

To:     &nb= sp;  ips@ece.cmu.edu
cc:     &n= bsp;  
Subject:   &nbs= p;    RE: iscsi : numer= ical negotiation wording is ambiguous




An example:
 08.txt logic
i->t DataPDULength=3D16k
t->i DataPDULength=3D 24k<= font size=3D3 face=3D"sans-serif">

Selected value is 16k

[Huff] If target knows that the Init= iator wants 16k, and therefore that its 24k is not going to be accepted, wh= y did the Target send 24K? [/Huff]

i->t DataPDULength=3D16k
t->i DataPDULength=3D 8k

Selected value is 8k

t->i DataPDULength=3D16k
i->t DataPDULength=3D 24k<= font size=3D3 face=3D"sans-serif">

Selected value is 16k

[Huff] If Initiator knows that the t= arget wants 16k, and therefore that its 24k is not going to be accepted, wh= y did the Initiator send 24K? [/Huff]


t->i DataPDULength=3D16k
i->t DataPDULength=3D 8k

Selected value is 8k

-----

Responder selects logic

i->t DataPDULength=3D16k
t->i DataPDULength=3D 24k<= font size=3D3 face=3D"sans-serif">

Error - Initiator Reject - Closes co= nnection

i->t DataPDULength=3D16k
t->i DataPDULength=3D 8k

Selected value is 8k

t->i DataPDULength=3D16k
i->t DataPDULength=3D 24k<= font size=3D3 face=3D"sans-serif">

Error Target has to terminate with p= arameter error

t->i DataPDULength=3D16k
i->t DataPDULength=3D 8k

Selected value is 8k




"Dev - Platys&qu= ot; <deva@platys.com> <= /font>

01-10-01 23:46
Please respond to "Dev - Platys= "
      &nb= sp;
        To: &nbs= p;      "Julian Satran" <Julian=5FSatran@il.ibm= .com>, <ips@ece.cmu.edu>=
        cc: &nbs= p;      
        Subject:=        RE: iscsi : numerical negotiation wording is am= biguous

       

Julian,
 
I am not sure why a 'REJECT' is requ= ired.
Can you please explain why is this r= equired?
 
I am with Santosh in this.
 
>There is NO need for any REJECT = in the above >case. If the initiator
>is'nt satisfied with the value r= eturned by the >originator and cannot
>function with the negotiated val= ues, it can simply >close the TCP
>connection. There is no need to = send any >REJECT.

Thanks
 
Deva
Adaptec


-----Original Message-----
From: owner-ips@ece.cmu.edu [= mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran
Sent: Monday, October 01, 200= 1 1:28 PM
To: ips@ece.cmu.edu
Subject: Re: iscsi : numerica= l negotiation wording is ambiguous
 

Santosh,

We are getting nowhere. Even if requ= ester is doing it's stuff - the requester will have to check and be prepare= d for a mistake. The coding will require a reject.

Julo

Santosh Rao <santo= shr@cup.hp.com>
Sent by: santoshr@cup.hp.com<= font size=3D3 face=3D"sans-serif">

01-10-01 20:37
Please respond to Santosh Rao= 		      &nb= sp;
       To:  = ;      ips@ece.cmu.edu
       cc:  = ;      "Sanjeev Bhagat (TRIPACE/Zoetermeer)" <s= bhagat@tripace.com>, Julian Satran/Haifa/IBM@IBMIL
       Subject: =        Re: iscsi : numerical negotiation wording is amb= iguous

     



Julian & Sanjeev,

Responding to both your mails......<= /font>

Julian :

I think you may have mis-interpreted= my comments. I believe Sanjeev has
clarified the intent of my suggestio= ns.

I am *not* suggesting that the respo= nder send back its values and these
be blindly imposed on the originator= . On the contrary, my suggestion is
that the computation of the result o= f the negotiation (higher or lower
of the 2 values) be only performed b= y the responder and sent back to the
originator.

The result of the negotiation is the= same in both cases and there is no
REJECT required in my case nor yours= . The difference is the advantages
I've stated in my model.


Sanjeev, in response to your comment= :

" [Sanjeev Bhagat (TRIPACE/Zoet= ermeer)] Although there is
>  no reject , but it can be= a problem in future .
>  Consider your example of = DataPDULength in your own
>  message. Suppose offering= party sends a value of 16,384
>  (this is also lowest valu= e it can send) and responding
>  party responds with 8,192= . In this case the offering
>  party will have to reject= the negotiation. So a reject
>  message is needed in this= case also. "


There is NO need for any REJECT in t= he above case. If the initiator
is'nt satisfied with the value retur= ned by the originator and cannot
function with the negotiated values,= it can simply close the TCP
connection. There is no need to send= any REJECT.


Thanks,
Santosh


> "Sanjeev Bhagat (TRIPACE/Z= oetermeer)" wrote:
>
> Thanks Julian, please find my f= urther comments in the message
>
>      -----Origin= al Message-----
>      From: Julia= n Satran [mailto:Julian=5FSatran@il.ibm.com]
>      Sent: Sunda= y, September 30, 2001 6:07 PM
>      To: ips@ece= .cmu.edu
>      Subject: RE= : iscsi : numerical negotiation wording is
>      ambiguous
>
>      Sanjeev,
>
>      I am not su= re clear I made the tiny diference between what I
>      say and wha= t Santosh said:
>
>      Santosh say= s:
>
>        1. a= requester sends A=3Dvaluex
>        2. a= responder sends B=3Dvaluey
>        3. t= he responder assumes that the value y is the correct
>         &nb= sp; value and so does an external observer
>         &nb= sp; [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather
>         &nb= sp; say it this way the responder computes the value with
>         &nb= sp; its own supported values and responds with a value y
>         &nb= sp; which the responder thinks is correct and so does an
>         &nb= sp; external observer
>        4. t= he requester checks that valuey is conformant (he will
>         &nb= sp; not believe it) and will reject it if not conformant
>         &nb= sp; else it will accept it
>         &nb= sp; [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct,
>         &nb= sp; but it is highly unlikely for the responder to reject
>         &nb= sp; the final result because the rule states that (lower or
>         &nb= sp; higher of two will be the result) and so the offering
>         &nb= sp; party should be able to accept the lower or higher
>         &nb= sp; range as defined by rule. In case the key is dependent
>         &nb= sp; upon some range of fixed values then the negotiation
>         &nb= sp; should be performed as list negotiation and not
>         &nb= sp; numerical negotiation.
>
>         &nb= sp; This might be what you "conventionally" do - I don't
>         &nb= sp; and that shows that convention like morals are a matter
>         &nb= sp; of geography :-)
>         &nb= sp; [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-)
>
>         &nb= sp; The advantage of this set of rules is that it allows an
>         &nb= sp; external observer to know what was selected without
>         &nb= sp; knowing the rules
>         &nb= sp; [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this
>         &nb= sp; case, I guess that the external observer has to know
>         &nb= sp; the rules to double check the value is correct or not
>         &nb= sp; The disadvantage is that messages have to be "built",
>         &nb= sp; an additional reject states exists and MOST IMPORTANT
>         &nb= sp; you need both messages
>
>         &nb= sp; In what I said:
>
>         &nb= sp; 1. The requester sends A=3Dvaluex
>         &nb= sp; 2. The Responder has to send either nothing (if valuex
>         &nb= sp; is enough on both sides to compute the result like in
>         &nb= sp; the case in which the function is a Boolean AND and the
>         &nb= sp; value is NO) or valuey
>         &nb= sp; 3. Both the requestor and responder have to compute the
>         &nb= sp; value (they have to know the rules anyhow) and so does
>         &nb= sp; the external observer
>
>         &nb= sp; The disadvantage is that the external observer has to
>         &nb= sp; know the rules
>         &nb= sp; The advantage is that there is no reject, in binary
>         &nb= sp; negotiations you can go away with shorter negotiations
>         &nb= sp; and you can set strings at fixed values.
>         &nb= sp; [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is
>         &nb= sp; no reject , but it can be a problem in future .
>         &nb= sp; Consider your example of DataPDULength in your own
>         &nb= sp; message. Suppose offering party sends a value of 16,384
>         &nb= sp; (this is also lowest value it can send) and responding
>         &nb= sp; party responds with 8,192. In this case the offering
>         &nb= sp; party will have to reject the negotiation. So a reject
>         &nb= sp; message is needed in this case also.
>
>
>      Sanjeev
>       "Sanj= eev Bhagat
>       (TRIPACE/Z= oetermeer)"                 &n= bsp;  To:        "'Santosh Rao'"
>       <sbhaga= t@tripace.com>            <santoshr@cup= .hp.com>, Julian
>       Sent by: o= wner-ips@ece.cmu.edu   Satran/Haifa/IBM@IBMIL
>         &nb= sp;                     &= nbsp;                cc:   &nb= sp;    ips@ece.cmu.edu
>       30-09-01 1= 6:32                     =       Subject:        RE: iscsi :
>       Please res= pond to "Sanjeev       numerical negotiation wording is=
>       Bhagat (TR= IPACE/Zoetermeer)"     ambiguous
>
>
>
>      All,
>
>      I agree wit= h Santosh that the responding party must respond
>      the result = of
>      the negotia= tion as compared with the value from offering
>      party. All<= /font>
>      negotiation= s in SCSI like (sync, disconnect etc) are also
>      done the sa= me way.
>      I also obje= ct to Julian's reason of a simple minded target
>      which wants= to
>      send certai= n fixed values only. In case a simple minded
>      target iden= tifies a
>      value which= it cannot support or is less than the value a
>      target can<= /font>
>      support, th= en 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 e= ven if simple minded target sends its fixed value
>      which is
>      greater tha= n the value sent by offering party then the final
>      result of
>      negotiation= will be taken as ( lesser of the two) and in
>      this case t= arget
>      which which= cannot support the lower value will produce some
>      illegal
>      results.
>
>      2. if simpl= e minded target wants to send its own value and
>      wants it to= be
>      accpeted th= en the responding party is not negotiating but
>      forcing the= result
>      on initiato= r(this method should not be allowed unless
>      explicitly = mentioned).
>
>      however if = there is another proposal of numeric negotiation
>      in which th= e
>      responding = party can force its result to be over ridden by
>      the offerin= g
>      party's res= ult then it is acceptable for offering party and
>      responding = party
>      to send the= re own supported key-value result and it can then
>      be computed= at
>      offering pa= rty's end.
>
>      IMP: (May b= e 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
>
>      -----Origin= al Message-----
>      From: Santo= sh Rao [mailto:santoshr@cup.hp.com]
>      Sent: Frida= y, 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 t= he 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 follow= ing
>      the same al= gorithm as the login key negotiation, wherein
>      originator = &
>      responder o= ffer their respective values and both sides need
>      to determin= e
>      the result = of the negotiation. i.e. both initiator and
>      target need= to
>      compare the= ir NSG with the other party's NSG and pick the
>      lower of th= e
>      2.
>
>      I suggest t= hat both the login key negotiation and the login
>      stage
>      negotiation= follow the policy that the originator offers a
>      value and t= he
>      responder p= icks the result of the negotiation based on (the
>      offered
>      value &= its own value). The value picked by the responder is
>      sent back
>      to the orig= inator.
>
>      This model = has the following advantages :
>
>      1) Only one= side picks the result of the negotiaton. Hence,
>      the 2 sides=
>      cannot go o= ut of sync on the value picked.
>
>      2) The orig= inator knows the negotiated result at the the
>      responder s= ince
>      the respond= er sends back the result of the negotiation.
>
>      3) This mod= el is easier to debug because of (1) & (2).
>
>      4) Less cod= e since only 1 party (responder) needs to perform
>      the
>      computation= to pick the result of the negotiation.
>
>      5) This sch= eme leaves less room for interop problems and
>      mis-interpr= etation since it is the more familiar negotiation
>      technique
>      that is in = use in most other mass storage protocols. (ex :
>      FC PLOGI, F= C
>      PRLI, etc).= From a first reading of the current negotiation
>      scheme, it<= /font>
>      is'nt readi= ly apparent that the currently defined model is
>      different
>      from the ab= ove and requires both sides to be picking the
>      result of t= he
>      negotiation= , instead of just the responder.
>
>      Comments ?<= /font>
>
>      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 006299F1C2256ADB_=-- From owner-ips@ece.cmu.edu Thu Oct 4 15:12: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 PAA22874 for ; Thu, 4 Oct 2001 15:12:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94If6i15089 for ips-outgoing; Thu, 4 Oct 2001 14:41:06 -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 f94If4l15079 for ; Thu, 4 Oct 2001 14:41:04 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 14:38:04 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD828@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: RE: iSCSI: ISID issue Date: Thu, 4 Oct 2001 14:33:04 -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, > As I said in my last note, I'm willing to abandon use of the ISID for the > purposes of naming SCSI Initiator Ports and replace that with some text key > (so that ISIDs are removed from the dual role of identifying sessions AND > SCSI initiator ports). But I haven't seen any specific proposal to that > effect and that addresses all the issues involved (as outlined also in my > last note). Ok, I think this is the key piece of your last note: > My point general point is > that I believe we need to have an unambiguous identifier of the SCSI > initiator port. This is for reasons of > (a) persistent reserverations (as defined today) as well as for future > extensions > (b) there is an obligation today (I think) for the transport layer to > present to the OS layers above a "picture" of the SCSI Initiator Ports > (isn't that what you keep saying goes in /dev stuff?). Wedge drivers rely > on this stuff too. > (c) some access control stuff (as defined by T10) but this is not a hard > requirement I would do the following: (a) Set aside all notion of "future extensions" thereby removing a need for an externally visible iSCSI Initiator Port Name for this purpose. (b) Use the iSCSI Initiator Node Name + iSCSI Target Node Name + TSID for this purpose. (c) Do nothing in the absence of a "hard requirement", and try to use the Initiator Node Name for this purpose rather than a Port Name. I would plan to deal with "future extensions" via a possible "future text key" to be specified after the "future extensions" are so that we have a concrete set of requirements and objectives to work to. In the Interim, we can advise T10 that iSCSI strongly prefers reservations to be associated with Initiators, rather than Initiator Ports. > In fact, if we do find an alternative to the ISID for naming SCSI Initiator > Ports, then the ISID would be irrelevant to the SCSI model (as the TSID is > now) and we won't need the ISID rule anymore (we'd need another rule for > port names, however). This includes one more reason: (d) iSCSI entity to which the SAM2 concept of SCSI Initiator Port maps to. As we discussed, and I think agreed, earlier, it is sufficient to assert the existence of such an entity in an iSCSI implementation (some sort of session data structure) for the purpose of mapping, but not provide an externally visible name that is independently useful outside the bounds of the specific iSCSI implementation. I think this leads to removing ISIDs and the ISID RULE without substituting a port name rule. What goes wrong if this is done? > We can then ask if there is any value in the iSCSI > protocol for either the ISID or the TSID (as I did many many > months ago prior to this dicussion). I'm not seeing any. We might be better off using that field to hold the Target Portal Group number; TSIDs would then only need to be unique to an Initiator within a Target Portal Group, and hence could be independently managed on a per-Portal Group basis, as opposed to the current TSID RULE that spans the entire Target (instead of configuring TSID ranges, one configures the Portal Group Number, which probably needs to be configured anyway). This also makes any attempt to span Target Portal Groups or recover a session across Target Portal Groups immediately obvious to the Target (the first is forbidden, the second might work, but probably requires special handling at the Target, and may need some more protocol support). One consequence of this field change would be to add Target Portal Group to (b) above, and that may actually be a good thing as it forces exposure of this fundamental level of structure. John had previously had a bad reaction to my additional suggestion to change the TSID field size to 24 bits and the Portal Group field size to 8 bits if the ISID to Target Portal Group change is made, but that's a second order issue at best (and one that I don't care that strongly about). Are we getting anywhere? 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 Oct 4 15:33: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 PAA23616 for ; Thu, 4 Oct 2001 15:33:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94IvFc16344 for ips-outgoing; Thu, 4 Oct 2001 14:57:15 -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 f94IvCl16339 for ; Thu, 4 Oct 2001 14:57:12 -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 OAA16172; Thu, 4 Oct 2001 14:54:46 -0400 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f94IuwH205044; Thu, 4 Oct 2001 12:56:58 -0600 Importance: Normal Subject: RE: iSCSI: ISID issue To: Black_David@emc.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Jim Hafner" Date: Thu, 4 Oct 2001 19:56:56 +0100 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/04/2001 11:56:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Comments in line. Jim Hafner Black_David@emc.com on 10/04/2001 06:56:46 PM To: Jim Hafner/Almaden/IBM@IBMUS, Black_David@emc.com cc: Subject: RE: iSCSI: ISID issue Jim, > As I said in my last note, I'm willing to abandon use of the ISID for the > purposes of naming SCSI Initiator Ports and replace that with some text key > (so that ISIDs are removed from the dual role of identifying sessions AND > SCSI initiator ports). But I haven't seen any specific proposal to that > effect and that addresses all the issues involved (as outlined also in my > last note). Ok, I think this is the key piece of your last note: > My point general point is > that I believe we need to have an unambiguous identifier of the SCSI > initiator port. This is for reasons of > (a) persistent reserverations (as defined today) as well as for future > extensions > (b) there is an obligation today (I think) for the transport layer to > present to the OS layers above a "picture" of the SCSI Initiator Ports > (isn't that what you keep saying goes in /dev stuff?). Wedge drivers rely > on this stuff too. > (c) some access control stuff (as defined by T10) but this is not a hard > requirement I would do the following: (a) Set aside all notion of "future extensions" thereby removing a need for an externally visible iSCSI Initiator Port Name for this purpose. (b) Use the iSCSI Initiator Node Name + iSCSI Target Node Name + TSID for this purpose. (c) Do nothing in the absence of a "hard requirement", and try to use the Initiator Node Name for this purpose rather than a Port Name. If we do (b), then we're effectively having hte target "name/identify" SCSI Initiator Port. OK, now, suppose the initiator has two sessions active to given target portal group. On one (say with TSID=5) he sends persistent reserve registration and on another (say with TSID=7) he sends persistent reserve registration + reservation. Now the target resets and the initiator cleans up context and starts up one new session. What does the target do? Does it assign TSID=5 or 7 or 9? What logic does it use? The order in which they were originally established? Does it decide to use 7 cause that had more 'stuff' associated with it? Does it decide to use 9 so that it can forget/discard all the persistent reservation information? The point here is that the target doesn't have any basis on which to bind the persistence property based on initiator port identifier. I just don't see how that works even in today's model. I don't know what you mean by (c). What "purpose" are you talking about? I would plan to deal with "future extensions" via a possible "future text key" to be specified after the "future extensions" are so that we have a concrete set of requirements and objectives to work to. In the Interim, we can advise T10 that iSCSI strongly prefers reservations to be associated with Initiators, rather than Initiator Ports. > In fact, if we do find an alternative to the ISID for naming SCSI Initiator > Ports, then the ISID would be irrelevant to the SCSI model (as the TSID is > now) and we won't need the ISID rule anymore (we'd need another rule for > port names, however). This includes one more reason: (d) iSCSI entity to which the SAM2 concept of SCSI Initiator Port maps to. As we discussed, and I think agreed, earlier, it is sufficient to assert the existence of such an entity in an iSCSI implementation (some sort of session data structure) for the purpose of mapping, but not provide an externally visible name that is independently useful outside the bounds of the specific iSCSI implementation. But I also argued that existing OS's like to see some consistency (you've even said they put stuff in /dev) on their initiator ports. If these are all driven by the target (in the sense of identification), then where can the iSCSI layer provide such consistency? I think this leads to removing ISIDs and the ISID RULE without substituting a port name rule. What goes wrong if this is done? I hope my discussion above touches on what I see as going wrong. > We can then ask if there is any value in the iSCSI > protocol for either the ISID or the TSID (as I did many many > months ago prior to this dicussion). I'm not seeing any. We might be better off using that field to hold the Target Portal Group number; TSIDs would then only need to be unique to an Initiator within a Target Portal Group, and hence could be independently managed on a per-Portal Group basis, as opposed to the current TSID RULE that spans the entire Target (instead of configuring TSID ranges, one configures the Portal Group Number, which probably needs to be configured anyway). This also makes any attempt to span Target Portal Groups or recover a session across Target Portal Groups immediately obvious to the Target (the first is forbidden, the second might work, but probably requires special handling at the Target, and may need some more protocol support). One consequence of this field change would be to add Target Portal Group to (b) above, and that may actually be a good thing as it forces exposure of this fundamental level of structure. You're proposal to include the target portal group number in the TSID is an *implementation of configuring TSID ranges* for each target portal group, isn't it? In fact, that would be how I would implement it my target (if I was building one, whether the spec said that it had this form or not -- and I'm implement my host driver pretty much the same way, via enumeration of drivers/devices (which pretty much constitute initiator portal groups) as they are discovered/loaded by the OS). Such an implementation guarantees compliance with the TSID RULE (and would do the same for the ISID RULE as well). So, you haven't avoided it, you've simply spec'ed an implementation that meets the requirements. The proposal to include the target portal group tag in the message header (either within or separate from the TSID) is an independent issue from the ISID one. John had previously had a bad reaction to my additional suggestion to change the TSID field size to 24 bits and the Portal Group field size to 8 bits if the ISID to Target Portal Group change is made, but that's a second order issue at best (and one that I don't care that strongly about). Are we getting anywhere? 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 Oct 4 15:36: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 PAA23666 for ; Thu, 4 Oct 2001 15:36:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94JE3d17661 for ips-outgoing; Thu, 4 Oct 2001 15:14:03 -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 f94JE2l17657 for ; Thu, 4 Oct 2001 15:14:02 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id 5B7401F5DB; Thu, 4 Oct 2001 12:13:56 -0700 (PDT) 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 MAA19418; Thu, 4 Oct 2001 12:15:18 -0700 (PDT) Message-ID: <3BBCB642.67AFD604@rose.hp.com> Date: Thu, 04 Oct 2001 12:19:30 -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: Prasenjit Sarkar Cc: ips@ece.cmu.edu Subject: Re: Data Digest Error question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Prasenjit, The Reject mechanism is intended to be uniformly applicable to all (recovery-savvy and otherwise) targets. Recovery R2T, OTOH, is only for ErrorRecoveryLevel>=1 capable implementations (DataSequenceInOrder=true as well, I think this needs to be called out in its description), since a recovery R2T implies going back in the data stream. The delivery subsystem failure status is the final termination status (even though there were several good data PDUs after the failed one) for ErrorRecoveryLevel=0 implementations, sent after waiting for the F-bit. Hope that helps. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Prasenjit Sarkar wrote: > > This question relates to how the target handles data digest errors for data > pdus. > > The spec says the target has to send a reject pdu with the attached pdu > header > + (recovery R2T OR delivery subsystem failure status) > > Why do we need two mechanisms? Wouldnt the pdu header indicate what needed > to be transmitted? Maybe a word of motivation might help. > > Prasenjit Sarkar > Research Staff Member > IBM Almaden Research > San Jose From owner-ips@ece.cmu.edu Thu Oct 4 15: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 PAA23757 for ; Thu, 4 Oct 2001 15:41:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94Il4i15560 for ips-outgoing; Thu, 4 Oct 2001 14:47: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 f94Il3l15554 for ; Thu, 4 Oct 2001 14:47:03 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 14:46:57 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD829@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Date: Thu, 4 Oct 2001 14:39:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14D03.D678B4C0" 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_01C14D03.D678B4C0 Content-Type: text/plain; charset="iso-8859-1" How about applying the "responder must send the result" rule to Boolean negotiations? The new text could then be: For Boolean negotiations (keys taking the values yes or no), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value to respond with are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value. Specifically, the two cases in which responses are OPTIONAL are: - The Boolean function is "AND" and the value "no" is received. The outcome of the negotiation is "no". - The Boolean function is "OR" and the value "yes" is received. The outcome of the negotiation is "yes". Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation. --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: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, October 04, 2001 1:57 PM To: ips@ece.cmu.edu Subject: RE: iscsi : numerical negotiation wording is ambiguous Well - even I got fed-up with this long thread. Here the new text I am suggesting for the negotiations ("vox populi"): 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 and the value it selects, based on the selection rule specific to the key, becomes the negotiation result. Selection of a value not admissible under the selection rules is considered a protocol error and handled accordingly. For Boolean negotiations (keys taking the values yes or no), 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). Both requestor and responder MUST to compute the negotiated value based on the new value(s) exchanged The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood". 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, only the initiator can initiate the negotiation start (through the first Text request) and completion (by setting to 1 and keeping to 1 the F bit in a Text request). Unless specified otherwise the negotiation process is stateless (based only on newly presented values). Comments? Julo ------_=_NextPart_001_01C14D03.D678B4C0 Content-Type: text/html; charset="iso-8859-1"
How about applying the "responder must send the result" rule to
Boolean negotiations?  The new text could then be:
 
For Boolean negotiations (keys taking the values yes or no), the
responding party MUST respond with the required key and the result
of the negotiation when the received value does not determine that
result by itself.  The last value transmitted becomes the
negotiation result.  The rules for selecting the value to respond
with are expressed as Boolean functions of the value received and
the value that the responding party would select in the absence
of knowledge of the received value.
 
Specifically, the two cases in which responses are OPTIONAL are:
- The Boolean function is "AND" and the value "no" is received.
    The outcome of the negotiation is "no".
- The Boolean function is "OR" and the value "yes" is received.
    The outcome of the negotiation is "yes".
Responses are REQUIRED in all other cases, and the value chosen
and sent by the responder becomes the outcome of the negotiation.
 
 
 
--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: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, October 04, 2001 1:57 PM
To: ips@ece.cmu.edu
Subject: RE: iscsi : numerical negotiation wording is ambiguous


Well - even I got fed-up with this long thread.

Here the new text I am suggesting for the negotiations ("vox populi"):

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 and the value it selects, based on the selection rule specific to the key, becomes the negotiation result.  Selection of a value not admissible under the selection rules is considered a protocol error and handled accordingly.

For Boolean negotiations (keys taking the values yes or no), 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). Both requestor and responder MUST to compute the negotiated value based on the new value(s) exchanged

The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood".

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, only the initiator can initiate the negotiation start (through the first Text request) and completion (by setting to 1 and keeping to 1 the F bit in a Text request).

Unless specified otherwise the negotiation process is stateless (based only on newly presented values).


Comments?
Julo


------_=_NextPart_001_01C14D03.D678B4C0-- From owner-ips@ece.cmu.edu Thu Oct 4 16:27: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 QAA24428 for ; Thu, 4 Oct 2001 16:27:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94JU9I18928 for ips-outgoing; Thu, 4 Oct 2001 15:30:09 -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 f94JU6l18919 for ; Thu, 4 Oct 2001 15:30:06 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 85A171F83D for ; Thu, 4 Oct 2001 15:27:57 -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 MAA23680 for ; Thu, 4 Oct 2001 12:31:22 -0700 (PDT) Message-ID: <3BBCBA06.1A09CADC@rose.hp.com> Date: Thu, 04 Oct 2001 12:35:34 -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 Subject: Re: Data Digest Error question References: <3BBCB642.67AFD604@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 "Mallikarjun C." wrote: > > Prasenjit, > > The Reject mechanism is intended to be uniformly applicable to > all (recovery-savvy and otherwise) targets. > > Recovery R2T, OTOH, is only for ErrorRecoveryLevel>=1 capable > implementations (DataSequenceInOrder=true Sorry, that was supposed to be DataSequenceInOrder=no. Also, it appears to me that the result function for this key should be AND, and there's a typo in the description - it says "no" for both cases. Julian, comments? >as well, I think this > needs to be called out in its description), since a recovery R2T > implies going back in the data stream. > > The delivery subsystem failure status is the final termination > status (even though there were several good data PDUs after the > failed one) for ErrorRecoveryLevel=0 implementations, sent after > waiting for the F-bit. > > Hope that helps. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Prasenjit Sarkar wrote: > > > > This question relates to how the target handles data digest errors for data > > pdus. > > > > The spec says the target has to send a reject pdu with the attached pdu > > header > > + (recovery R2T OR delivery subsystem failure status) > > > > Why do we need two mechanisms? Wouldnt the pdu header indicate what needed > > to be transmitted? Maybe a word of motivation might help. > > > > Prasenjit Sarkar > > Research Staff Member > > IBM Almaden Research > > San Jose -- 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 Thu Oct 4 16:54: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 QAA24807 for ; Thu, 4 Oct 2001 16:54:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94K9Ig21773 for ips-outgoing; Thu, 4 Oct 2001 16:09:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f94GSrl04959 for ; Thu, 4 Oct 2001 12:28:53 -0400 (EDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f94GT4628291 for ; Thu, 4 Oct 2001 09:29:05 -0700 (PDT) Received: from ussvlexc06.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.12.0/8.12.0/NTAP-1.3) with ESMTP id f94GSgw5012621 for ; Thu, 4 Oct 2001 09:28:42 -0700 (PDT) Received: by ussvlexc06.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 09:28:41 -0700 Message-ID: <02740A3D0809D5118C7C00034707E9F335FA09@USSVLEXC10> From: "Pittman, Joseph" To: "'ips@ece.cmu.edu'" Subject: iSCSI: Questions about naming, multi-pathing, multi-port targets Date: Thu, 4 Oct 2001 09:22:50 -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 am fairly new to the iSCSI effort, and this is my first question to the IPS mailing list. But I have been following the mailing list for awhile now, particularly the recent system identification discussions. And I am now working in earnest on an iSCSI target implementation, which has brought into focus the need for me to get a more complete understanding of the concepts. What is the expected naming and access model for a target with multiple physical ports/IP addresses? I understand from the iSCSI Naming and Discovery document that a target node presents one or more Portal Groups, and that an iSCSI session is conducted over exactly one portal group. Is it expected that a target with 4 ports will have a single "portal group"? Or 4 separate portal groups? Would operating system SCSI initiator code prefer to see 4 independent paths into the target, or a single session-layer path with multiple lower-level paths of connectivity? And how is the OS supposed to discover the association between target portals and their portal groups? In the FCP-SCSI world, each FC port on a multi-ported target device (e.g. SAN-connected disk array) is an independent communicating entity, with its own FC port and WWN. There is no concept of a networking session which spans multiple physical connections. As I understand it, the existence of multiple paths to the same underlying set of LUNs is detected by examining SCSI inquiry data from the detected devices. A driver (or a "wedge layer") within an operating system examines all available LUNs through all FCP HBAs under its control, and uses SCSI inquiry to detect the existence of multiple paths to the same LUN. The driver or wedge layer then advertises to the higher layers of the SCSI block storage stack only the set of unique target devices. The driver routes incoming SCSI requests from above to to one of the available paths, based on some algorithm which may take into account availability and relative performance of the paths. Now consider the case of adding support for iSCSI connectivity into an existing OS SCSI request stack. The most straightforward way for an iSCSI driver to drop into an existing infrastructure would be for a 4-port target to appear as 4 distinct DEVICES. The driver or "wedge layer", using IP address as the fundamental identifier for its notion of target identifier, would detect the presence of 4 separate "targets", use inquiries to detect multiple paths to the LUNs through these separate devices, etc. An approach which is more iSCSI-aware could take advantage of available config info (via static configuration? SLP? iSNS?) to recognize that all 4 IP addresses map to the same iSCSI Target Node. The ISID rule states that there can be only one session with a given ISID between an iSCSI Initiator and an iSCSI Target Portal Group. So how does the initiator discover the relationship between portals and groups on the target? And what would the OS implementors rather do, establish a separate session to each IP address, or establish a single session over each portal group? Impact on the target-mode implementer: should a target implementation endeavor to present a single portal group? Or a different group for each portal? Or a different group for each HBA (which may have one or more ports)? One factor in deciding this is the diversity of the possible approaches to handling iSCSI processing: - onboard a single-port HBA - onboard a multi-port HBA - within a driver in an embedded OS which uses a per-instance driver architecture - within a driver in an embedded OS which uses a per-device class driver architecture - within an overarching iSCSI management layer Any thoughts or guidance would be greatly appreciated. -- Joe Pittman jpittman@netapp.com From owner-ips@ece.cmu.edu Thu Oct 4 17:15: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 RAA25063 for ; Thu, 4 Oct 2001 17:15:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94K8Rw21721 for ips-outgoing; Thu, 4 Oct 2001 16:08:27 -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 f94ExPl28151 for ; Thu, 4 Oct 2001 10:59:25 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f94ESID03705; Thu, 4 Oct 2001 10:28:18 -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 f94ESHr23612; Thu, 4 Oct 2001 10:28:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15292.29223.876000.583204@gargle.gargle.HOWL> Date: Thu, 4 Oct 2001 10:28:55 -0400 From: Paul Koning To: rsnively@Brocade.COM Cc: santoshr@cup.hp.com, ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. 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 3 October 2001) by Robert Snively: > I would have thought that it was indicating the DataPDULength it > was capable of accepting, committing the other port to not > exceeding that value. Clearly that is what it has to be. If a PDU length limit is per direction, the only interpretation that works is that you indicate the max length you're willing to have coming IN. There is no reason to indicate the max you're willing to send -- all that is required is that you never send more than the limit indicated by the other side (but you may never send something as big as that limit, if your own transmitter has a limit smaller than that). So the notion of two numbers, one per direction, is fine, but the word "use" is ambiguous. A clearer wording is "... specify in DataPDULength the maximum PDU length it is willing to receive". Then the sender can send PDUs smaller than the DataPDULength requested by the destination, or the same, but not larger. (This is how MTU works.) paul > > -----Original Message----- > > From: Santosh Rao [mailto:santoshr@cup.hp.com] > > Sent: Wednesday, October 03, 2001 10:32 AM > > To: Dev - Platys; Julian Satran > > Cc: Sandeep Joshi; ips@ece.cmu.edu > > Subject: iscsi : DataPDULength can differ in each direction. > > > > > > Deva, Julian & All, > > > > I think we have a more fundamental problem here, that spans beyond the > > issue of which negotiation model should be used for numerical & binary > > key negotiation. This problem needs to be addressed seperately. > > > > The DataPDULength can and should be allowed to be different in each > > direction. I -> T direction PDUs should be allowed to use a different > > PDU Length than T -> I direction PDUs. > > > > Each side should be allowed to specify the DataPDULength it will be > > using and there should be no attempt to negotiate this value. > > From owner-ips@ece.cmu.edu Thu Oct 4 18:29: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 SAA25893 for ; Thu, 4 Oct 2001 18:29:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94LVji27515 for ips-outgoing; Thu, 4 Oct 2001 17:31:45 -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 f94LVhl27511 for ; Thu, 4 Oct 2001 17:31:44 -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 RAA15250; Thu, 4 Oct 2001 17:29:19 -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 f94LUxH244918; Thu, 4 Oct 2001 15:31:00 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Questions about naming, multi-pathing, multi-port targets To: "Pittman, Joseph" Cc: "'ips@ece.cmu.edu'" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 4 Oct 2001 14:30:06 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/04/2001 03:30:59 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The Portal Group ID is returned by the SendTargets command, as well as the SLP response and the iSNS response. The target should not only be prepared to respond to SendTarget, by specifying the Portal Groups, it also needs to register with SLP and/or iSNS by specifying its portal groups. . . . 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 "Pittman, Joseph" @ece.cmu.edu on 10/04/2001 09:22:50 AM Sent by: owner-ips@ece.cmu.edu To: "'ips@ece.cmu.edu'" cc: Subject: iSCSI: Questions about naming, multi-pathing, multi-port targets I am fairly new to the iSCSI effort, and this is my first question to the IPS mailing list. But I have been following the mailing list for awhile now, particularly the recent system identification discussions. And I am now working in earnest on an iSCSI target implementation, which has brought into focus the need for me to get a more complete understanding of the concepts. What is the expected naming and access model for a target with multiple physical ports/IP addresses? I understand from the iSCSI Naming and Discovery document that a target node presents one or more Portal Groups, and that an iSCSI session is conducted over exactly one portal group. Is it expected that a target with 4 ports will have a single "portal group"? Or 4 separate portal groups? Would operating system SCSI initiator code prefer to see 4 independent paths into the target, or a single session-layer path with multiple lower-level paths of connectivity? And how is the OS supposed to discover the association between target portals and their portal groups? In the FCP-SCSI world, each FC port on a multi-ported target device (e.g. SAN-connected disk array) is an independent communicating entity, with its own FC port and WWN. There is no concept of a networking session which spans multiple physical connections. As I understand it, the existence of multiple paths to the same underlying set of LUNs is detected by examining SCSI inquiry data from the detected devices. A driver (or a "wedge layer") within an operating system examines all available LUNs through all FCP HBAs under its control, and uses SCSI inquiry to detect the existence of multiple paths to the same LUN. The driver or wedge layer then advertises to the higher layers of the SCSI block storage stack only the set of unique target devices. The driver routes incoming SCSI requests from above to to one of the available paths, based on some algorithm which may take into account availability and relative performance of the paths. Now consider the case of adding support for iSCSI connectivity into an existing OS SCSI request stack. The most straightforward way for an iSCSI driver to drop into an existing infrastructure would be for a 4-port target to appear as 4 distinct DEVICES. The driver or "wedge layer", using IP address as the fundamental identifier for its notion of target identifier, would detect the presence of 4 separate "targets", use inquiries to detect multiple paths to the LUNs through these separate devices, etc. An approach which is more iSCSI-aware could take advantage of available config info (via static configuration? SLP? iSNS?) to recognize that all 4 IP addresses map to the same iSCSI Target Node. The ISID rule states that there can be only one session with a given ISID between an iSCSI Initiator and an iSCSI Target Portal Group. So how does the initiator discover the relationship between portals and groups on the target? And what would the OS implementors rather do, establish a separate session to each IP address, or establish a single session over each portal group? Impact on the target-mode implementer: should a target implementation endeavor to present a single portal group? Or a different group for each portal? Or a different group for each HBA (which may have one or more ports)? One factor in deciding this is the diversity of the possible approaches to handling iSCSI processing: - onboard a single-port HBA - onboard a multi-port HBA - within a driver in an embedded OS which uses a per-instance driver architecture - within a driver in an embedded OS which uses a per-device class driver architecture - within an overarching iSCSI management layer Any thoughts or guidance would be greatly appreciated. -- Joe Pittman jpittman@netapp.com From owner-ips@ece.cmu.edu Thu Oct 4 19:06: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 TAA26100 for ; Thu, 4 Oct 2001 19:06:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94MCjG00074 for ips-outgoing; Thu, 4 Oct 2001 18:12:45 -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 f94MCil00066 for ; Thu, 4 Oct 2001 18:12: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 SAA13251; Thu, 4 Oct 2001 18:12:35 -0400 (EDT) Message-ID: <3BBCDEB2.8D5C24E1@cisco.com> Date: Thu, 04 Oct 2001 17:12:02 -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: Julian Satran CC: ietf-ips 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, I would prefer that responses are required for boolean negotiations as well. Even if the response is optional, an implementation must allow for it. Also, I assume that if the target offers a key that requires a response, the initiator must still respond. This is how I understand draft -08 to work. Regards, Steve Senum Julian Satran wrote: > > Well - even I got fed-up with this long thread. > > Here the new text I am suggesting for the negotiations ("vox populi"): > > 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 and the value it selects, based on the selection rule specific to > the key, becomes the negotiation result. Selection of a value not admissible > under the selection rules is considered a protocol error and handled > accordingly. > > For Boolean negotiations (keys taking the values yes or no), 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). Both requestor > and responder MUST to compute the negotiated value based on the new value(s) > exchanged > > The value "?" with any key has the meaning of enquiry and should be answered > with the current value or "NotUnderstood". > > 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, > only the initiator can initiate the negotiation start (through the first Text > request) and completion (by setting to 1 and keeping to 1 the F bit in a Text > request). > > Unless specified otherwise the negotiation process is stateless (based only on > newly presented values). > > Comments? > Julo From owner-ips@ece.cmu.edu Thu Oct 4 19:11: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 TAA26160 for ; Thu, 4 Oct 2001 19:11:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94Mc0a01586 for ips-outgoing; Thu, 4 Oct 2001 18:38:00 -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 f94Mbul01575 for ; Thu, 4 Oct 2001 18:37:56 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 18:40:03 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD82D@CORPMX14> From: Black_David@emc.com To: hafner@almaden.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISID issue Date: Thu, 4 Oct 2001 18:29:53 -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 Yet more comments inline. --David > David, > > Comments in line. > > Jim Hafner > > > Black_David@emc.com on 10/04/2001 06:56:46 PM > > To: Jim Hafner/Almaden/IBM@IBMUS, Black_David@emc.com > cc: > Subject: RE: iSCSI: ISID issue > > > > Jim, > > > As I said in my last note, I'm willing to abandon use of the ISID for the > > purposes of naming SCSI Initiator Ports and replace that with some text key > > (so that ISIDs are removed from the dual role of identifying sessions AND > > SCSI initiator ports). But I haven't seen any specific proposal to that > > effect and that addresses all the issues involved (as outlined also in my > > last note). > > Ok, I think this is the key piece of your last note: > > > My point general point is > > that I believe we need to have an unambiguous identifier of the SCSI > > initiator port. This is for reasons of > > (a) persistent reserverations (as defined today) as well as for future > > extensions > > (b) there is an obligation today (I think) for the transport layer to > > present to the OS layers above a "picture" of the SCSI Initiator Ports > > (isn't that what you keep saying goes in /dev stuff?). Wedge drivers rely > > on this stuff too. > > (c) some access control stuff (as defined by T10) but this is not a hard > > requirement > > I would do the following: > > (a) Set aside all notion of "future extensions" thereby removing a need > for an externally visible iSCSI Initiator Port Name for this purpose. > (b) Use the iSCSI Initiator Node Name + iSCSI Target Node Name + TSID > for this purpose. > (c) Do nothing in the absence of a "hard requirement", and try to use > the Initiator Node Name for this purpose rather than a Port Name. > > > If we do (b), then we're effectively having hte target "name/identify" SCSI > Initiator Port. OK, now, suppose the initiator has two sessions active to > given target portal group. On one (say with TSID=5) he sends persistent > reserve registration and on another (say with TSID=7) he sends persistent > reserve registration + reservation. Now the target resets and the > initiator cleans up context and starts up one new session. What does the > target do? Does it assign TSID=5 or 7 or 9? If the Initiator wants the state from TSID 5 (or 7), the Initiator sets TSID to 5 (or 7) on Login. If the Initiator does not want that state, it sets TSID to 0 on Login, and the Target can assign 9 or 15 or 523. If the Target has removed or lost the state for TSID 5 or 7, the Initiator gets back an error when attempting to login using those TSID values. Targets SHOULD NOT aggressively reuse TSID values to avoid possible confusion (e.g., if in the interim, the Target has assigned 5 to a new session from the same Initiator, confusion may result - correctly written Initiators can avoid such confusion, but not aggressively reusing TSID values increases robustness). [.. text asking how the above could work elided ..] > I don't know what you mean by (c). What "purpose" are you talking about? Access control. I think it should be clear by now that given the choice, iSCSI Node Names are the preferred entities to use to express Access Control policy and decisions, not iSCSI Port Names. Note that my (a), (b), and (c) were intended to respond to your (a), (b) and (c). > I would plan to deal with "future extensions" via a possible "future text key" > to be specified after the "future extensions" are so that we have a concrete > set of requirements and objectives to work to. In the Interim, we can > advise T10 that iSCSI strongly prefers reservations to be associated with > Initiators, rather than Initiator Ports. > > > In fact, if we do find an alternative to the ISID for naming SCSI Initiator > > Ports, then the ISID would be irrelevant to the SCSI model (as the TSID is > > now) and we won't need the ISID rule anymore (we'd need another rule for > > port names, however). > > This includes one more reason: > > (d) iSCSI entity to which the SAM2 concept of SCSI Initiator Port maps to. > > As we discussed, and I think agreed, earlier, it is sufficient to assert > the existence of such an entity in an iSCSI implementation (some sort of > session data structure) for the purpose of mapping, but not provide an > externally visible name that is independently useful outside the bounds of > the specific iSCSI implementation. > > > But I also argued that existing OS's like to see some consistency (you've > even said they put stuff in /dev) on their initiator ports. If these are > all driven by the target (in the sense of identification), then where can > the iSCSI layer provide such consistency? > It won't be the TSID, and it probably won't be the ISID because, as currently specified, it also lacks sufficient consistency for this purpose. The info will come out of local device configuration information on the Initiator, which may or may not turn out to match up with Initiator Portal Groups. This kind of thing is already platform-specific and will remain so. Folks like Veritas will continue to rely on their own volume headers for configuration of VxVM and the like rather that device names (FWIW, this is the only technique that has proven to have sufficient robustness in practice). > > We can then ask if there is any value in the iSCSI > > protocol for either the ISID or the TSID (as I did many many > > months ago prior to this dicussion). > > I'm not seeing any. We might be better off using that field to hold > the Target Portal Group number; TSIDs would then only need to be unique > to an Initiator within a Target Portal Group, and hence could be > independently managed on a per-Portal Group basis, as opposed to the > current TSID RULE that spans the entire Target (instead of configuring > TSID ranges, one configures the Portal Group Number, which probably > needs to be configured anyway). This also makes any attempt to span > Target Portal Groups or recover a session across Target Portal Groups > immediately obvious to the Target (the first is forbidden, the > second might work, but probably requires special handling at the Target, > and may need some more protocol support). One consequence of > this field change would be to add Target Portal Group to (b) above, and > that may actually be a good thing as it forces exposure of this > fundamental level of structure. > > > You're proposal to include the target portal group number in the TSID is an > *implementation of configuring TSID ranges* for each target portal group, > isn't it? In fact, that would be how I would implement it my target (if I > was building one, whether the spec said that it had this form or not -- and > I'm implement my host driver pretty much the same way, via enumeration of > drivers/devices (which pretty much constitute initiator portal groups) as > they are discovered/loaded by the OS). Such an implementation guarantees > compliance with the TSID RULE (and would do the same for the ISID RULE as > well). So, you haven't avoided it, you've simply spec'ed an implementation > that meets the requirements. > > The proposal to include the target portal group tag in the message header > (either within or separate from the TSID) is an independent issue from the > ISID one. > I agree, but observe that if we specify the one and only way in which the Target Portal Group MUST be encoded in the TSID, then code can be written in both iSCSI implementations and management tools that relies on the encoding being done that way. I think there's value to that. --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 Oct 4 19:57: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 TAA26481 for ; Thu, 4 Oct 2001 19:57:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94NEpb03589 for ips-outgoing; Thu, 4 Oct 2001 19:14:51 -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 f94NEnl03578 for ; Thu, 4 Oct 2001 19:14: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 5F4EE2F4C for ; Thu, 4 Oct 2001 17:14:48 -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 81E9C58D for ; Thu, 4 Oct 2001 17:14:47 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id QAA08275 for ips@ece.cmu.edu; Thu, 4 Oct 2001 16:13:47 -0700 (PDT) From: Dave Sheehy Message-Id: <200110042313.QAA08275@acropora.rose.agilent.com> Subject: RE: iscsi : DataPDULength can differ in each direction. To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Thu, 04 Oct 2001 16:13:46 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Comments in text. > > > Can someone give a tangible benefit to this that can > > outweigh the > > > spec and implementation churn at this late stage of the game? > > > > It would allow iSCSI HBAs to interact more efficiently > > with SW iSCSI > > implementations and vice versa. > > > > I don't believe it would in practice. Consider the following. The max > PDU size sent during login is more that just that, it is in fact the > senders maximum supportable max PDU size. If one side sends 64k and > the other side 8k although it is technically indicating it can't > receive more than 8k in a single PDU, for all practical purposes it is > also indicating it can't handle, and therefore can't send PDUs bigger > than 8k. I think that's a faulty interpretation of what's being proposed. As in both Fibre Channel and TCP the offered PDU size is the size you're willing to accept. It can and often is completely decoupled from the size you're capable of sending. This is commonly implemented in Fibre Channel and it's not exactly rocket science. > I believe if we go this route we'll simply see the side with the lower > DataPDULength sending its "natural" size PDUs and never sending the > larger size wanted by the other side. More on this below ... > > > > From my point of view the benefit of asymmetric PDU > > sizes would have > > > to be very large to make it worth the extra complexity > > in buffer > > > management code alone. > > > > >From the vantage point of an iSCSI HBA it doesn't seem > > all that hard. > > > > Well, it seems to me faced with a peer with a different max PDU size > there are relatively few ways to proceed. Again, I believe it's fairly straightforward and there are real life examples that work exactly this way. The only unfortunate thing is that it's been proposed at this late date. In hind sight, it's a feature with an obvious benefit. > If the peer has a lower max PDU size there are 2 choices. Use 2 buffer > pools, one for receive set to the local Max PDU size, and one for send > set to the peer Max PDU size. This is where the extra buffer > management complexity comes in. Or, use one buffer pool and simply > part fill the buffers for sending. This is the easy case. I don't see what buffer size has to do with PDU size that's not implementation dependent. The PDU content is going to be fragmented anyway (i.e. network header, iSCSI header, data, digest, ...) so the problem you describe exists regardless. > If the peer has a larger max PDU size then either only send up to the > local PDU size, as I mentioned above, or chain buffers together to > build larger than the local max PDU size. Again, this is where the > extra buffer management complexity comes in. Remember that by > definition these chains will need to be bigger than the largest chain > size the implementation can handle. Unless for some reason the > DataPDULength sent was chosen at some arbitrary size smaller than the > implementations maximum. I think SW iSCSI stacks are going to want to use big PDUs and in general iSCSI HBAs are going to use small ones. I think the SW stacks are going to set up their buffer structures to use large PDUs. I don't think (although it's certainly possible) that they are going to dynamically adjust their buffer sizes for each iSCSI session. So, in the scenario where a SW iSCSI stack is talking to an iSCSI HBA it's buffering is going to be used inefficiently in both directions. If the Data PDU Length is negotiated separately for each direction then the buffering on the SW side is being used inefficiently in only one direction. Both sides win with this behavior. Dave From owner-ips@ece.cmu.edu Thu Oct 4 20:02: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 UAA26531 for ; Thu, 4 Oct 2001 20:02:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f94NEoo03587 for ips-outgoing; Thu, 4 Oct 2001 19:14: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 f94NEml03573 for ; Thu, 4 Oct 2001 19:14:48 -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 55BC328F3; Thu, 4 Oct 2001 17:14:47 -0600 (MDT) Received: from axcsbh5.cos.agilent.com (axcsbh5.cos.agilent.com [130.29.152.150]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 211735A4; Thu, 4 Oct 2001 17:14:47 -0600 (MDT) Received: from 130.29.152.150 by axcsbh5.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 04 Oct 2001 17:14:46 -0600 Received: by axcsbh5.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 17:14:46 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A008390E7D@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , ips@ece.cmu.edu Subject: Re: iSCSI: Serial Number Arithmetic Date: Thu, 4 Oct 2001 17:14:40 -0600 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 draft says serial number arithmetic as defined in RFC 1982 is to be used for comparisons and arithmetic on CmdSN but but it uses operations which are inconsistant with that statement. 2.2.2.1 (bottom half of page 26) re: the processing for MaxCmdSN and ExpCmdSN - "and with a difference bounded by 2**31-1" should be deleted (3 places). The RFC 1982 Serial Number Arithmetic rules cover the meaning of addition of a positive integer of limited range and comparison (<, > and =) for serial numbers. "Only two operations are defined upon serial numbers, addition of a positive integer of limited range, and comparison with another serial number." The operation difference is not defined for Serial Numbers. 2.2.2.2 re: "difference is greater than 2**31-1" - The operation difference is not defined for Serial number arithmetic. Even if it was defined as the inverse of addition, addition is only defined for adding a value up to 2**31-1. Is the intent of the statement that it should cover only the value where the results of StatSN > ExpStatSN and StatSN < ExpStatSN are undefined or is the intent that it cover that value plus the values where ExpStat > StatSN? The former doesn't seem useful and the latter seems rather severe. Regards, Pat Thaler From owner-ips@ece.cmu.edu Thu Oct 4 20:50: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 UAA26808 for ; Thu, 4 Oct 2001 20:50:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f950QIx07720 for ips-outgoing; Thu, 4 Oct 2001 20:26:18 -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 f950QHl07715 for ; Thu, 4 Oct 2001 20:26:17 -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 EEB933389; Thu, 4 Oct 2001 18:26:16 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id AA89C568; Thu, 4 Oct 2001 18:26:16 -0600 (MDT) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 18:26:16 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A008390EA5@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , "'Santosh Rao'" , Rod Harrison Cc: Ayman Ghanem , ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Thu, 4 Oct 2001 18:26:15 -0600 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 Sanjeev, I don't see how allowing each side to independently specify the DataPDULength it can accept complicates anything. If Device X can receive 10 Kbyte PDUs and Device Y can only receive 2 Kbyte PDUs, then the implication of allowing them to be independent is Device X can only send 2 Kbyte PDUs to Device Y - it has to obey Device Y's input limitations. Device Y may send 10 Kbyte PDUs to Device X if it has that capability or it can send 2 Kbyte PDUs if its transmit side isn't able to send longer ones. The transmitter isn't required to send the maximum PDU size that the receiver can handle. Furthermore, in many cases buffer pools will be shared among multiple connections. Therefore a buffer management strategy that depends upon the max PDU length would be non-ideal. Pat -----Original Message----- From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] Sent: Wednesday, October 03, 2001 3:26 PM To: 'Santosh Rao'; Rod Harrison Cc: Ayman Ghanem; ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. All, I think making DataPDULength different on two side will bring complexity in implementation. Calculation of CRC, handling unknown and very high value of DataPDUlength, change in buffer management code etc etc and above all.. a radical change so late in the specs chould be avoided. In my view we rather can choose for either of the two ways 1. Either make DataPDULength as list negotiation, which makes sure that the computing party choses a result which other party will definitley support or 2. keep it like numeric negotiation with result being computed by responding party and double checked by the offering party. In case there is still any error when the offering party gets the result, they may either go for reject or re-nogotiation. Sanjeev -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, October 03, 2001 11:46 PM To: Rod Harrison Cc: Ayman Ghanem; ips@ece.cmu.edu Subject: Re: iscsi : DataPDULength can differ in each direction. Rod, The issue came up as a result of Deva pointing out that an initiator may not be able to function with the minimal of the 2 DataPDULengths (initiator's & target's) in the case where the value chosen was not its value. In order to allow for such implementations that had issues with the DataPDULength, I raised this question. The benefit of both sides being allowed different DataPDULengths is : a) Each side can specify its max supported value which the other side would not exceed. The sender & receiver would be able to function with different DataPDULengths, with the guarantee that their advertised receive pdu length will not be exceeded, thus, allowing more flexible interoperability of implementations. (btw, the proposal should have read : Each side is allowed to advertise its maximum receive pdu length.) b) It may also allow 2 parties with differing PDU lengths to send larger sized PDUs in one direction to the party that advertised a higher receive pdu length. However, I do admit there's a cost to making this change, given we are so late in the draft rev and several implementations have already been made. If this is not an issue of concern to the majority of implementations, I am ok with the current definition, although it is more limiting on implementations. Thanks, Santosh Rod Harrison wrote: > > Can someone give a tangible benefit to this that can outweigh the > spec and implementation churn at this late stage of the game? > > From my point of view the benefit of asymmetric PDU sizes would have > to be very large to make it worth the extra complexity in buffer > management code alone. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Ayman Ghanem > Sent: Wednesday, October 03, 2001 8:29 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : DataPDULength can differ in each direction. > > Well, the proposal says: > > Each side should be allowed to specify the DataPDULength it will be > using and there should be no attempt to negotiate this value. Rather, > the key is exchanged in either direction to inform the other side as > to > what sized PDUs it should expect. > > So, I understand that as if the initiator sends > DataPDULength=reallyBigNumber, then it is informing the target that > this is > what it will be using, but the target should not attempt to negotiate > it. > > -Ayman > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf > Of > > Buck Landry > > Sent: Wednesday, October 03, 2001 2:13 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > > > It may add complexity, but, since DataPDULength is only a boundary > on > > the maximum number of bytes transmitted in a Data PDU (not the > minimum), > > "the first" *does* have a say about it. Right? > > > > -----Original Message----- > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > Sent: Wednesday, October 03, 2001 1:38 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > > > I think this will add unnecessary complexity, specially for data > CRCs > > having > > to be calculated based on two different PDU sizes for Reads and > Writes. > > Also, one end may choose to do data digests in software. If the > other > > end > > decides to use a really large PDU length (and the first doesn't have > a > > say > > about it), this could be a problem. > > > > -Ayman > > > > > > -- ################################## 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 Oct 4 20:54: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 UAA26847 for ; Thu, 4 Oct 2001 20:54:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f950c4A08353 for ips-outgoing; Thu, 4 Oct 2001 20:38: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 (81033r2ce.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f950c2l08348 for ; Thu, 4 Oct 2001 20:38:03 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Oct 2001 02:40:05 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B989D@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'THALER,PAT (A-Roseville,ex1)'" , "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , "'Santosh Rao'" , Rod Harrison Cc: Ayman Ghanem , ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Fri, 5 Oct 2001 02:39:58 +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 Pat, Sorry for my previous response. I have tried to re-examine the things on my own end. I think i am going to agree with you. I donot think buffer complexity will be any issue as the two things can be very easily handled. but i do have one doubt at this moment for buffer management: If the dataPDUSize as informed by the responder is very high and initiator cannot supply that high PDU size because it does not have enough capacity to make that huge amount of dataPDUSize , dont u think it will paralyze the initator's end. ( i might be wrong, but i think there is a limit to sender's buffer sending capacity as well. And if that is so then there has to be a negotiation of the dataPDUSize. Sanjeev -----Original Message----- From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com] Sent: Friday, October 05, 2001 2:26 AM To: Sanjeev Bhagat (TRIPACE/Zoetermeer); 'Santosh Rao'; Rod Harrison Cc: Ayman Ghanem; ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. Sanjeev, I don't see how allowing each side to independently specify the DataPDULength it can accept complicates anything. If Device X can receive 10 Kbyte PDUs and Device Y can only receive 2 Kbyte PDUs, then the implication of allowing them to be independent is Device X can only send 2 Kbyte PDUs to Device Y - it has to obey Device Y's input limitations. Device Y may send 10 Kbyte PDUs to Device X if it has that capability or it can send 2 Kbyte PDUs if its transmit side isn't able to send longer ones. The transmitter isn't required to send the maximum PDU size that the receiver can handle. Furthermore, in many cases buffer pools will be shared among multiple connections. Therefore a buffer management strategy that depends upon the max PDU length would be non-ideal. Pat -----Original Message----- From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] Sent: Wednesday, October 03, 2001 3:26 PM To: 'Santosh Rao'; Rod Harrison Cc: Ayman Ghanem; ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. All, I think making DataPDULength different on two side will bring complexity in implementation. Calculation of CRC, handling unknown and very high value of DataPDUlength, change in buffer management code etc etc and above all.. a radical change so late in the specs chould be avoided. In my view we rather can choose for either of the two ways 1. Either make DataPDULength as list negotiation, which makes sure that the computing party choses a result which other party will definitley support or 2. keep it like numeric negotiation with result being computed by responding party and double checked by the offering party. In case there is still any error when the offering party gets the result, they may either go for reject or re-nogotiation. Sanjeev -----Original Message----- From: Santosh Rao [mailto:santoshr@cup.hp.com] Sent: Wednesday, October 03, 2001 11:46 PM To: Rod Harrison Cc: Ayman Ghanem; ips@ece.cmu.edu Subject: Re: iscsi : DataPDULength can differ in each direction. Rod, The issue came up as a result of Deva pointing out that an initiator may not be able to function with the minimal of the 2 DataPDULengths (initiator's & target's) in the case where the value chosen was not its value. In order to allow for such implementations that had issues with the DataPDULength, I raised this question. The benefit of both sides being allowed different DataPDULengths is : a) Each side can specify its max supported value which the other side would not exceed. The sender & receiver would be able to function with different DataPDULengths, with the guarantee that their advertised receive pdu length will not be exceeded, thus, allowing more flexible interoperability of implementations. (btw, the proposal should have read : Each side is allowed to advertise its maximum receive pdu length.) b) It may also allow 2 parties with differing PDU lengths to send larger sized PDUs in one direction to the party that advertised a higher receive pdu length. However, I do admit there's a cost to making this change, given we are so late in the draft rev and several implementations have already been made. If this is not an issue of concern to the majority of implementations, I am ok with the current definition, although it is more limiting on implementations. Thanks, Santosh Rod Harrison wrote: > > Can someone give a tangible benefit to this that can outweigh the > spec and implementation churn at this late stage of the game? > > From my point of view the benefit of asymmetric PDU sizes would have > to be very large to make it worth the extra complexity in buffer > management code alone. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Ayman Ghanem > Sent: Wednesday, October 03, 2001 8:29 PM > To: ips@ece.cmu.edu > Subject: RE: iscsi : DataPDULength can differ in each direction. > > Well, the proposal says: > > Each side should be allowed to specify the DataPDULength it will be > using and there should be no attempt to negotiate this value. Rather, > the key is exchanged in either direction to inform the other side as > to > what sized PDUs it should expect. > > So, I understand that as if the initiator sends > DataPDULength=reallyBigNumber, then it is informing the target that > this is > what it will be using, but the target should not attempt to negotiate > it. > > -Ayman > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf > Of > > Buck Landry > > Sent: Wednesday, October 03, 2001 2:13 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > > > It may add complexity, but, since DataPDULength is only a boundary > on > > the maximum number of bytes transmitted in a Data PDU (not the > minimum), > > "the first" *does* have a say about it. Right? > > > > -----Original Message----- > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > Sent: Wednesday, October 03, 2001 1:38 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > > > I think this will add unnecessary complexity, specially for data > CRCs > > having > > to be calculated based on two different PDU sizes for Reads and > Writes. > > Also, one end may choose to do data digests in software. If the > other > > end > > decides to use a really large PDU length (and the first doesn't have > a > > say > > about it), this could be a problem. > > > > -Ayman > > > > > > -- ################################## 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 Oct 4 20:59: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 UAA26880 for ; Thu, 4 Oct 2001 20:59:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f950AvQ06834 for ips-outgoing; Thu, 4 Oct 2001 20:10:57 -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 f950Atl06830 for ; Thu, 4 Oct 2001 20:10:55 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id B837A1F513; Thu, 4 Oct 2001 17:10: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 RAA05982; Thu, 4 Oct 2001 17:10:45 -0700 (PDT) Message-ID: <3BBCFC2D.DC567B88@cup.hp.com> Date: Thu, 04 Oct 2001 17:17:49 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Julian Satran , IPS Reflector Subject: Re: iscsi : originating & responding parties in login. 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 don't understand why that requirement exists. An initiator should be considered as the originator if he sends a login key implicitly thru the use of defaults. This ensures that the login process ends at the initiator and avoids redundant login handshakes. Could you please explain further as to why you need to differentiate b/n an initiator that sent keys explicitly and one that used defaults ? Thanks, Santosh Julian Satran wrote: > > Santosh, > > The reason for this negotiation rule is to make it stateless. > > Julo > > Santosh Rao > To: Julian > Sent by: santoshr@cup.hp.com Satran/Haifa/IBM@IBMIL > cc: IPS Reflector > 03-10-01 23:23 > Please respond to Santosh Rao Subject: Re: iscsi : > originating & responding parties in > login. > > > > Julian Satran wrote: > > > Julian Satran wrote: > > > > > As negotiations can start at either initiator or target the > > originator > > > the one that starts the negotiation. > > > > Julian, > > > > OTOH, since the initiator did offer a value (the default value), > is'nt > > it always the originator ? In which case [other than a target vendor > > specific proprietary key] would an operational negotiation start at > > the > > target ? > > +++ offering a value is an active thing. Defaults and previous > values > > don't count. +++ > > This is intriguing. If an initiator explicitly sent a key value > (albeit, > with the key initialized to the default), the initiator is considered > the originator. However, if the initiator chose to not send the key > explicitly, but use the default, it then becomes the responder. [if > target does not accept the default.] > > This leads to different on-the-wire login behaviour if the initiator > chose to use defaults instead of sending those same key values > explicitly. It also causes an additional dummy login hand-shake for no > purpose. > > Thus, in the case where initiator wants to use, say, > FirstBurstSize=128 > & target allows FirstBurstSize to be 8, then, the behaviour on the > wire > is different depending on whether the initiator used the default or > explicitly sent the key. > > Case 1) Initiator sends the default value as an explicit offering > ------------------------------------------------------------------ > I -> T : FirstBurstSize=128 (initiator is the originator) > (CSG=Operational, NSG=FFP). T=1 > > T -> I : FirstBurstSize=8 (target responds with lower value it > supports.) > (CSG=Operational, NSG=FFP). T=1 > > Negotiation ends at initiator with both sides picking > FirstBurstSize=8. > Single login handshake. > > Case 2) Initiator does not send the key. (default is in use). > ------------------------------------------------------------- > I -> T : (no key sent). (defaults to 128.) > (CSG=Operational , NSG=FFP). T=1 > > T -> I : FirstBurstSize=8 > (CSG=Operational, NSG=Operational). T=0 > > I -> T : FirstBurstSize=128 (initiator explicitly resends the default > !). > (CSG=Operational, NSG=FFP). T=1 > > T -> I : (no key sent. but a dummy login response to conclude login is > sent). > (CSG=Operational, NSG=FFP). T=1 > > Negotiation ends at the target, with both sides settling at > FirstBurstSize=8 > Login phase ends at the initiator. 2 login handshakes. > > Julian : What is the benefit of the above behaviour ? It results in > inconsistent login behaviour and will only cause initiators to send > login keys explicitly, defeating the purpose of defining defaults. > > I would rather the spec state that the initiator is the originator of > the key when it uses default values, so that the login behaviour is > the > same in both scenarios above. > > Thanks, > Santosh > > > > > > > Julian, > > > > > > I've YET another login question for you : > > > > > > Please refer the following text in Section 2.2.4 of the Rev 08 > draft > > : > > > > > > "For numerical negotiations, the responding party MUST respond > with > > > the > > > required key." > > > > > > When the initiator uses the default settings for a login key (i.e. > > > does > > > not send the key) and a target does not support that default, it > has > > > to > > > originate the key in its login response to notify the initiator > that > > > it > > > does not support the default. > > > > > > In the above example, who is the originating party & responding > > party > > > ? > > > Is the initiator always considered an originating party for all > the > > > operational and security keys, even if it did not explicitly send > > that > > > key in its login ? > > > > > > If the target originated a login key, say DataPDULength, (and is > > > therefore, to be considered as the originating party ?), based on > > your > > > rule quoted above, the exchange would be : > > > > > > I -> T : (no key is sent for DataPDULength. Assumes default of 16 > > > units. > > > (8K).) > > > > > > T -> I : DataPDULength=8 > > > > > > I -> T : DataPDULength=8 (See quoted rule above.) > > > > > > The definition of originating & responding party is not clear when > > > defaults are used by the initiator and can lead to [mis- > > > ?]interpretations such as the above. > > > > > > The above response from I -> T seems redundant to me. I suggest > that > > > the > > > draft clearly state who the originating & responding party are > when > > > defaults are used, so as to avoid confusion along the above lines. > > > > > > 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 Thu Oct 4 21:00: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 VAA26910 for ; Thu, 4 Oct 2001 21:00:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f950eWk08493 for ips-outgoing; Thu, 4 Oct 2001 20:40:32 -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 f950eUl08486 for ; Thu, 4 Oct 2001 20:40:30 -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 AA7D62F24; Thu, 4 Oct 2001 18:40:29 -0600 (MDT) Received: from axcsbh1.cos.agilent.com (axcsbh1.cos.agilent.com [130.29.152.143]) by msgrel1.cos.agilent.com (Postfix) with ESMTP id 8C42A28F; Thu, 4 Oct 2001 18:40:29 -0600 (MDT) Received: by axcsbh1.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 18:40:29 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A008390EB0@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Ayman Ghanem , ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Thu, 4 Oct 2001 18:40:28 -0600 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 Ayman, A few people have raised the issue of added complexity because of the CRC calculation having to be done on different PDU sizes and I don't understand the difficulty. No matter what maximum PDU size one supports one has to do the CRC on the actual PDUs which are sent which will vary. One doesn't always send the maximum - sometimes the write or read is for less data than that. Anyway the calculation is done one byte/word/(other chunk size) at a time until one gets to the end of the PDU regardles of the length. I would appreciate if someone could clarify why different max PDU sizes complicate CRC calculation. Pat -----Original Message----- From: Ayman Ghanem [mailto:aghanem@cisco.com] Sent: Wednesday, October 03, 2001 11:38 AM To: ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. I think this will add unnecessary complexity, specially for data CRCs having to be calculated based on two different PDU sizes for Reads and Writes. Also, one end may choose to do data digests in software. If the other end decides to use a really large PDU length (and the first doesn't have a say about it), this could be a problem. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Santosh Rao > Sent: Wednesday, October 03, 2001 12:32 PM > To: Dev - Platys; Julian Satran > Cc: Sandeep Joshi; ips@ece.cmu.edu > Subject: iscsi : DataPDULength can differ in each direction. > > > Deva, Julian & All, > > I think we have a more fundamental problem here, that spans beyond the > issue of which negotiation model should be used for numerical & binary > key negotiation. This problem needs to be addressed seperately. > > The DataPDULength can and should be allowed to be different in each > direction. I -> T direction PDUs should be allowed to use a different > PDU Length than T -> I direction PDUs. > > Each side should be allowed to specify the DataPDULength it will be > using and there should be no attempt to negotiate this value. Rather, > the key is exchanged in either direction to inform the other side as to > what sized PDUs it should expect. > > This is somwhat akin to a protocol's MTU definition or a max_frame_size > definition (ex : FC PLOGI Receive Data Field Size in its common service > parameters.). THese values are allowed to be different going in each > direction, allowing for implementation specific quirks that restrict the > use of certain values. (ex : some DMA bugs may require implementations > to have their DataPDULength to be a cache line size shorter, etc.) > > I suggest the definition of the DataPDULength key be re-phrased taking > the above into account. > > Regards, > Santosh > > Dev - Platys wrote: > > > > Santosh, > > > > The point is, if the target is not capable of supporting 16K > (it is just an > > example that is being discussed), then it indicates that is > what it wants. > > Initiator can close the connection. (No reject is necessary though). > > > > However, if the target knows it can support the initiator > negotiated value, > > it could return it. > > > > Again, Yes, implicitly it becomes the responder selects logic. > > > > Deva > > Adaptec > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Sandeep Joshi > > Sent: Wednesday, October 03, 2001 7:29 AM > > To: ips@ece.cmu.edu > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > The first & third example below seem illogical. > > > > The responder should not be sending 24K if the initial > > sender has chosen a value of 16K, since there is no > > possibility of that 24K being accepted (unless we want > > three way exchanges for every negotiation??) > > > > The problem of a Reject message does not arise since the > > responder should only be choosing something less than 16K. > > So I guess this puts me in the "responder selects logic" > > camp. > > > > -Sandeep > > > > Julian Satran wrote: > > > > > > An example: > > > 08.txt logic > > > i->t DataPDULength=16k > > > t->i DataPDULength= 24k > > > > > > Selected value is 16k > > > > > > i->t DataPDULength=16k > > > t->i DataPDULength= 8k > > > > > > Selected value is 8k > > > > > > t->i DataPDULength=16k > > > i->t DataPDULength= 24k > > > > > > Selected value is 16k > > > > > > t->i DataPDULength=16k > > > i->t DataPDULength= 8k > > > > > > Selected value is 8k > > > > > > ----- > > > > > > Responder selects logic > > > > > > i->t DataPDULength=16k > > > t->i DataPDULength= 24k > > > > > > Error - Initiator Reject - Closes connection > > > > > > i->t DataPDULength=16k > > > t->i DataPDULength= 8k > > > > > > Selected value is 8k > > > > > > t->i DataPDULength=16k > > > i->t DataPDULength= 24k > > > > > > Error Target has to terminate with parameter error > > > > > > t->i DataPDULength=16k > > > i->t DataPDULength= 8k > > > > > > Selected value is 8k > > > > > > "Dev - Platys" > > > To: "Julian Satran" > > > , > > > 01-10-01 23:46 > > > Please respond to "Dev - cc: > > > Platys" Subject: RE: iscsi : > > > numerical negotiation wording is ambiguous > > > > > > > > > > > > Julian, > > > > > > I am not sure why a 'REJECT' is required. > > > Can you please explain why is this required? > > > > > > I am with Santosh in this. > > > > > > >There is NO need for any REJECT in the above >case. If the initiator > > > >is'nt satisfied with the value returned by the >originator and cannot > > > >function with the negotiated values, it can simply >close the TCP > > > >connection. There is no need to send any >REJECT. > > > > > > Thanks > > > > > > Deva > > > Adaptec > > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > Julian Satran > > > Sent: Monday, October 01, 2001 1:28 PM > > > To: ips@ece.cmu.edu > > > Subject: Re: iscsi : numerical negotiation wording is ambiguous > > > > > > Santosh, > > > > > > We are getting nowhere. Even if requester is doing it's stuff - the > > > requester will have to check and be prepared for a mistake. The coding > > > will require a reject. > > > > > > Julo > > > > > > Santosh Rao > > > To: ips@ece.cmu.edu > > > Sent by: cc: "Sanjeev Bhagat > > > santoshr@cup.hp.com (TRIPACE/Zoetermeer)" , > > > Julian Satran/Haifa/IBM@IBMIL > > > 01-10-01 20:37 Subject: Re: iscsi : numerical > > > Please respond to negotiation wording is ambiguous > > > Santosh Rao > > > > > > > > > Julian & Sanjeev, > > > > > > Responding to both your mails...... > > > > > > Julian : > > > > > > I think you may have mis-interpreted my comments. I believe Sanjeev > > > has > > > clarified the intent of my suggestions. > > > > > > I am *not* suggesting that the responder send back its values and > > > these > > > be blindly imposed on the originator. On the contrary, my suggestion > > > is > > > that the computation of the result of the negotiation (higher or lower > > > of the 2 values) be only performed by the responder and sent back to > > > the > > > originator. > > > > > > The result of the negotiation is the same in both cases and there is > > > no > > > REJECT required in my case nor yours. The difference is the advantages > > > I've stated in my model. > > > > > > Sanjeev, in response to your comment : > > > > > > " [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > > no reject , but it can be a problem in future . > > > > Consider your example of DataPDULength in your own > > > > message. Suppose offering party sends a value of 16,384 > > > > (this is also lowest value it can send) and responding > > > > party responds with 8,192. In this case the offering > > > > party will have to reject the negotiation. So a reject > > > > message is needed in this case also. " > > > > > > There is NO need for any REJECT in the above case. If the initiator > > > is'nt satisfied with the value returned by the originator and cannot > > > function with the negotiated values, it can simply close the TCP > > > connection. There is no need to send any REJECT. > > > > > > Thanks, > > > Santosh > > > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > > > Thanks Julian, please find my further comments in the message > > > > > > > > -----Original Message----- > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > Sent: Sunday, September 30, 2001 6:07 PM > > > > To: ips@ece.cmu.edu > > > > Subject: RE: iscsi : numerical negotiation wording is > > > > ambiguous > > > > > > > > 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 > > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] I would rather > > > > say it this way the responder computes the value with > > > > its own supported values and responds with a value y > > > > which the responder thinks is correct 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 > > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although correct, > > > > but it is highly unlikely for the responder to reject > > > > the final result because the rule states that (lower or > > > > higher of two will be the result) and so the offering > > > > party should be able to accept the lower or higher > > > > range as defined by rule. In case the key is dependent > > > > upon some range of fixed values then the negotiation > > > > should be performed as list negotiation and not > > > > numerical negotiation. > > > > > > > > This might be what you "conventionally" do - I don't > > > > and that shows that convention like morals are a matter > > > > of geography :-) > > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] :-) > > > > > > > > The advantage of this set of rules is that it allows an > > > > external observer to know what was selected without > > > > knowing the rules > > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Even in this > > > > case, I guess that the external observer has to know > > > > the rules to double check the value is correct or not > > > > 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. > > > > [Sanjeev Bhagat (TRIPACE/Zoetermeer)] Although there is > > > > no reject , but it can be a problem in future . > > > > Consider your example of DataPDULength in your own > > > > message. Suppose offering party sends a value of 16,384 > > > > (this is also lowest value it can send) and responding > > > > party responds with 8,192. In this case the offering > > > > party will have to reject the negotiation. So a reject > > > > message is needed in this case also. > > > > > > > > > > > > Sanjeev > > > > "Sanjeev Bhagat > > > > (TRIPACE/Zoetermeer)" To: "'Santosh > > > Rao'" > > > > , Julian > > > > Sent by: owner-ips@ece.cmu.edu Satran/Haifa/IBM@IBMIL > > > > cc: > > > ips@ece.cmu.edu > > > > 30-09-01 16:32 Subject: RE: > > > iscsi : > > > > Please respond to "Sanjeev numerical negotiation wording > > > is > > > > Bhagat (TRIPACE/Zoetermeer)" 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 > > > > > > > > > > -- > > > ################################## > > > 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 Oct 4 21:00: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 VAA26922 for ; Thu, 4 Oct 2001 21:00:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f950EGw07012 for ips-outgoing; Thu, 4 Oct 2001 20:14:16 -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 f950EFl07008 for ; Thu, 4 Oct 2001 20:14:15 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 77EFF1F65E; Thu, 4 Oct 2001 17:14:09 -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 RAA06090; Thu, 4 Oct 2001 17:14:04 -0700 (PDT) Message-ID: <3BBCFCEF.BAD23DE7@cup.hp.com> Date: Thu, 04 Oct 2001 17:21:03 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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, Thanks for incorporating the proposed change ! I suggest that all forms of negotiation use the same model. This includes login stage negotiation, binary key negotiation , list negotiation & numerical negotiation. The responder always sends back the result of the negotiation. The negotiation rules continue to apply. Only, they are now to be computed at 1 place alone, which is the target. In addition, I also suggest that the initiator always be considered originator & the target a responder. This is because the initiator ALWAYS makes the initial key offering, either explicitly or implicitly thru the use of a default. Thanks, Santosh Julian Satran wrote: > > Well - even I got fed-up with this long thread. > > Here the new text I am suggesting for the negotiations ("vox populi"): > > 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 and the value it selects, based on the selection rule > specific to the key, becomes the negotiation result. Selection of a > value not admissible under the selection rules is considered a > protocol error and handled accordingly. > > For Boolean negotiations (keys taking the values yes or no), 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). Both requestor and responder > MUST to compute the negotiated value based on the new value(s) > exchanged > > The value "?" with any key has the meaning of enquiry and should be > answered with the current value or "NotUnderstood". > > 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, only the initiator can initiate the negotiation start > (through the first Text request) and completion (by setting to 1 and > keeping to 1 the F bit in a Text request). > > Unless specified otherwise the negotiation process is stateless (based > only on newly presented values). > > Comments? > Julo > From owner-ips@ece.cmu.edu Thu Oct 4 21:06: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 VAA27015 for ; Thu, 4 Oct 2001 21:06:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f950bDB08317 for ips-outgoing; Thu, 4 Oct 2001 20:37:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f950b6l08305 for ; Thu, 4 Oct 2001 20:37:06 -0400 (EDT) Received: from hawk.corp.netapp.com (mh02 [10.10.20.101]) by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f950bM628422 for ; Thu, 4 Oct 2001 17:37:22 -0700 (PDT) Received: from ussvlexc06.corp.netapp.com (localhost [127.0.0.1]) by hawk.corp.netapp.com (8.12.0/8.12.0/NTAP-1.3) with ESMTP id f950axAN023759 for ; Thu, 4 Oct 2001 17:36:59 -0700 (PDT) Received: by ussvlexc06.corp.netapp.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Oct 2001 17:36:58 -0700 Message-ID: <02740A3D0809D5118C7C00034707E9F335FA10@USSVLEXC10> From: "Pittman, Joseph" To: "'ips@ece.cmu.edu'" Subject: iSCSI: Questions about naming, multi-pathing, multi-port targets Date: Thu, 4 Oct 2001 17:32:02 -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 am fairly new to the iSCSI effort, and this is my first question to the IPS mailing list. But I have been following the mailing list for awhile now, particularly the recent system identification discussions. And I am now working in earnest on an iSCSI target implementation, which has brought into focus the need for me to get a more complete understanding of the concepts. What is the expected naming and access model for a target with multiple physical ports/IP addresses? I understand from the iSCSI Naming and Discovery document that a target node presents one or more Portal Groups, and that an iSCSI session is conducted over exactly one portal group. Is it expected that a target with 4 ports will have a single "portal group"? Or 4 separate portal groups? Would operating system SCSI initiator code prefer to see 4 independent paths into the target, or a single session-layer path with multiple lower-level paths of connectivity? And how is the OS supposed to discover the association between target portals and their portal groups? In the FCP-SCSI world, each FC port on a multi-ported target device (e.g. SAN-connected disk array) is an independent communicating entity, with its own FC port and WWN. There is no concept of a networking session which spans multiple physical connections. As I understand it, the existence of multiple paths to the same underlying set of LUNs is detected by examining SCSI inquiry data from the detected devices. A driver (or a "wedge layer") within an operating system examines all available LUNs through all FCP HBAs under its control, and uses SCSI inquiry to detect the existence of multiple paths to the same LUN. The driver or wedge layer then advertises to the higher layers of the SCSI block storage stack only the set of unique target devices. The driver routes incoming SCSI requests from above to to one of the available paths, based on some algorithm which may take into account availability and relative performance of the paths. Now consider the case of adding support for iSCSI connectivity into an existing OS SCSI request stack. The most straightforward way for an iSCSI driver to drop into an existing infrastructure would be for a 4-port target to appear as 4 distinct DEVICES. The driver or "wedge layer", using IP address as the fundamental identifier for its notion of target identifier, would detect the presence of 4 separate "targets", use inquiries to detect multiple paths to the LUNs through these separate devices, etc. An approach which is more iSCSI-aware could take advantage of available config info (via static configuration? SLP? iSNS?) to recognize that all 4 IP addresses map to the same iSCSI Target Node. The ISID rule states that there can be only one session with a given ISID between an iSCSI Initiator and an iSCSI Target Portal Group. So how does the initiator discover the relationship between portals and groups on the target? And what would the OS implementors rather do, establish a separate session to each IP address, or establish a single session over each portal group? Impact on the target-mode implementer: should a target implementation endeavor to present a single portal group? Or a different group for each portal? Or a different group for each HBA (which may have one or more ports)? One factor in deciding this is the diversity of the possible approaches to handling iSCSI processing: - onboard a single-port HBA - onboard a multi-port HBA - within a driver in an embedded OS which uses a per-instance driver architecture - within a driver in an embedded OS which uses a per-device class driver architecture - within an overarching iSCSI management layer Any thoughts or guidance would be greatly appreciated. -- Joe Pittman jpittman@netapp.com From owner-ips@ece.cmu.edu Thu Oct 4 21:39: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 VAA28222 for ; Thu, 4 Oct 2001 21:39:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f950sLj09310 for ips-outgoing; Thu, 4 Oct 2001 20:54:21 -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 f950sJl09305 for ; Thu, 4 Oct 2001 20:54:19 -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 TAA48630; Thu, 4 Oct 2001 19:51:55 -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 f950r1H249246; Thu, 4 Oct 2001 18:53:02 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: ISID and the New Persistent Reservations Proposals 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, 4 Oct 2001 17:51:59 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/04/2001 06:53:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, I have spent some time stepping through the issues of Target Generation of SSID or ISID along with Persistent Reserves. I will start with Persistent Reserves and then move to the SSID/ISID issue. I have tried to lay it out persistent reserves so that everyone can follow it (may not work out but that is the attempt), I have also reviewed this with Jim Hafner, so unless I have some typos I think it is correct. Persistent Reserves have three new proposed versions: (in each of the following assume that the Initiator Node has 2 Ports A, and B, and the Target Node has 2 Ports X, and Y. Also the subject LUN is called LU5). I will start with point #0 that represents Persistent Reservations as of today, and then step through the 3 new options. 0. Today, Initiator Port A, can create a Persistent Reservation for LU5 with Target Port X, and then only I/O to LU5 can occur via the path from Initiator port A to Target Port X, all other I/Os to LU5 will be blocked. That is LU5 I/O via A to Y will be blocked as will B to X and B to Y. Three New additional proposals for handling Persistent reservations are being pushed by folks in T10: 1. Persistent reservations to LU5 can be made via Port A, and that will apply on the A to X path and the A to Y path. I/O to LU5 from Port B to either X or Y will be blocked. 2. Persistent reservation to LU5 made via Port A or Port B to Target Port X, will permit I/O to LU5 via Port A or B, if sent to Target Port X. However, I/O to LU5 via Initiator Ports A or Port B will be blocked if it is sent to Target Port Y. 3. Persistent reservation to LU5 made via Initiator Port A or Port B to Target Ports X or Y may occur, and I/O to LU5 may then occur via any path A to X, A to Y, B to X, or B to Y. In both todays model (#0) or in proposal #1 the Target needs to place the Persistent reservation against the Full iSCSI Initiator Port Name. This is the iSCSI Initiator Node Name Plus the ISID. In proposal #1 the Full iSCSI Initiator Port Name is then made known to all the target ports (in the same SCSI Device), and that name is then used to determine the Persistent Reservation State for each of the Target Ports relative to the subject LU. In proposal 2 and 3, above, the name to be used in the Reservations is just the iSCSI Initiator Node Name (No ISID). In proposal #2 the Name is not shared with the other Target Ports (in that SCSI Device) so Persistence only apples to I/O arriving at that Target Port from any Initiator port on the Initiator Node which made the Reservation. And in proposal 3 the iSCSI Initiator Node Name is shared among the Target Ports so that Persistence can be applied to any Target Port (in that SCSI Device), which is addressed by any Port on the Initiator Node which made the Reservation. Now, with regards to the issue that has been kicking around about the target assigning the SSID, it does not matter one way or the other with today's position #0 or proposal numbers 2 or 3. where the SSID comes from. However, proposal #1 needs a unique ISID, and can not use a dynamically created SSID generated by each target Port. There are other reasons why folks do not even want the ISID, or the SSID generated by the target, but those reasons have nothing to do with these Persistent Reservation proposals. I have been suggesting to the N &D team and others that if we limit the Dynamic Target Allocation to only the ISID (and of course the TSID) but not a complete SSID, that there may be a workable solution. I say ISID, since I believe it must be assured uniqueness per Initiator Port. One reason can be seen in #0, & #1 above. Now suppose that one of the Target's Job was to Generate a unique ISID for each Initiator Port, within and Initiator Node, which wanted to go into session. If you combine with that, the rule that if the Initiator Port sets and sends its own ISID on the Login the Target will accept it, and then use the Full Initiator Port Name to check for Persistent Reserves, I think we approach a working solution. Now you also have to ensure that upon a Target Boot, (which has to remember the Persistent Reservation Status), it needs to also remember the high water mark of ISIDs given out to each Initiator Node. With that high water mark the Target can continue assigning the ISIDs for that Initiator Node. Then I think your words were do not aggressively reused ISIDs. I think that if the Target has not gone down for a day or so, ISIDs not in use might be re-used, etc. We have 65K valid values per Initiator Node so reuse should not be a problem. OK now lets review what we have said. There is a way for a very simple routine on the Target to assign the ISIDs. If Sent an ISID in the Login it should accept it (if it can), and check on persistent reserves of type #0, or #1. The Initiator can save the ISID, in case it goes down and want to come back up, and reclaim the reserves, or it can blow the reserves away and start again with a Target assigned ISID. OK now in one of your last notes, I think you said a similar thing. This is also what I attempted to explain to the N &D team. So anyway, as good engineers we have been able to come up with something that works. The problem that the N & D team had is, so what. What we have now works, and has a smaller impact on the Target. So if it works we need to decide if we should do it or NOT, and focus the conversation on that. I had sent a note in previously that explained that if we have a way to set the iSCSI Initiator Node Name then we must have a way to set the ISID by the Initiator Node. Therefore, the question goes, why get the Target involved. Here is what I said in another note: If you accept that HBAs should get the iSCSI Initiator Node Name passed to it in some manner from the OS, then we did not see why it can not get the ISID at the same time also. If one were to argue that the HBA can not get the iSCSI Initiator Node Name, I think this is a bit strange, since almost every thing I install in systems, has to go through some type of Wizard, or vendor install routine that actually installs the support driver, etc. (This is all set when the OS is fully up and the Registry etc. is clearly available.) I would expect that with current OSs, this would be a normal approach. In the future, I suppose it might be possible that the OSs might have a more dynamic routine to hand out the iSCSI Initiator Node Name and ISID so that Hot Swap HBAs could come up without effort. However, until then, I am not sure it is unreasonable for a vendor to require the customer to run an update routine, even after performing an HBA Hot Swap. There is of course, the first up boot situation. I think it should be possible to have a default, first time HBA boot Name that uses the iqn form of the iSCSI Name, and an ISID of FFFF (not 0 as said previously). This should be enough to bring up a "first time up boot", since after the OS is started, the approprate install routine should be kicked off, and the real iSCSI Initiator Node Name and real ISID set in the Flash for that, and any other iSCSI HBAs. By the way I have a SCSI HBA in my personal system that runs its own BIOS routine and when it comes up, but before it boots, it asks questions if needed or just announces it is there. Configuration value can be entered at that time. So even that approach is possible. So based on the above, I do not think requiring the HBAs to have an install/update routine (which sets its Flash) is even a problem. This means that a Single iSCSI Initiator Node Name should be easy to obtain and will apply for all the iSCSI Initiators, whether HW or SW. And likewise it should be straight forward to secure the ISID at the same time. All this following well understood current install processes. Therefore, additional routines on the Target for handing out ISIDs should not be needed. OK, I tried to bring all the ISID issues together here so we could all examine them. I hope this was useful. . . . 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 Oct 4 21:41: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 VAA28246 for ; Thu, 4 Oct 2001 21:41:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f951NcG10990 for ips-outgoing; Thu, 4 Oct 2001 21:23:38 -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 f951Nal10985 for ; Thu, 4 Oct 2001 21:23:36 -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 UAA48538; Thu, 4 Oct 2001 20:21:12 -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 f951MJH26216; Thu, 4 Oct 2001 19:22:19 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: Questions about naming, multi-pathing, multi-port targets To: "Pittman, Joseph" Cc: "'ips@ece.cmu.edu'" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 4 Oct 2001 18:21:27 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/04/2001 07:22:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Joe, Unless there is an important reason to keep the Ports Separate, the most useful thing to do is to include them all in a single Portal Group. Some of the discussions that you may have seen have been mostly focused on the Initiator side, where there could be several different vendors' HBAs installed. But it was generally expected that if you create a Target, that you would have the same vendor HBAs in your Target. So when you select a vendor (assuming it is not your own companies), you would want them to be able to handle Multiple Connections per Session, across the Multiple Vendor HBAs. If you chose an HBA vendor that can not do that, then you might have 4 Portal groups each with one portal. Some vendors will also put more then one Ethernet Connection on their HBA and will be able to have Multiple Connections per Session within the HBAs. Some of these vendors will be able to gang several of those HBAs gather for an even larger Portal Group. Other vendors will not be able to group with other of their own HBAs, and you will again have a Portal Group per HBA. However, in this case the individual Portal Groups will contain the Multiple Ethernet Portals on each HBA. If on the other hand if you are making your own SW iSCSI implementation, and working with 4 NIC cards, you should be the one that creates the Multiple Connections per Sessions across all your NIC cards. If you plan on using a vendors HBA that knows how to Gang the HBAs into Portal Groups, your problem will be porting or having the vendor port their Device Driver into your NetApp operating environment. My PERSONAL opinion is that Bigger is Better. That is, the Larger the Portal Group the better. . . . 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 "Pittman, Joseph" @ece.cmu.edu on 10/04/2001 05:32:02 PM Sent by: owner-ips@ece.cmu.edu To: "'ips@ece.cmu.edu'" cc: Subject: iSCSI: Questions about naming, multi-pathing, multi-port targets I am fairly new to the iSCSI effort, and this is my first question to the IPS mailing list. But I have been following the mailing list for awhile now, particularly the recent system identification discussions. And I am now working in earnest on an iSCSI target implementation, which has brought into focus the need for me to get a more complete understanding of the concepts. What is the expected naming and access model for a target with multiple physical ports/IP addresses? I understand from the iSCSI Naming and Discovery document that a target node presents one or more Portal Groups, and that an iSCSI session is conducted over exactly one portal group. Is it expected that a target with 4 ports will have a single "portal group"? Or 4 separate portal groups? Would operating system SCSI initiator code prefer to see 4 independent paths into the target, or a single session-layer path with multiple lower-level paths of connectivity? And how is the OS supposed to discover the association between target portals and their portal groups? In the FCP-SCSI world, each FC port on a multi-ported target device (e.g. SAN-connected disk array) is an independent communicating entity, with its own FC port and WWN. There is no concept of a networking session which spans multiple physical connections. As I understand it, the existence of multiple paths to the same underlying set of LUNs is detected by examining SCSI inquiry data from the detected devices. A driver (or a "wedge layer") within an operating system examines all available LUNs through all FCP HBAs under its control, and uses SCSI inquiry to detect the existence of multiple paths to the same LUN. The driver or wedge layer then advertises to the higher layers of the SCSI block storage stack only the set of unique target devices. The driver routes incoming SCSI requests from above to to one of the available paths, based on some algorithm which may take into account availability and relative performance of the paths. Now consider the case of adding support for iSCSI connectivity into an existing OS SCSI request stack. The most straightforward way for an iSCSI driver to drop into an existing infrastructure would be for a 4-port target to appear as 4 distinct DEVICES. The driver or "wedge layer", using IP address as the fundamental identifier for its notion of target identifier, would detect the presence of 4 separate "targets", use inquiries to detect multiple paths to the LUNs through these separate devices, etc. An approach which is more iSCSI-aware could take advantage of available config info (via static configuration? SLP? iSNS?) to recognize that all 4 IP addresses map to the same iSCSI Target Node. The ISID rule states that there can be only one session with a given ISID between an iSCSI Initiator and an iSCSI Target Portal Group. So how does the initiator discover the relationship between portals and groups on the target? And what would the OS implementors rather do, establish a separate session to each IP address, or establish a single session over each portal group? Impact on the target-mode implementer: should a target implementation endeavor to present a single portal group? Or a different group for each portal? Or a different group for each HBA (which may have one or more ports)? One factor in deciding this is the diversity of the possible approaches to handling iSCSI processing: - onboard a single-port HBA - onboard a multi-port HBA - within a driver in an embedded OS which uses a per-instance driver architecture - within a driver in an embedded OS which uses a per-device class driver architecture - within an overarching iSCSI management layer Any thoughts or guidance would be greatly appreciated. -- Joe Pittman jpittman@netapp.com From owner-ips@ece.cmu.edu Thu Oct 4 22:24: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 WAA28711 for ; Thu, 4 Oct 2001 22:24:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f951eub12028 for ips-outgoing; Thu, 4 Oct 2001 21:40:56 -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 f951esl12024 for ; Thu, 4 Oct 2001 21:40:54 -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 UAA66394 for ; Thu, 4 Oct 2001 20:38:30 -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 f951dbH258668 for ; Thu, 4 Oct 2001 19:39:37 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI:Changes in Loging Negotiation To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 4 Oct 2001 18:38:45 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/04/2001 07:39:37 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Now that Julian has made the latest change, I think we are now polishing the knobs. We have a Plugfest coming up which is going to use version 8. (Maybe we can get in Julian's latest, but that is not sure.) Also we are out of time and version 9 is suppose to be editorial (if possible). So I know it is hard not to Polish, but unless it is an important show stopper lets get on with what ever else we need to do and leave this alone. Nothing in what I said should stop important changes, just please ask your self, is it important enough to perhaps cause yet another iteration. Remember it will not make the plugfest anyway. We should be focusing on closure here. This should apply to all the stuff we have to do. If it is a protocol change, you should consider it to be very important, else forget it. That is, not to say that we should not polish the Documents. We Should. . . . 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 Oct 5 06: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 GAA18095 for ; Fri, 5 Oct 2001 06:55:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95ADNl18410 for ips-outgoing; Fri, 5 Oct 2001 06:13: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 f95ADLl18405 for ; Fri, 5 Oct 2001 06:13:21 -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 MAA09602 for ; Fri, 5 Oct 2001 12:13:13 +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 f95ADDF61914 for ; Fri, 5 Oct 2001 12:13:13 +0200 Subject: Re: iSCSI: ImmediateData & InitialR2T To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 5 Oct 2001 12:24:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/10/2001 13:13:13 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk why ? Julo "Ayman Ghanem" .com> cc: Sent by: Subject: iSCSI: ImmediateData & InitialR2T owner-ips@ece. cmu.edu 04-10-01 17:42 Please respond to "Ayman Ghanem" Julian, The use of these two keys is currently set to "Use: ALL". I think they should be allowed only on the leading connection, so a second connection can not change them on the first. -Ayman From owner-ips@ece.cmu.edu Fri Oct 5 06:58: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 GAA18136 for ; Fri, 5 Oct 2001 06:58:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95ADRd18416 for ips-outgoing; Fri, 5 Oct 2001 06:13:27 -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 f95ADPl18412 for ; Fri, 5 Oct 2001 06:13:25 -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 MAA15828 for ; Fri, 5 Oct 2001 12:13: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 f95ADGP66502 for ; Fri, 5 Oct 2001 12:13:16 +0200 Subject: RE: iSCSI: ISID issue To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 5 Oct 2001 12:35:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/10/2001 13:13:16 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, Only a slight correction to ease your conscience. The text calls for a dynamic ISID allocated by the OS. Jim just suggested that in the kickoff stage implementation can get away with an almost static allocation and even later may use a dynamic partitioning scheme instead of a recourse to OS on every session creation. Julo Black_David@em c.com To: John Hufferd/San Jose/IBM@IBMUS, Sent by: ips@ece.cmu.edu owner-ips@ece. cc: cmu.edu Subject: RE: iSCSI: ISID issue 04-10-01 18:24 Please respond to Black_David John, Lacking additional visible support, I'm going to give up on this issue, but I think a serious mistake is being made. Two portions of your message reinforce my opinion: > However, there were some other things that we batted around that I will > cover here. First, the Name which you want to work with in the iSCSI ACLs > is the iSCSI Initiator Node Name. That should be the same for ALL iSCSI > Initiators in a Host Node. If vendors attempt to use anything else, I > think they are not following the spec. And should be sent to Singapore for > Caning :-) Not :-), rather an unrealistic exercise in wishful thinking. I have yet to see a coherent explanation of why this will not repeat the Fibre Channel Node WWN experience (which started out with the same intention and the same "not following the spec" notion for use of different Node WWNs on the same Platform - nonetheless, that's what happened). I expect problems to arise not so much in iSCSI ACLs (a new mechanism), but in the adaptation of existing SCSI LU access control mechanisms to iSCSI. > When Jim talked about the new SCSI idea that would have Persistent Reserves > being tied to the Initiator Node, it seemed clear to me, and I think to > the others on the team, that the iSCSI Initiator Node Name was ideal to be > used for that purpose. Jim pointed out, again to us, that this name was > NOT part of any other Nexus meaning, it is only to be used with Persistent > Reserves. All other Nexus meanings are against the iSCSI Initiator's FULL > NAME which is the iSCSI initiator Node Name and the ISID. That is a change from what Jim has described on the list, which required a persistent name for the iSCSI Initiator Port (not Node); what you have described in the above paragraph does not. Given that this sort of change is possible in what T10 is considering, I think we should cease trying to anticipate and provide for what T10 might (or might not) do, and instead deal with the results of what T10 does after it happens. The upshot is that ISIDs now serve no visible purpose, aside from complicating session setup - nonetheless, they're apparently going to stay in the specification ... did the N&D folks really intend this result? --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 Oct 5 07:10: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 HAA18464 for ; Fri, 5 Oct 2001 07:10:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95ADNC18409 for ips-outgoing; Fri, 5 Oct 2001 06:13: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 f95ADJl18400 for ; Fri, 5 Oct 2001 06:13:19 -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 MAA140800 for ; Fri, 5 Oct 2001 12:13: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 f95AD9P96666 for ; Fri, 5 Oct 2001 12:13:09 +0200 Subject: Re: [Fwd: iscsi : question on async message behaviour.] To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 5 Oct 2001 11:32:57 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/10/2001 13:13:10 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, I will add this although your request is on the "nitpicking" side as the draft states clearly and in several places that close the session is an acceptable action. However this has nothing to do with recovery since supporting individual connection login and logout is mandatory if you support multiple connections. The wording will be: Initiator MUST send a Logout with a reason code of "Close the connection" to cleanly shutdown the connection. The initiator MAY also issue a Logout with the reason code of "Close the session", to completely close the session, but ONLY if it does not support or use multiple connections in the specific session. Julo Santosh Rao cc: Sent by: Subject: [Fwd: iscsi : question on async message santoshr@cup.h behaviour.] p.com 03-10-01 23:27 Please respond to Santosh Rao Julian, One more issue that got dropped by the wayside. I'd appreciate if you could please incorporate the below change so that initiators that use session recovery are not considered non-conformant to the standard. Thanks, Santosh Santosh Rao wrote: > > Julian, > > Consider the below definition for handling of the "target requests > logout" async message : > > " 1 Target requests Logout. This Async Message MUST be sent on the > same connection as the one be 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." > > It specifies that initiators MUST use the "close the connection logout". > However, note that initiators are also allowed to use a "close the > session" logout when they only implement session recovery. > > Hope you will be able to re-word the above definition with session > recovery factored in. > > 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 Oct 5 07: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 HAA19224 for ; Fri, 5 Oct 2001 07:53:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95B4Pa20831 for ips-outgoing; Fri, 5 Oct 2001 07:04:25 -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 f95B4Ml20826 for ; Fri, 5 Oct 2001 07:04:22 -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 NAA102864 for ; Fri, 5 Oct 2001 13:04:14 +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 f95B4EP249472 for ; Fri, 5 Oct 2001 13:04:14 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Data Digest Error question X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Fri, 5 Oct 2001 14:04:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/10/2001 14:04:14, Serialize complete at 05/10/2001 14:04:14 Content-Type: multipart/alternative; boundary="=_alternative 003CDA7AC2256ADC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003CDA7AC2256ADC_= Content-Type: text/plain; charset="us-ascii" Yes there is a typo (the second appearance is yes). However the function is correctly stated as OR i.e. the result is yes if at least one of them wants order (it requires both to agree to say no). Julo "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 04-10-01 21:35 Please respond to cbm To: ips cc: Subject: Re: Data Digest Error question "Mallikarjun C." wrote: > > Prasenjit, > > The Reject mechanism is intended to be uniformly applicable to > all (recovery-savvy and otherwise) targets. > > Recovery R2T, OTOH, is only for ErrorRecoveryLevel>=1 capable > implementations (DataSequenceInOrder=true Sorry, that was supposed to be DataSequenceInOrder=no. Also, it appears to me that the result function for this key should be AND, and there's a typo in the description - it says "no" for both cases. Julian, comments? >as well, I think this > needs to be called out in its description), since a recovery R2T > implies going back in the data stream. > > The delivery subsystem failure status is the final termination > status (even though there were several good data PDUs after the > failed one) for ErrorRecoveryLevel=0 implementations, sent after > waiting for the F-bit. > > Hope that helps. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Prasenjit Sarkar wrote: > > > > This question relates to how the target handles data digest errors for data > > pdus. > > > > The spec says the target has to send a reject pdu with the attached pdu > > header > > + (recovery R2T OR delivery subsystem failure status) > > > > Why do we need two mechanisms? Wouldnt the pdu header indicate what needed > > to be transmitted? Maybe a word of motivation might help. > > > > Prasenjit Sarkar > > Research Staff Member > > IBM Almaden Research > > San Jose -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com --=_alternative 003CDA7AC2256ADC_= Content-Type: text/html; charset="us-ascii"
Yes there is a typo (the second appearance is yes).
However the function is correctly stated as OR  i.e. the result is yes if at least one of them wants order (it requires both to agree to say no).

Julo


"Mallikarjun C." <cbm@rose.hp.com>
Sent by: owner-ips@ece.cmu.edu

04-10-01 21:35
Please respond to cbm

       
        To:        ips <ips@ece.cmu.edu>
        cc:        
        Subject:        Re: Data Digest Error question

       


"Mallikarjun C." wrote:
>
> Prasenjit,
>
> The Reject mechanism is intended to be uniformly applicable to
> all (recovery-savvy and otherwise) targets.
>
> Recovery R2T, OTOH, is only for ErrorRecoveryLevel>=1 capable
> implementations (DataSequenceInOrder=true

Sorry, that was supposed to be DataSequenceInOrder=no.

Also, it appears to me that the result function for this key
should be AND, and there's a typo in the description - it says
"no" for both cases.  Julian, comments?

>as well, I think this
> needs to be called out in its description), since a recovery R2T
> implies going back in the data stream.
>
> The delivery subsystem failure status is the final termination
> status (even though there were several good data PDUs after the
> failed one) for ErrorRecoveryLevel=0 implementations, sent after
> waiting for the F-bit.
>
> Hope that helps.
>
> Regards.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668 Hewlett-Packard, Roseville.
> cbm@rose.hp.com
>
> Prasenjit Sarkar wrote:
> >
> > This question relates to how the target handles data digest errors for data
> > pdus.
> >
> > The spec says the target has to send a reject pdu with the attached pdu
> > header
> > + (recovery R2T OR delivery subsystem failure status)
> >
> > Why do we need two mechanisms? Wouldnt the pdu header indicate what needed
> > to be transmitted? Maybe a word of motivation might help.
> >
> >    Prasenjit Sarkar
> >    Research Staff Member
> >    IBM Almaden Research
> >    San Jose

--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com

--=_alternative 003CDA7AC2256ADC_=-- From owner-ips@ece.cmu.edu Fri Oct 5 08:00: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 IAA19359 for ; Fri, 5 Oct 2001 08:00:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95BCr721194 for ips-outgoing; Fri, 5 Oct 2001 07:12:53 -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 f95BCol21189 for ; Fri, 5 Oct 2001 07:12:51 -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 NAA29654 for ; Fri, 5 Oct 2001 13:12: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 f95BChF70060 for ; Fri, 5 Oct 2001 13:12:43 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Minor comment on draft -08 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Fri, 5 Oct 2001 14:12:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/10/2001 14:12:43, Serialize complete at 05/10/2001 14:12:43 Content-Type: multipart/alternative; boundary="=_alternative 003DA195C2256ADC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003DA195C2256ADC_= Content-Type: text/plain; charset="us-ascii" Steve, No it was a typo. Steve Senum 05-10-01 00:29 Please respond to Steve Senum To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iSCSI: Minor comment on draft -08 Julian, I noticed that the following text got removed from the description about hexadecimal encoding: Upper and lower case letters may be used interchangeably in hexadecimal notation (i.e., 0x1aBc, 0x1AbC and 0x1ABC are equivalent). Was this intentional? Also, is 0X the same as 0x (and 0b the same as 0B)? Thanks, Steve Senum --=_alternative 003DA195C2256ADC_= Content-Type: text/html; charset="us-ascii"
Steve,

No it was a typo.


Steve Senum <ssenum@cisco.com>

05-10-01 00:29
Please respond to Steve Senum

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        iSCSI: Minor comment on draft -08

       


Julian,

I noticed that the following text got removed from
the description about hexadecimal encoding:

  Upper and lower case letters may be used
  interchangeably in hexadecimal notation
  (i.e., 0x1aBc, 0x1AbC and  0x1ABC are equivalent).  

Was this intentional?  Also, is 0X the same as 0x
(and 0b the same as 0B)?

Thanks,
Steve Senum

--=_alternative 003DA195C2256ADC_=-- From owner-ips@ece.cmu.edu Fri Oct 5 08:56: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 IAA20883 for ; Fri, 5 Oct 2001 08:56:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95C5tv23687 for ips-outgoing; Fri, 5 Oct 2001 08:05:55 -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 f95C5ql23682 for ; Fri, 5 Oct 2001 08:05:52 -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 OAA63488 for ; Fri, 5 Oct 2001 14:05: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 f95C5hF187528 for ; Fri, 5 Oct 2001 14:05:43 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - revised 2.2.4 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Fri, 5 Oct 2001 15:05:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/10/2001 15:05:42, Serialize complete at 05/10/2001 15:05:42 Content-Type: multipart/alternative; boundary="=_alternative 0042782AC2256ADC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0042782AC2256ADC_= Content-Type: text/plain; charset="us-ascii" Here is a revised (complete) part 2.2.4 based on recent agreed changes: 1.1.1 Text Mode Negotiation During login and thereafter some session or connection parameters are negotiated through an exchange of textual information. All negotiations are stateless - i.e. the result MUST be based only on newly exchanged values. The general format of text negotiation is: Originator-> = Responder-> =|reject|NotUnderstood The value can be a number, a single literal constant a Boolean value (yes or no) or a list of comma separated literal constant values. In literal list negotiation, the originator sends for each key a list of options (literal constants which may include "none") in its order of preference. The responding party answers with the first value from the list it supports and is allowed to use for the specific originator. The constant "none" MUST always be used to indicate a missing function. However, none is a valid selection only if it is explicitly offered. If a target is not supporting, or not allowed to use with a specific originator, any of the offered options, it may use the constant "reject". The constants "none" and "reject" are reserved and must be used only as described here. Any key not understood is answered with "NotUnderstood". For numerical and single literal negotiations, the responding party MUST respond with the required key and the value it selects, based on the selection rule specific to the key, becomes the negotiation result. Selection of a value not admissible under the selection rules is considered a protocol error and handled accordingly. For Boolean negotiations (keys taking the values yes or no), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value to respond with are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value. Specifically, the two cases in which responses are OPTIONAL are: - The Boolean function is "AND" and the value "no" is received. The outcome of the negotiation is "no". - The Boolean function is "OR" and the value "yes" is received. The outcome of the negotiation is "yes". Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation. The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood". 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, only the initiator can initiate the negotiation start (through the first Text request) and completion (by setting to 1 and keeping to 1 the F bit in a Text request). Comments ? Julo --=_alternative 0042782AC2256ADC_= Content-Type: text/html; charset="us-ascii"
Here is a revised (complete) part 2.2.4 based on recent agreed changes:

1.1.1        Text Mode Negotiation

During login and thereafter some session or connection parameters are negotiated through an exchange of textual information.

All negotiations are stateless - i.e. the result MUST be based only on newly exchanged values.

The general format of text negotiation is:

Originator-> <key>=<valuex>
Responder-> <key>=<valuey>|reject|NotUnderstood

The value can be a number, a single literal constant a Boolean value (yes or no) or a list of comma separated literal constant values.

In literal list negotiation, the originator sends for each key a list of options (literal constants which may include "none") in its order of preference.

The responding party answers with the first value from the list it supports and is allowed to use for the specific originator.

The constant "none" MUST always be used to indicate a missing function. However, none is a valid selection only if it is explicitly offered.

If a target is not supporting, or not allowed to use with a specific originator, any of the offered options, it may use the constant "reject".  The constants "none" and "reject" are reserved and must be used only as described here.  Any key not understood is answered with "NotUnderstood".

For numerical and single literal negotiations, the responding party MUST respond with the required key and the value it selects, based on the selection rule specific to the key, becomes the negotiation result.  Selection of a value not admissible under the selection rules is considered a protocol error and handled accordingly.

For Boolean negotiations (keys taking the values yes or no), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself.  The last value transmitted becomes the negotiation result.  The rules for selecting the value to respond with are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value.
 
Specifically, the two cases in which responses are OPTIONAL are:

- The Boolean function is "AND" and the value "no" is received. The outcome of the negotiation is "no".
- The Boolean function is "OR" and the value "yes" is received. The outcome of the negotiation is "yes".

Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation.

The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood".

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, only the initiator can initiate the negotiation start (through the first Text request) and completion (by setting to 1 and keeping to 1 the F bit in a Text request).


Comments ?

Julo --=_alternative 0042782AC2256ADC_=-- From owner-ips@ece.cmu.edu Fri Oct 5 11:10: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 LAA23737 for ; Fri, 5 Oct 2001 11:10:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95E3oB00843 for ips-outgoing; Fri, 5 Oct 2001 10:03: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 f95E3ml00839 for ; Fri, 5 Oct 2001 10:03:48 -0400 (EDT) Received: from ahganemw2k (dhcp-161-44-68-116.cisco.com [161.44.68.116]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA03392 for ; Fri, 5 Oct 2001 10:03:42 -0400 (EDT) From: "Ayman Ghanem" To: Subject: RE: iSCSI: ImmediateData & InitialR2T Date: Fri, 5 Oct 2001 09:02:55 -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 The text doesn't say these are connection specific, so they must be session specific. Connection 1 logs in and doesn't send the ImmediateData key because it wants to use the default "yes". If connection 2 sends ImmediateData=no and the target agrees to that, how is this going to affect connection 1 which thinks it can send immediate data, and may actually have data in flight to the target. I think these two keys should have the same use restrictions as DataPDULength, FirstBurstSize, and MaxBurstSize, all have Use:LO. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, October 05, 2001 4:24 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: ImmediateData & InitialR2T > > > > why ? Julo > > > > > "Ayman Ghanem" > > > .com> cc: > > Sent by: Subject: iSCSI: > ImmediateData & InitialR2T > owner-ips@ece. > > cmu.edu > > > > > > 04-10-01 17:42 > > Please respond > > to "Ayman > > Ghanem" > > > > > > > > > Julian, > > The use of these two keys is currently set to "Use: ALL". I think they > should be allowed only on the leading connection, so a second connection > can > not change them on the first. > > -Ayman > > > > > > From owner-ips@ece.cmu.edu Fri Oct 5 11: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 LAA24735 for ; Fri, 5 Oct 2001 11:58:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95Ep7O04131 for ips-outgoing; Fri, 5 Oct 2001 10:51:07 -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 f95Ep5l04117 for ; Fri, 5 Oct 2001 10:51:05 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Oct 2001 10:51:00 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD831@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISID and the New Persistent Reservations Proposals Date: Fri, 5 Oct 2001 10:43:04 -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, Thanks, that's a useful summary. There are some important points to add. > However, proposal #1 needs a unique ISID, and can not use a dynamically > created SSID generated by each target Port. Or it needs an iSCSI text key to serve the port naming function of the ISID - the reason to do this rather than the ISID is that it cleanly splits persistent reservation management away from iSCSI session management. This has a couple of advantages: - It allows us to exactly accommodate whatever T10 does by defining the semantics of the text key appropriately. We won't have the same degree of flexibility in redefining ISID behavior. - It allows us to resolve the "blow it away" issue caused by ISID reuse without having to trade off aspects of that resolution against consequences for proposal #1, whose status in T10 is unknown. I would prefer deferring this whole issue of "New Persistent Reservation Proposals" until T10's direction is clear, and in the interim advise T10 that proposal #1 is a poor fit to iSCSI. As I indicated earlier, ISIDs in their current form aren't sufficient to deal with proposal #1 - while the specification will map onto iSCSI, the current specification of ISIDs will not ensure that the added functionality will work as intended. We would have to significantly expand the ISID rule to do so (that expansion will be problematic), and hence if proposal #1 is adopted, we may wind up with not only the ISID, but also a text key to deal with the resulting mismatch. This is one more reason to stop trying to design in anticipation of what T10 may or may not do. > Now you also have to ensure that upon a Target Boot, (which has to remember > the Persistent Reservation Status), it needs to also remember the high > water mark of ISIDs given out to each Initiator Node. With that high water > mark the Target can continue assigning the ISIDs for that Initiator Node. > Then I think your words were do not aggressively reused ISIDs. I think > that if the Target has not gone down for a day or so, ISIDs not in use > might be re-used, etc. > > We have 65K valid values per Initiator Node so reuse should not be a problem. This is actually a "SHOULD", not a "MUST", because a properly coded Initiator can figure out what's going on even if TSIDs (ISIDs in the above paragraph) are reused with some care. I'll spare everyone the details, as they're a bit subtle and deal with a situation in which the Target has already made a mistake (lost a persistent reserve), and hence it's reasonable to wonder what else the Target will get wrong. We agree that it's better to avoid depending on completely correct behavior in this sort of error situation. > So anyway, as good engineers we have been able to come up with something > that works. The problem that the N & D team had is, so what. What we have > now works, and has a smaller impact on the Target. I'm not sure that what we have now "works" courtesy of the Option A/Option B issue on when a Target is supposed to blow away a previous session. The current requirement that the Initiator specify the ISID, along with the expectation that ISID values will be aggressively reused is the direct cause of that problem. The best solution I've seen to it is to remove ISIDs, yielding a clear distinction between an Initiator who specifies a TSID (wants its old state back) vs. sends 0 as the TSID (wants a brand new session). I also take issue with the "smaller impact on the Target" statement above -- it may be based on the incorrect assumption that Targets would have to manage ISIDs in addition to TSIDs. ISIDs can be removed in their entirety, and TSID management would continue to work in essentially the current fashion. There's been at least one statement on the list that having Targets completely control the allocation of identifiers used to manage target resources (e.g., persistent reserves) simplifies Targets. > I had sent a note in previously that explained that if we have a way to set > the iSCSI Initiator Node Name then we must have a way to set the ISID by > the Initiator Node. Therefore, the question goes, why get the Target > involved. Wrong question, IMHO. Try "If TSIDs already solve the problem, why get the Initiator involved?" :-). Those who want to keep the ISID need to defend the additional complexity that it adds to the protocol, rather than uniformly criticize any proposed change as disruptive, IMHO. As to the statement that the ISID can be configured to an HBA in the same manner as the iSCSI Initiator Node Name, I observe that fewer things to configure lead to fewer opportunities to make mistakes and better scaling of management. > Therefore, additional routines on the Target for handing out ISIDs should > not be needed. I agree, just get rid of ISIDs entirely :-). --David > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Thursday, October 04, 2001 8:52 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: iSCSI: ISID and the New Persistent Reservations Proposals > > > David, > I have spent some time stepping through the issues of Target Generation of > SSID or ISID along with Persistent Reserves. I will start with Persistent > Reserves and then move to the SSID/ISID issue. > > I have tried to lay it out persistent reserves so that everyone can follow > it (may not work out but that is the attempt), I have also reviewed this > with Jim Hafner, so unless I have some typos I think it is correct. > > Persistent Reserves have three new proposed versions: (in each of the > following assume that the Initiator Node has 2 Ports A, and B, and the > Target Node has 2 Ports X, and Y. Also the subject LUN is called LU5). I > will start with point #0 that represents Persistent Reservations as of > today, and then step through the 3 new options. > > 0. Today, Initiator Port A, can create a Persistent Reservation for LU5 > with Target Port X, and then only I/O to LU5 can occur via the path from > Initiator port A to Target Port X, all other I/Os to LU5 will be blocked. > That is LU5 I/O via A to Y will be blocked as will B to X and B to Y. > > Three New additional proposals for handling Persistent reservations are > being pushed by folks in T10: > 1. Persistent reservations to LU5 can be made via Port A, and that will > apply on the A to X path and the A to Y path. I/O to LU5 from Port B to > either X or Y will be blocked. > 2. Persistent reservation to LU5 made via Port A or Port B to Target Port > X, will permit I/O to LU5 via Port A or B, if sent to Target Port X. > However, I/O to LU5 via Initiator Ports A or Port B will be blocked if it > is sent to Target Port Y. > 3. Persistent reservation to LU5 made via Initiator Port A or Port B to > Target Ports X or Y may occur, and I/O to LU5 may then occur via any path A > to X, A to Y, B to X, or B to Y. > > In both todays model (#0) or in proposal #1 the Target needs to place the > Persistent reservation against the Full iSCSI Initiator Port Name. This > is the iSCSI Initiator Node Name Plus the ISID. In proposal #1 the Full > iSCSI Initiator Port Name is then made known to all the target ports (in > the same SCSI Device), and that name is then used to determine the > Persistent Reservation State for each of the Target Ports relative to the > subject LU. > > In proposal 2 and 3, above, the name to be used in the Reservations is > just the iSCSI Initiator Node Name (No ISID). In proposal #2 the Name is > not shared with the other Target Ports (in that SCSI Device) so Persistence > only apples to I/O arriving at that Target Port from any Initiator port on > the Initiator Node which made the Reservation. And in proposal 3 the iSCSI > Initiator Node Name is shared among the Target Ports so that Persistence > can be applied to any Target Port (in that SCSI Device), which is addressed > by any Port on the Initiator Node which made the Reservation. > > Now, with regards to the issue that has been kicking around about the > target assigning the SSID, it does not matter one way or the other with > today's position #0 or proposal numbers 2 or 3. where the SSID comes from. > However, proposal #1 needs a unique ISID, and can not use a dynamically > created SSID generated by each target Port. There are other reasons why > folks do not even want the ISID, or the SSID generated by the target, but > those reasons have nothing to do with these Persistent Reservation > proposals. > > I have been suggesting to the N &D team and others that if we limit the > Dynamic Target Allocation to only the ISID (and of course the TSID) but not > a complete SSID, that there may be a workable solution. I say ISID, since > I believe it must be assured uniqueness per Initiator Port. One reason can > be seen in #0, & #1 above. > > Now suppose that one of the Target's Job was to Generate a unique ISID for > each Initiator Port, within and Initiator Node, which wanted to go into > session. If you combine with that, the rule that if the Initiator Port > sets and sends its own ISID on the Login the Target will accept it, and > then use the Full Initiator Port Name to check for Persistent Reserves, I > think we approach a working solution. > > Now you also have to ensure that upon a Target Boot, (which has to remember > the Persistent Reservation Status), it needs to also remember the high > water mark of ISIDs given out to each Initiator Node. With that high water > mark the Target can continue assigning the ISIDs for that Initiator Node. > Then I think your words were do not aggressively reused ISIDs. I think > that if the Target has not gone down for a day or so, ISIDs not in use > might be re-used, etc. > > We have 65K valid values per Initiator Node so reuse should not be a problem. > > OK now lets review what we have said. There is a way for a very simple > routine on the Target to assign the ISIDs. If Sent an ISID in the Login it > should accept it (if it can), and check on persistent reserves of type #0, > or #1. The Initiator can save the ISID, in case it goes down and want to > come back up, and reclaim the reserves, or it can blow the reserves away > and start again with a Target assigned ISID. > > OK now in one of your last notes, I think you said a similar thing. This > is also what I attempted to explain to the N &D team. > > So anyway, as good engineers we have been able to come up with something > that works. The problem that the N & D team had is, so what. What we have > now works, and has a smaller impact on the Target. > > So if it works we need to decide if we should do it or NOT, and focus the > conversation on that. > > I had sent a note in previously that explained that if we have a way to set > the iSCSI Initiator Node Name then we must have a way to set the ISID by > the Initiator Node. Therefore, the question goes, why get the Target > involved. > > Here is what I said in another note: > > If you accept that HBAs should get the iSCSI Initiator Node Name passed to > it in some manner from the OS, then we did not see why it can not get the > ISID at the same time also. If one were to argue that the HBA can not get > the iSCSI Initiator Node Name, I think this is a bit strange, since almost > every thing I install in systems, has to go through some type of Wizard, or > vendor install routine that actually installs the support driver, etc. > (This is all set when the OS is fully up and the Registry etc. is clearly > available.) I would expect that with current OSs, this would be a normal > approach. In the future, I suppose it might be possible that the OSs > might have a more dynamic routine to hand out the iSCSI Initiator Node Name > and ISID so that Hot Swap HBAs could come up without effort. However, > until then, I am not sure it is unreasonable for a vendor to require the > customer to run an update routine, even after performing an HBA Hot Swap. > > There is of course, the first up boot situation. I think it should be > possible to have a default, first time HBA boot Name that uses the iqn form > of the iSCSI Name, and an ISID of FFFF (not 0 as said previously). This > should be enough to bring up a "first time up boot", since after the OS is > started, the approprate install routine should be kicked off, and the real > iSCSI Initiator Node Name and real ISID set in the Flash for that, and any > other iSCSI HBAs. > > By the way I have a SCSI HBA in my personal system that runs its own BIOS > routine and when it comes up, but before it boots, it asks questions if > needed or just announces it is there. Configuration value can be entered > at that time. So even that approach is possible. > > So based on the above, I do not think requiring the HBAs to have an > install/update routine (which sets its Flash) is even a problem. > > This means that a Single iSCSI Initiator Node Name should be easy to obtain > and will apply for all the iSCSI Initiators, whether HW or SW. And likewise > it should be straight forward to secure the ISID at the same time. All > this following well understood current install processes. > > Therefore, additional routines on the Target for handing out ISIDs should > not be needed. > > OK, I tried to bring all the ISID issues together here so we could all > examine them. I hope this was useful. > > > > > > > > > . > . > . > 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 Oct 5 12:24: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 MAA25675 for ; Fri, 5 Oct 2001 12:24:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95Fd4207431 for ips-outgoing; Fri, 5 Oct 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 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 f95Fd2l07426 for ; Fri, 5 Oct 2001 11:39:02 -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 RAA90758 for ; Fri, 5 Oct 2001 17:38:53 +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 f95FcrP290572 for ; Fri, 5 Oct 2001 17:38:53 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI:Changes in Loging Negotiation X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Fri, 5 Oct 2001 18:38:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/10/2001 18:38:52, Serialize complete at 05/10/2001 18:38:52 Content-Type: multipart/alternative; boundary="=_alternative 0055FF82C2256ADC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0055FF82C2256ADC_= Content-Type: text/plain; charset="us-ascii" John, You are right technically. I assume that for the plugfest that was the way people implement this anyhow. The only difference is that the previous text did no mandate this behavior while the current test is strict (beyond what I judged as necessary). To help I am going to post on my site a pdf called 8a - that will be an errata to 8 with changes marked. Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 05-10-01 03:38 Please respond to John Hufferd To: ips@ece.cmu.edu cc: Subject: iSCSI:Changes in Loging Negotiation Now that Julian has made the latest change, I think we are now polishing the knobs. We have a Plugfest coming up which is going to use version 8. (Maybe we can get in Julian's latest, but that is not sure.) Also we are out of time and version 9 is suppose to be editorial (if possible). So I know it is hard not to Polish, but unless it is an important show stopper lets get on with what ever else we need to do and leave this alone. Nothing in what I said should stop important changes, just please ask your self, is it important enough to perhaps cause yet another iteration. Remember it will not make the plugfest anyway. We should be focusing on closure here. This should apply to all the stuff we have to do. If it is a protocol change, you should consider it to be very important, else forget it. That is, not to say that we should not polish the Documents. We Should. . . . 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 --=_alternative 0055FF82C2256ADC_= Content-Type: text/html; charset="us-ascii"
John,

You are right technically.  I assume that for the plugfest that was the way people implement this anyhow.
The only difference is that the previous text did no mandate this behavior while the current test is strict (beyond what I judged as necessary). To help I am going to post on my site a pdf called 8a - that will be an errata to 8 with changes
marked.

Julo


John Hufferd/San Jose/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

05-10-01 03:38
Please respond to John Hufferd

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iSCSI:Changes in Loging Negotiation

       


Now that Julian has made the latest change, I think we are now polishing
the knobs.  We have a Plugfest coming up which is going to use version 8.
(Maybe we can get in Julian's latest, but that is not sure.) Also we are
out of time and version 9 is suppose to be editorial (if possible).

So I know it is hard not to Polish, but unless it is an important show
stopper lets get on with what ever else we need to do and leave this alone.

Nothing in what I said should stop important changes, just please ask your
self, is it important enough to perhaps cause yet another iteration.
Remember it will not make the plugfest anyway.

We should be focusing on closure here.  This should apply to all the stuff
we have to do.  If it is a protocol change, you should consider it to be
very important, else forget it.  That is, not to say that we should not
polish the Documents.  We Should.


.
.
.
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

--=_alternative 0055FF82C2256ADC_=-- From owner-ips@ece.cmu.edu Fri Oct 5 12:24: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 MAA25694 for ; Fri, 5 Oct 2001 12:24:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95G2JF08991 for ips-outgoing; Fri, 5 Oct 2001 12:02:19 -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 f95G2Il08987 for ; Fri, 5 Oct 2001 12:02: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 A6EA11F59D for ; Fri, 5 Oct 2001 09:02: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 JAA09618 for ; Fri, 5 Oct 2001 09:02:05 -0700 (PDT) Message-ID: <3BBDDB27.F0C6CDF1@cup.hp.com> Date: Fri, 05 Oct 2001 09:09:11 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi : query based login negotiation. References: <3BBB20AD.F4FA549E@research.bell-labs.com> <3BBB3C1B.A96CCBB8@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, I have another question on the subject of login negotiation, which was brought up earlier in a previous mail. I've enclosed the mail below [with irrelevant portions snipped out.] Could you please clarify if the below described behaviour is possible ? Thanks, Santosh Santosh Rao wrote: > > Julian, > > Another value-add of the "responder picks the negotiation result model" > is that the initiator can use the following "query based" negotiation > model to always use the values the target is capable of offering : > > I -> T : DataPDULength=? > T -> I : DataPDULength=64K > > Both sides agree to use a DataPDULength of 64K. > I suggest that we allow the above "query based model", since this is > more efficient to use when an initiator has no key limitations and would > like to use the value a target can offer. In order to allow the "query > based model", you would need to state in the draft that a key value of > "?" over-rides the default, implying the target offered value would be > the result of the negotiation. > > In particular, the "query based model" is quite useful when an initiator > wishes to function with the target's maximal supported values for keys > like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T, > LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any > limitations on its own key value. > > 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 Oct 5 12:28: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 MAA25766 for ; Fri, 5 Oct 2001 12:28:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95Fa2x07246 for ips-outgoing; Fri, 5 Oct 2001 11:36:02 -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 f95FZwl07240 for ; Fri, 5 Oct 2001 11:35:58 -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 LAA15016; Fri, 5 Oct 2001 11:33:32 -0400 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f95FYcY173272; Fri, 5 Oct 2001 09:34:38 -0600 Importance: Normal Subject: RE: iSCSI: ISID and the New Persistent Reservations Proposals To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 5 Oct 2001 08:34:36 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/05/2001 08:34:38 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, I think I'm finally coming around to understand the full nature of what you're proposing. However, I'm not comfortable with it, though I have no more strong technical arguments against it. My strongest discomfort is this: in essence you are removing the SCSI Initiator Port Name from the iSCSI implementation of the model. You're hoping to fill that gap later with a text key whose semantics have yet to be defined. My expectation is that once you attempt to put the name back in you're recreated the OptionA/OptionB debate and will never be able to solve that satisfactorially. I'm concerned that removing the notion of SCSI Initiator Port Name from the model today, you will have strongly hindered iSCSI's ability to take advantage of a number of things that T10 will be able to do, now that Names are part of the lexicon. I also believe as I've stated that the OS's are going to prefer to see a more stable SCSI port view of the initiator's ports than we're currently anticipating in iSCSI. Finally, I think - the reason to do this rather than the ISID is that it cleanly splits persistent reservation management away from iSCSI session management. is a major violation of layering. You're going to burden the reservation management with having to coordinate iSCSI actions. [I've argued that conservative reuse of ISIDs to different target portal groups provides a clean consistent view of SCSI Initiator Ports to the upper layers and that's all that's needed.] None of those are strong technical arguments however. I think we agree that the problem comes up because the belief that coordination of ISIDs on the initiator side is going to be difficult. I'm not convinced that's the case, but let me try a different approach, which may make the implementation easier. Let's postulate two things (a) that initiator portal groups can get their iSCSI Name from the OS (without that, the issue is moot because theyn each portal group would have its own name and its management of ISIDs) and (b) that the initiator portal groups can be enumerated by the OS (as they are enabled/discovered/installed/etc.) (/dev/iscsi0,...). In other words, each initiator portal group would have access to the iSCSI Name and it's portal group tag. [You outlined a similar thing on the target side.] We have two choices: (a) embed the initiator portal group tag in the ISID (that provides effective partitioning without management intervention). (b) put the initiator portal group tag in a text key (then I don't need to partition ISIDs, as each will be qualified by the tag. These are semantically equivalent (it's just as if the ISID field got bigger in (b)). The only reason to choose option (b) over (a) then is if the ISID field (2bytes) isn't big enough. You've suggested that (a) is a "preferred implementation" for the target side. Is there any reason that can't be done in the same way on the initiator side? All devices get enumerated in some form or another in every OS. We can then take advantage of that inherent enumeration. Some final points. You wrote: As I indicated earlier, ISIDs in their current form aren't sufficient to deal with proposal #1 - while the specification will map onto iSCSI, the current specification of ISIDs will not ensure that the added functionality will work as intended. We would have to significantly expand the ISID rule to do so (that expansion will be problematic), and hence if proposal #1 is adopted, we may wind up with not only the ISID, but also a text key to deal with the resulting mismatch. I don't understand these claims still. Why aren't ISIDs sufficient with conservative reuse (as noted above). What other expansion to ISID rule do you foresee? As I've said, there must be a rule that prevents parallel I_T nexus and that will have to be based on the SCSI Initiator Port name (however that is defined). If you don't use the ISID as part of the name but a key (or both), then you'll get a new rule with exactly the same language, just replacing ISID with "key" or "key + ISID". If you don't provide a SCSI Initiator Port name, you will never be able to enable proposal #1 (and you'll look an awful lot like parallel SCSI in functionality). I'd like to hear from some of the other T10 folks on this list, if any have opinions on this issue. After that, I'd suggest we call concensus as I've run my fingers ragged (and my brain as well). Jim Hafner Black_David@emc.com@ece.cmu.edu on 10/05/2001 07:43:04 am Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISID and the New Persistent Reservations Proposals John, Thanks, that's a useful summary. There are some important points to add. > However, proposal #1 needs a unique ISID, and can not use a dynamically > created SSID generated by each target Port. Or it needs an iSCSI text key to serve the port naming function of the ISID - the reason to do this rather than the ISID is that it cleanly splits persistent reservation management away from iSCSI session management. This has a couple of advantages: - It allows us to exactly accommodate whatever T10 does by defining the semantics of the text key appropriately. We won't have the same degree of flexibility in redefining ISID behavior. - It allows us to resolve the "blow it away" issue caused by ISID reuse without having to trade off aspects of that resolution against consequences for proposal #1, whose status in T10 is unknown. I would prefer deferring this whole issue of "New Persistent Reservation Proposals" until T10's direction is clear, and in the interim advise T10 that proposal #1 is a poor fit to iSCSI. As I indicated earlier, ISIDs in their current form aren't sufficient to deal with proposal #1 - while the specification will map onto iSCSI, the current specification of ISIDs will not ensure that the added functionality will work as intended. We would have to significantly expand the ISID rule to do so (that expansion will be problematic), and hence if proposal #1 is adopted, we may wind up with not only the ISID, but also a text key to deal with the resulting mismatch. This is one more reason to stop trying to design in anticipation of what T10 may or may not do. > Now you also have to ensure that upon a Target Boot, (which has to remember > the Persistent Reservation Status), it needs to also remember the high > water mark of ISIDs given out to each Initiator Node. With that high water > mark the Target can continue assigning the ISIDs for that Initiator Node. > Then I think your words were do not aggressively reused ISIDs. I think > that if the Target has not gone down for a day or so, ISIDs not in use > might be re-used, etc. > > We have 65K valid values per Initiator Node so reuse should not be a problem. This is actually a "SHOULD", not a "MUST", because a properly coded Initiator can figure out what's going on even if TSIDs (ISIDs in the above paragraph) are reused with some care. I'll spare everyone the details, as they're a bit subtle and deal with a situation in which the Target has already made a mistake (lost a persistent reserve), and hence it's reasonable to wonder what else the Target will get wrong. We agree that it's better to avoid depending on completely correct behavior in this sort of error situation. > So anyway, as good engineers we have been able to come up with something > that works. The problem that the N & D team had is, so what. What we have > now works, and has a smaller impact on the Target. I'm not sure that what we have now "works" courtesy of the Option A/Option B issue on when a Target is supposed to blow away a previous session. The current requirement that the Initiator specify the ISID, along with the expectation that ISID values will be aggressively reused is the direct cause of that problem. The best solution I've seen to it is to remove ISIDs, yielding a clear distinction between an Initiator who specifies a TSID (wants its old state back) vs. sends 0 as the TSID (wants a brand new session). I also take issue with the "smaller impact on the Target" statement above -- it may be based on the incorrect assumption that Targets would have to manage ISIDs in addition to TSIDs. ISIDs can be removed in their entirety, and TSID management would continue to work in essentially the current fashion. There's been at least one statement on the list that having Targets completely control the allocation of identifiers used to manage target resources (e.g., persistent reserves) simplifies Targets. > I had sent a note in previously that explained that if we have a way to set > the iSCSI Initiator Node Name then we must have a way to set the ISID by > the Initiator Node. Therefore, the question goes, why get the Target > involved. Wrong question, IMHO. Try "If TSIDs already solve the problem, why get the Initiator involved?" :-). Those who want to keep the ISID need to defend the additional complexity that it adds to the protocol, rather than uniformly criticize any proposed change as disruptive, IMHO. As to the statement that the ISID can be configured to an HBA in the same manner as the iSCSI Initiator Node Name, I observe that fewer things to configure lead to fewer opportunities to make mistakes and better scaling of management. > Therefore, additional routines on the Target for handing out ISIDs should > not be needed. I agree, just get rid of ISIDs entirely :-). --David > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Thursday, October 04, 2001 8:52 PM > To: Black_David@emc.com > Cc: ips@ece.cmu.edu > Subject: iSCSI: ISID and the New Persistent Reservations Proposals > > > David, > I have spent some time stepping through the issues of Target Generation of > SSID or ISID along with Persistent Reserves. I will start with Persistent > Reserves and then move to the SSID/ISID issue. > > I have tried to lay it out persistent reserves so that everyone can follow > it (may not work out but that is the attempt), I have also reviewed this > with Jim Hafner, so unless I have some typos I think it is correct. > > Persistent Reserves have three new proposed versions: (in each of the > following assume that the Initiator Node has 2 Ports A, and B, and the > Target Node has 2 Ports X, and Y. Also the subject LUN is called LU5). I > will start with point #0 that represents Persistent Reservations as of > today, and then step through the 3 new options. > > 0. Today, Initiator Port A, can create a Persistent Reservation for LU5 > with Target Port X, and then only I/O to LU5 can occur via the path from > Initiator port A to Target Port X, all other I/Os to LU5 will be blocked. > That is LU5 I/O via A to Y will be blocked as will B to X and B to Y. > > Three New additional proposals for handling Persistent reservations are > being pushed by folks in T10: > 1. Persistent reservations to LU5 can be made via Port A, and that will > apply on the A to X path and the A to Y path. I/O to LU5 from Port B to > either X or Y will be blocked. > 2. Persistent reservation to LU5 made via Port A or Port B to Target Port > X, will permit I/O to LU5 via Port A or B, if sent to Target Port X. > However, I/O to LU5 via Initiator Ports A or Port B will be blocked if it > is sent to Target Port Y. > 3. Persistent reservation to LU5 made via Initiator Port A or Port B to > Target Ports X or Y may occur, and I/O to LU5 may then occur via any path A > to X, A to Y, B to X, or B to Y. > > In both todays model (#0) or in proposal #1 the Target needs to place the > Persistent reservation against the Full iSCSI Initiator Port Name. This > is the iSCSI Initiator Node Name Plus the ISID. In proposal #1 the Full > iSCSI Initiator Port Name is then made known to all the target ports (in > the same SCSI Device), and that name is then used to determine the > Persistent Reservation State for each of the Target Ports relative to the > subject LU. > > In proposal 2 and 3, above, the name to be used in the Reservations is > just the iSCSI Initiator Node Name (No ISID). In proposal #2 the Name is > not shared with the other Target Ports (in that SCSI Device) so Persistence > only apples to I/O arriving at that Target Port from any Initiator port on > the Initiator Node which made the Reservation. And in proposal 3 the iSCSI > Initiator Node Name is shared among the Target Ports so that Persistence > can be applied to any Target Port (in that SCSI Device), which is addressed > by any Port on the Initiator Node which made the Reservation. > > Now, with regards to the issue that has been kicking around about the > target assigning the SSID, it does not matter one way or the other with > today's position #0 or proposal numbers 2 or 3. where the SSID comes from. > However, proposal #1 needs a unique ISID, and can not use a dynamically > created SSID generated by each target Port. There are other reasons why > folks do not even want the ISID, or the SSID generated by the target, but > those reasons have nothing to do with these Persistent Reservation > proposals. > > I have been suggesting to the N &D team and others that if we limit the > Dynamic Target Allocation to only the ISID (and of course the TSID) but not > a complete SSID, that there may be a workable solution. I say ISID, since > I believe it must be assured uniqueness per Initiator Port. One reason can > be seen in #0, & #1 above. > > Now suppose that one of the Target's Job was to Generate a unique ISID for > each Initiator Port, within and Initiator Node, which wanted to go into > session. If you combine with that, the rule that if the Initiator Port > sets and sends its own ISID on the Login the Target will accept it, and > then use the Full Initiator Port Name to check for Persistent Reserves, I > think we approach a working solution. > > Now you also have to ensure that upon a Target Boot, (which has to remember > the Persistent Reservation Status), it needs to also remember the high > water mark of ISIDs given out to each Initiator Node. With that high water > mark the Target can continue assigning the ISIDs for that Initiator Node. > Then I think your words were do not aggressively reused ISIDs. I think > that if the Target has not gone down for a day or so, ISIDs not in use > might be re-used, etc. > > We have 65K valid values per Initiator Node so reuse should not be a problem. > > OK now lets review what we have said. There is a way for a very simple > routine on the Target to assign the ISIDs. If Sent an ISID in the Login it > should accept it (if it can), and check on persistent reserves of type #0, > or #1. The Initiator can save the ISID, in case it goes down and want to > come back up, and reclaim the reserves, or it can blow the reserves away > and start again with a Target assigned ISID. > > OK now in one of your last notes, I think you said a similar thing. This > is also what I attempted to explain to the N &D team. > > So anyway, as good engineers we have been able to come up with something > that works. The problem that the N & D team had is, so what. What we have > now works, and has a smaller impact on the Target. > > So if it works we need to decide if we should do it or NOT, and focus the > conversation on that. > > I had sent a note in previously that explained that if we have a way to set > the iSCSI Initiator Node Name then we must have a way to set the ISID by > the Initiator Node. Therefore, the question goes, why get the Target > involved. > > Here is what I said in another note: > > If you accept that HBAs should get the iSCSI Initiator Node Name passed to > it in some manner from the OS, then we did not see why it can not get the > ISID at the same time also. If one were to argue that the HBA can not get > the iSCSI Initiator Node Name, I think this is a bit strange, since almost > every thing I install in systems, has to go through some type of Wizard, or > vendor install routine that actually installs the support driver, etc. > (This is all set when the OS is fully up and the Registry etc. is clearly > available.) I would expect that with current OSs, this would be a normal > approach. In the future, I suppose it might be possible that the OSs > might have a more dynamic routine to hand out the iSCSI Initiator Node Name > and ISID so that Hot Swap HBAs could come up without effort. However, > until then, I am not sure it is unreasonable for a vendor to require the > customer to run an update routine, even after performing an HBA Hot Swap. > > There is of course, the first up boot situation. I think it should be > possible to have a default, first time HBA boot Name that uses the iqn form > of the iSCSI Name, and an ISID of FFFF (not 0 as said previously). This > should be enough to bring up a "first time up boot", since after the OS is > started, the approprate install routine should be kicked off, and the real > iSCSI Initiator Node Name and real ISID set in the Flash for that, and any > other iSCSI HBAs. > > By the way I have a SCSI HBA in my personal system that runs its own BIOS > routine and when it comes up, but before it boots, it asks questions if > needed or just announces it is there. Configuration value can be entered > at that time. So even that approach is possible. > > So based on the above, I do not think requiring the HBAs to have an > install/update routine (which sets its Flash) is even a problem. > > This means that a Single iSCSI Initiator Node Name should be easy to obtain > and will apply for all the iSCSI Initiators, whether HW or SW. And likewise > it should be straight forward to secure the ISID at the same time. All > this following well understood current install processes. > > Therefore, additional routines on the Target for handing out ISIDs should > not be needed. > > OK, I tried to bring all the ISID issues together here so we could all > examine them. I hope this was useful. > > > > > > > > > . > . > . > 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 Oct 5 12:37: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 MAA25932 for ; Fri, 5 Oct 2001 12:37:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95FUIC06864 for ips-outgoing; Fri, 5 Oct 2001 11:30:18 -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 f95FUGl06860 for ; Fri, 5 Oct 2001 11: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 RAA305426 for ; Fri, 5 Oct 2001 17: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 f95FU1F157082 for ; Fri, 5 Oct 2001 17:30:01 +0200 To: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: RE: iscsi : DataPDULength can differ in each direction. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Fri, 5 Oct 2001 18:29:57 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 05/10/2001 18:30:01, Serialize complete at 05/10/2001 18:30:01 Content-Type: multipart/alternative; boundary="=_alternative 00552F0EC2256ADC_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00552F0EC2256ADC_= Content-Type: text/plain; charset="us-ascii" I think that the set of arguments we have heard are solid enough to the DataPDUlength becoming a parameter that characterizes the receiver only. However this parameter should be also connection specific so that the sender and receiver can align (some framing mechanisms may require adaptation to path MTU) and having a different DataPDUlength on different paths can affect recovery. If we leave it session specific the logic of iSCSI can easily incorporate different PDU lengths and the draft changes are very limited. Julo Dave Sheehy Sent by: owner-ips@ece.cmu.edu 05-10-01 01:13 Please respond to Dave Sheehy To: ips@ece.cmu.edu (IETF IP SAN Reflector) cc: Subject: RE: iscsi : DataPDULength can differ in each direction. Comments in text. > > > Can someone give a tangible benefit to this that can > > outweigh the > > > spec and implementation churn at this late stage of the game? > > > > It would allow iSCSI HBAs to interact more efficiently > > with SW iSCSI > > implementations and vice versa. > > > > I don't believe it would in practice. Consider the following. The max > PDU size sent during login is more that just that, it is in fact the > senders maximum supportable max PDU size. If one side sends 64k and > the other side 8k although it is technically indicating it can't > receive more than 8k in a single PDU, for all practical purposes it is > also indicating it can't handle, and therefore can't send PDUs bigger > than 8k. I think that's a faulty interpretation of what's being proposed. As in both Fibre Channel and TCP the offered PDU size is the size you're willing to accept. It can and often is completely decoupled from the size you're capable of sending. This is commonly implemented in Fibre Channel and it's not exactly rocket science. > I believe if we go this route we'll simply see the side with the lower > DataPDULength sending its "natural" size PDUs and never sending the > larger size wanted by the other side. More on this below ... > > > > From my point of view the benefit of asymmetric PDU > > sizes would have > > > to be very large to make it worth the extra complexity > > in buffer > > > management code alone. > > > > >From the vantage point of an iSCSI HBA it doesn't seem > > all that hard. > > > > Well, it seems to me faced with a peer with a different max PDU size > there are relatively few ways to proceed. Again, I believe it's fairly straightforward and there are real life examples that work exactly this way. The only unfortunate thing is that it's been proposed at this late date. In hind sight, it's a feature with an obvious benefit. > If the peer has a lower max PDU size there are 2 choices. Use 2 buffer > pools, one for receive set to the local Max PDU size, and one for send > set to the peer Max PDU size. This is where the extra buffer > management complexity comes in. Or, use one buffer pool and simply > part fill the buffers for sending. This is the easy case. I don't see what buffer size has to do with PDU size that's not implementation dependent. The PDU content is going to be fragmented anyway (i.e. network header, iSCSI header, data, digest, ...) so the problem you describe exists regardless. > If the peer has a larger max PDU size then either only send up to the > local PDU size, as I mentioned above, or chain buffers together to > build larger than the local max PDU size. Again, this is where the > extra buffer management complexity comes in. Remember that by > definition these chains will need to be bigger than the largest chain > size the implementation can handle. Unless for some reason the > DataPDULength sent was chosen at some arbitrary size smaller than the > implementations maximum. I think SW iSCSI stacks are going to want to use big PDUs and in general iSCSI HBAs are going to use small ones. I think the SW stacks are going to set up their buffer structures to use large PDUs. I don't think (although it's certainly possible) that they are going to dynamically adjust their buffer sizes for each iSCSI session. So, in the scenario where a SW iSCSI stack is talking to an iSCSI HBA it's buffering is going to be used inefficiently in both directions. If the Data PDU Length is negotiated separately for each direction then the buffering on the SW side is being used inefficiently in only one direction. Both sides win with this behavior. Dave --=_alternative 00552F0EC2256ADC_= Content-Type: text/html; charset="us-ascii"
I think that the set of arguments we have heard are solid enough to the DataPDUlength becoming a parameter that characterizes the receiver only.  

However this parameter should be also connection specific so that the sender and receiver can align (some framing mechanisms may require adaptation to path MTU) and having a different DataPDUlength on different paths can affect recovery.

If we leave it session specific the logic of iSCSI can easily incorporate different PDU lengths and the draft changes are very limited.

Julo


Dave Sheehy <dbs@acropora.rose.agilent.com>
Sent by: owner-ips@ece.cmu.edu

05-10-01 01:13
Please respond to Dave Sheehy

       
        To:        ips@ece.cmu.edu (IETF IP SAN Reflector)
        cc:        
        Subject:        RE: iscsi : DataPDULength can differ in each direction.

       



Comments in text.

>   >  >                  Can someone give a tangible benefit to this that can
>   >  outweigh the
>   >  > spec and implementation churn at this late stage of the game?
>   >
>   >  It would allow iSCSI HBAs to interact more efficiently
>   >  with SW iSCSI
>   >  implementations and vice versa.
>   >
>
> I don't believe it would in practice. Consider the following. The max
> PDU size sent during login is more that just that, it is in fact the
> senders maximum supportable max PDU size. If one side sends 64k and
> the other side 8k although it is technically indicating it can't
> receive more than 8k in a single PDU, for all practical purposes it is
> also indicating it can't handle, and therefore can't send PDUs bigger
> than 8k.

I think that's a faulty interpretation of what's being proposed. As in both
Fibre Channel and TCP the offered PDU size is the size you're willing to
accept. It can and often is completely decoupled from the size you're capable
of sending. This is commonly implemented in Fibre Channel and it's not
exactly rocket science.

> I believe if we go this route we'll simply see the side with the lower
> DataPDULength sending its "natural" size PDUs and never sending the
> larger size wanted by the other side. More on this below ...
>
>   >  >                  From my point of view the benefit of asymmetric PDU
>   >  sizes would have
>   >  > to be very large to make it worth the extra complexity
>   >  in buffer
>   >  > management code alone.
>   >
>   >  >From the vantage point of an iSCSI HBA it doesn't seem
>   >  all that hard.
>   >
>
> Well, it seems to me faced with a peer with a different max PDU size
> there are relatively few ways to proceed.

Again, I believe it's fairly straightforward and there are real life
examples that work exactly this way. The only unfortunate thing is that it's
been proposed at this late date. In hind sight, it's a feature with an
obvious benefit.

> If the peer has a lower max PDU size there are 2 choices. Use 2 buffer
> pools, one for receive set to the local Max PDU size, and one for send
> set to the peer Max PDU size. This is where the extra buffer
> management complexity comes in. Or, use one buffer pool and simply
> part fill the buffers for sending. This is the easy case.

I don't see what buffer size has to do with PDU size that's not implementation
dependent. The PDU content is going to be fragmented anyway (i.e. network
header, iSCSI header, data, digest, ...) so the problem you describe exists
regardless.

> If the peer has a larger max PDU size then either only send up to the
> local PDU size, as I mentioned above, or chain buffers together to
> build larger than the local max PDU size. Again, this is where the
> extra buffer management complexity comes in. Remember that by
> definition these chains will need to be bigger than the largest chain
> size the implementation can handle. Unless for some reason the
> DataPDULength sent was chosen at some arbitrary size smaller than the
> implementations maximum.

I think SW iSCSI stacks are going to want to use big PDUs and in general
iSCSI HBAs are going to use small ones. I think the SW stacks are going to
set up their buffer structures to use large PDUs. I don't think (although
it's certainly possible) that they are going to dynamically adjust their
buffer sizes for each iSCSI session. So, in the scenario where a SW iSCSI
stack is talking to an iSCSI HBA it's buffering is going to be used
inefficiently in both directions. If the Data PDU Length is negotiated
separately for each direction then the buffering on the SW side is being
used inefficiently in only one direction. Both sides win with this behavior.

Dave

--=_alternative 00552F0EC2256ADC_=-- From owner-ips@ece.cmu.edu Fri Oct 5 13:28: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 NAA26967 for ; Fri, 5 Oct 2001 13:28:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95GLZ510237 for ips-outgoing; Fri, 5 Oct 2001 12:21:35 -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 f95GLXl10230 for ; Fri, 5 Oct 2001 12:21:33 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Oct 5 12:20:45 EDT 2001 Received: from aura.research.bell-labs.com ([135.104.46.10]) by grubby; Fri Oct 5 12:20:58 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 MAA16927 for ; Fri, 5 Oct 2001 12:20:16 -0400 (EDT) Message-ID: <3BBDDDBF.5BF56B9D@research.bell-labs.com> Date: Fri, 05 Oct 2001 12:20:15 -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 Reflector Subject: Re: iscsi : query based login negotiation. References: <3BBB20AD.F4FA549E@research.bell-labs.com> <3BBB3C1B.A96CCBB8@cup.hp.com> <3BBDDB27.F0C6CDF1@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 Another alternative is to let the the initiator send "DataPDULength=0". The target can then select & send a lower value it prefers. See Appendix D A value of 0 indicates no limit (the largest possible number) This would work for DataPDULength, MaxBurst and FirstBurst. -Sandeep Santosh Rao wrote: > > Julian, > > I have another question on the subject of login negotiation, which was > brought up earlier in a previous mail. I've enclosed the mail below > [with irrelevant portions snipped out.] > > Could you please clarify if the below described behaviour is possible ? > > Thanks, > Santosh > > Santosh Rao wrote: > > > > Julian, > > > > Another value-add of the "responder picks the negotiation result model" > > is that the initiator can use the following "query based" negotiation > > model to always use the values the target is capable of offering : > > > > I -> T : DataPDULength=? > > T -> I : DataPDULength=64K > > > > Both sides agree to use a DataPDULength of 64K. > > > I suggest that we allow the above "query based model", since this is > > more efficient to use when an initiator has no key limitations and would > > like to use the value a target can offer. In order to allow the "query > > based model", you would need to state in the draft that a key value of > > "?" over-rides the default, implying the target offered value would be > > the result of the negotiation. > > > > In particular, the "query based model" is quite useful when an initiator > > wishes to function with the target's maximal supported values for keys > > like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T, > > LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any > > limitations on its own key value. > > > > 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 Oct 5 14:30: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 OAA28159 for ; Fri, 5 Oct 2001 14:30:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95HxEB16797 for ips-outgoing; Fri, 5 Oct 2001 13:59:14 -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 f95HxCl16793 for ; Fri, 5 Oct 2001 13:59:12 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel10.hp.com (Postfix) with ESMTP id DF0F81FB73 for ; Fri, 5 Oct 2001 10:59: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 KAA16028 for ; Fri, 5 Oct 2001 10:59:02 -0700 (PDT) Message-ID: <3BBDF690.9F97245F@cup.hp.com> Date: Fri, 05 Oct 2001 11:06:08 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re: iscsi : query based login negotiation. References: <1BEBA5E8600DD4119A50009027AF54A008390FB6@axcs04.cos.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The '0' semantics works fine for me. We just need some mechanism wherein an initiator can accept values from the target for some keys, without expressing any limitations of its own on those key values. Currently, 0 implies no limit for the following numerical keys : - DataPDULength - MaxBurstSize - FirstBurstSize The following key definitions need to be modified to indicate that 0 implies no limit : - MaxConnections - LogoutLoginMaxTime - MaxOutstandingR2T Thanks, Santosh "THALER,PAT (A-Roseville,ex1)" wrote: > > Using 0 to specify no limit or largest possible number is a better solution. > Overloading query to mean "no limit" during negotiation can create confusion > between when it is being used for that and when it is just being used to > check the value at the partner. > > Pat > > -----Original Message----- > From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] > Sent: Friday, October 05, 2001 9:20 AM > To: IPS Reflector > Subject: Re: iscsi : query based login negotiation. > > Another alternative is to let the the initiator send > "DataPDULength=0". The target can then select & send > a lower value it prefers. > > See Appendix D > A value of 0 indicates no limit (the largest possible number) > > This would work for DataPDULength, MaxBurst and FirstBurst. > > -Sandeep > > Santosh Rao wrote: > > > > Julian, > > > > I have another question on the subject of login negotiation, which was > > brought up earlier in a previous mail. I've enclosed the mail below > > [with irrelevant portions snipped out.] > > > > Could you please clarify if the below described behaviour is possible ? > > > > Thanks, > > Santosh > > > > Santosh Rao wrote: > > > > > > Julian, > > > > > > Another value-add of the "responder picks the negotiation result model" > > > is that the initiator can use the following "query based" negotiation > > > model to always use the values the target is capable of offering : > > > > > > I -> T : DataPDULength=? > > > T -> I : DataPDULength=64K > > > > > > Both sides agree to use a DataPDULength of 64K. > > > > > I suggest that we allow the above "query based model", since this is > > > more efficient to use when an initiator has no key limitations and would > > > like to use the value a target can offer. In order to allow the "query > > > based model", you would need to state in the draft that a key value of > > > "?" over-rides the default, implying the target offered value would be > > > the result of the negotiation. > > > > > > In particular, the "query based model" is quite useful when an initiator > > > wishes to function with the target's maximal supported values for keys > > > like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T, > > > LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any > > > limitations on its own key value. > > > > > > 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 > > ################################## -- ################################## 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 Oct 5 14:30: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 OAA28180 for ; Fri, 5 Oct 2001 14:30:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95HUJ714950 for ips-outgoing; Fri, 5 Oct 2001 13:30:19 -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 f95HUIl14944 for ; Fri, 5 Oct 2001 13:30:18 -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 F3DF632F9; Fri, 5 Oct 2001 11:30:17 -0600 (MDT) Received: from axcsbh5.cos.agilent.com (axcsbh5.cos.agilent.com [130.29.152.150]) by msgrel1.cos.agilent.com (Postfix) with SMTP id D878C5D2; Fri, 5 Oct 2001 11:30:17 -0600 (MDT) Received: from 130.29.152.150 by axcsbh5.cos.agilent.com (InterScan E-Mail VirusWall NT); Fri, 05 Oct 2001 11:30:17 -0600 Received: by axcsbh5.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Oct 2001 11:30:17 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A008390FB6@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Sandeep Joshi , IPS Reflector Subject: RE: iscsi : query based login negotiation. Date: Fri, 5 Oct 2001 11:30:16 -0600 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 0 to specify no limit or largest possible number is a better solution. Overloading query to mean "no limit" during negotiation can create confusion between when it is being used for that and when it is just being used to check the value at the partner. Pat -----Original Message----- From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] Sent: Friday, October 05, 2001 9:20 AM To: IPS Reflector Subject: Re: iscsi : query based login negotiation. Another alternative is to let the the initiator send "DataPDULength=0". The target can then select & send a lower value it prefers. See Appendix D A value of 0 indicates no limit (the largest possible number) This would work for DataPDULength, MaxBurst and FirstBurst. -Sandeep Santosh Rao wrote: > > Julian, > > I have another question on the subject of login negotiation, which was > brought up earlier in a previous mail. I've enclosed the mail below > [with irrelevant portions snipped out.] > > Could you please clarify if the below described behaviour is possible ? > > Thanks, > Santosh > > Santosh Rao wrote: > > > > Julian, > > > > Another value-add of the "responder picks the negotiation result model" > > is that the initiator can use the following "query based" negotiation > > model to always use the values the target is capable of offering : > > > > I -> T : DataPDULength=? > > T -> I : DataPDULength=64K > > > > Both sides agree to use a DataPDULength of 64K. > > > I suggest that we allow the above "query based model", since this is > > more efficient to use when an initiator has no key limitations and would > > like to use the value a target can offer. In order to allow the "query > > based model", you would need to state in the draft that a key value of > > "?" over-rides the default, implying the target offered value would be > > the result of the negotiation. > > > > In particular, the "query based model" is quite useful when an initiator > > wishes to function with the target's maximal supported values for keys > > like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T, > > LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any > > limitations on its own key value. > > > > 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 Oct 5 14: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 OAA28191 for ; Fri, 5 Oct 2001 14:30:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95HZrh15297 for ips-outgoing; Fri, 5 Oct 2001 13:35:53 -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 f95HZml15290 for ; Fri, 5 Oct 2001 13:35:50 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by cleitus.hosting.pacbell.net id NAA21093; Fri, 5 Oct 2001 13:35:26 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "Julian Satran" , Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Fri, 5 Oct 2001 10:34:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C7_01C14D89.42BC2790" 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 This is a multi-part message in MIME format. ------=_NextPart_000_00C7_01C14D89.42BC2790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Julian, Couldn't quite understand what you are saying. Could you indicate which of the following you are proposing. 1. Each receiver specifies the max DatPDUlength it is willing to receive. 2. There is no negotiation, and the values are (possibly) different in each direction? 3. The values are negotiated by the leading connection only? 4. Framing mechanism if used are not an issue because the length used will be the lower of the length indicated and what is allowed by the framing protocol? Somesh -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Friday, October 05, 2001 8:30 AM To: ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. Importance: High I think that the set of arguments we have heard are solid enough to the DataPDUlength becoming a parameter that characterizes the receiver only. However this parameter should be also connection specific so that the sender and receiver can align (some framing mechanisms may require adaptation to path MTU) and having a different DataPDUlength on different paths can affect recovery. If we leave it session specific the logic of iSCSI can easily incorporate different PDU lengths and the draft changes are very limited. Julo Dave Sheehy Sent by: owner-ips@ece.cmu.edu 05-10-01 01:13 Please respond to Dave Sheehy To: ips@ece.cmu.edu (IETF IP SAN Reflector) cc: Subject: RE: iscsi : DataPDULength can differ in each direction. Comments in text. > > > Can someone give a tangible benefit to this that can > > outweigh the > > > spec and implementation churn at this late stage of the game? > > > > It would allow iSCSI HBAs to interact more efficiently > > with SW iSCSI > > implementations and vice versa. > > > > I don't believe it would in practice. Consider the following. The max > PDU size sent during login is more that just that, it is in fact the > senders maximum supportable max PDU size. If one side sends 64k and > the other side 8k although it is technically indicating it can't > receive more than 8k in a single PDU, for all practical purposes it is > also indicating it can't handle, and therefore can't send PDUs bigger > than 8k. I think that's a faulty interpretation of what's being proposed. As in both Fibre Channel and TCP the offered PDU size is the size you're willing to accept. It can and often is completely decoupled from the size you're capable of sending. This is commonly implemented in Fibre Channel and it's not exactly rocket science. > I believe if we go this route we'll simply see the side with the lower > DataPDULength sending its "natural" size PDUs and never sending the > larger size wanted by the other side. More on this below ... > > > > From my point of view the benefit of asymmetric PDU > > sizes would have > > > to be very large to make it worth the extra complexity > > in buffer > > > management code alone. > > > > >From the vantage point of an iSCSI HBA it doesn't seem > > all that hard. > > > > Well, it seems to me faced with a peer with a different max PDU size > there are relatively few ways to proceed. Again, I believe it's fairly straightforward and there are real life examples that work exactly this way. The only unfortunate thing is that it's been proposed at this late date. In hind sight, it's a feature with an obvious benefit. > If the peer has a lower max PDU size there are 2 choices. Use 2 buffer > pools, one for receive set to the local Max PDU size, and one for send > set to the peer Max PDU size. This is where the extra buffer > management complexity comes in. Or, use one buffer pool and simply > part fill the buffers for sending. This is the easy case. I don't see what buffer size has to do with PDU size that's not implementation dependent. The PDU content is going to be fragmented anyway (i.e. network header, iSCSI header, data, digest, ...) so the problem you describe exists regardless. > If the peer has a larger max PDU size then either only send up to the > local PDU size, as I mentioned above, or chain buffers together to > build larger than the local max PDU size. Again, this is where the > extra buffer management complexity comes in. Remember that by > definition these chains will need to be bigger than the largest chain > size the implementation can handle. Unless for some reason the > DataPDULength sent was chosen at some arbitrary size smaller than the > implementations maximum. I think SW iSCSI stacks are going to want to use big PDUs and in general iSCSI HBAs are going to use small ones. I think the SW stacks are going to set up their buffer structures to use large PDUs. I don't think (although it's certainly possible) that they are going to dynamically adjust their buffer sizes for each iSCSI session. So, in the scenario where a SW iSCSI stack is talking to an iSCSI HBA it's buffering is going to be used inefficiently in both directions. If the Data PDU Length is negotiated separately for each direction then the buffering on the SW side is being used inefficiently in only one direction. Both sides win with this behavior. Dave ------=_NextPart_000_00C7_01C14D89.42BC2790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Julian,
 
Couldn't quite understand what you are = saying. Could=20 you
indicate which of the following you are=20 proposing.
 
1.=20 Each receiver specifies the max DatPDUlength it is = willing
to=20 receive.
 
2.=20 There is no negotiation, and the values are (possibly) different in=20 each
direction?
 
3. The=20 values are negotiated by the leading connection = only?
 
4.=20 Framing mechanism if used are not an issue because the=20 length
used=20 will be the lower of the length indicated and what is allowed=20 by
the=20 framing protocol?
 
Somesh
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Friday, October 05, 2001 8:30 AM
To:=20 ips@ece.cmu.edu
Subject: RE: iscsi : DataPDULength can = differ in=20 each direction.
Importance: = High


I think that the set of arguments we have = heard are=20 solid enough to the DataPDUlength becoming a parameter that = characterizes the=20 receiver only.  

However this=20 parameter should be also connection specific so that the sender and = receiver=20 can align (some framing mechanisms may require adaptation to path MTU) = and=20 having a different DataPDUlength on different paths can affect=20 recovery.

If we leave = it session=20 specific the logic of iSCSI can easily incorporate different PDU = lengths and=20 the draft changes are very limited.

Julo


Dave Sheehy=20 <dbs@acropora.rose.agilent.com>
Sent by: owner-ips@ece.cmu.edu =

05-10-01 01:13 =
Please respond to Dave Sheehy =

        =
        To: =    =20    ips@ece.cmu.edu (IETF IP SAN Reflector) =
        cc: =    =20    
  =  =20     Subject:        RE: iscsi :=20 DataPDULength can differ in each direction.

     =20  



Comments in text.

>   >  > =    =20              Can someone give a = tangible=20 benefit to this that can
>   >  outweigh = the
>  =20 >  > spec and implementation churn at this late stage of = the=20 game?
>   >
>   >  It would allow = iSCSI HBAs=20 to interact more efficiently
>   >  with SW = iSCSI
>=20   >  implementations and vice versa.
>   = >
>=20
> I don't believe it would in practice. Consider the following. = The=20 max
> PDU size sent during login is more that just that, it is = in fact=20 the
> senders maximum supportable max PDU size. If one side = sends 64k=20 and
> the other side 8k although it is technically indicating it = can't
> receive more than 8k in a single PDU, for all practical = purposes=20 it is
> also indicating it can't handle, and therefore can't = send PDUs=20 bigger
> than 8k.

I think that's a faulty interpretation = of=20 what's being proposed. As in both
Fibre Channel and TCP the offered = PDU=20 size is the size you're willing to
accept. It can and often is = completely=20 decoupled from the size you're capable
of sending. This is commonly = implemented in Fibre Channel and it's not
exactly rocket=20 science.

> I believe if we go this route we'll simply see = the side=20 with the lower
> DataPDULength sending its "natural" size PDUs = and never=20 sending the
> larger size wanted by the other side. More on this = below=20 ...
>
>   >  >       =    =20        From my point of view the benefit of = asymmetric=20 PDU
>   >  sizes would have
>   > =  >=20 to be very large to make it worth the extra complexity
>   = >=20  in buffer
>   >  > management code = alone.
>=20   >
>   >  >From the vantage point of an = iSCSI=20 HBA it doesn't seem
>   >  all that hard.
> =  =20 >
>
> Well, it seems to me faced with a peer with a = different=20 max PDU size
> there are relatively few ways to = proceed.

Again, I=20 believe it's fairly straightforward and there are real life =
examples that=20 work exactly this way. The only unfortunate thing is that it's
been = proposed at this late date. In hind sight, it's a feature with = an
obvious=20 benefit.

> If the peer has a lower max PDU size there are 2 = choices.=20 Use 2 buffer
> pools, one for receive set to the local Max PDU = size, and=20 one for send
> set to the peer Max PDU size. This is where the = extra=20 buffer
> management complexity comes in. Or, use one buffer pool = and=20 simply
> part fill the buffers for sending. This is the easy=20 case.

I don't see what buffer size has to do with PDU size = that's not=20 implementation
dependent. The PDU content is going to be fragmented = anyway=20 (i.e. network
header, iSCSI header, data, digest, ...) so the = problem you=20 describe exists
regardless.

> If the peer has a larger = max PDU=20 size then either only send up to the
> local PDU size, as I = mentioned=20 above, or chain buffers together to
> build larger than the = local max=20 PDU size. Again, this is where the
> extra buffer management = complexity=20 comes in. Remember that by
> definition these chains will need = to be=20 bigger than the largest chain
> size the implementation can = handle.=20 Unless for some reason the
> DataPDULength sent was chosen at = some=20 arbitrary size smaller than the
> implementations = maximum.

I=20 think SW iSCSI stacks are going to want to use big PDUs and in=20 general
iSCSI HBAs are going to use small ones. I think the SW = stacks are=20 going to
set up their buffer structures to use large PDUs. I don't = think=20 (although
it's certainly possible) that they are going to = dynamically=20 adjust their
buffer sizes for each iSCSI session. So, in the = scenario where=20 a SW iSCSI
stack is talking to an iSCSI HBA it's buffering is going = to be=20 used
inefficiently in both directions. If the Data PDU Length is=20 negotiated
separately for each direction then the buffering on the = SW side=20 is being
used = inefficiently in only=20 one direction. Both sides win with this=20 = behavior.

Dave




------=_NextPart_000_00C7_01C14D89.42BC2790-- From owner-ips@ece.cmu.edu Fri Oct 5 14: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 OAA28391 for ; Fri, 5 Oct 2001 14:41:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95HTew14899 for ips-outgoing; Fri, 5 Oct 2001 13:29:40 -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 f95HTdl14895 for ; Fri, 5 Oct 2001 13:29:39 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel12.hp.com (Postfix) with ESMTP id 736E71F83B for ; Fri, 5 Oct 2001 10:29:33 -0700 (PDT) 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 KAA15027 for ; Fri, 5 Oct 2001 10:30:56 -0700 (PDT) Message-ID: <3BBDEF4B.CB17FD86@rose.hp.com> Date: Fri, 05 Oct 2001 10:35:07 -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 Subject: Re: iscsi : DataPDULength can differ in each direction. 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 don't really have a strong opinion on connection vs session applicability of DataPDULength, but one comment. If we specify the current ExpDataSN in Task Management function request (reassign) to be in stead "Expected Buffer Offset", this appears to enable per-connection DataPDULength. Specifying a buffer offset may also be helpful to targets in general, not requiring them to bring the DataSN->buffer_offset translation from a (potentially failed) different NIC (though perhaps it is not all that serious in practice since implementations will send DataPDULength-sized PDUs except for the last in an I/O). Do you see any other issues that complicate a connection-specific value? Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > I think that the set of arguments we have heard are solid enough to > the DataPDUlength becoming a parameter that characterizes the receiver > only. > > However this parameter should be also connection specific so that the > sender and receiver can align (some framing mechanisms may require > adaptation to path MTU) and having a different DataPDUlength on > different paths can affect recovery. > > If we leave it session specific the logic of iSCSI can easily > incorporate different PDU lengths and the draft changes are very > limited. > > Julo > > Dave Sheehy > To: > Sent by: owner-ips@ece.cmu.edu ips@ece.cmu.edu (IETF IP > SAN Reflector) > 05-10-01 01:13 cc: > Please respond to Dave Sheehy Subject: RE: > iscsi : DataPDULength can > differ in each direction. > > > > Comments in text. > > > > > Can someone give a tangible benefit to this > that can > > > outweigh the > > > > spec and implementation churn at this late stage of the game? > > > > > > It would allow iSCSI HBAs to interact more efficiently > > > with SW iSCSI > > > implementations and vice versa. > > > > > > > I don't believe it would in practice. Consider the following. The > max > > PDU size sent during login is more that just that, it is in fact the > > senders maximum supportable max PDU size. If one side sends 64k and > > the other side 8k although it is technically indicating it can't > > receive more than 8k in a single PDU, for all practical purposes it > is > > also indicating it can't handle, and therefore can't send PDUs > bigger > > than 8k. > > I think that's a faulty interpretation of what's being proposed. As in > both > Fibre Channel and TCP the offered PDU size is the size you're willing > to > accept. It can and often is completely decoupled from the size you're > capable > of sending. This is commonly implemented in Fibre Channel and it's not > > exactly rocket science. > > > I believe if we go this route we'll simply see the side with the > lower > > DataPDULength sending its "natural" size PDUs and never sending the > > larger size wanted by the other side. More on this below ... > > > > > > From my point of view the benefit of > asymmetric PDU > > > sizes would have > > > > to be very large to make it worth the extra complexity > > > in buffer > > > > management code alone. > > > > > > >From the vantage point of an iSCSI HBA it doesn't seem > > > all that hard. > > > > > > > Well, it seems to me faced with a peer with a different max PDU size > > there are relatively few ways to proceed. > > Again, I believe it's fairly straightforward and there are real life > examples that work exactly this way. The only unfortunate thing is > that it's > been proposed at this late date. In hind sight, it's a feature with an > obvious benefit. > > > If the peer has a lower max PDU size there are 2 choices. Use 2 > buffer > > pools, one for receive set to the local Max PDU size, and one for > send > > set to the peer Max PDU size. This is where the extra buffer > > management complexity comes in. Or, use one buffer pool and simply > > part fill the buffers for sending. This is the easy case. > > I don't see what buffer size has to do with PDU size that's not > implementation > dependent. The PDU content is going to be fragmented anyway (i.e. > network > header, iSCSI header, data, digest, ...) so the problem you describe > exists > regardless. > > > If the peer has a larger max PDU size then either only send up to > the > > local PDU size, as I mentioned above, or chain buffers together to > > build larger than the local max PDU size. Again, this is where the > > extra buffer management complexity comes in. Remember that by > > definition these chains will need to be bigger than the largest > chain > > size the implementation can handle. Unless for some reason the > > DataPDULength sent was chosen at some arbitrary size smaller than > the > > implementations maximum. > > I think SW iSCSI stacks are going to want to use big PDUs and in > general > iSCSI HBAs are going to use small ones. I think the SW stacks are > going to > set up their buffer structures to use large PDUs. I don't think > (although > it's certainly possible) that they are going to dynamically adjust > their > buffer sizes for each iSCSI session. So, in the scenario where a SW > iSCSI > stack is talking to an iSCSI HBA it's buffering is going to be used > inefficiently in both directions. If the Data PDU Length is negotiated > separately for each direction then the buffering on the SW side is > being > used inefficiently in only one direction. Both sides win with this > behavior. > > Dave From owner-ips@ece.cmu.edu Fri Oct 5 15:22: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 PAA29566 for ; Fri, 5 Oct 2001 15:22:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95IDes17829 for ips-outgoing; Fri, 5 Oct 2001 14:13:40 -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 f95IDdl17824 for ; Fri, 5 Oct 2001 14:13:39 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id 88F48CCC for ; Fri, 5 Oct 2001 14:13:34 -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 LAA24639 for ; Fri, 5 Oct 2001 11:14:56 -0700 (PDT) Message-ID: <3BBDF99B.C804F306@rose.hp.com> Date: Fri, 05 Oct 2001 11:19:07 -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 Subject: Re: iSCSI: Data Digest Error question 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 Satran wrote: > > Yes there is a typo (the second appearance is yes). > However the function is correctly stated as OR i.e. the result is yes > if at least one of them wants order (it requires both to agree to say > no). Yes, you are right. I guess I was thinking negative logic. Thanks. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com > > Julo > > "Mallikarjun C." > To: ips > Sent by: owner-ips@ece.cmu.edu > cc: > 04-10-01 21:35 Subject: Re: Data > Please respond to cbm Digest Error question > > > > "Mallikarjun C." wrote: > > > > Prasenjit, > > > > The Reject mechanism is intended to be uniformly applicable to > > all (recovery-savvy and otherwise) targets. > > > > Recovery R2T, OTOH, is only for ErrorRecoveryLevel>=1 capable > > implementations (DataSequenceInOrder=true > > Sorry, that was supposed to be DataSequenceInOrder=no. > > Also, it appears to me that the result function for this key > should be AND, and there's a typo in the description - it says > "no" for both cases. Julian, comments? > > >as well, I think this > > needs to be called out in its description), since a recovery R2T > > implies going back in the data stream. > > > > The delivery subsystem failure status is the final termination > > status (even though there were several good data PDUs after the > > failed one) for ErrorRecoveryLevel=0 implementations, sent after > > waiting for the F-bit. > > > > Hope that helps. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > Prasenjit Sarkar wrote: > > > > > > This question relates to how the target handles data digest errors > for data > > > pdus. > > > > > > The spec says the target has to send a reject pdu with the > attached pdu > > > header > > > + (recovery R2T OR delivery subsystem failure status) > > > > > > Why do we need two mechanisms? Wouldnt the pdu header indicate > what needed > > > to be transmitted? Maybe a word of motivation might help. > > > > > > Prasenjit Sarkar > > > Research Staff Member > > > IBM Almaden Research > > > San Jose > > -- > 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 Oct 5 15: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 PAA29598 for ; Fri, 5 Oct 2001 15:24:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95IO3s18568 for ips-outgoing; Fri, 5 Oct 2001 14:24:03 -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 f95IO1l18562 for ; Fri, 5 Oct 2001 14:24: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 CA6901F84D for ; Fri, 5 Oct 2001 11:23: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 LAA17604 for ; Fri, 5 Oct 2001 11:23:46 -0700 (PDT) Message-ID: <3BBDFC5B.930EDC7F@cup.hp.com> Date: Fri, 05 Oct 2001 11:30:51 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: ips Subject: Re: iscsi : DataPDULength can differ in each direction. References: <3BBDEF4B.CB17FD86@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 Having now accepted that DataPDULength is a "maximum receive pdu length" limitation that each end point is allowed to express, this key needs to be on a per connection basis, and not a per session basis. The reason for this being that limitations on DataPDULength (more aptly, max receive pdu length) stem from implementation specific quirks. (One of the reasons for allowing this feature, in the first place.). Since a multi-cxn session can [ideally] span multiple iscsi hardware vendor implementations + optionally, software iscsi implementation[s], the DataPDULength should be expressed on a per-cxn basis. As a side note, with the change in the semantics of this field, would it be appropriate to consider re-naming DataPDULength to MaxRecvPDULength ("Maximum Receive PDU Length") ? Thanks, Santosh "Mallikarjun C." wrote: > > Julian, > > I don't really have a strong opinion on connection vs session > applicability of DataPDULength, but one comment. > > If we specify the current ExpDataSN in Task Management function > request (reassign) to be in stead "Expected Buffer Offset", this > appears to enable per-connection DataPDULength. Specifying a > buffer offset may also be helpful to targets in general, not > requiring them to bring the DataSN->buffer_offset translation > from a (potentially failed) different NIC (though perhaps it is > not all that serious in practice since implementations will > send DataPDULength-sized PDUs except for the last in an I/O). > > Do you see any other issues that complicate a connection-specific > value? > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Julian Satran wrote: > > > > I think that the set of arguments we have heard are solid enough to > > the DataPDUlength becoming a parameter that characterizes the receiver > > only. > > > > However this parameter should be also connection specific so that the > > sender and receiver can align (some framing mechanisms may require > > adaptation to path MTU) and having a different DataPDUlength on > > different paths can affect recovery. > > > > If we leave it session specific the logic of iSCSI can easily > > incorporate different PDU lengths and the draft changes are very > > limited. > > > > Julo > > > > Dave Sheehy > > To: > > Sent by: owner-ips@ece.cmu.edu ips@ece.cmu.edu (IETF IP > > SAN Reflector) > > 05-10-01 01:13 cc: > > Please respond to Dave Sheehy Subject: RE: > > iscsi : DataPDULength can > > differ in each direction. > > > > > > > > Comments in text. > > > > > > > Can someone give a tangible benefit to this > > that can > > > > outweigh the > > > > > spec and implementation churn at this late stage of the game? > > > > > > > > It would allow iSCSI HBAs to interact more efficiently > > > > with SW iSCSI > > > > implementations and vice versa. > > > > > > > > > > I don't believe it would in practice. Consider the following. The > > max > > > PDU size sent during login is more that just that, it is in fact the > > > senders maximum supportable max PDU size. If one side sends 64k and > > > the other side 8k although it is technically indicating it can't > > > receive more than 8k in a single PDU, for all practical purposes it > > is > > > also indicating it can't handle, and therefore can't send PDUs > > bigger > > > than 8k. > > > > I think that's a faulty interpretation of what's being proposed. As in > > both > > Fibre Channel and TCP the offered PDU size is the size you're willing > > to > > accept. It can and often is completely decoupled from the size you're > > capable > > of sending. This is commonly implemented in Fibre Channel and it's not > > > > exactly rocket science. > > > > > I believe if we go this route we'll simply see the side with the > > lower > > > DataPDULength sending its "natural" size PDUs and never sending the > > > larger size wanted by the other side. More on this below ... > > > > > > > > From my point of view the benefit of > > asymmetric PDU > > > > sizes would have > > > > > to be very large to make it worth the extra complexity > > > > in buffer > > > > > management code alone. > > > > > > > > >From the vantage point of an iSCSI HBA it doesn't seem > > > > all that hard. > > > > > > > > > > Well, it seems to me faced with a peer with a different max PDU size > > > there are relatively few ways to proceed. > > > > Again, I believe it's fairly straightforward and there are real life > > examples that work exactly this way. The only unfortunate thing is > > that it's > > been proposed at this late date. In hind sight, it's a feature with an > > obvious benefit. > > > > > If the peer has a lower max PDU size there are 2 choices. Use 2 > > buffer > > > pools, one for receive set to the local Max PDU size, and one for > > send > > > set to the peer Max PDU size. This is where the extra buffer > > > management complexity comes in. Or, use one buffer pool and simply > > > part fill the buffers for sending. This is the easy case. > > > > I don't see what buffer size has to do with PDU size that's not > > implementation > > dependent. The PDU content is going to be fragmented anyway (i.e. > > network > > header, iSCSI header, data, digest, ...) so the problem you describe > > exists > > regardless. > > > > > If the peer has a larger max PDU size then either only send up to > > the > > > local PDU size, as I mentioned above, or chain buffers together to > > > build larger than the local max PDU size. Again, this is where the > > > extra buffer management complexity comes in. Remember that by > > > definition these chains will need to be bigger than the largest > > chain > > > size the implementation can handle. Unless for some reason the > > > DataPDULength sent was chosen at some arbitrary size smaller than > > the > > > implementations maximum. > > > > I think SW iSCSI stacks are going to want to use big PDUs and in > > general > > iSCSI HBAs are going to use small ones. I think the SW stacks are > > going to > > set up their buffer structures to use large PDUs. I don't think > > (although > > it's certainly possible) that they are going to dynamically adjust > > their > > buffer sizes for each iSCSI session. So, in the scenario where a SW > > iSCSI > > stack is talking to an iSCSI HBA it's buffering is going to be used > > inefficiently in both directions. If the Data PDU Length is negotiated > > separately for each direction then the buffering on the SW side is > > being > > used inefficiently in only one direction. Both sides win with this > > behavior. > > > > Dave -- ################################## 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 Oct 5 17:00: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 RAA01384 for ; Fri, 5 Oct 2001 17:00:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95KMrx27111 for ips-outgoing; Fri, 5 Oct 2001 16:22:53 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f95KMol27103 for ; Fri, 5 Oct 2001 16:22:51 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f95KM3S24178 for ; Fri, 5 Oct 2001 16:22:04 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 5 Oct 2001 16:22:17 -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 4CJKPFRS; Fri, 5 Oct 2001 16:22:04 -0400 Received: from travos.nortelnetworks.com (cse-ns-laptop.us.nortel.com [47.16.69.109]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T54YV50D; Fri, 5 Oct 2001 16:22:04 -0400 Message-Id: <5.0.2.1.2.20011005162658.02971060@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 05 Oct 2001 16:40:03 -0400 To: ips@ece.cmu.edu From: "Franco Travostino" Subject: iFCP: Minutes authors' confcall Fri October 5th Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_27069024==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_27069024==_.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 I) Review of iFCP version 5 changes and document status (CM) The document was submitted to the IETF repository as 5.0. CM quickly described the changes: a) New security text. b) Deleted appendix b (IP to FC connectivity) per co-author and IPS wg comments c) Stale frame detection -- Added text describing recommended policy for making a transition to the Unsynchronized state following loss of contact with SNTP server. d) Following reboot or cold start, added timed wait before the gateway may initiate TCP connections. Requested to prevent collisions with in-flight traffic from previous connections. e) Specified TCP RST as the means to abosrt a TCP connection when an error occurs. f) Added AES section ME provided I-D references for AES. FT argued that the section addressing d) suggests a far too short timeout (5 sec), which may only work for in-flight traffic and not for TCP retransmissions. DR suggested a 2 min. value (standard), with capability to adjust it through a management interface. II) Security Update (FT) FT reported that the iFCP security text had been included in the Aboba draft, and that a merge effort took place to harmonize/consolidate the iSCSI/iFCP/FCIP contributions. FT warned that the -01.txt version of the Aboba draft has several known merge problems in the iFCP+FCIP section, and they have been discussed and worked on already to a large extent. FT mentioned that at the last iscsi-security call the policy work by the IPsec Policy WG came up as a potential blueprint for defining security attributes into iSNS. JT will be looking into this opportunity. JT presented several design choices for iSNS security. iSNS security is needed to protect data other than identities (e.g., N_PORT attributes, SCNs), which an eavesdropper could use to launch targeted attacks (e.g., DoS attacks). A key choice is TLS vs IPsec/IKE. TLS appears to be a necessary and sufficient solution when talking to an iSNS server. Most likely, however, iFCP implementations will want to piggyback on existing IPsec/IKE apparatus, for merely practical reasons. There was consensus that IPsec/IKE will be used. JT asked whether confidentiality matters in iFCP to iSNS exchanges. There was consensus that encryption is a MUST implement just like it is for the iFCP protocol. III) Discussion of comments not incorporated in iFCP, rev 5 (CM) a) QoS hints from FC exchanges b) TPRLO frame size For a), there was consensus that the specification should not venture into describing QoS hooks built into FC traffic, either as PLOGI options or CS_CTL field. Normative text and current practice do not support use of these hooks, thus iFCP gateways will not see these QoS hints in FC exchanges. For b), CM explained why the failure semantics related to frame size are already covered in detail, and how other border cases for TRPLO frame size cannot happen by design. IV) Last call action items The co-authors agree that release 6 of the iFCP specification, publicly available next week, is by all means a complete draft, meeting all the known last call requirements (with the notable exception of the signature key authentication section in the security area, which still needs to be synchronized with work happening or soon-to-be-happening within iscsi-security). Thorough reviews from the larger community are in order at this point. -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 --=====================_27069024==_.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

I) Review of iFCP version 5 changes and document status (CM)

The document was submitted to the IETF repository as 5.0. CM quickly described the changes:
a) New security text.
b) Deleted appendix b (IP to FC connectivity) per co-author and IPS wg comments
c) Stale frame detection -- Added text describing recommended policy for making a transition to the Unsynchronized state following loss of contact with SNTP server.
d) Following reboot or cold start, added timed wait before the gateway may initiate TCP connections. Requested to prevent collisions with in-flight traffic from previous connections.
e) Specified TCP RST as the means to abosrt a TCP connection when an error occurs.
f) Added AES section

ME provided I-D references for AES. FT argued that the section addressing d) suggests a far too short timeout (5 sec), which may only work for in-flight traffic and not for TCP retransmissions. DR suggested a 2 min. value (standard), with capability to adjust it through a management interface.

II) Security Update (FT)

FT reported that the iFCP security text had been included in the Aboba draft, and that a merge effort took place to harmonize/consolidate the iSCSI/iFCP/FCIP contributions. FT warned that the -01.txt version of the Aboba draft has several known merge problems in the iFCP+FCIP section, and they have been discussed and worked on already to a large extent.

FT mentioned that at the last iscsi-security call the policy work by the IPsec Policy WG came up as a potential blueprint for defining security attributes into iSNS. JT will be looking into this opportunity.

JT presented several design choices for iSNS security. iSNS security is needed to protect data other than identities (e.g., N_PORT attributes, SCNs), which an eavesdropper could use to launch targeted attacks (e.g., DoS attacks). A key choice is TLS vs IPsec/IKE. TLS appears to be a necessary and sufficient solution when talking to an iSNS server. Most likely, however, iFCP implementations will want to piggyback on existing IPsec/IKE apparatus, for merely practical reasons. There was consensus that IPsec/IKE will be used. JT asked whether confidentiality matters in iFCP to iSNS exchanges. There was consensus that encryption is a MUST implement just like it is for the iFCP protocol.

III) Discussion of comments not incorporated in iFCP, rev 5 (CM)
a) QoS hints from FC exchanges
b) TPRLO frame size
For a), there was consensus that the specification should not venture into describing QoS hooks built into FC traffic, either as PLOGI options or CS_CTL field. Normative text and current practice do not support use of these hooks, thus  iFCP gateways will not see these QoS hints in FC exchanges.

For b), CM explained why the failure semantics related to frame size are already covered in detail, and how other border cases for TRPLO frame size cannot happen by design.

IV) Last call action items

The co-authors agree that release 6 of the iFCP specification, publicly available next week,  is by all means a complete draft, meeting all the known last call requirements (with the notable exception of the signature key authentication section in the security area, which still needs to be synchronized with work happening or soon-to-be-happening within iscsi-security). Thorough reviews from the larger community are in order at this point.

-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
 --=====================_27069024==_.ALT-- From owner-ips@ece.cmu.edu Fri Oct 5 17:02: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 RAA01469 for ; Fri, 5 Oct 2001 17:02:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95Jq9824952 for ips-outgoing; Fri, 5 Oct 2001 15:52:09 -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 f95Jq6l24946 for ; Fri, 5 Oct 2001 15:52:07 -0400 (EDT) Received: (from mailgate@localhost) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id PAA17244 for ips@ece.cmu.edu; Fri, 5 Oct 2001 15:51:59 -0400 (EDT) Received: from compuserve.com (dal-tgn-tlv-vty45.as.wcom.net [216.192.236.45]) by siaar1ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id PAA17223 for ; Fri, 5 Oct 2001 15:51:57 -0400 (EDT) Message-ID: <3BBE1055.D24C92D5@compuserve.com> Date: Fri, 05 Oct 2001 14:56:05 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: draft-ietf-ips-fcencapsulation-03.txt sent to I-D office Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit draft-ietf-ips-fcencapsulation-03.txt has been sent to the Internet Drafts office. draft-ietf-ips-fcencapsulation-03.txt contains the following changes: o Adding a reference to FC-FS in 5.3 FC SOF and EOF o Clarifying the relationship between the bit stream on a serial FC link and the byte stream on a TCP connection (affected sections 5.1 and 5.2). o Clarifying "frame content" in the revised 5.2 text as proposed on the list by Charles Monia. o Clarifying that the Encapsulation Header CRC follows the same rules as above in 3.1. The I-D Office should announce the new draft in the next week or so. For those in a bigger hurry, the document is being placed on the T11 web site as 01-524v0. Details will follow tomorrow after the T11 webmaster has done his magic. Enjoy. Ralph... From owner-ips@ece.cmu.edu Fri Oct 5 18:13: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 SAA03044 for ; Fri, 5 Oct 2001 18:13:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95L0xn29729 for ips-outgoing; Fri, 5 Oct 2001 17:00:59 -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 f95L0vl29724 for ; Fri, 5 Oct 2001 17:00:57 -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 90AF33020 for ; Fri, 5 Oct 2001 15:00:56 -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 323FA5EC for ; Fri, 5 Oct 2001 15:00:56 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id NAA09653 for ips@ece.cmu.edu; Fri, 5 Oct 2001 13:59:56 -0700 (PDT) From: Dave Sheehy Message-Id: <200110052059.NAA09653@acropora.rose.agilent.com> Subject: Re: iscsi : DataPDULength can differ in each direction. To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Fri, 05 Oct 2001 13:59:55 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, > Is this a feature that you believe is going to be useful ? Yes, I do. I already described the specific scenario in a prior email. > I proposed > this because I believed the way it is currently done is incorrect. The > DataPDULength negotiation should ideally follow the model of the FC > PLOGI common service params "receive buffer length" which an initiator & > target exchange. In essence, each side tells the other what is the > maximum length it can receive. I agree. In retrospect it seems obvious. > However, I'm also pragmatic and realize that several vendors have > already gotten their implementations done and so, I did'nt push for this > strongly. Do you believe this is something that is going to be useful > and implementations will require specific tweaks to the PDU lengths they > can use ? Since it is a change in behavior it will require tweaks as you say but not significant changes. I believe that the gains make it worthwhile. Dave From owner-ips@ece.cmu.edu Fri Oct 5 18:17: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 SAA03066 for ; Fri, 5 Oct 2001 18:17:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95KjT928611 for ips-outgoing; Fri, 5 Oct 2001 16:45:29 -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 f95KjRl28606 for ; Fri, 5 Oct 2001 16:45:27 -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 D04D733AD for ; Fri, 5 Oct 2001 14:45:26 -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 7E0965C5 for ; Fri, 5 Oct 2001 14:45:26 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id NAA09625 for ips@ece.cmu.edu; Fri, 5 Oct 2001 13:44:26 -0700 (PDT) From: Dave Sheehy Message-Id: <200110052044.NAA09625@acropora.rose.agilent.com> Subject: Re: iscsi : DataPDULength can differ in each direction. To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Fri, 05 Oct 2001 13:44:25 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > Having now accepted that DataPDULength is a "maximum receive pdu length" > limitation that each end point is allowed to express, this key needs to > be on a per connection basis, and not a per session basis. > > The reason for this being that limitations on DataPDULength (more aptly, > max receive pdu length) stem from implementation specific quirks. (One > of the reasons for allowing this feature, in the first place.). Following this same line of reasoning the keys: MaxBurstSize FirstBurstSize MaxOutstandingR2T DataPDUInOrder DataSequenceInOrder ErrorRecoveryLevel are all potentially implementation specific and should not be categorized as LO. Dave From owner-ips@ece.cmu.edu Fri Oct 5 22: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 WAA06384 for ; Fri, 5 Oct 2001 22:07:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95MxP906766 for ips-outgoing; Fri, 5 Oct 2001 18:59:25 -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 f95MxNl06762 for ; Fri, 5 Oct 2001 18:59:23 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail16.vwh1.net (RS ver 1.0.60s) with SMTP id 036655578; Fri, 5 Oct 2001 18:58:40 -0400 (EDT) From: "Dev - Platys" To: "Santosh Rao" , "ips" Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Fri, 5 Oct 2001 16:05:21 -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: <3BBDFC5B.930EDC7F@cup.hp.com> X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Having looked at the discussions and putting some more thoughts, I agree that Max PDU length should be provided by both the initiator and target and can be called as MaxRecvPDULength. Whether it is connection specific or session specific will add little complexity. Implementing different PDU lengths for initiator and target will not add any complexity. >Since a multi-cxn session can [ideally] span multiple iscsi hardware >vendor implementations + optionally, software iscsi implementation[s], >the DataPDULength should be expressed on a per-cxn basis. I am also with the reasoning that says why this parameter ould be connection based instead of session specific. Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Santosh Rao Sent: Friday, October 05, 2001 11:31 AM To: ips Subject: Re: iscsi : DataPDULength can differ in each direction. Having now accepted that DataPDULength is a "maximum receive pdu length" limitation that each end point is allowed to express, this key needs to be on a per connection basis, and not a per session basis. The reason for this being that limitations on DataPDULength (more aptly, max receive pdu length) stem from implementation specific quirks. (One of the reasons for allowing this feature, in the first place.). Since a multi-cxn session can [ideally] span multiple iscsi hardware vendor implementations + optionally, software iscsi implementation[s], the DataPDULength should be expressed on a per-cxn basis. As a side note, with the change in the semantics of this field, would it be appropriate to consider re-naming DataPDULength to MaxRecvPDULength ("Maximum Receive PDU Length") ? Thanks, Santosh "Mallikarjun C." wrote: > > Julian, > > I don't really have a strong opinion on connection vs session > applicability of DataPDULength, but one comment. > > If we specify the current ExpDataSN in Task Management function > request (reassign) to be in stead "Expected Buffer Offset", this > appears to enable per-connection DataPDULength. Specifying a > buffer offset may also be helpful to targets in general, not > requiring them to bring the DataSN->buffer_offset translation > from a (potentially failed) different NIC (though perhaps it is > not all that serious in practice since implementations will > send DataPDULength-sized PDUs except for the last in an I/O). > > Do you see any other issues that complicate a connection-specific > value? > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Julian Satran wrote: > > > > I think that the set of arguments we have heard are solid enough to > > the DataPDUlength becoming a parameter that characterizes the receiver > > only. > > > > However this parameter should be also connection specific so that the > > sender and receiver can align (some framing mechanisms may require > > adaptation to path MTU) and having a different DataPDUlength on > > different paths can affect recovery. > > > > If we leave it session specific the logic of iSCSI can easily > > incorporate different PDU lengths and the draft changes are very > > limited. > > > > Julo > > > > Dave Sheehy > > To: > > Sent by: owner-ips@ece.cmu.edu ips@ece.cmu.edu (IETF IP > > SAN Reflector) > > 05-10-01 01:13 cc: > > Please respond to Dave Sheehy Subject: RE: > > iscsi : DataPDULength can > > differ in each direction. > > > > > > > > Comments in text. > > > > > > > Can someone give a tangible benefit to this > > that can > > > > outweigh the > > > > > spec and implementation churn at this late stage of the game? > > > > > > > > It would allow iSCSI HBAs to interact more efficiently > > > > with SW iSCSI > > > > implementations and vice versa. > > > > > > > > > > I don't believe it would in practice. Consider the following. The > > max > > > PDU size sent during login is more that just that, it is in fact the > > > senders maximum supportable max PDU size. If one side sends 64k and > > > the other side 8k although it is technically indicating it can't > > > receive more than 8k in a single PDU, for all practical purposes it > > is > > > also indicating it can't handle, and therefore can't send PDUs > > bigger > > > than 8k. > > > > I think that's a faulty interpretation of what's being proposed. As in > > both > > Fibre Channel and TCP the offered PDU size is the size you're willing > > to > > accept. It can and often is completely decoupled from the size you're > > capable > > of sending. This is commonly implemented in Fibre Channel and it's not > > > > exactly rocket science. > > > > > I believe if we go this route we'll simply see the side with the > > lower > > > DataPDULength sending its "natural" size PDUs and never sending the > > > larger size wanted by the other side. More on this below ... > > > > > > > > From my point of view the benefit of > > asymmetric PDU > > > > sizes would have > > > > > to be very large to make it worth the extra complexity > > > > in buffer > > > > > management code alone. > > > > > > > > >From the vantage point of an iSCSI HBA it doesn't seem > > > > all that hard. > > > > > > > > > > Well, it seems to me faced with a peer with a different max PDU size > > > there are relatively few ways to proceed. > > > > Again, I believe it's fairly straightforward and there are real life > > examples that work exactly this way. The only unfortunate thing is > > that it's > > been proposed at this late date. In hind sight, it's a feature with an > > obvious benefit. > > > > > If the peer has a lower max PDU size there are 2 choices. Use 2 > > buffer > > > pools, one for receive set to the local Max PDU size, and one for > > send > > > set to the peer Max PDU size. This is where the extra buffer > > > management complexity comes in. Or, use one buffer pool and simply > > > part fill the buffers for sending. This is the easy case. > > > > I don't see what buffer size has to do with PDU size that's not > > implementation > > dependent. The PDU content is going to be fragmented anyway (i.e. > > network > > header, iSCSI header, data, digest, ...) so the problem you describe > > exists > > regardless. > > > > > If the peer has a larger max PDU size then either only send up to > > the > > > local PDU size, as I mentioned above, or chain buffers together to > > > build larger than the local max PDU size. Again, this is where the > > > extra buffer management complexity comes in. Remember that by > > > definition these chains will need to be bigger than the largest > > chain > > > size the implementation can handle. Unless for some reason the > > > DataPDULength sent was chosen at some arbitrary size smaller than > > the > > > implementations maximum. > > > > I think SW iSCSI stacks are going to want to use big PDUs and in > > general > > iSCSI HBAs are going to use small ones. I think the SW stacks are > > going to > > set up their buffer structures to use large PDUs. I don't think > > (although > > it's certainly possible) that they are going to dynamically adjust > > their > > buffer sizes for each iSCSI session. So, in the scenario where a SW > > iSCSI > > stack is talking to an iSCSI HBA it's buffering is going to be used > > inefficiently in both directions. If the Data PDU Length is negotiated > > separately for each direction then the buffering on the SW side is > > being > > used inefficiently in only one direction. Both sides win with this > > behavior. > > > > Dave -- ################################## 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 Oct 5 22:07: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 WAA06400 for ; Fri, 5 Oct 2001 22:07:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95MjUs05996 for ips-outgoing; Fri, 5 Oct 2001 18:45: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 f95MjMl05984 for ; Fri, 5 Oct 2001 18:45:23 -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 1966860; Fri, 05 Oct 2001 15:45:24 -0700 Message-ID: <3BBE38F9.8316CF9@redswitch.com> Date: Fri, 05 Oct 2001 15:49:29 -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: "THALER,PAT (A-Roseville,ex1)" CC: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" , "'Santosh Rao'" , Rod Harrison , Ayman Ghanem , ips@ece.cmu.edu, Thomas Dineen Subject: Re: iscsi : DataPDULength can differ in each direction. References: <1BEBA5E8600DD4119A50009027AF54A008390EA5@axcs04.cos.agilent.com> 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: After reading Pat's note below it came to me that Pat's description, shown below, is similar to that of TCP, which I believe is still a part or your the iSCSI stack. Because of this I would suggest that we should use a scheme that is similar to and compatible with that of TCP. After all both will be living right next to each other within an implementation. Even if an implementor chooses not to use TCP it will still be a well known and workable technique. Thomas Dineen "THALER,PAT (A-Roseville,ex1)" wrote: > > Sanjeev, > > I don't see how allowing each side to independently specify the > DataPDULength it can accept complicates anything. If Device X can receive 10 > Kbyte PDUs and Device Y can only receive 2 Kbyte PDUs, then the implication > of allowing them to be independent is > > Device X can only send 2 Kbyte PDUs to Device Y - it has to obey Device > Y's input limitations. > > Device Y may send 10 Kbyte PDUs to Device X if it has that capability or > it can send 2 Kbyte PDUs if its transmit side isn't able to send longer > ones. The transmitter isn't required to send the maximum PDU size that the > receiver can handle. > > Furthermore, in many cases buffer pools will be shared among multiple > connections. Therefore a buffer management strategy that depends upon the > max PDU length would be non-ideal. > > Pat > > -----Original Message----- > From: Sanjeev Bhagat (TRIPACE/Zoetermeer) [mailto:sbhagat@tripace.com] > Sent: Wednesday, October 03, 2001 3:26 PM > To: 'Santosh Rao'; Rod Harrison > Cc: Ayman Ghanem; ips@ece.cmu.edu > Subject: RE: iscsi : DataPDULength can differ in each direction. > > All, > > I think making DataPDULength different on two side will bring complexity in > implementation. Calculation of CRC, handling unknown and very high value of > DataPDUlength, change in buffer management code etc etc and above all.. a > radical change so late in the specs chould be avoided. > > In my view we rather can choose for either of the two ways > 1. Either make DataPDULength as list negotiation, which makes sure that the > computing party choses a result which other party will definitley support > > or > 2. keep it like numeric negotiation with result being computed by responding > party and double checked by the offering party. In case there is still any > error when the offering party gets the result, they may either go for reject > or re-nogotiation. > > Sanjeev > > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, October 03, 2001 11:46 PM > To: Rod Harrison > Cc: Ayman Ghanem; ips@ece.cmu.edu > Subject: Re: iscsi : DataPDULength can differ in each direction. > > Rod, > > The issue came up as a result of Deva pointing out that an initiator may > not be able to function with the minimal of the 2 DataPDULengths > (initiator's & target's) in the case where the value chosen was not its > value. > > In order to allow for such implementations that had issues with the > DataPDULength, I raised this question. > > The benefit of both sides being allowed different DataPDULengths is : > > a) Each side can specify its max supported value which the other side > would not exceed. The sender & receiver would be able to function with > different DataPDULengths, with the guarantee that their advertised > receive pdu length will not be exceeded, thus, allowing more flexible > interoperability of implementations. (btw, the proposal should have read > : Each side is allowed to advertise its maximum receive pdu length.) > > b) It may also allow 2 parties with differing PDU lengths to send larger > sized PDUs in one direction to the party that advertised a higher > receive pdu length. > > However, I do admit there's a cost to making this change, given we are > so late in the draft rev and several implementations have already been > made. If this is not an issue of concern to the majority of > implementations, I am ok with the current definition, although it is > more limiting on implementations. > > Thanks, > Santosh > > Rod Harrison wrote: > > > > Can someone give a tangible benefit to this that can outweigh the > > spec and implementation churn at this late stage of the game? > > > > From my point of view the benefit of asymmetric PDU sizes would > have > > to be very large to make it worth the extra complexity in buffer > > management code alone. > > > > - Rod > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Ayman Ghanem > > Sent: Wednesday, October 03, 2001 8:29 PM > > To: ips@ece.cmu.edu > > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > Well, the proposal says: > > > > Each side should be allowed to specify the DataPDULength it will > be > > using and there should be no attempt to negotiate this value. > Rather, > > the key is exchanged in either direction to inform the other side > as > > to > > what sized PDUs it should expect. > > > > So, I understand that as if the initiator sends > > DataPDULength=reallyBigNumber, then it is informing the target that > > this is > > what it will be using, but the target should not attempt to negotiate > > it. > > > > -Ayman > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf > > Of > > > Buck Landry > > > Sent: Wednesday, October 03, 2001 2:13 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > > > > > > It may add complexity, but, since DataPDULength is only a boundary > > on > > > the maximum number of bytes transmitted in a Data PDU (not the > > minimum), > > > "the first" *does* have a say about it. Right? > > > > > > -----Original Message----- > > > From: Ayman Ghanem [mailto:aghanem@cisco.com] > > > Sent: Wednesday, October 03, 2001 1:38 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: iscsi : DataPDULength can differ in each direction. > > > > > > > > > I think this will add unnecessary complexity, specially for data > > CRCs > > > having > > > to be calculated based on two different PDU sizes for Reads and > > Writes. > > > Also, one end may choose to do data digests in software. If the > > other > > > end > > > decides to use a really large PDU length (and the first doesn't have > > a > > > say > > > about it), this could be a problem. > > > > > > -Ayman > > > > > > > > > > > -- > ################################## > 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 Oct 5 22:47: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 WAA07906 for ; Fri, 5 Oct 2001 22:47:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f962LQY16288 for ips-outgoing; Fri, 5 Oct 2001 22:21: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 f962LPl16284 for ; Fri, 5 Oct 2001 22:21:25 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Oct 2001 22:03:12 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD846@CORPMX14> From: Black_David@emc.com To: hafner@almaden.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISID and the New Persistent Reservations Proposals Date: Fri, 5 Oct 2001 21:52:59 -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, > My strongest discomfort is this: in essence you are removing the SCSI > Initiator Port Name from the iSCSI implementation of the model. You're > hoping to fill that gap later with a text key whose semantics have yet to > be defined. Having the text key semantics be "yet to be defined" seems reasonable because the behavior required by T10 is in the same state. Horse first, then cart :-). > My expectation is that once you attempt to put the name back > in you're recreated the OptionA/OptionB debate and will never > be able to solve that satisfactorially. I disagree. ISIDs aren't negotiable, text keys are. In the text key situation analogous to the ISID situation that causes the OptionA/OptionB mess, the Target can set the text key to some sort of "Port Identity Conflict Detected" value and ship everything back to the Initiator with no harm done. Trying to do that sort of thing with ISIDs would be a mess, as indicated by the amount of email on OptionA/OptionB. > I'm concerned that removing the notion of SCSI Initiator Port Name > from the model today, you will have strongly hindered iSCSI's ability > to take advantage of a number of things that T10 > will be able to do, now that Names are part of the lexicon. And I have a strong discomfort with designing for functionality that isn't specified. We already have a mismatch where the current T10 proposal #1 does not match current ISID specification (see below on conservative reuse). As T10 does things with the Port Name, we can put in the text key(s) required to make them work. > I also believe as I've stated that the OS's are going to prefer to see > a more stable SCSI port view of the initiator's ports than we're currently > anticipating in iSCSI. As long as the TSID is not used to provide this view, there is no problem here (e.g., the enumeration of interface cards on boot can be used). > Finally, I think > - the reason to do this rather than the ISID is that it cleanly splits > persistent reservation management away from iSCSI session management. > is a major violation of layering. You're going to burden the reservation > management with having to coordinate iSCSI actions. I disagree. The interaction required is something that will have to happen anyway if T10 adopts any proposal that has reservations span sessions at the Target. Suppose that port X opens a session to port A, places a persistent reservation that spans target ports, and then opens a session to port B - as part of setting up that second session, port B has to interact with the persistent reservation logic to discover that the reservation exists and applies to the second session. This is all that's required, and it's true for any transport - in each cases the transport-specific port identification has to be passed from the transport to the SCSI reservation logic. The only wrinkle is that iSCSI gets this name from a text key instead of a WWN or a parallel SCSI bus ID - at the SCSI level, this shouldn't matter (the IDs are opaque and are being checked for equality). In other words, if there's a layering problem here, it's in SAM2 ... > [I've argued that conservative reuse of ISIDs to different target portal groups > provides a clean consistent view of SCSI Initiator Ports to the upper layers and > that's all that's needed.] But that requirement is NOT in the current draft, and inserting it would impact implementation approaches such as that originally described by Nick Martin in which an iSCSI implementation has to cons up an ISID in the potential absence of coordination with other implementations that share the same iSCSI Initiator Node Name. The nasty problems result when there are multiple Initiators connected to multiple Targets, but not all Initiators are connected to all Targets - an Initiator could set up several sessions and only then discover that the ISID it used is taken and have to tear down those sessions and start over. This is why ISIDs as currently specified aren't sufficient to deal with proposal #1 and changing them to do so would be a visible technical change. > None of those are strong technical arguments however. > > I think we agree that the problem comes up because the belief that > coordination of ISIDs on the initiator side is going to be difficult. I'm > not convinced that's the case, but let me try a different approach, which > may make the implementation easier. The summary is to have the OS enumeration provide the portal group tag, and make that part of the ISID either explicitly or via a text key that implicitly extends the ISID. It's a good try, but I think it runs into problems because device enumeration order in an operating system can change between reboots for all sorts of reasons ranging from the unavoidable (interface card fails in a fashion that causes it not to be discovered on boot - this is discovery by plug-and-play logic or the like, not iSCSI discovery) to the inane (stupid plug and play tricks, new driver revisions). This may wind up adding the Initiator Portal Group number to the list of things that an Initiator has to remember in order to get its persistent reservation state restored. --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 Oct 5 22:48: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 WAA07919 for ; Fri, 5 Oct 2001 22:48:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f961SnW13769 for ips-outgoing; Fri, 5 Oct 2001 21:28:49 -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 f961Sml13765 for ; Fri, 5 Oct 2001 21:28:48 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Oct 2001 21:10:39 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD845@CORPMX14> From: Black_David@emc.com To: hufferd@us.ibm.com, ips@ece.cmu.edu Subject: RE: iSCSI:Changes in Loging Negotiation Date: Fri, 5 Oct 2001 21:05: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 I want to slightly tone down a couple of John's comments: > Also we are > out of time and version 9 is suppose to be editorial (if possible). Version 9 is supposed to be primarily editorial, but that doesn't mean that we can't put in technical changes that are discovered to be needed in the interim. > Nothing in what I said should stop important changes, just please ask your > self, is it important enough to perhaps cause yet another iteration. > Remember it will not make the plugfest anyway. I would hope people are only bringing important things to the list, but considering whether they'll cause another iteration is not a good criteria. It's highly unlikely that -09 will be the final version, as there's probably at least one more iteration after that to deal with what we do in Salt Lake City, and the odds of the version that enters WG Last Call coming out with no changes necessary are infinitesimal. 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 Oct 5 22:52: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 WAA07951 for ; Fri, 5 Oct 2001 22:52:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f95NnQP09213 for ips-outgoing; Fri, 5 Oct 2001 19:49:26 -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 f95NnOl09208 for ; Fri, 5 Oct 2001 19:49:24 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 8B43A84A for ; Fri, 5 Oct 2001 16:49:23 -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 QAA14582 for ; Fri, 5 Oct 2001 16:49:19 -0700 (PDT) Message-ID: <3BBE48A9.CE6BC448@cup.hp.com> Date: Fri, 05 Oct 2001 16:56:25 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi : X bit in SCSI Command PDU. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, With the elimination of command relay from iscsi [in the interests of simplification ?], I believe that the X bit in the SCSI Command PDU can also be removed. As it exists today, the X bit is only being used for command restart, which is at attempt by the initiator to plug a potential hole in the CmdSN sequence at the target. It does this on failing to get an ExpCmdSN ack for a previously sent command within some timeout period. Given the above usage of command restart, no X bit is required to be set in the SCSI Command PDU when command re-start is done. Either : (a) the target had dropped the command earlier due to a digest error, in which case, the command restart plugs the CmdSN hole in the target. [OR] (b) the target had received the command and was working on it, when the initiator timed out too soon and attempted a command restart to plug [what it thought was] a possible hole in the CmdSN sequence. In case (a), no X bit was required, since the target knows nothing of the original command. In case (b), no X bit is required again, since the (ExpCmdSN, MaxCmdSN) window would have advanced and the target can silently discard the received retry and continue working on the original command received. Removal of the X bit in the SCSI Command PDU has the following benefits : a) The CmdSN rules at the target are simplified. No need to look at X bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) window. b) The reject reason code "command already in progress" can be removed. There's no need for this reject reason code anymore, since X bit itself is not required, and the targets can silently discard commands outside the command window and continue to work on the original instance of the command already being processed at the target. c) Less work for the target and less resources consumed since it no longer needs to generate a Reject PDU of type "command in progress". It can just silently discard any command PDU outside the (ExpCmdSN, MaxCmdSN) window. d) Less code for the target, since it does not need : - any Reject code paths when it receives X bit command PDUs that are already in progress. - No special casing of CmdSN checking rules. - No overheads of verifying a received command based on its initiator task tag, to check if the task is currently active, prior to sending a Reject response with "command in progress". 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 Sat Oct 6 01:54: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 BAA11970 for ; Sat, 6 Oct 2001 01:54:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f965BG723880 for ips-outgoing; Sat, 6 Oct 2001 01:11:16 -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 f965BEl23874 for ; Sat, 6 Oct 2001 01:11:14 -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 HAA241582 for ; Sat, 6 Oct 2001 07:11:07 +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 f965B6t146822 for ; Sat, 6 Oct 2001 07:11:07 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Serial Number Arithmetic X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 6 Oct 2001 08:11:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 06/10/2001 08:11:06, Serialize complete at 06/10/2001 08:11:06 Content-Type: multipart/alternative; boundary="=_alternative 001C8519C2256ADD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 001C8519C2256ADD_= Content-Type: text/plain; charset="us-ascii" Pat - Comments in text - Thanks, Julo _____________________ Julian, The draft says serial number arithmetic as defined in RFC 1982 is to be used for comparisons and arithmetic on CmdSN but but it uses operations which are inconsistant with that statement. 2.2.2.1 (bottom half of page 26) re: the processing for MaxCmdSN and ExpCmdSN - "and with a difference bounded by 2**31-1" should be deleted (3 places). The RFC 1982 Serial Number Arithmetic rules cover the meaning of addition of a positive integer of limited range and comparison (<, > and =) for serial numbers. "Only two operations are defined upon serial numbers, addition of a positive integer of limited range, and comparison with another serial number." The operation difference is not defined for Serial Numbers. +++ will fix - 2**31-1 is implied by serial arithmetic+++ 2.2.2.2 re: "difference is greater than 2**31-1" - The operation difference is not defined for Serial number arithmetic. Even if it was defined as the inverse of addition, addition is only defined for adding a value up to 2**31-1. Is the intent of the statement that it should cover only the value where the results of StatSN > ExpStatSN and StatSN < ExpStatSN are undefined or is the intent that it cover that value plus the values where ExpStat > StatSN? The former doesn't seem useful and the latter seems rather severe. Regards, Pat Thaler ++++ StatSN follows regular mod(2**32) arithmetic. 2**31 is meant to state the limit at which recovery action becomes mandatory Here is a new 2.2.2.2 that perhaps states this clearer+++ 1.1.1.1 Response/Status Numbering and Acknowledging Responses in transit from the target to the initiator are numbered. The StatSN (Status Sequence Number) is used for this purpose. StatSN is a counter maintained per connection. ExpStatSN is used by the initiator to acknowledge status. The status sequence number space is that of 32bit integers and the arithmetic operations are the regular mod(2**32) arithmetic. Status numbering starts with the Login response to the first Login request of the connection. The Login response includes an initial value for status numbering. To enable command recovery the target MAY maintain enough state information to enable data and status recovery after a connection failure. A target can discard all the state information maintained for recovery after the status delivery is acknowledged through ExpStatSN. A large absolute difference between StatSN and ExpStatSN may indicate a failed connection. Initiators undertake recovery actions if the difference is greater than an implementation defined constant that SHALL NOT exceed 2**31-1. Initiators and Targets MUST support the response-numbering scheme. --=_alternative 001C8519C2256ADD_= Content-Type: text/html; charset="us-ascii"
Pat - Comments in text - Thanks, Julo
_____________________
Julian,

The draft says serial number arithmetic as defined in RFC 1982 is to be used
for comparisons and arithmetic on CmdSN but but it uses operations which are
inconsistant with that statement.

2.2.2.1 (bottom half of page 26) re: the processing for MaxCmdSN and
ExpCmdSN - "and with a difference bounded by 2**31-1" should be deleted (3
places). The RFC 1982 Serial Number Arithmetic rules cover the meaning of
addition of a positive integer of limited range and comparison (<, > and =)
for serial numbers. "Only two operations are defined upon serial numbers,
addition of a positive integer of limited range, and comparison with another
serial number."  The operation difference is not defined for Serial
Numbers.<?xml:namespace prefix = o ns =
"urn:schemas-microsoft-com:office:office" />
+++ will fix - 2**31-1 is implied by serial arithmetic+++

2.2.2.2 re: "difference is greater than 2**31-1" - The operation difference
is not defined for Serial number arithmetic. Even if it was defined as the
inverse of addition, addition is only defined for adding a value up to
2**31-1. Is the intent of the statement that it should cover only the value
where the results of StatSN > ExpStatSN and StatSN < ExpStatSN are undefined
or is the intent that it cover that value plus the values where ExpStat >
StatSN? The former doesn't seem useful and the latter seems rather severe.

Regards,
Pat Thaler
++++ StatSN follows regular mod(2**32) arithmetic. 2**31 is meant to state the limit at which recovery action becomes mandatory
Here is a new 2.2.2.2 that perhaps states this clearer+++


1.1.1.1        Response/Status Numbering and Acknowledging

Responses in transit from the target to the initiator are numbered.  The StatSN (Status Sequence Number) is used for this purpose. StatSN is a counter maintained per connection.  ExpStatSN is used by the initiator to acknowledge status. The status sequence number space is that of 32bit integers and the arithmetic operations are the regular mod(2**32) arithmetic.

Status numbering starts with the Login response to the first Login request of the connection. The Login response includes an initial value for status numbering.

To enable command recovery the target MAY maintain enough state information to enable data and status recovery after a connection failure.  A target can discard all the state information maintained for recovery after the status delivery is acknowledged through ExpStatSN.

A large absolute difference between StatSN and ExpStatSN may indicate a failed connection. Initiators undertake recovery actions if the difference is greater than an implementation defined constant that SHALL NOT exceed 2**31-1.

Initiators and Targets MUST support the response-numbering scheme.

--=_alternative 001C8519C2256ADD_=-- From owner-ips@ece.cmu.edu Sat Oct 6 03: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 DAA23542 for ; Sat, 6 Oct 2001 03:01:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f966n2E27845 for ips-outgoing; Sat, 6 Oct 2001 02:49:02 -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 f966n0l27841 for ; Sat, 6 Oct 2001 02:49:00 -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 IAA194650 for ; Sat, 6 Oct 2001 08:48: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 f966mrb72980 for ; Sat, 6 Oct 2001 08:48:53 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: ImmediateData & InitialR2T X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 6 Oct 2001 09:48:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 06/10/2001 09:48:53, Serialize complete at 06/10/2001 09:48:53 Content-Type: multipart/alternative; boundary="=_alternative 00257874C2256ADD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00257874C2256ADD_= Content-Type: text/plain; charset="us-ascii" Ayman, iSCSI connections are not separate entities. Commands are sent over a session and connection should not be visible over a certain level. Using Immediate data belongs to a very high level layer (where the endpoint facilities are handled). Connections should have nothing to say about it. Julo "Ayman Ghanem" Sent by: owner-ips@ece.cmu.edu 05-10-01 16:02 Please respond to "Ayman Ghanem" To: cc: Subject: RE: iSCSI: ImmediateData & InitialR2T The text doesn't say these are connection specific, so they must be session specific. Connection 1 logs in and doesn't send the ImmediateData key because it wants to use the default "yes". If connection 2 sends ImmediateData=no and the target agrees to that, how is this going to affect connection 1 which thinks it can send immediate data, and may actually have data in flight to the target. I think these two keys should have the same use restrictions as DataPDULength, FirstBurstSize, and MaxBurstSize, all have Use:LO. -Ayman > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Friday, October 05, 2001 4:24 AM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: ImmediateData & InitialR2T > > > > why ? Julo > > > > > "Ayman Ghanem" > > > .com> cc: > > Sent by: Subject: iSCSI: > ImmediateData & InitialR2T > owner-ips@ece. > > cmu.edu > > > > > > 04-10-01 17:42 > > Please respond > > to "Ayman > > Ghanem" > > > > > > > > > Julian, > > The use of these two keys is currently set to "Use: ALL". I think they > should be allowed only on the leading connection, so a second connection > can > not change them on the first. > > -Ayman > > > > > > --=_alternative 00257874C2256ADD_= Content-Type: text/html; charset="us-ascii"
Ayman,

iSCSI connections are not separate entities. Commands are sent over a session and connection should not be visible over a certain level.  Using Immediate data belongs to a very high level layer (where the endpoint facilities are handled).
Connections should have nothing to say about it.

Julo


"Ayman Ghanem" <aghanem@cisco.com>
Sent by: owner-ips@ece.cmu.edu

05-10-01 16:02
Please respond to "Ayman Ghanem"

       
        To:        <ips@ece.cmu.edu>
        cc:        
        Subject:        RE: iSCSI: ImmediateData & InitialR2T

       


The text doesn't say these are connection specific, so they must be session
specific. Connection 1 logs in and doesn't send the ImmediateData key
because it wants to use the default "yes". If connection 2 sends
ImmediateData=no and the target agrees to that, how is this going to affect
connection 1 which thinks it can send immediate data, and may actually have
data in flight to the target. I think these two keys should have the same
use restrictions as DataPDULength, FirstBurstSize, and MaxBurstSize, all
have Use:LO.

-Ayman

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Friday, October 05, 2001 4:24 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI: ImmediateData & InitialR2T
>
>
>
> why ?  Julo
>
>
>
>
>                     "Ayman Ghanem"
>
>                     <aghanem@cisco       To:
> <ips@ece.cmu.edu>
>                     .com>                cc:
>
>                     Sent by:             Subject:     iSCSI:
> ImmediateData & InitialR2T
>                     owner-ips@ece.
>
>                     cmu.edu
>
>
>
>
>
>                     04-10-01 17:42
>
>                     Please respond
>
>                     to "Ayman
>
>                     Ghanem"
>
>
>
>
>
>
>
>
> Julian,
>
> The use of these two keys is currently set to "Use: ALL". I think they
> should be allowed only on the leading connection, so a second connection
> can
> not change them on the first.
>
> -Ayman
>
>
>
>
>
>

--=_alternative 00257874C2256ADD_=-- From owner-ips@ece.cmu.edu Sat Oct 6 03:02: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 DAA23630 for ; Sat, 6 Oct 2001 03:02:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f966FCM26454 for ips-outgoing; Sat, 6 Oct 2001 02:15:12 -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 f966FAl26450 for ; Sat, 6 Oct 2001 02:15: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 IAA43874 for ; Sat, 6 Oct 2001 08:15: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 f966F2t249396 for ; Sat, 6 Oct 2001 08:15:02 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSi -08a (an errata in PDF format only) X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 6 Oct 2001 09:14:59 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 06/10/2001 09:15:02, Serialize complete at 06/10/2001 09:15:02 Content-Type: multipart/alternative; boundary="=_alternative 00225FAEC2256ADD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00225FAEC2256ADD_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, I've put an errata (including the new negotiation agreed) as a pdf file on my site (08a). Difference from 08 are marked. Julo --=_alternative 00225FAEC2256ADD_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

I've put an errata (including the new negotiation agreed) as a pdf file on my site (08a).
Difference from 08 are marked.


Julo --=_alternative 00225FAEC2256ADD_=-- From owner-ips@ece.cmu.edu Sat Oct 6 10: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 KAA27104 for ; Sat, 6 Oct 2001 10:35:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f96Dfu027904 for ips-outgoing; Sat, 6 Oct 2001 09:41: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 (81033r2ce.skybernet.net [217.17.136.66]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f96Dfnl27896 for ; Sat, 6 Oct 2001 09:41:49 -0400 (EDT) Received: by ZOETERMEER with Internet Mail Service (5.5.2653.19) id ; Sat, 6 Oct 2001 15:43:55 +0200 Message-ID: <8C59010722BBD31194640050DA6EC6971B98A7@ZOETERMEER> From: "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - revised 2.2.4 Date: Sat, 6 Oct 2001 15:43:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C14E6C.ED336F10" 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_01C14E6C.ED336F10 Content-Type: text/plain; charset="iso-8859-1" Julian, I would also request an explicit definition of offering party and responding party. The current text still leaves ambiguity when target sends a key in response to implicit default key of the Intiator. In this case who is the offering party and who is the responding party Sanjeev -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, October 05, 2001 2:06 PM To: ips@ece.cmu.edu Subject: iSCSI - revised 2.2.4 Here is a revised (complete) part 2.2.4 based on recent agreed changes: 1.1.1 Text Mode Negotiation During login and thereafter some session or connection parameters are negotiated through an exchange of textual information. All negotiations are stateless - i.e. the result MUST be based only on newly exchanged values. The general format of text negotiation is: Originator-> = Responder-> =|reject|NotUnderstood The value can be a number, a single literal constant a Boolean value (yes or no) or a list of comma separated literal constant values. In literal list negotiation, the originator sends for each key a list of options (literal constants which may include "none") in its order of preference. The responding party answers with the first value from the list it supports and is allowed to use for the specific originator. The constant "none" MUST always be used to indicate a missing function. However, none is a valid selection only if it is explicitly offered. If a target is not supporting, or not allowed to use with a specific originator, any of the offered options, it may use the constant "reject". The constants "none" and "reject" are reserved and must be used only as described here. Any key not understood is answered with "NotUnderstood". For numerical and single literal negotiations, the responding party MUST respond with the required key and the value it selects, based on the selection rule specific to the key, becomes the negotiation result. Selection of a value not admissible under the selection rules is considered a protocol error and handled accordingly. For Boolean negotiations (keys taking the values yes or no), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value to respond with are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value. Specifically, the two cases in which responses are OPTIONAL are: - The Boolean function is "AND" and the value "no" is received. The outcome of the negotiation is "no". - The Boolean function is "OR" and the value "yes" is received. The outcome of the negotiation is "yes". Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation. The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood". 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, only the initiator can initiate the negotiation start (through the first Text request) and completion (by setting to 1 and keeping to 1 the F bit in a Text request). Comments ? Julo ------_=_NextPart_001_01C14E6C.ED336F10 Content-Type: text/html; charset="iso-8859-1"

Julian,
 
I would also request an explicit definition of offering party and responding party. The current text still leaves ambiguity when target sends a key in response to implicit default key of the Intiator. In this case who is the offering party and who is the responding party
 
Sanjeev
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, October 05, 2001 2:06 PM
To: ips@ece.cmu.edu
Subject: iSCSI - revised 2.2.4


Here is a revised (complete) part 2.2.4 based on recent agreed changes:

1.1.1        Text Mode Negotiation

During login and thereafter some session or connection parameters are negotiated through an exchange of textual information.

All negotiations are stateless - i.e. the result MUST be based only on newly exchanged values.

The general format of text negotiation is:

Originator-> <key>=<valuex>
Responder-> <key>=<valuey>|reject|NotUnderstood

The value can be a number, a single literal constant a Boolean value (yes or no) or a list of comma separated literal constant values.

In literal list negotiation, the originator sends for each key a list of options (literal constants which may include "none") in its order of preference.

The responding party answers with the first value from the list it supports and is allowed to use for the specific originator.

The constant "none" MUST always be used to indicate a missing function. However, none is a valid selection only if it is explicitly offered.

If a target is not supporting, or not allowed to use with a specific originator, any of the offered options, it may use the constant "reject".  The constants "none" and "reject" are reserved and must be used only as described here.  Any key not understood is answered with "NotUnderstood".

For numerical and single literal negotiations, the responding party MUST respond with the required key and the value it selects, based on the selection rule specific to the key, becomes the negotiation result.  Selection of a value not admissible under the selection rules is considered a protocol error and handled accordingly.

For Boolean negotiations (keys taking the values yes or no), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself.  The last value transmitted becomes the negotiation result.  The rules for selecting the value to respond with are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value.
 
Specifically, the two cases in which responses are OPTIONAL are:

- The Boolean function is "AND" and the value "no" is received. The outcome of the negotiation is "no".
- The Boolean function is "OR" and the value "yes" is received. The outcome of the negotiation is "yes".

Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation.

The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood".

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, only the initiator can initiate the negotiation start (through the first Text request) and completion (by setting to 1 and keeping to 1 the F bit in a Text request).


Comments ?

Julo
------_=_NextPart_001_01C14E6C.ED336F10-- From owner-ips@ece.cmu.edu Sat Oct 6 14:22: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 OAA28434 for ; Sat, 6 Oct 2001 14:22:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f96HHxr07665 for ips-outgoing; Sat, 6 Oct 2001 13:17: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 f96HHtl07657 for ; Sat, 6 Oct 2001 13:17: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 TAA30572 for ; Sat, 6 Oct 2001 19:17: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 f96HHgb213924 for ; Sat, 6 Oct 2001 19:17:44 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI - revised 2.2.4 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 6 Oct 2001 20:17:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 06/10/2001 20:17:43, Serialize complete at 06/10/2001 20:17:43 Content-Type: multipart/alternative; boundary="=_alternative 005EFD6EC2256ADD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 005EFD6EC2256ADD_= Content-Type: text/plain; charset="us-ascii" See definitions - Julo "Sanjeev Bhagat (TRIPACE/Zoetermeer)" 06-10-01 15:43 Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iSCSI - revised 2.2.4 Julian, I would also request an explicit definition of offering party and responding party. The current text still leaves ambiguity when target sends a key in response to implicit default key of the Intiator. In this case who is the offering party and who is the responding party Sanjeev -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, October 05, 2001 2:06 PM To: ips@ece.cmu.edu Subject: iSCSI - revised 2.2.4 Here is a revised (complete) part 2.2.4 based on recent agreed changes: 1.1.1 Text Mode Negotiation During login and thereafter some session or connection parameters are negotiated through an exchange of textual information. All negotiations are stateless - i.e. the result MUST be based only on newly exchanged values. The general format of text negotiation is: Originator-> = Responder-> =|reject|NotUnderstood The value can be a number, a single literal constant a Boolean value (yes or no) or a list of comma separated literal constant values. In literal list negotiation, the originator sends for each key a list of options (literal constants which may include "none") in its order of preference. The responding party answers with the first value from the list it supports and is allowed to use for the specific originator. The constant "none" MUST always be used to indicate a missing function. However, none is a valid selection only if it is explicitly offered. If a target is not supporting, or not allowed to use with a specific originator, any of the offered options, it may use the constant "reject". The constants "none" and "reject" are reserved and must be used only as described here. Any key not understood is answered with "NotUnderstood". For numerical and single literal negotiations, the responding party MUST respond with the required key and the value it selects, based on the selection rule specific to the key, becomes the negotiation result. Selection of a value not admissible under the selection rules is considered a protocol error and handled accordingly. For Boolean negotiations (keys taking the values yes or no), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value to respond with are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value. Specifically, the two cases in which responses are OPTIONAL are: - The Boolean function is "AND" and the value "no" is received. The outcome of the negotiation is "no". - The Boolean function is "OR" and the value "yes" is received. The outcome of the negotiation is "yes". Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation. The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood". 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, only the initiator can initiate the negotiation start (through the first Text request) and completion (by setting to 1 and keeping to 1 the F bit in a Text request). Comments ? Julo --=_alternative 005EFD6EC2256ADD_= Content-Type: text/html; charset="us-ascii"
See definitions  - Julo


"Sanjeev Bhagat (TRIPACE/Zoetermeer)" <sbhagat@tripace.com>

06-10-01 15:43
Please respond to "Sanjeev Bhagat (TRIPACE/Zoetermeer)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iSCSI - revised 2.2.4

       


Julian,
 
I would also request an explicit definition of offering party and responding party. The current text still leaves ambiguity when target sends a key in response to implicit default key of the Intiator. In this case who is the offering party and who is the responding party
 
Sanjeev
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, October 05, 2001 2:06 PM
To: ips@ece.cmu.edu
Subject: iSCSI - revised 2.2.4

Here is a revised (complete) part 2.2.4 based on recent agreed changes:

1.1.1        Text Mode Negotiation

During login and thereafter some session or connection parameters are negotiated through an exchange of textual information.

All negotiations are stateless - i.e. the result MUST be based only on newly exchanged values.

The general format of text negotiation is:

Originator-> <key>=<valuex>
Responder-> <key>=<valuey>|reject|NotUnderstood

The value can be a number, a single literal constant a Boolean value (yes or no) or a list of comma separated literal constant values.

In literal list negotiation, the originator sends for each key a list of options (literal constants which may include "none") in its order of preference.

The responding party answers with the first value from the list it supports and is allowed to use for the specific originator.

The constant "none" MUST always be used to indicate a missing function. However, none is a valid selection only if it is explicitly offered.

If a target is not supporting, or not allowed to use with a specific originator, any of the offered options, it may use the constant "reject".  The constants "none" and "reject" are reserved and must be used only as described here.  Any key not understood is answered with "NotUnderstood".

For numerical and single literal negotiations, the responding party MUST respond with the required key and the value it selects, based on the selection rule specific to the key, becomes the negotiation result.  Selection of a value not admissible under the selection rules is considered a protocol error and handled accordingly.

For Boolean negotiations (keys taking the values yes or no), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself.  The last value transmitted becomes the negotiation result.  The rules for selecting the value to respond with are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value.
 
Specifically, the two cases in which responses are OPTIONAL are:

- The Boolean function is "AND" and the value "no" is received. The outcome of the negotiation is "no".
- The Boolean function is "OR" and the value "yes" is received. The outcome of the negotiation is "yes".

Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation.

The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood".

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, only the initiator can initiate the negotiation start (through the first Text request) and completion (by setting to 1 and keeping to 1 the F bit in a Text request).


Comments ?

Julo

--=_alternative 005EFD6EC2256ADD_=-- From owner-ips@ece.cmu.edu Sat Oct 6 14:26: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 OAA28447 for ; Sat, 6 Oct 2001 14:26:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f96HpNJ09204 for ips-outgoing; Sat, 6 Oct 2001 13:51:23 -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 f96HpKl09199 for ; Sat, 6 Oct 2001 13:51:20 -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 TAA77210 for ; Sat, 6 Oct 2001 19:51: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 f96HpCt48584 for ; Sat, 6 Oct 2001 19:51:12 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi : X bit in SCSI Command PDU. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 6 Oct 2001 20:51:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 06/10/2001 20:51:12, Serialize complete at 06/10/2001 20:51:12 Content-Type: multipart/alternative; boundary="=_alternative 00620E75C2256ADD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00620E75C2256ADD_= Content-Type: text/plain; charset="us-ascii" Santosh, I am not sure you went through all scenarios. A conversation with your colleague - Mallikarjun - and getting through the state table may go a long way to clarify the need for X. And I am sure that by now you found yourself several . Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 06-10-01 01:56 Please respond to Santosh Rao To: IPS Reflector cc: Subject: iscsi : X bit in SCSI Command PDU. All, With the elimination of command relay from iscsi [in the interests of simplification ?], I believe that the X bit in the SCSI Command PDU can also be removed. As it exists today, the X bit is only being used for command restart, which is at attempt by the initiator to plug a potential hole in the CmdSN sequence at the target. It does this on failing to get an ExpCmdSN ack for a previously sent command within some timeout period. Given the above usage of command restart, no X bit is required to be set in the SCSI Command PDU when command re-start is done. Either : (a) the target had dropped the command earlier due to a digest error, in which case, the command restart plugs the CmdSN hole in the target. [OR] (b) the target had received the command and was working on it, when the initiator timed out too soon and attempted a command restart to plug [what it thought was] a possible hole in the CmdSN sequence. In case (a), no X bit was required, since the target knows nothing of the original command. In case (b), no X bit is required again, since the (ExpCmdSN, MaxCmdSN) window would have advanced and the target can silently discard the received retry and continue working on the original command received. Removal of the X bit in the SCSI Command PDU has the following benefits : a) The CmdSN rules at the target are simplified. No need to look at X bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) window. b) The reject reason code "command already in progress" can be removed. There's no need for this reject reason code anymore, since X bit itself is not required, and the targets can silently discard commands outside the command window and continue to work on the original instance of the command already being processed at the target. c) Less work for the target and less resources consumed since it no longer needs to generate a Reject PDU of type "command in progress". It can just silently discard any command PDU outside the (ExpCmdSN, MaxCmdSN) window. d) Less code for the target, since it does not need : - any Reject code paths when it receives X bit command PDUs that are already in progress. - No special casing of CmdSN checking rules. - No overheads of verifying a received command based on its initiator task tag, to check if the task is currently active, prior to sending a Reject response with "command in progress". 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 00620E75C2256ADD_= Content-Type: text/html; charset="us-ascii"

Santosh,

I am not sure you went through all scenarios. A conversation with your colleague - Mallikarjun - and getting through the state table may go a long way to clarify the need for X.

And I am sure that by now you found yourself several .

Julo


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

06-10-01 01:56
Please respond to Santosh Rao

       
        To:        IPS Reflector <ips@ece.cmu.edu>
        cc:        
        Subject:        iscsi : X bit in SCSI Command PDU.

       


All,

With the elimination of command relay from iscsi [in the interests of
simplification ?], I believe that the X bit in the SCSI Command PDU can
also be removed. As it exists today, the X bit is only being used for
command restart, which is at attempt by the initiator to plug a
potential hole in the CmdSN sequence at the target. It does this on
failing to get an ExpCmdSN ack for a previously sent command within some
timeout period.

Given the above usage of command restart, no X bit is required to be set
in the SCSI Command PDU when command re-start is done.

Either :
(a) the target had dropped the command earlier due to a digest error, in
which case, the command restart plugs the CmdSN hole in the target.

[OR]

(b) the target had received the command and was working on it, when the
initiator timed out too soon and attempted a command restart to plug
[what it thought was] a possible hole in the CmdSN sequence.

In case (a), no X bit was required, since the target knows nothing of
the original command. In case (b), no X bit is required again, since the
(ExpCmdSN, MaxCmdSN) window would have advanced and the target can
silently discard the received retry and continue working on the original
command received.

Removal of the X bit in the SCSI Command PDU has the following benefits
:

a) The CmdSN rules at the target are simplified. No need to look at X
bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) window.

b) The reject reason code "command already in progress" can be removed.
There's no need for this reject reason code anymore, since X bit itself
is not required, and the targets can silently discard commands outside
the command window and continue to work on the original instance of the
command already being processed at the target.

c) Less work for the target and less resources consumed since it no
longer needs to generate a Reject PDU of type "command in progress". It
can just silently discard any command PDU outside the (ExpCmdSN,
MaxCmdSN) window.

d) Less code for the target, since it does not need :
- any Reject code paths when it receives X bit command PDUs that are
already in progress.
- No special casing of CmdSN checking rules.
- No overheads of verifying a received command based on its initiator
task tag, to check if the task is currently active, prior to sending a
Reject response with "command in progress".


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 00620E75C2256ADD_=-- From owner-ips@ece.cmu.edu Sat Oct 6 15:55: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 PAA28885 for ; Sat, 6 Oct 2001 15:55:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f96J3nA12745 for ips-outgoing; Sat, 6 Oct 2001 15:03: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 f96J3kl12740 for ; Sat, 6 Oct 2001 15:03:46 -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 VAA27820 for ; Sat, 6 Oct 2001 21:03:39 +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 f96J3db245290 for ; Sat, 6 Oct 2001 21:03:39 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iscsi : DataPDULength can differ in each direction. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 6 Oct 2001 22:03:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 06/10/2001 22:03:39, Serialize complete at 06/10/2001 22:03:39 Content-Type: multipart/alternative; boundary="=_alternative 0068BDE3C2256ADD_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0068BDE3C2256ADD_= Content-Type: text/plain; charset="us-ascii" As I said this requested change has value and we are going to do our best to incorporate it in 09. Fortunately PDUlength has few dependencies in the protocol. Unfortunately (as I said already) we would like PDUlength to a be a per connection parameter as it is it closely related to the Path MTU. This later assumption may require some changes in the recovery mechanism (the current recovery mechanism assumes that any PDU can be "replayed" as it was on every connection and this assumption won't hold anymore). Mallikarjun and myself will attempt to get a better understanding of the things required and will keep you updated. I think we have enough information to work on it and we will keep the list updated on what we think can be done and how. We have several alternatives and would appreciate some timeout on this thread. Julo --=_alternative 0068BDE3C2256ADD_= Content-Type: text/html; charset="us-ascii"
As I said this requested change has value and we are going to do our best to incorporate it in 09.

Fortunately PDUlength has few dependencies in the protocol.

Unfortunately (as I said already) we would like PDUlength to a be a per connection parameter as it is it closely related to the Path MTU.  

This later assumption may require some changes in the recovery mechanism (the current recovery mechanism assumes that any PDU can be "replayed" as it was on every connection and this assumption won't hold anymore).

Mallikarjun and myself will attempt to get a better understanding of the things required and will keep you updated.

I think we have enough information to work on it and we will keep the list updated on what we think can be done and how.

We have several alternatives and would appreciate some timeout on this thread.

Julo --=_alternative 0068BDE3C2256ADD_=-- From owner-ips@ece.cmu.edu Sun Oct 7 03:34: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 DAA21156 for ; Sun, 7 Oct 2001 03:34:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f976ceD13625 for ips-outgoing; Sun, 7 Oct 2001 02:38: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 f976cbl13621 for ; Sun, 7 Oct 2001 02:38:37 -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 IAA84122 for ; Sun, 7 Oct 2001 08:38: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 f976cS0192878 for ; Sun, 7 Oct 2001 08:38:28 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi : DataPDULength can differ in each direction. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sun, 7 Oct 2001 09:38:24 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 07/10/2001 09:38:28, Serialize complete at 07/10/2001 09:38:28 Content-Type: multipart/alternative; boundary="=_alternative 002484B8C2256ADE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 002484B8C2256ADE_= Content-Type: text/plain; charset="us-ascii" Mallikarjun, We go offline on this. The dataoffset brings us to where we did not want ever to be - scoreboarding by initiator. This is against SCSI basics - data transfer is managed by target. Julo "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 05-10-01 19:35 Please respond to cbm To: ips cc: Subject: Re: iscsi : DataPDULength can differ in each direction. Julian, I don't really have a strong opinion on connection vs session applicability of DataPDULength, but one comment. If we specify the current ExpDataSN in Task Management function request (reassign) to be in stead "Expected Buffer Offset", this appears to enable per-connection DataPDULength. Specifying a buffer offset may also be helpful to targets in general, not requiring them to bring the DataSN->buffer_offset translation from a (potentially failed) different NIC (though perhaps it is not all that serious in practice since implementations will send DataPDULength-sized PDUs except for the last in an I/O). Do you see any other issues that complicate a connection-specific value? Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > I think that the set of arguments we have heard are solid enough to > the DataPDUlength becoming a parameter that characterizes the receiver > only. > > However this parameter should be also connection specific so that the > sender and receiver can align (some framing mechanisms may require > adaptation to path MTU) and having a different DataPDUlength on > different paths can affect recovery. > > If we leave it session specific the logic of iSCSI can easily > incorporate different PDU lengths and the draft changes are very > limited. > > Julo > > Dave Sheehy > To: > Sent by: owner-ips@ece.cmu.edu ips@ece.cmu.edu (IETF IP > SAN Reflector) > 05-10-01 01:13 cc: > Please respond to Dave Sheehy Subject: RE: > iscsi : DataPDULength can > differ in each direction. > > > > Comments in text. > > > > > Can someone give a tangible benefit to this > that can > > > outweigh the > > > > spec and implementation churn at this late stage of the game? > > > > > > It would allow iSCSI HBAs to interact more efficiently > > > with SW iSCSI > > > implementations and vice versa. > > > > > > > I don't believe it would in practice. Consider the following. The > max > > PDU size sent during login is more that just that, it is in fact the > > senders maximum supportable max PDU size. If one side sends 64k and > > the other side 8k although it is technically indicating it can't > > receive more than 8k in a single PDU, for all practical purposes it > is > > also indicating it can't handle, and therefore can't send PDUs > bigger > > than 8k. > > I think that's a faulty interpretation of what's being proposed. As in > both > Fibre Channel and TCP the offered PDU size is the size you're willing > to > accept. It can and often is completely decoupled from the size you're > capable > of sending. This is commonly implemented in Fibre Channel and it's not > > exactly rocket science. > > > I believe if we go this route we'll simply see the side with the > lower > > DataPDULength sending its "natural" size PDUs and never sending the > > larger size wanted by the other side. More on this below ... > > > > > > From my point of view the benefit of > asymmetric PDU > > > sizes would have > > > > to be very large to make it worth the extra complexity > > > in buffer > > > > management code alone. > > > > > > >From the vantage point of an iSCSI HBA it doesn't seem > > > all that hard. > > > > > > > Well, it seems to me faced with a peer with a different max PDU size > > there are relatively few ways to proceed. > > Again, I believe it's fairly straightforward and there are real life > examples that work exactly this way. The only unfortunate thing is > that it's > been proposed at this late date. In hind sight, it's a feature with an > obvious benefit. > > > If the peer has a lower max PDU size there are 2 choices. Use 2 > buffer > > pools, one for receive set to the local Max PDU size, and one for > send > > set to the peer Max PDU size. This is where the extra buffer > > management complexity comes in. Or, use one buffer pool and simply > > part fill the buffers for sending. This is the easy case. > > I don't see what buffer size has to do with PDU size that's not > implementation > dependent. The PDU content is going to be fragmented anyway (i.e. > network > header, iSCSI header, data, digest, ...) so the problem you describe > exists > regardless. > > > If the peer has a larger max PDU size then either only send up to > the > > local PDU size, as I mentioned above, or chain buffers together to > > build larger than the local max PDU size. Again, this is where the > > extra buffer management complexity comes in. Remember that by > > definition these chains will need to be bigger than the largest > chain > > size the implementation can handle. Unless for some reason the > > DataPDULength sent was chosen at some arbitrary size smaller than > the > > implementations maximum. > > I think SW iSCSI stacks are going to want to use big PDUs and in > general > iSCSI HBAs are going to use small ones. I think the SW stacks are > going to > set up their buffer structures to use large PDUs. I don't think > (although > it's certainly possible) that they are going to dynamically adjust > their > buffer sizes for each iSCSI session. So, in the scenario where a SW > iSCSI > stack is talking to an iSCSI HBA it's buffering is going to be used > inefficiently in both directions. If the Data PDU Length is negotiated > separately for each direction then the buffering on the SW side is > being > used inefficiently in only one direction. Both sides win with this > behavior. > > Dave --=_alternative 002484B8C2256ADE_= Content-Type: text/html; charset="us-ascii"
Mallikarjun,

We go offline on this. The dataoffset brings us to where we did not want ever to be - scoreboarding by initiator.
This is against SCSI basics - data transfer is managed by target.

Julo


"Mallikarjun C." <cbm@rose.hp.com>
Sent by: owner-ips@ece.cmu.edu

05-10-01 19:35
Please respond to cbm

       
        To:        ips <ips@ece.cmu.edu>
        cc:        
        Subject:        Re: iscsi : DataPDULength can differ in each direction.

       


Julian,

I don't really have a strong opinion on connection vs session
applicability of DataPDULength, but one comment.

If we specify the current ExpDataSN in Task Management function
request (reassign) to be in stead "Expected Buffer Offset", this
appears to enable per-connection DataPDULength.  Specifying a
buffer offset may also be helpful to targets in general, not
requiring them to bring the DataSN->buffer_offset translation
from a (potentially failed) different NIC (though perhaps it is
not all that serious in practice since implementations will
send DataPDULength-sized PDUs except for the last in an I/O).

Do you see any other issues that complicate a connection-specific
value?

Regards.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com

Julian Satran wrote:
>
> I think that the set of arguments we have heard are solid enough to
> the DataPDUlength becoming a parameter that characterizes the receiver
> only.
>
> However this parameter should be also connection specific so that the
> sender and receiver can align (some framing mechanisms may require
> adaptation to path MTU) and having a different DataPDUlength on
> different paths can affect recovery.
>
> If we leave it session specific the logic of iSCSI can easily
> incorporate different PDU lengths and the draft changes are very
> limited.
>
> Julo
>
>  Dave Sheehy
>  <dbs@acropora.rose.agilent.com>                 To:
>  Sent by: owner-ips@ece.cmu.edu           ips@ece.cmu.edu (IETF IP
>                                          SAN Reflector)
>  05-10-01 01:13                                  cc:
>  Please respond to Dave Sheehy                   Subject:        RE:
>                                          iscsi : DataPDULength can
>                                          differ in each direction.
>
>
>
> Comments in text.
>
> >   >  >                  Can someone give a tangible benefit to this
> that can
> >   >  outweigh the
> >   >  > spec and implementation churn at this late stage of the game?
> >   >
> >   >  It would allow iSCSI HBAs to interact more efficiently
> >   >  with SW iSCSI
> >   >  implementations and vice versa.
> >   >
> >
> > I don't believe it would in practice. Consider the following. The
> max
> > PDU size sent during login is more that just that, it is in fact the
> > senders maximum supportable max PDU size. If one side sends 64k and
> > the other side 8k although it is technically indicating it can't
> > receive more than 8k in a single PDU, for all practical purposes it
> is
> > also indicating it can't handle, and therefore can't send PDUs
> bigger
> > than 8k.
>
> I think that's a faulty interpretation of what's being proposed. As in
> both
> Fibre Channel and TCP the offered PDU size is the size you're willing
> to
> accept. It can and often is completely decoupled from the size you're
> capable
> of sending. This is commonly implemented in Fibre Channel and it's not
>
> exactly rocket science.
>
> > I believe if we go this route we'll simply see the side with the
> lower
> > DataPDULength sending its "natural" size PDUs and never sending the
> > larger size wanted by the other side. More on this below ...
> >
> >   >  >                  From my point of view the benefit of
> asymmetric PDU
> >   >  sizes would have
> >   >  > to be very large to make it worth the extra complexity
> >   >  in buffer
> >   >  > management code alone.
> >   >
> >   >  >From the vantage point of an iSCSI HBA it doesn't seem
> >   >  all that hard.
> >   >
> >
> > Well, it seems to me faced with a peer with a different max PDU size
> > there are relatively few ways to proceed.
>
> Again, I believe it's fairly straightforward and there are real life
> examples that work exactly this way. The only unfortunate thing is
> that it's
> been proposed at this late date. In hind sight, it's a feature with an
> obvious benefit.
>
> > If the peer has a lower max PDU size there are 2 choices. Use 2
> buffer
> > pools, one for receive set to the local Max PDU size, and one for
> send
> > set to the peer Max PDU size. This is where the extra buffer
> > management complexity comes in. Or, use one buffer pool and simply
> > part fill the buffers for sending. This is the easy case.
>
> I don't see what buffer size has to do with PDU size that's not
> implementation
> dependent. The PDU content is going to be fragmented anyway (i.e.
> network
> header, iSCSI header, data, digest, ...) so the problem you describe
> exists
> regardless.
>
> > If the peer has a larger max PDU size then either only send up to
> the
> > local PDU size, as I mentioned above, or chain buffers together to
> > build larger than the local max PDU size. Again, this is where the
> > extra buffer management complexity comes in. Remember that by
> > definition these chains will need to be bigger than the largest
> chain
> > size the implementation can handle. Unless for some reason the
> > DataPDULength sent was chosen at some arbitrary size smaller than
> the
> > implementations maximum.
>
> I think SW iSCSI stacks are going to want to use big PDUs and in
> general
> iSCSI HBAs are going to use small ones. I think the SW stacks are
> going to
> set up their buffer structures to use large PDUs. I don't think
> (although
> it's certainly possible) that they are going to dynamically adjust
> their
> buffer sizes for each iSCSI session. So, in the scenario where a SW
> iSCSI
> stack is talking to an iSCSI HBA it's buffering is going to be used
> inefficiently in both directions. If the Data PDU Length is negotiated
> separately for each direction then the buffering on the SW side is
> being
> used inefficiently in only one direction. Both sides win with this
> behavior.
>
> Dave

--=_alternative 002484B8C2256ADE_=-- From owner-ips@ece.cmu.edu Sun Oct 7 04:21: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 EAA21305 for ; Sun, 7 Oct 2001 04:21:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f977b7q16019 for ips-outgoing; Sun, 7 Oct 2001 03:37:07 -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 f977b5l16014 for ; Sun, 7 Oct 2001 03:37:05 -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 JAA54668 for ; Sun, 7 Oct 2001 09:36:58 +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 f977avX269994 for ; Sun, 7 Oct 2001 09:36:58 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi : query based login negotiation. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sun, 7 Oct 2001 10:36:54 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 07/10/2001 10:36:58, Serialize complete at 07/10/2001 10:36:58 Content-Type: multipart/alternative; boundary="=_alternative 00291B18C2256ADE_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00291B18C2256ADE_= Content-Type: text/plain; charset="us-ascii" Santosh, I am somewhat at a loss as to what you are suggesting. We use now "?" to query current value (not necessarily the default or maximum). If the list finds desirable a Maximum/Minimum based negotiation we may want to introduce another type of query or have the ? return a triple (current,maximum,minimum). Please note that this type of information is probably also provided by a management tool that has the device characteristics and to where this function naturally belongs. Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 05-10-01 18:09 Please respond to Santosh Rao To: IPS Reflector cc: Subject: iscsi : query based login negotiation. Julian, I have another question on the subject of login negotiation, which was brought up earlier in a previous mail. I've enclosed the mail below [with irrelevant portions snipped out.] Could you please clarify if the below described behaviour is possible ? Thanks, Santosh Santosh Rao wrote: > > Julian, > > Another value-add of the "responder picks the negotiation result model" > is that the initiator can use the following "query based" negotiation > model to always use the values the target is capable of offering : > > I -> T : DataPDULength=? > T -> I : DataPDULength=64K > > Both sides agree to use a DataPDULength of 64K. > I suggest that we allow the above "query based model", since this is > more efficient to use when an initiator has no key limitations and would > like to use the value a target can offer. In order to allow the "query > based model", you would need to state in the draft that a key value of > "?" over-rides the default, implying the target offered value would be > the result of the negotiation. > > In particular, the "query based model" is quite useful when an initiator > wishes to function with the target's maximal supported values for keys > like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T, > LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any > limitations on its own key value. > > 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 00291B18C2256ADE_= Content-Type: text/html; charset="us-ascii"
Santosh,

I am somewhat at a loss as to what you are suggesting.
We use now "?" to query current value (not necessarily the default or maximum).
If the list finds desirable a Maximum/Minimum based negotiation we may want to introduce another
type of query or have the ? return a triple (current,maximum,minimum).  
Please note that this type of information is probably also
provided by a management tool that has the device characteristics and to where this function naturally belongs.

Julo


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

05-10-01 18:09
Please respond to Santosh Rao

       
        To:        IPS Reflector <ips@ece.cmu.edu>
        cc:        
        Subject:        iscsi : query based login negotiation.

       


Julian,

I have another question on the subject of login negotiation, which was
brought up earlier in a previous mail. I've enclosed the mail below
[with irrelevant portions snipped out.]

Could you please clarify if the below described behaviour is possible ?

Thanks,
Santosh


Santosh Rao wrote:
>
> Julian,
>
> Another value-add of the "responder picks the negotiation result model"
> is that the initiator can use the following "query based" negotiation
> model to always use the values the target is capable of offering :
>
> I -> T : DataPDULength=?
> T -> I : DataPDULength=64K
>
> Both sides agree to use a DataPDULength of 64K.

> I suggest that we allow the above "query based model", since this is
> more efficient to use when an initiator has no key limitations and would
> like to use the value a target can offer. In order to allow the "query
> based model", you would need to state in the draft that a key value of
> "?" over-rides the default, implying the target offered value would be
> the result of the negotiation.
>
> In particular, the "query based model" is quite useful when an initiator
> wishes to function with the target's maximal supported values for keys
> like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T,
> LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any
> limitations on its own key value.
>
> 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 00291B18C2256ADE_=-- From owner-ips@ece.cmu.edu Sun Oct 7 05:08: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 FAA21432 for ; Sun, 7 Oct 2001 05:08:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f978KPW17774 for ips-outgoing; Sun, 7 Oct 2001 04:20:25 -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 f978KNl17768 for ; Sun, 7 Oct 2001 04:20: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 EAA54948 for ; Sun, 7 Oct 2001 04:17:57 -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 f978J5D84530 for ; Sun, 7 Oct 2001 02:19:05 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI:TargetName Kework=value 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: Sun, 7 Oct 2001 01:18:09 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/07/2001 02:19:05 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Appendix D dealing with the Login/Text Operational keys has the following statement with regards to TargetName=: "The TargetName key may also be returned by the "SendTargets" text request (and that is its only use when issued by a target)." Yet in Appendix A, under Login Phase examples, all the examples seem to end by the target sending the TargetName=. Which of these Appendix are correct? Can the Target send TargetName = keyword outside of a response to the "SendTarget" Command? . . . 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 Sun Oct 7 13:14: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 NAA24625 for ; Sun, 7 Oct 2001 13:14:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f97GE0E17249 for ips-outgoing; Sun, 7 Oct 2001 12:14:00 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from siaar2aa.compuserve.com (siaar2aa.compuserve.com [149.174.40.137]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f97GDvl17236 for ; Sun, 7 Oct 2001 12:13:57 -0400 (EDT) Received: (from mailgate@localhost) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id MAA05903 for ips@ece.cmu.edu; Sun, 7 Oct 2001 12:13:50 -0400 (EDT) Received: from compuserve.com (dal-tgn-tvq-vty19.as.wcom.net [216.192.240.19]) by siaar2aa.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id MAA05641 for ; Sun, 7 Oct 2001 12:13:37 -0400 (EDT) Message-ID: <3BC0802A.5D0A43AA@compuserve.com> Date: Sun, 07 Oct 2001 11:17:46 -0500 From: Ralph Weber Reply-To: ENDL_TX@computer.org X-Mailer: Mozilla 4.7 [en]C-CCK-MCD NSCPCD47 (Win98; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IPS Reflector Subject: draft-ietf-ips-fcencapsulation-03 on T11 web site References: <3BBE1055.D24C92D5@compuserve.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit draft-ietf-ips-fcencapsulation-03 is now available on the T11 web site as: ftp://ftp.t11.org/t11/pub/fc/bb-2/01-524v0.txt ftp://ftp.t11.org/t11/pub/fc/bb-2/01-524v0.pdf The PDF file has change bar for all changed from -02. FYI Ralph... From owner-ips@ece.cmu.edu Sun Oct 7 21:14: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 VAA26549 for ; Sun, 7 Oct 2001 21:14:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f97MkRS05331 for ips-outgoing; Sun, 7 Oct 2001 18:46:27 -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 f95F5al05023 for ; Fri, 5 Oct 2001 11:05:37 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f95F36D07304; Fri, 5 Oct 2001 11:03:06 -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 f95F35t04492; Fri, 5 Oct 2001 11:03:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15293.52176.384000.352706@gargle.gargle.HOWL> Date: Fri, 5 Oct 2001 11:03:44 -0400 From: Paul Koning To: santoshr@cup.hp.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iscsi : originating & responding parties in login. References: <3BBCFC2D.DC567B88@cup.hp.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 4 October 2001) by Santosh Rao: > Julian, > > I don't understand why that requirement exists. An initiator should be > considered as the originator if he sends a login key implicitly thru the > use of defaults. This ensures that the login process ends at the > initiator and avoids redundant login handshakes. > > Could you please explain further as to why you need to differentiate b/n > an initiator that sent keys explicitly and one that used defaults ? I second that. The default should simply be an alternate way of encoding the value. It only adds useless complexity if the state machine reacts differently for default vs. the same value explicitly coded. paul From owner-ips@ece.cmu.edu Sun Oct 7 21:16: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 VAA26574 for ; Sun, 7 Oct 2001 21:16:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f97Mkjj05347 for ips-outgoing; Sun, 7 Oct 2001 18:46:45 -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 f95FGYl05851 for ; Fri, 5 Oct 2001 11:16:34 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f95FGHD07356; Fri, 5 Oct 2001 11:16:17 -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 f95FGH405239; Fri, 5 Oct 2001 11:16:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15293.52968.673000.606083@gargle.gargle.HOWL> Date: Fri, 5 Oct 2001 11:16:56 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI - revised 2.2.4 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 5 October 2001) by Julian Satran: > ... > For numerical and single literal negotiations, the responding party MUST > respond with the required key and the value it selects, based on the > selection rule specific to the key, becomes the negotiation result. > Selection of a value not admissible under the selection rules is > considered a protocol error and handled accordingly. > > For Boolean negotiations (keys taking the values yes or no), the > responding party MUST respond with the required key and the result of the > negotiation when the received value does not determine that result by > itself. The last value transmitted becomes the negotiation result. The > rules for selecting the value to respond with are expressed as Boolean > functions of the value received and the value that the responding party > would select in the absence of knowledge of the received value. > > Specifically, the two cases in which responses are OPTIONAL are: > > - The Boolean function is "AND" and the value "no" is received. The > outcome of the negotiation is "no". > - The Boolean function is "OR" and the value "yes" is received. The > outcome of the negotiation is "yes". > > Responses are REQUIRED in all other cases, and the value chosen and sent > by the responder becomes the outcome of the negotiation. Julian, I'm agreeing with Santosh here -- there's extra complexity for the boolean case that just adds code without any benefit. More code == more bugs. The rule should be the same for all cases -- responder sends back the result of the negotiation, always, no exceptions. That way, the half page of rules quoted above reduces to simply the following: The responding party MUST respond with the required key and the value it selects, based on the selection rule specific to the key, becomes the negotiation result. Selection of a value not admissible under the selection rules is considered a protocol error and handled accordingly. No exception cases, no variations for different data types. paul From owner-ips@ece.cmu.edu Sun Oct 7 21:23: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 VAA26603 for ; Sun, 7 Oct 2001 21:23:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f97KK9F28407 for ips-outgoing; Sun, 7 Oct 2001 16:20:09 -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 f97KK6l28401 for ; Sun, 7 Oct 2001 16:20:06 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id NAA24638; Sun, 7 Oct 2001 13:19:43 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , Subject: RE: iscsi : DataPDULength can differ in each direction. Date: Sun, 7 Oct 2001 21:22: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 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 and all, Before you go ahead and spend time and energy on this I would just like to re-iterate my concerns that in practice few, if any, implementations will support asymmetric PDU sizes. If, for example, a software initiator indicates a max PDU size of 128k and a hardware target indicates 8k, do we really think the target will ever send a 128k PDU? I don't believe it will. The supporting argument seems to be predicated on the fact that the buffer management changes needed to make this happen are trivial. However, if an implementation can chain buffers together on transmit to build PDUs larger than the maximum size offered why can't it do so on receive? And if it can do so on receive why would it ever offer a maximum lower than the real maximum it can support? As an aside, I think this change might create something of a headache for sniffers since they now have to buffer the larger of the offered sizes instead of the smaller. I agree that asymmetric PDU sizes seem beneficial but I have a very hard time believing we'll see any implementations that can take advantage of this feature. I also think the benefit might be relatively small and is probably not worth the level of spec change at this late stage. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Saturday, October 06, 2001 8:04 PM To: ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. As I said this requested change has value and we are going to do our best to incorporate it in 09. Fortunately PDUlength has few dependencies in the protocol. Unfortunately (as I said already) we would like PDUlength to a be a per connection parameter as it is it closely related to the Path MTU. This later assumption may require some changes in the recovery mechanism (the current recovery mechanism assumes that any PDU can be "replayed" as it was on every connection and this assumption won't hold anymore). Mallikarjun and myself will attempt to get a better understanding of the things required and will keep you updated. I think we have enough information to work on it and we will keep the list updated on what we think can be done and how. We have several alternatives and would appreciate some timeout on this thread. Julo From owner-ips@ece.cmu.edu Sun Oct 7 21: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 VAA27852 for ; Sun, 7 Oct 2001 21:37:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f980nLU11205 for ips-outgoing; Sun, 7 Oct 2001 20:49:21 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f980nIl11199 for ; Sun, 7 Oct 2001 20:49:18 -0400 (EDT) Received: from e33.bld.us.ibm.com (e33.esmtp.ibm.com [9.14.4.131]) by admin.ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id RAA59060 for ; Sun, 7 Oct 2001 17:59:06 -0400 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 QAA40502 for ; Sun, 7 Oct 2001 16:57:49 -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 f97Lwv231864 for ; Sun, 7 Oct 2001 15:58:57 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: AuthMethod 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: Sun, 7 Oct 2001 14:58:00 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/07/2001 03:58:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I can not find in our Spec. document a complete Syntactical and Semantic Definition of the keyword strings "AuthMethod=", "DataDigest", or "HeaderDigest". I think it would be useful for these keyword strings to be defined in a manner like the Operational keyword strings that are in Appendix D. . . . 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 Sun Oct 7 21:50: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 VAA28009 for ; Sun, 7 Oct 2001 21:50:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f980ICE09605 for ips-outgoing; Sun, 7 Oct 2001 20:18:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f980IAl09600 for ; Sun, 7 Oct 2001 20:18:10 -0400 (EDT) Received: from e34.bld.us.ibm.com (e34.esmtp.ibm.com [9.14.4.132]) by admin.ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id SAA33576 for ; Sun, 7 Oct 2001 18:36:10 -0400 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 SAA52902 for ; Sun, 7 Oct 2001 18:30: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.98) with ESMTP id f97MVl269534 for ; Sun, 7 Oct 2001 16:31:47 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI:Login Phase and SessionType To: "Julian Satran" Cc: "ips" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sun, 7 Oct 2001 15:30:50 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/07/2001 04:31:47 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Section 5, Login Phase, contains the statement "The initial Login request MUST include the InitiatorName and SessionType key=value pairs." Since the SessionType key=value pair has a default of normal, perhaps the above quoted text is not correct. Perhaps the text should read, "The initial Login request MUST include the InitiatorName and MAY contain SessionType key=value pairs." . . . 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 Sun Oct 7 21:59: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 VAA28145 for ; Sun, 7 Oct 2001 21:59:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f981ad313628 for ips-outgoing; Sun, 7 Oct 2001 21:36: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 f981abl13622 for ; Sun, 7 Oct 2001 21:36: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 DAA54800 for ; Mon, 8 Oct 2001 03:36: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.97.1) with ESMTP id f981aTX267406 for ; Mon, 8 Oct 2001 03:36:29 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Mon, 8 Oct 2001 04:36:26 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/10/2001 04:36:28, Serialize complete at 08/10/2001 04:36:28 Content-Type: multipart/alternative; boundary="=_alternative 0008E05AC2256ADF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0008E05AC2256ADF_= Content-Type: text/plain; charset="us-ascii" Oops - the examples are incorrect and I could have sworn that I've corrected this (as I've seen it myself). Thanks, Julo ____________________________ Julian, Appendix D dealing with the Login/Text Operational keys has the following statement with regards to TargetName=: "The TargetName key may also be returned by the "SendTargets" text request (and that is its only use when issued by a target)." Yet in Appendix A, under Login Phase examples, all the examples seem to end by the target sending the TargetName=. Which of these Appendix are correct? Can the Target send TargetName= keyword outside of a response to the "SendTarget" Command? . . . 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 --=_alternative 0008E05AC2256ADF_= Content-Type: text/html; charset="us-ascii"
Oops - the examples are incorrect and I could have sworn that I've corrected this (as I've seen it myself).

Thanks,
Julo
____________________________
Julian,
Appendix D dealing with the Login/Text Operational keys has the following statement with regards to TargetName=<iSCSI-Name>:

"The TargetName key may also be returned by the "SendTargets" text request (and that is its only use when issued by a target)."

Yet in Appendix A, under Login Phase examples,  all the examples seem to end by the target sending the TargetName=<iSCSI-Name>.  

Which of these Appendix are correct? Can the Target send TargetName=<iSCSI-Name> keyword outside of a response to the "SendTarget" Command?  

.
.
.
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
--=_alternative 0008E05AC2256ADF_=-- From owner-ips@ece.cmu.edu Sun Oct 7 22:06: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 WAA28222 for ; Sun, 7 Oct 2001 22:06:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f981ViC13363 for ips-outgoing; Sun, 7 Oct 2001 21:31:44 -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 f981Vel13344 for ; Sun, 7 Oct 2001 21:31:40 -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 DAA97966 for ; Mon, 8 Oct 2001 03:31:19 +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 f981VJ0271654 for ; Mon, 8 Oct 2001 03:31:19 +0200 Subject: Re: iscsi : DataPDULength can differ in each direction. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 7 Oct 2001 12:05:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/10/2001 04:31:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dave, Implementation specific? I assume you wanted to say connection specific. No the parameters you quote (except MaxOutstandingR2T) are not connection specific. They reflect multiplexing capability that the transport allows for SCSI. Making them connection specific will only complicate things with no added benefit. MaxOutstandingR2T might be viewed as a way to compensate for RTT bu depend also on handling capabilities of the end-points. Julo Dave Sheehy cc: Sent by: Subject: Re: iscsi : DataPDULength can differ in owner-ips@ece.cmu.edu each direction. 05-10-01 22:44 Please respond to Dave Sheehy > Having now accepted that DataPDULength is a "maximum receive pdu length" > limitation that each end point is allowed to express, this key needs to > be on a per connection basis, and not a per session basis. > > The reason for this being that limitations on DataPDULength (more aptly, > max receive pdu length) stem from implementation specific quirks. (One > of the reasons for allowing this feature, in the first place.). Following this same line of reasoning the keys: MaxBurstSize FirstBurstSize MaxOutstandingR2T DataPDUInOrder DataSequenceInOrder ErrorRecoveryLevel are all potentially implementation specific and should not be categorized as LO. Dave From owner-ips@ece.cmu.edu Sun Oct 7 22:10: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 WAA28251 for ; Sun, 7 Oct 2001 22:10:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f981Viq13364 for ips-outgoing; Sun, 7 Oct 2001 21:31:44 -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 f981Vfl13350 for ; Sun, 7 Oct 2001 21:31:41 -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 DAA83912 for ; Mon, 8 Oct 2001 03:31:22 +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 f981VLX93036 for ; Mon, 8 Oct 2001 03:31:22 +0200 Subject: RE: iSCSI: ISID and the New Persistent Reservations Proposals To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 7 Oct 2001 12:30:07 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/10/2001 04:31:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, What puzzles me is that the you bring the negotiation argument as an argument is favor of text keys. I think that having a response of "conflict detected" is completely equivalent to option c (if I recall correctly the number). And handling keys that do not conflict trough the OS may prove trickier than handle 16 bit numbers. An Item that Jim suggested (more permanent initiator port numbers) may favor another structure based on the portal-group-tag and a session number within the tag with slow reuse. We may want then to have a different split between ISID and TSID (and/or include a similar split for TSID). Julo Black_David@em c.com To: hafner@almaden.ibm.com, ips@ece.cmu.edu Sent by: cc: owner-ips@ece. Subject: RE: iSCSI: ISID and the New Persistent cmu.edu Reservations Proposals 06-10-01 03:52 Please respond to Black_David Jim, > My strongest discomfort is this: in essence you are removing the SCSI > Initiator Port Name from the iSCSI implementation of the model. You're > hoping to fill that gap later with a text key whose semantics have yet to > be defined. Having the text key semantics be "yet to be defined" seems reasonable because the behavior required by T10 is in the same state. Horse first, then cart :-). > My expectation is that once you attempt to put the name back > in you're recreated the OptionA/OptionB debate and will never > be able to solve that satisfactorially. I disagree. ISIDs aren't negotiable, text keys are. In the text key situation analogous to the ISID situation that causes the OptionA/OptionB mess, the Target can set the text key to some sort of "Port Identity Conflict Detected" value and ship everything back to the Initiator with no harm done. Trying to do that sort of thing with ISIDs would be a mess, as indicated by the amount of email on OptionA/OptionB. > I'm concerned that removing the notion of SCSI Initiator Port Name > from the model today, you will have strongly hindered iSCSI's ability > to take advantage of a number of things that T10 > will be able to do, now that Names are part of the lexicon. And I have a strong discomfort with designing for functionality that isn't specified. We already have a mismatch where the current T10 proposal #1 does not match current ISID specification (see below on conservative reuse). As T10 does things with the Port Name, we can put in the text key(s) required to make them work. > I also believe as I've stated that the OS's are going to prefer to see > a more stable SCSI port view of the initiator's ports than we're currently > anticipating in iSCSI. As long as the TSID is not used to provide this view, there is no problem here (e.g., the enumeration of interface cards on boot can be used). > Finally, I think > - the reason to do this rather than the ISID is that it cleanly splits > persistent reservation management away from iSCSI session management. > is a major violation of layering. You're going to burden the reservation > management with having to coordinate iSCSI actions. I disagree. The interaction required is something that will have to happen anyway if T10 adopts any proposal that has reservations span sessions at the Target. Suppose that port X opens a session to port A, places a persistent reservation that spans target ports, and then opens a session to port B - as part of setting up that second session, port B has to interact with the persistent reservation logic to discover that the reservation exists and applies to the second session. This is all that's required, and it's true for any transport - in each cases the transport-specific port identification has to be passed from the transport to the SCSI reservation logic. The only wrinkle is that iSCSI gets this name from a text key instead of a WWN or a parallel SCSI bus ID - at the SCSI level, this shouldn't matter (the IDs are opaque and are being checked for equality). In other words, if there's a layering problem here, it's in SAM2 ... > [I've argued that conservative reuse of ISIDs to different target portal groups > provides a clean consistent view of SCSI Initiator Ports to the upper layers and > that's all that's needed.] But that requirement is NOT in the current draft, and inserting it would impact implementation approaches such as that originally described by Nick Martin in which an iSCSI implementation has to cons up an ISID in the potential absence of coordination with other implementations that share the same iSCSI Initiator Node Name. The nasty problems result when there are multiple Initiators connected to multiple Targets, but not all Initiators are connected to all Targets - an Initiator could set up several sessions and only then discover that the ISID it used is taken and have to tear down those sessions and start over. This is why ISIDs as currently specified aren't sufficient to deal with proposal #1 and changing them to do so would be a visible technical change. > None of those are strong technical arguments however. > > I think we agree that the problem comes up because the belief that > coordination of ISIDs on the initiator side is going to be difficult. I'm > not convinced that's the case, but let me try a different approach, which > may make the implementation easier. The summary is to have the OS enumeration provide the portal group tag, and make that part of the ISID either explicitly or via a text key that implicitly extends the ISID. It's a good try, but I think it runs into problems because device enumeration order in an operating system can change between reboots for all sorts of reasons ranging from the unavoidable (interface card fails in a fashion that causes it not to be discovered on boot - this is discovery by plug-and-play logic or the like, not iSCSI discovery) to the inane (stupid plug and play tricks, new driver revisions). This may wind up adding the Initiator Portal Group number to the list of things that an Initiator has to remember in order to get its persistent reservation state restored. --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 Oct 8 07:20: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 HAA17732 for ; Mon, 8 Oct 2001 07:20:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98AgvG19893 for ips-outgoing; Mon, 8 Oct 2001 06:42:57 -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 f98Agsl19889 for ; Mon, 8 Oct 2001 06:42:55 -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 BF504318; Mon, 8 Oct 2001 12:42:48 +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 LAA07600; Mon, 8 Oct 2001 11:42:48 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 11:41:22 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L8CSK89>; Mon, 8 Oct 2001 11:41:22 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C3B@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" , "'Julian_Satran@il.ibm.com'" Subject: Login PDU needs digests adding to it Date: Mon, 8 Oct 2001 11:42:44 +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 Julo, I think I have been here before but... Please can you add the header digest field to the Login PDU as digests can now be present in a Login PDU once the security phase has been completed. Cheers 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 Oct 8 07:23: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 HAA17770 for ; Mon, 8 Oct 2001 07:23:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98Avuo20591 for ips-outgoing; Mon, 8 Oct 2001 06:57:56 -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 f98Avrl20583 for ; Mon, 8 Oct 2001 06:57:53 -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 CF4B92CD; Mon, 8 Oct 2001 12:57:47 +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 LAA11548; Mon, 8 Oct 2001 11:57:47 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 11:57:46 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L80KVLL>; Mon, 8 Oct 2001 11:57:46 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C3D@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" , "'Julian_Satran@il.ibm.com'" Subject: Vendor specific data in Reject PDU. Date: Mon, 8 Oct 2001 11:57:45 +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 The SCSI Response PDU allows Vendor Specific data (3.4.6). Can this be extended to the Reject PDU after the "Complete Header of Bad PDU"?. This will help diagnosing errors. Cheers 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 Oct 8 07:24: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 HAA17800 for ; Mon, 8 Oct 2001 07:24:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98AjrP20007 for ips-outgoing; Mon, 8 Oct 2001 06:45:53 -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 f98Ajpl20002 for ; Mon, 8 Oct 2001 06:45:51 -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 1BE1B31F; Mon, 8 Oct 2001 12:45:49 +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 LAA08484; Mon, 8 Oct 2001 11:45:48 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 11:44:20 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L8CSL1K>; Mon, 8 Oct 2001 11:44:20 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C3C@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" , "'Julian_Satran@il.ibm.com'" Subject: Allow LogoutLoginMaxTime = 0 to 3600 Date: Mon, 8 Oct 2001 11:45:44 +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 Can the LogoutLoginMaxTime range be extended to include 0. If a target does not want the session to be maintained for session recovery (i.e. the session timer be zero) then this value needs to be negoiated to 0. 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 Oct 8 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 HAA17811 for ; Mon, 8 Oct 2001 07:24:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98Acig19697 for ips-outgoing; Mon, 8 Oct 2001 06:38:44 -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 f98Acel19692 for ; Mon, 8 Oct 2001 06:38:42 -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 3CF26312; Mon, 8 Oct 2001 12:38:37 +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 LAA06777; Mon, 8 Oct 2001 11:38:36 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 11:38:34 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L80K4KC>; Mon, 8 Oct 2001 11:38:34 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C39@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu, "'Julian_Satran@il.ibm.com'" Subject: Rewording of 3.19.1 Date: Mon, 8 Oct 2001 11:38:32 +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 Section 3.19.1 does not make sense. The functionality is correct but is just needs re-wording to: Whenever the NOP-In is sent as a "ping" to an initiator (not as a response to a NOP-Out) the StatSN field will contain as usual the next StatSN but StatSN for this connection is not advanced. Cheers 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 Oct 8 07:28: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 HAA17991 for ; Mon, 8 Oct 2001 07:28:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98AV9b19360 for ips-outgoing; Mon, 8 Oct 2001 06:31: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 f98AV5l19355 for ; Mon, 8 Oct 2001 06:31:06 -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 8F9F72FA; Mon, 8 Oct 2001 12:31: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 LAA04329; Mon, 8 Oct 2001 11:31:02 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 11:30:57 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L80KT0J>; Mon, 8 Oct 2001 11:30:57 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C38@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu, "'Julian_Satran@il.ibm.com'" Subject: Addition of CmdSN in Data-out PDU Date: Mon, 8 Oct 2001 11:30:56 +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 Please can the CmdSN be added to the Data-out PDU to improve implementations when receiving unsolicited Data-out PDUs: Currently, implementations have to search the command queue list for the associated command using the ITT as the search criteria. For solicited Data-out PDUs this is not an issue as they contain the Target Task Tag. However, for unsolicated Data PDUs (Target Task Tag = 0xFFFFFFFF) the locating of the associated command can be greatly enhanced by adding the Associated CmdSN to Data-out PDU. Cheers 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 Oct 8 08:18: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 IAA19494 for ; Mon, 8 Oct 2001 08:18:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98BO3021798 for ips-outgoing; Mon, 8 Oct 2001 07:24:03 -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 f98BO0l21789 for ; Mon, 8 Oct 2001 07:24:01 -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 D96D265 for ; Mon, 8 Oct 2001 13:23:58 +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 MAA17864 for ; Mon, 8 Oct 2001 12:23:58 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 12:22:32 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L8CSNFM>; Mon, 8 Oct 2001 12:22:32 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C45@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: iscsi: Vendor specific data in Reject PDU. Date: Mon, 8 Oct 2001 12:23: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 The SCSI Response PDU allows Vendor Specific data (3.4.6). Can this be extended to the Reject PDU after the "Complete Header of Bad PDU"?. This will help diagnosing errors. Cheers 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 Oct 8 08:21: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 IAA19575 for ; Mon, 8 Oct 2001 08:21:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98BMqO21694 for ips-outgoing; Mon, 8 Oct 2001 07:22: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 f98BMil21684 for ; Mon, 8 Oct 2001 07:22: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 E1801156 for ; Mon, 8 Oct 2001 13:22:41 +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 MAA17699 for ; Mon, 8 Oct 2001 12:22:41 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 12:21:15 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L8CSNDP>; Mon, 8 Oct 2001 12:21:15 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C41@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: iscsi: Addition of CmdSN in Data-out PDU Date: Mon, 8 Oct 2001 12:22: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 Please can the CmdSN be added to the Data-out PDU to improve implementations when receiving unsolicited Data-out PDUs: Currently, implementations have to search the command queue list for the associated command using the ITT as the search criteria. For solicited Data-out PDUs this is not an issue as they contain the Target Task Tag. However, for unsolicated Data PDUs (Target Task Tag = 0xFFFFFFFF) the locating of the associated command can be greatly enhanced by adding the Associated CmdSN to Data-out PDU. Cheers 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 Oct 8 08: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 IAA19586 for ; Mon, 8 Oct 2001 08:21:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98BM3i21638 for ips-outgoing; Mon, 8 Oct 2001 07:22:03 -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 f98BM0l21633 for ; Mon, 8 Oct 2001 07:22:01 -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 1BBB690 for ; Mon, 8 Oct 2001 13:21:58 +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 MAA17584 for ; Mon, 8 Oct 2001 12:21:57 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 12:21:57 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L80KWQ7>; Mon, 8 Oct 2001 12:21:57 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C40@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: Apologies: No " iscsi" label Date: Mon, 8 Oct 2001 12:21:56 +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 Sorry folks - I forgot. As some people may be using filters then I will resend. Please delete the old ones. Matthew From owner-ips@ece.cmu.edu Mon Oct 8 08:23: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 IAA19630 for ; Mon, 8 Oct 2001 08:23:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98BND221729 for ips-outgoing; Mon, 8 Oct 2001 07:23: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 f98BN7l21720 for ; Mon, 8 Oct 2001 07:23:11 -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 A608E15A for ; Mon, 8 Oct 2001 13:22:58 +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 MAA17739 for ; Mon, 8 Oct 2001 12:22:58 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 12:21:32 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L8CSND6>; Mon, 8 Oct 2001 12:21:32 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C42@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: iscsi: Rewording of 3.19.1 Date: Mon, 8 Oct 2001 12:22: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 Section 3.19.1 does not make sense. The functionality is correct but is just needs re-wording to: Whenever the NOP-In is sent as a "ping" to an initiator (not as a response to a NOP-Out) the StatSN field will contain as usual the next StatSN but StatSN for this connection is not advanced. Cheers 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 Oct 8 08:25: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 IAA19756 for ; Mon, 8 Oct 2001 08:25:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98BNjs21773 for ips-outgoing; Mon, 8 Oct 2001 07:23:45 -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 f98BNhl21766 for ; Mon, 8 Oct 2001 07:23:43 -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 1087B8A for ; Mon, 8 Oct 2001 13:23:41 +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 MAA17838 for ; Mon, 8 Oct 2001 12:23:40 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 12:23:40 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L80KWS5>; Mon, 8 Oct 2001 12:23:40 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C44@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: iscsi: Allow LogoutLoginMaxTime = 0 to 3600 Date: Mon, 8 Oct 2001 12:23: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 Can the LogoutLoginMaxTime range be extended to include 0. If a target does not want the session to be maintained for session recovery (i.e. the session timer be zero) then this value needs to be negoiated to 0. 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 Oct 8 08:29: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 IAA19863 for ; Mon, 8 Oct 2001 08:29:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98BNTe21745 for ips-outgoing; Mon, 8 Oct 2001 07:23:29 -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 f98BNLl21736 for ; Mon, 8 Oct 2001 07:23:22 -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 D872631C for ; Mon, 8 Oct 2001 13:23:19 +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 MAA17807 for ; Mon, 8 Oct 2001 12:23:19 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Mon, 08 Oct 2001 12:21:53 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L8CSN1K>; Mon, 8 Oct 2001 12:21:53 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C43@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" Subject: iscsi: Login PDU needs digests adding to it Date: Mon, 8 Oct 2001 12:23: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 Julo, I think I have been here before but... Please can you add the header digest field to the Login PDU as digests can now be present in a Login PDU once the security phase has been completed. Cheers 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 Oct 8 08:42: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 IAA20210 for ; Mon, 8 Oct 2001 08:42:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98BtgZ23332 for ips-outgoing; Mon, 8 Oct 2001 07:55: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 f98Btel23323 for ; Mon, 8 Oct 2001 07:55:40 -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 NAA288342 for ; Mon, 8 Oct 2001 13:55: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 f98BtWS169944 for ; Mon, 8 Oct 2001 13:55:32 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI:Login Phase and SessionType X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Mon, 8 Oct 2001 14:55:29 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/10/2001 14:55:31, Serialize complete at 08/10/2001 14:55:31 Content-Type: multipart/alternative; boundary="=_alternative 003BB786C2256ADF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003BB786C2256ADF_= Content-Type: text/plain; charset="us-ascii" Correct. The text will be: The initial Login request MUST include the InitiatorName key=value pair. The initial Login request MAY also include the SessionType key=value pair in which case if the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName. Thanks, Julo John Hufferd@IBMUS 08-10-01 00:30 To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: iSCSI:Login Phase and SessionType Julian, Section 5, Login Phase, contains the statement "The initial Login request MUST include the InitiatorName and SessionType key=value pairs." Since the SessionType key=value pair has a default of normal, perhaps the above quoted text is not correct. Perhaps the text should read, "The initial Login request MUST include the InitiatorName and MAY contain SessionType key=value pairs." . . . 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 --=_alternative 003BB786C2256ADF_= Content-Type: text/html; charset="us-ascii"
Correct. The text will be:

The initial Login request MUST include the InitiatorName key=value pair. The initial Login request MAY also include the SessionType key=value pair in which case if the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName.

Thanks,
Julo



John Hufferd@IBMUS

08-10-01 00:30

       
        To:        Julian Satran/Haifa/IBM@IBMIL@IBMDE
        cc:        ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        iSCSI:Login Phase and SessionType

       


Julian,
Section 5,  Login Phase, contains the statement

"The initial Login request MUST include the InitiatorName and SessionType key=value pairs."  

Since the SessionType key=value pair has a default of normal, perhaps the above quoted text is not correct.

Perhaps the text should read,

"The initial Login request MUST include the InitiatorName and MAY contain SessionType key=value pairs."

.
.
.
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

--=_alternative 003BB786C2256ADF_=-- From owner-ips@ece.cmu.edu Mon Oct 8 09:01: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 JAA20599 for ; Mon, 8 Oct 2001 09:01:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98CFrG24338 for ips-outgoing; Mon, 8 Oct 2001 08:15:53 -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 f98B7el20985 for ; Mon, 8 Oct 2001 07:07: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 HAA17459; Mon, 8 Oct 2001 07:07:36 -0400 (EDT) Message-Id: <200110081107.HAA17459@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-security-02.txt Date: Mon, 08 Oct 2001 07:07:36 -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 : Securing iSCSI, iFCP and FCIP Author(s) : B. Aboba et al. Filename : draft-ietf-ips-security-02.txt Pages : 49 Date : 05-Oct-01 This document discusses how iSCSI, iFCP, and FCIP may utilize IPsec to provide authentication, integrity, confidentiality and replay protection A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-02.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-security-02.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-security-02.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: <20011005150330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011005150330.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Mon Oct 8 09:02: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 JAA20622 for ; Mon, 8 Oct 2001 09:02:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98BtgN23331 for ips-outgoing; Mon, 8 Oct 2001 07:55: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 f98Btdl23322 for ; Mon, 8 Oct 2001 07:55: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 NAA288340 for ; Mon, 8 Oct 2001 13:55:31 +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 f98BtVS169942 for ; Mon, 8 Oct 2001 13:55:31 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iscsi : DataPDULength can differ in each direction. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Mon, 8 Oct 2001 14:55:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/10/2001 14:55:30, Serialize complete at 08/10/2001 14:55:30 Content-Type: multipart/alternative; boundary="=_alternative 003A2EF3C2256ADF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003A2EF3C2256ADF_= Content-Type: text/plain; charset="us-ascii" Rod, Actually you bring up a valid point. The length different in the two directions is perhaps the less important feature in the floated proposal. However it stressed (once again) that we need a more flexible PDUlength scheme: that should allow dynamic changes (some of the framing schemes proposed will require that) that can be different on different connections Having it different on the two directions is a slight side effect that can be beneficial and comes at zero price once you have done the former. And the I think that it can be done with minimal disruption (very little code and this only if you implement ErrorLevel 1 and 2). Julo "Rod Harrison" Sent by: owner-ips@ece.cmu.edu 07-10-01 22:22 Please respond to "Rod Harrison" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iscsi : DataPDULength can differ in each direction. Julian and all, Before you go ahead and spend time and energy on this I would just like to re-iterate my concerns that in practice few, if any, implementations will support asymmetric PDU sizes. If, for example, a software initiator indicates a max PDU size of 128k and a hardware target indicates 8k, do we really think the target will ever send a 128k PDU? I don't believe it will. The supporting argument seems to be predicated on the fact that the buffer management changes needed to make this happen are trivial. However, if an implementation can chain buffers together on transmit to build PDUs larger than the maximum size offered why can't it do so on receive? And if it can do so on receive why would it ever offer a maximum lower than the real maximum it can support? As an aside, I think this change might create something of a headache for sniffers since they now have to buffer the larger of the offered sizes instead of the smaller. I agree that asymmetric PDU sizes seem beneficial but I have a very hard time believing we'll see any implementations that can take advantage of this feature. I also think the benefit might be relatively small and is probably not worth the level of spec change at this late stage. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Saturday, October 06, 2001 8:04 PM To: ips@ece.cmu.edu Subject: RE: iscsi : DataPDULength can differ in each direction. As I said this requested change has value and we are going to do our best to incorporate it in 09. Fortunately PDUlength has few dependencies in the protocol. Unfortunately (as I said already) we would like PDUlength to a be a per connection parameter as it is it closely related to the Path MTU. This later assumption may require some changes in the recovery mechanism (the current recovery mechanism assumes that any PDU can be "replayed" as it was on every connection and this assumption won't hold anymore). Mallikarjun and myself will attempt to get a better understanding of the things required and will keep you updated. I think we have enough information to work on it and we will keep the list updated on what we think can be done and how. We have several alternatives and would appreciate some timeout on this thread. Julo --=_alternative 003A2EF3C2256ADF_= Content-Type: text/html; charset="us-ascii"
Rod,

Actually you bring up a valid point.  The length different in the two directions is perhaps the less important feature in the floated proposal.  However it stressed (once again) that we need a more flexible PDUlength scheme:
  • that should allow dynamic changes (some of the framing schemes proposed will require that)
  • that can be different on different connections


    Having it different on the two directions is a slight side effect that can be beneficial and comes at zero price once you have done the former.

    And the I think that it can be done with minimal disruption (very little code and this only if you implement ErrorLevel 1 and 2).

    Julo


    "Rod Harrison" <rod.harrison@windriver.com>
    Sent by: owner-ips@ece.cmu.edu

    07-10-01 22:22
    Please respond to "Rod Harrison"

    		       
            To:        Julian Satran/Haifa/IBM@IBMIL, <ips@ece.cmu.edu>
            cc:        
            Subject:        RE: iscsi : DataPDULength can differ in each direction.

           


    Julian and all,

       Before you go ahead and spend time and energy on this I would just
    like to re-iterate my concerns that in practice few, if any,
    implementations will support asymmetric PDU sizes.

                    If, for example, a software initiator indicates a max PDU size of
    128k and a hardware target indicates 8k, do we really think the target
    will ever send a 128k PDU? I don't believe it will. The supporting
    argument seems to be predicated on the fact that the buffer management
    changes needed to make this happen are trivial. However, if an
    implementation can chain buffers together on transmit to build PDUs
    larger than the maximum size offered why can't it do so on receive?
    And if it can do so on receive why would it ever offer a maximum lower
    than the real maximum it can support?

                    As an aside, I think this change might create something of a headache
    for sniffers since they now have to buffer the larger of the offered
    sizes instead of the smaller.

                    I agree that asymmetric PDU sizes seem beneficial but I have a very
    hard time believing we'll see any implementations that can take
    advantage of this feature. I also think the benefit might be
    relatively small and is probably not worth the level of spec change at
    this late stage.

                    - Rod


    -----Original Message-----
    From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
    Julian Satran
    Sent: Saturday, October 06, 2001 8:04 PM
    To: ips@ece.cmu.edu
    Subject: RE: iscsi : DataPDULength can differ in each direction.



    As I said this requested change has value and we are going to do our
    best to incorporate it in 09.

    Fortunately PDUlength has few dependencies in the protocol.

    Unfortunately (as I said already) we would like PDUlength to a be a
    per connection parameter as it is it closely related to the Path MTU.

    This later assumption may require some changes in the recovery
    mechanism (the current recovery mechanism assumes that any PDU can be
    "replayed" as it was on every connection and this assumption won't
    hold anymore).

    Mallikarjun and myself will attempt to get a better understanding of
    the things required and will keep you updated.

    I think we have enough information to work on it and we will keep the
    list updated on what we think can be done and how.

    We have several alternatives and would appreciate some timeout on this
    thread.

    Julo

--=_alternative 003A2EF3C2256ADF_=-- From owner-ips@ece.cmu.edu Mon Oct 8 12:49: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 MAA25875 for ; Mon, 8 Oct 2001 12:49:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98G8g410486 for ips-outgoing; Mon, 8 Oct 2001 12:08:42 -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 f98G8el10482 for ; Mon, 8 Oct 2001 12:08:40 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 636E2343; Mon, 8 Oct 2001 09:08: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 JAA23656; Mon, 8 Oct 2001 09:08:34 -0700 (PDT) Message-ID: <3BC1D134.63A7500@cup.hp.com> Date: Mon, 08 Oct 2001 09:15:48 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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 : X bit in SCSI Command PDU. 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, Can you please clarify in which scenarios the X bit is required in the SCSI Command PDU ? With the removal of command replay, a re-transmitted scsi command for the purpose of plugging a possible hole in the target's CmdSN sequence can be handled at the target without requiring to look at the X bit. I see no need to retain the X bit in the SCSI Command PDU. Further, the X bit could also be removed from all iscsi command pdu's other than the login pdu, wherein, the X bit has different semantics. The X bit is only meaningful and truly required in the login command pdu (where it is used to indicate a logout+re-login). In all other PDUs, it can be removed. Regards, Santosh Julian Satran wrote: > > Santosh, > > I am not sure you went through all scenarios. A conversation with your > colleague - Mallikarjun - and getting through the state table may go a > long way to clarify the need for X. > > And I am sure that by now you found yourself several . > > Julo > > Santosh Rao > To: IPS Reflector > Sent by: owner-ips@ece.cmu.edu > cc: > 06-10-01 01:56 Subject: iscsi : X > Please respond to Santosh Rao bit in SCSI Command PDU. > > > > All, > > With the elimination of command relay from iscsi [in the interests of > simplification ?], I believe that the X bit in the SCSI Command PDU > can > also be removed. As it exists today, the X bit is only being used for > command restart, which is at attempt by the initiator to plug a > potential hole in the CmdSN sequence at the target. It does this on > failing to get an ExpCmdSN ack for a previously sent command within > some > timeout period. > > Given the above usage of command restart, no X bit is required to be > set > in the SCSI Command PDU when command re-start is done. > > Either : > (a) the target had dropped the command earlier due to a digest error, > in > which case, the command restart plugs the CmdSN hole in the target. > > [OR] > > (b) the target had received the command and was working on it, when > the > initiator timed out too soon and attempted a command restart to plug > [what it thought was] a possible hole in the CmdSN sequence. > > In case (a), no X bit was required, since the target knows nothing of > the original command. In case (b), no X bit is required again, since > the > (ExpCmdSN, MaxCmdSN) window would have advanced and the target can > silently discard the received retry and continue working on the > original > command received. > > Removal of the X bit in the SCSI Command PDU has the following > benefits > : > > a) The CmdSN rules at the target are simplified. No need to look at X > bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) window. > > b) The reject reason code "command already in progress" can be > removed. > There's no need for this reject reason code anymore, since X bit > itself > is not required, and the targets can silently discard commands outside > the command window and continue to work on the original instance of > the > command already being processed at the target. > > c) Less work for the target and less resources consumed since it no > longer needs to generate a Reject PDU of type "command in progress". > It > can just silently discard any command PDU outside the (ExpCmdSN, > MaxCmdSN) window. > > d) Less code for the target, since it does not need : > - any Reject code paths when it receives X bit command PDUs that are > already in progress. > - No special casing of CmdSN checking rules. > - No overheads of verifying a received command based on its initiator > task tag, to check if the task is currently active, prior to sending a > Reject response with "command in progress". > > 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 > ################################## -- ################################## 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 Mon Oct 8 12:50: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 MAA25891 for ; Mon, 8 Oct 2001 12:50:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98G1oI09926 for ips-outgoing; Mon, 8 Oct 2001 12:01:50 -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 f98G1hl09915 for ; Mon, 8 Oct 2001 12:01:43 -0400 (EDT) Received: from russian.wrs.com (russian [147.11.45.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA18976 for ; Mon, 8 Oct 2001 09:01:28 -0700 (PDT) From: andy currid Received: (from andy@localhost) by russian.wrs.com (8.9.1/8.9.0) id JAA18956 for ips@ece.cmu.edu; Mon, 8 Oct 2001 09:01:36 -0700 (PDT) Message-Id: <200110081601.JAA18956@russian.wrs.com> Subject: iscsi: discovery session - logout To: ips@ece.cmu.edu Date: Mon, 8 Oct 2001 09:01:35 -0700 (PDT) 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 iSCSI version 8, sections 2.4 and and Appendix D.31, states that the only command accepted in full feature phase of a discovery session is a Text Request with the SendTargets key. Shouldn't a discovery session also accept a Logout command? Andy -- Andy Currid andy@windriver.com Server Products Group http://www.windriver.com Wind River Networks Phone : (1) 510 749 2191 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 From owner-ips@ece.cmu.edu Mon Oct 8 12: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 MAA26036 for ; Mon, 8 Oct 2001 12:56:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98FkSo08741 for ips-outgoing; Mon, 8 Oct 2001 11:46: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 f98FkPl08735 for ; Mon, 8 Oct 2001 11:46: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 LAA26978; Mon, 8 Oct 2001 11:43:59 -0400 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f98FkNi62334; Mon, 8 Oct 2001 09:46:23 -0600 Importance: Normal Subject: RE: iSCSI: ISID and the New Persistent Reservations Proposals To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 8 Oct 2001 08:46:22 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/08/2001 08:46:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, A few (hopefiully final) comments in line. Jim Hafner Black_David@emc.com on 10/05/2001 06:52:59 pm To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: RE: iSCSI: ISID and the New Persistent Reservations Proposals Jim, > My strongest discomfort is this: in essence you are removing the SCSI > Initiator Port Name from the iSCSI implementation of the model. You're > hoping to fill that gap later with a text key whose semantics have yet to > be defined. Having the text key semantics be "yet to be defined" seems reasonable because the behavior required by T10 is in the same state. Horse first, then cart :-). The behavior required by T10 is not "yet to be defined". What is missing is crossing a few t's and dotting a few i's to make the proposed new behavior more backward compatible with existing implementations. The general model is defined, though not yet approved (but I think you can expect something in the next 3 months). > My expectation is that once you attempt to put the name back > in you're recreated the OptionA/OptionB debate and will never > be able to solve that satisfactorially. I disagree. ISIDs aren't negotiable, text keys are. In the text key situation analogous to the ISID situation that causes the OptionA/OptionB mess, the Target can set the text key to some sort of "Port Identity Conflict Detected" value and ship everything back to the Initiator with no harm done. Trying to do that sort of thing with ISIDs would be a mess, as indicated by the amount of email on OptionA/OptionB. I don't get this? You're going to have the target "negotiate the value of this key"? We don't negotiate the value of the iSCSIName. This would fall under the same category (I would hope!). Saying "conflict" for key=value isn't any different from saying "conflict" for ISID. > I'm concerned that removing the notion of SCSI Initiator Port Name > from the model today, you will have strongly hindered iSCSI's ability > to take advantage of a number of things that T10 > will be able to do, now that Names are part of the lexicon. And I have a strong discomfort with designing for functionality that isn't specified. We already have a mismatch where the current T10 proposal #1 does not match current ISID specification (see below on conservative reuse). As T10 does things with the Port Name, we can put in the text key(s) required to make them work. I don't see a mismatch, further comment below. > I also believe as I've stated that the OS's are going to prefer to see > a more stable SCSI port view of the initiator's ports than we're currently > anticipating in iSCSI. As long as the TSID is not used to provide this view, there is no problem here (e.g., the enumeration of interface cards on boot can be used). Then I can use the enumeration for ISIDs as well, as I outlined. > Finally, I think > - the reason to do this rather than the ISID is that it cleanly splits > persistent reservation management away from iSCSI session management. > is a major violation of layering. You're going to burden the reservation > management with having to coordinate iSCSI actions. I disagree. The interaction required is something that will have to happen anyway if T10 adopts any proposal that has reservations span sessions at the Target. Suppose that port X opens a session to port A, places a persistent reservation that spans target ports, and then opens a session to port B - as part of setting up that second session, port B has to interact with the persistent reservation logic to discover that the reservation exists and applies to the second session. This is all that's required, and it's true for any transport - in each cases the transport-specific port identification has to be passed from the transport to the SCSI reservation logic. The only wrinkle is that iSCSI gets this name from a text key instead of a WWN or a parallel SCSI bus ID - at the SCSI level, this shouldn't matter (the IDs are opaque and are being checked for equality). In other words, if there's a layering problem here, it's in SAM2 ... The interaction I was talking about (which is what I thought you were addressing) was in the OS side (not the target). It was about having the application that is coordinating the reservation passing key stuff through the layers (within the initiator) to the iSCSI initiator layer to get this key over to the target. You had talked about the reservation application passing key=values down through the layers for iSCSI to use for SCSI Initiator port identification (or some such). That's the layering I was referring to. The target has always had to do some (minimal) cross port coordination. The newer proposals in T10 will require more (but no more in iSCSI than in any other protocol, except SPI where this proposal has no relevance). > [I've argued that conservative reuse of ISIDs to different target portal groups > provides a clean consistent view of SCSI Initiator Ports to the upper layers and > that's all that's needed.] But that requirement is NOT in the current draft, and inserting it would impact implementation approaches such as that originally described by Nick Martin in which an iSCSI implementation has to cons up an ISID in the potential absence of coordination with other implementations that share the same iSCSI Initiator Node Name. The nasty problems result when there are multiple Initiators connected to multiple Targets, but not all Initiators are connected to all Targets - an Initiator could set up several sessions and only then discover that the ISID it used is taken and have to tear down those sessions and start over. This is why ISIDs as currently specified aren't sufficient to deal with proposal #1 and changing them to do so would be a visible technical change. I disagree here. (a) The current spec says what the ISIDs are used for and how they ought to be generated (loosely). (b) It does not make conservative reuse a REQUIREMENT, but it does suggest reasons for that. (c) Conservative reuse is NOT a requirement anyway (and I've never said it is). It makes for some things being simpler. I'm confused by your use of the terms "multiple initiators" and "multiple targets". Are we talking with the same iSCSI Name or different names? This issue has nothing to do with three or more entities. It is strictly scoped between one iSCSI initiator (by name) and one iSCSI target (by name). > None of those are strong technical arguments however. > > I think we agree that the problem comes up because the belief that > coordination of ISIDs on the initiator side is going to be difficult. I'm > not convinced that's the case, but let me try a different approach, which > may make the implementation easier. The summary is to have the OS enumeration provide the portal group tag, and make that part of the ISID either explicitly or via a text key that implicitly extends the ISID. It's a good try, but I think it runs into problems because device enumeration order in an operating system can change between reboots for all sorts of reasons ranging from the unavoidable (interface card fails in a fashion that causes it not to be discovered on boot - this is discovery by plug-and-play logic or the like, not iSCSI discovery) to the inane (stupid plug and play tricks, new driver revisions). This may wind up adding the Initiator Portal Group number to the list of things that an Initiator has to remember in order to get its persistent reservation state restored. But this isn't a problem at all. So things move around. The only affect this would have is on a persistent reservation of type #1 and in that case, perhaps enough resets and reboots have occured to have clean up and cluster recovery so that the problem isn't there. --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 Oct 8 13:35: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 NAA27338 for ; Mon, 8 Oct 2001 13:35:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98GYLW12461 for ips-outgoing; Mon, 8 Oct 2001 12:34:21 -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 f98GYIl12451 for ; Mon, 8 Oct 2001 12:34:19 -0400 (EDT) Received: from russian.wrs.com (russian [147.11.45.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA09351 for ; Mon, 8 Oct 2001 09:34:00 -0700 (PDT) From: andy currid Received: (from andy@localhost) by russian.wrs.com (8.9.1/8.9.0) id JAA19054 for ips@ece.cmu.edu; Mon, 8 Oct 2001 09:34:07 -0700 (PDT) Message-Id: <200110081634.JAA19054@russian.wrs.com> Subject: iscsi - InitiatorName key during login To: ips@ece.cmu.edu Date: Mon, 8 Oct 2001 09:34:07 -0700 (PDT) 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 iSCSI version 8 is unclear as to whether InitiatorName is required in the first login PDU of every login in a session, or just the leading login. Chapter 5, Login Phase, states - "The login phase sequence of commands and responses proceeds as follows: - login initial request - login partial response (optional) - more login requests and responses (optional) - login final-response (mandatory) The initial login request MUST include the InitiatorName and SessionType key=value pairs." Taken in the context, this wording implies that for any login, the first login PDU must contain the InitiatorName key. Appendix D.13, InitiatorName, states that InitiatorName is Leading Only and that "this key MUST be provided by the initiator of the TCP connection to the remote endpoint before the end of the login phase". This wording implies that InitiatorName is supplied in the leading login only, and need not necessrily appear in the first login PDU of the leading login. So which is correct? It seems to me that requiring that InitiatorName be present in the first PDU of the leading login is a must, to allow targets to verify up front whether or not they wish to proceed further with this initiator. I don't think there's much incremental benefit to having InitiatorName appear in the first login PDU of every login. Andy -- Andy Currid andy@windriver.com Server Products Group http://www.windriver.com Wind River Networks Phone : (1) 510 749 2191 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 From owner-ips@ece.cmu.edu Mon Oct 8 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 NAA27403 for ; Mon, 8 Oct 2001 13:38:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98GZBY12512 for ips-outgoing; Mon, 8 Oct 2001 12:35: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 f98GZ9l12506 for ; Mon, 8 Oct 2001 12:35: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 EAFAE485 for ; Mon, 8 Oct 2001 09:35:08 -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 JAA24992 for ; Mon, 8 Oct 2001 09:35:03 -0700 (PDT) Message-ID: <3BC1D769.99652917@cup.hp.com> Date: Mon, 08 Oct 2001 09:42:17 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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 - revised 2.2.4 References: <8C59010722BBD31194640050DA6EC6971B98A7@ZOETERMEER> 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 apologize upfront for being so persistent on this. However, it would really help if you could give some clear example of a scenario as to why the initiator cannot be considered the originator of a negotiation, when it offers a key value implicitly, through the use of a default. Several people on this list (Paul Konning, Sanjeev, Deva, myself, and perhaps others, that I cannot recall at the moment) have asked that the spec must not differentiate login behaviour when the initiator offers a key explicitly vs. when it offers a key implicitly thru the use of the default. Please help us understand the need for iscsi to distingush the login behaviour in the above case. [through some tangible scenarios and examples]. Thanks, Santosh > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > Julian, > > I would also request an explicit definition of offering party and > responding party. The current text still leaves ambiguity when target > sends a key in response to implicit default key of the Intiator. In > this case who is the offering party and who is the responding party > > Sanjeev > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, October 05, 2001 2:06 PM > To: ips@ece.cmu.edu > Subject: iSCSI - revised 2.2.4 > > Here is a revised (complete) part 2.2.4 based on recent > agreed changes: > > 1.1.1 Text Mode Negotiation > > During login and thereafter some session or connection > parameters are negotiated through an exchange of textual > information. > > All negotiations are stateless - i.e. the result MUST be > based only on newly exchanged values. > > The general format of text negotiation is: > > Originator-> = > Responder-> =|reject|NotUnderstood > > The value can be a number, a single literal constant a > Boolean value (yes or no) or a list of comma separated > literal constant values. > > In literal list negotiation, the originator sends for each > key a list of options (literal constants which may include > "none") in its order of preference. > > The responding party answers with the first value from the > list it supports and is allowed to use for the specific > originator. > > The constant "none" MUST always be used to indicate a > missing function. However, none is a valid selection only if > it is explicitly offered. > > If a target is not supporting, or not allowed to use with a > specific originator, any of the offered options, it may use > the constant "reject". The constants "none" and "reject" > are reserved and must be used only as described here. Any > key not understood is answered with "NotUnderstood". > > For numerical and single literal negotiations, the > responding party MUST respond with the required key and the > value it selects, based on the selection rule specific to > the key, becomes the negotiation result. Selection of a > value not admissible under the selection rules is considered > a protocol error and handled accordingly. > > For Boolean negotiations (keys taking the values yes or no), > the responding party MUST respond with the required key and > the result of the negotiation when the received value does > not determine that result by itself. The last value > transmitted becomes the negotiation result. The rules for > selecting the value to respond with are expressed as Boolean > functions of the value received and the value that the > responding party would select in the absence of knowledge of > the received value. > > Specifically, the two cases in which responses are OPTIONAL > are: > > - The Boolean function is "AND" and the value "no" is > received. The outcome of the negotiation is "no". > - The Boolean function is "OR" and the value "yes" is > received. The outcome of the negotiation is "yes". > > Responses are REQUIRED in all other cases, and the value > chosen and sent by the responder becomes the outcome of the > negotiation. > > The value "?" with any key has the meaning of enquiry and > should be answered with the current value or > "NotUnderstood". > > 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, only the initiator can > initiate the negotiation start (through the first Text > request) and completion (by setting to 1 and keeping to 1 > the F bit in a Text request). > > Comments ? > > 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 Mon Oct 8 14:59: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 OAA28925 for ; Mon, 8 Oct 2001 14:59:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98IFCH20023 for ips-outgoing; Mon, 8 Oct 2001 14:15:12 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f98IFAl20019 for ; Mon, 8 Oct 2001 14:15:10 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 921638D3 for ; Mon, 8 Oct 2001 12:15:09 -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 D56DCD9 for ; Mon, 8 Oct 2001 12:15:08 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id LAA13198 for ips@ece.cmu.edu; Mon, 8 Oct 2001 11:14:08 -0700 (PDT) From: Dave Sheehy Message-Id: <200110081814.LAA13198@acropora.rose.agilent.com> Subject: Re: iscsi : DataPDULength can differ in each direction. To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Mon, 08 Oct 2001 11:14:07 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, > Implementation specific? I assume you wanted to say connection specific. No, I said what I meant and I meant what I said. :-) I can easily envision implementation restrictions (bounds if you will) with regard to any of the parameters I listed. I think you are being far too optimistic that implementors will enable all that the spec allows. In particular: > Following this same line of reasoning the keys: > > MaxBurstSize > FirstBurstSize An implementation can easily be limited by the size of burst it can handle due to buffering capacity or other data structure limitations of the HW. > MaxOutstandingR2T This requires resources in the HW implementation to track the outstanding requests. Implementations will vary in the capacity of tracking said requests. > DataPDUInOrder > DataSequenceInOrder Some HW implementations will limited in their capability to handle out of order data. Current Fibre Channel implementations illustrate this type of constraint well. > ErrorRecoveryLevel Implementations may limit the types of error recovery available. I can envision different implementation choices being made in the ability to restart IOs. I also think it may be problematic moving and restarting an IO between implementations. > No the parameters you quote (except MaxOutstandingR2T) are not connection > specific. > They reflect multiplexing capability that the transport allows for SCSI. > Making them connection specific will > only complicate things with no added benefit. In which case you add the complication that the iSCSI layer will have to query (or know apriori) the capabilities of all its interfaces prior to opening any leading connections. That way it won't negotiate beyond the capabilities of any of its individual interfaces. Dave From owner-ips@ece.cmu.edu Mon Oct 8 15:02: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 PAA28983 for ; Mon, 8 Oct 2001 15:02:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98IRw421137 for ips-outgoing; Mon, 8 Oct 2001 14:27:58 -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 f98IRul21131 for ; Mon, 8 Oct 2001 14:27:57 -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 34F5F209A for ; Mon, 8 Oct 2001 12:27:56 -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 A0C002D2 for ; Mon, 8 Oct 2001 12:27:55 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id LAA13212 for ips@ece.cmu.edu; Mon, 8 Oct 2001 11:26:55 -0700 (PDT) From: Dave Sheehy Message-Id: <200110081826.LAA13212@acropora.rose.agilent.com> Subject: RE: iscsi : DataPDULength can differ in each direction. To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Mon, 08 Oct 2001 11:26:54 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > Before you go ahead and spend time and energy on this I would just > like to re-iterate my concerns that in practice few, if any, > implementations will support asymmetric PDU sizes. > > If, for example, a software initiator indicates a max PDU size of > 128k and a hardware target indicates 8k, do we really think the target > will ever send a 128k PDU? You can count on it. Fibre Channel works that way today and if allowed iSCSI will as well. > I don't believe it will. The supporting > argument seems to be predicated on the fact that the buffer management > changes needed to make this happen are trivial. However, if an > implementation can chain buffers together on transmit to build PDUs > larger than the maximum size offered why can't it do so on receive? > And if it can do so on receive why would it ever offer a maximum lower > than the real maximum it can support? Because the receive is doing direct placement and the transmit side is not. Efficient direct placement works best with small PDUs. The transmit side could care less. > As an aside, I think this change might create something of a headache > for sniffers since they now have to buffer the larger of the offered > sizes instead of the smaller. I haven't heard the Fibre Channel analyzer folks complain about assymetric frame sizes. > I agree that asymmetric PDU sizes seem beneficial but I have a very > hard time believing we'll see any implementations that can take > advantage of this feature. I also think the benefit might be > relatively small and is probably not worth the level of spec change at > this late stage. On the contrary, I think this is a big win for the SW implementations. Header parsing accounts for a good deal of the receive side processing. If that can be reduced it will free up CPU bandwidth on the SW side. Dave From owner-ips@ece.cmu.edu Mon Oct 8 15:02: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 PAA28999 for ; Mon, 8 Oct 2001 15:02:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98HvdH18654 for ips-outgoing; Mon, 8 Oct 2001 13:57:39 -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 f98Hvbl18648 for ; Mon, 8 Oct 2001 13:57:37 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id D824B1F617 for ; Mon, 8 Oct 2001 13:57:31 -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 BD0A31F504 for ; Mon, 8 Oct 2001 13:57:31 -0400 (EDT) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2653.19) id <4LYDPGAJ>; Mon, 8 Oct 2001 13:57:31 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF19C@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iscsi - InitiatorName key during login Date: Mon, 8 Oct 2001 13:57:28 -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 would think InitiatorName is required on the first login PDU of every connection - InitiatorName is required for target authentication of the initiator, and that happens each time a connection joins the session. To behave otherwise seems an opportunity for identity spoofing? In any case, this needs to be clarified in the next revision... 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: andy currid [mailto:andy@windriver.com] > Sent: Monday, October 08, 2001 9:34 AM > To: ips@ece.cmu.edu > Subject: iscsi - InitiatorName key during login > > > > iSCSI version 8 is unclear as to whether InitiatorName is required > in the first login PDU of every login in a session, or just the > leading login. > > Chapter 5, Login Phase, states - > > "The login phase sequence of commands and responses proceeds > as follows: > > - login initial request > - login partial response (optional) > - more login requests and responses (optional) > - login final-response (mandatory) > > The initial login request MUST include the InitiatorName and > SessionType key=value pairs." > > Taken in the context, this wording implies that for any login, the > first login PDU must contain the InitiatorName key. > > Appendix D.13, InitiatorName, states that InitiatorName is Leading > Only and that "this key MUST be provided by the initiator of the TCP > connection to the remote endpoint before the end of the login phase". > > This wording implies that InitiatorName is supplied in the leading > login only, and need not necessrily appear in the first login PDU > of the leading login. > > So which is correct? > > It seems to me that requiring that InitiatorName be present in the > first PDU of the leading login is a must, to allow targets to verify > up front whether or not they wish to proceed further with this > initiator. I don't think there's much incremental benefit to having > InitiatorName appear in the first login PDU of every login. > > Andy > -- > Andy Currid andy@windriver.com > Server Products Group http://www.windriver.com > Wind River Networks Phone : (1) 510 749 2191 > 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 > From owner-ips@ece.cmu.edu Mon Oct 8 15:59: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 PAA00041 for ; Mon, 8 Oct 2001 15:59:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98IvHp23518 for ips-outgoing; Mon, 8 Oct 2001 14:57: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 f98IvDl23503 for ; Mon, 8 Oct 2001 14:57:13 -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 UAA23056 for ; Mon, 8 Oct 2001 20:57: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 f98Iv5S148208 for ; Mon, 8 Oct 2001 20:57:05 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi : DataPDULength can differ in each direction. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Mon, 8 Oct 2001 21:57:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/10/2001 21:57:04, Serialize complete at 08/10/2001 21:57:04 Content-Type: multipart/alternative; boundary="=_alternative 0068256CC2256ADF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0068256CC2256ADF_= Content-Type: text/plain; charset="us-ascii" Dave, Implementation is not a session parameter :-) What do you mean by an implementation specific parameter? Is it that every connection has a different implementation and they cooperate? Or do not cooperate? Julo Dave Sheehy Sent by: owner-ips@ece.cmu.edu 08-10-01 20:14 Please respond to Dave Sheehy To: ips@ece.cmu.edu (IETF IP SAN Reflector) cc: Subject: Re: iscsi : DataPDULength can differ in each direction. Julian, > Implementation specific? I assume you wanted to say connection specific. No, I said what I meant and I meant what I said. :-) I can easily envision implementation restrictions (bounds if you will) with regard to any of the parameters I listed. I think you are being far too optimistic that implementors will enable all that the spec allows. In particular: > Following this same line of reasoning the keys: > > MaxBurstSize > FirstBurstSize An implementation can easily be limited by the size of burst it can handle due to buffering capacity or other data structure limitations of the HW. > MaxOutstandingR2T This requires resources in the HW implementation to track the outstanding requests. Implementations will vary in the capacity of tracking said requests. > DataPDUInOrder > DataSequenceInOrder Some HW implementations will limited in their capability to handle out of order data. Current Fibre Channel implementations illustrate this type of constraint well. > ErrorRecoveryLevel Implementations may limit the types of error recovery available. I can envision different implementation choices being made in the ability to restart IOs. I also think it may be problematic moving and restarting an IO between implementations. > No the parameters you quote (except MaxOutstandingR2T) are not connection > specific. > They reflect multiplexing capability that the transport allows for SCSI. > Making them connection specific will > only complicate things with no added benefit. In which case you add the complication that the iSCSI layer will have to query (or know apriori) the capabilities of all its interfaces prior to opening any leading connections. That way it won't negotiate beyond the capabilities of any of its individual interfaces. Dave --=_alternative 0068256CC2256ADF_= Content-Type: text/html; charset="us-ascii"
Dave,

Implementation is not a session parameter :-)
What do you mean by an implementation specific parameter?  Is it that every connection has a different implementation and they cooperate? Or do not cooperate?

Julo


Dave Sheehy <dbs@acropora.rose.agilent.com>
Sent by: owner-ips@ece.cmu.edu

08-10-01 20:14
Please respond to Dave Sheehy

       
        To:        ips@ece.cmu.edu (IETF IP SAN Reflector)
        cc:        
        Subject:        Re: iscsi : DataPDULength can differ in each direction.

       


Julian,

> Implementation specific? I assume you wanted to say connection specific.

No, I said what I meant and I meant what I said. :-)

I can easily envision implementation restrictions (bounds if you will) with
regard to any of the parameters I listed. I think you are being far too
optimistic that implementors will enable all that the spec allows.

In particular:

> Following this same line of reasoning the keys:
>
>            MaxBurstSize
>            FirstBurstSize

An implementation can easily be limited by the size of burst it can handle
due to buffering capacity or other data structure limitations of the HW.

>            MaxOutstandingR2T

This requires resources in the HW implementation to track the outstanding
requests. Implementations will vary in the capacity of tracking said requests.

>            DataPDUInOrder
>            DataSequenceInOrder

Some HW implementations will limited in their capability to handle out of
order data. Current Fibre Channel implementations illustrate this type of
constraint well.

>            ErrorRecoveryLevel

Implementations may limit the types of error recovery available. I can
envision different implementation choices being made in the ability to
restart IOs. I also think it may be problematic moving and restarting an
IO between implementations.

> No the parameters you quote (except MaxOutstandingR2T) are not connection
> specific.
> They reflect multiplexing capability that the transport allows for SCSI.
> Making them connection specific will
> only complicate things with no added benefit.

In which case you add the complication that the iSCSI layer will have to
query (or know apriori) the capabilities of all its interfaces prior to
opening any leading connections. That way it won't negotiate beyond the
capabilities of any of its individual interfaces.

Dave

--=_alternative 0068256CC2256ADF_=-- From owner-ips@ece.cmu.edu Mon Oct 8 16:50: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 QAA01637 for ; Mon, 8 Oct 2001 16:50:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98Jav826740 for ips-outgoing; Mon, 8 Oct 2001 15:36:57 -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 f98Jatl26734 for ; Mon, 8 Oct 2001 15:36:55 -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 f98JahT18027; Mon, 8 Oct 2001 15:36:47 -0400 (EDT) From: "Eddy Quicksall" To: , Subject: iSCSI: text negotiation information Date: Mon, 8 Oct 2001 15:36:10 -0400 Message-ID: <000f01c15030$7e3b6ac0$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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section 2.4.2 says: Target requests are not limited to matching key=value pairs as offered by the initiator. Exactly what does "matching key=value pairs" mean? It probably means matching keys not matching keys and values both. I assume this sentence means the target can request keys that were not offered by the initiator. If so, can we change the text to make that more clear (or make more clear what it really means). It further says: However, only the initiator can initiate the negotiation start (through the first Text request) and completion (by setting to 1 and keeping to 1 the F bit in a Text request). I wonder if this sentence is really needed (because this fact is already given in other paragraphs). If not, can we remove them? Its placement can make one think that a target can't be an originator. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Mon Oct 8 17: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 RAA02804 for ; Mon, 8 Oct 2001 17:32:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98Kbio01855 for ips-outgoing; Mon, 8 Oct 2001 16:37:44 -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 f98KbVl01819 for ; Mon, 8 Oct 2001 16:37:31 -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 QAA11652; Mon, 8 Oct 2001 16:35:05 -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 f98KbT231812; Mon, 8 Oct 2001 14:37:29 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iscsi - InitiatorName key during login To: "Julian Satran" , "KRUEGER,MARJORIE (HP-Roseville,ex1)" , andy@windriver.com] Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 8 Oct 2001 13:36:41 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/08/2001 02:37:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Marjorie is correct. Without the Initiator Name on all Logins a Secondary Connection can spoof its way in. The appendix needs to be corrected. . . . 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 "KRUEGER,MARJORIE (HP-Roseville,ex1)" @ece.cmu.edu on 10/08/2001 10:57:28 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iscsi - InitiatorName key during login I would think InitiatorName is required on the first login PDU of every connection - InitiatorName is required for target authentication of the initiator, and that happens each time a connection joins the session. To behave otherwise seems an opportunity for identity spoofing? In any case, this needs to be clarified in the next revision... 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: andy currid [mailto:andy@windriver.com] > Sent: Monday, October 08, 2001 9:34 AM > To: ips@ece.cmu.edu > Subject: iscsi - InitiatorName key during login > > > > iSCSI version 8 is unclear as to whether InitiatorName is required > in the first login PDU of every login in a session, or just the > leading login. > > Chapter 5, Login Phase, states - > > "The login phase sequence of commands and responses proceeds > as follows: > > - login initial request > - login partial response (optional) > - more login requests and responses (optional) > - login final-response (mandatory) > > The initial login request MUST include the InitiatorName and > SessionType key=value pairs." > > Taken in the context, this wording implies that for any login, the > first login PDU must contain the InitiatorName key. > > Appendix D.13, InitiatorName, states that InitiatorName is Leading > Only and that "this key MUST be provided by the initiator of the TCP > connection to the remote endpoint before the end of the login phase". > > This wording implies that InitiatorName is supplied in the leading > login only, and need not necessrily appear in the first login PDU > of the leading login. > > So which is correct? > > It seems to me that requiring that InitiatorName be present in the > first PDU of the leading login is a must, to allow targets to verify > up front whether or not they wish to proceed further with this > initiator. I don't think there's much incremental benefit to having > InitiatorName appear in the first login PDU of every login. > > Andy > -- > Andy Currid andy@windriver.com > Server Products Group http://www.windriver.com > Wind River Networks Phone : (1) 510 749 2191 > 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 > From owner-ips@ece.cmu.edu Mon Oct 8 17:33: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 RAA02816 for ; Mon, 8 Oct 2001 17:33:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98L9nX04248 for ips-outgoing; Mon, 8 Oct 2001 17:09: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 f98L9jl04240 for ; Mon, 8 Oct 2001 17:09:45 -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 XAA76986 for ; Mon, 8 Oct 2001 23:09: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 f98L9cS31674 for ; Mon, 8 Oct 2001 23:09:38 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iscsi - InitiatorName key during login X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Oct 2001 00:09:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 00:09:38, Serialize complete at 09/10/2001 00:09:38 Content-Type: multipart/alternative; boundary="=_alternative 00744801C2256ADF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00744801C2256ADF_= Content-Type: text/plain; charset="us-ascii" You are the naming team so you must be right! The current authentication schemes do not make specific use of the InitiatorName but some authentication has to be used. What makes InitiaatorName needed that you did consider earlier? Julo John Hufferd@IBMUS 08-10-01 22:36 To: Julian Satran/Haifa/IBM@IBMIL@IBMDE, "KRUEGER,MARJORIE (HP-Roseville,ex1)" , andy@windriver.com] cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: RE: iscsi - InitiatorName key during login Marjorie is correct. Without the Initiator Name on all Logins a Secondary Connection can spoof its way in. The appendix needs to be corrected. . . . 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 Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iscsi - InitiatorName key during login I would think InitiatorName is required on the first login PDU of every connection - InitiatorName is required for target authentication of the initiator, and that happens each time a connection joins the session. To behave otherwise seems an opportunity for identity spoofing? In any case, this needs to be clarified in the next revision... 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: andy currid [mailto:andy@windriver.com] > Sent: Monday, October 08, 2001 9:34 AM > To: ips@ece.cmu.edu > Subject: iscsi - InitiatorName key during login > > > > iSCSI version 8 is unclear as to whether InitiatorName is required > in the first login PDU of every login in a session, or just the > leading login. > > Chapter 5, Login Phase, states - > > "The login phase sequence of commands and responses proceeds > as follows: > > - login initial request > - login partial response (optional) > - more login requests and responses (optional) > - login final-response (mandatory) > > The initial login request MUST include the InitiatorName and > SessionType key=value pairs." > > Taken in the context, this wording implies that for any login, the > first login PDU must contain the InitiatorName key. > > Appendix D.13, InitiatorName, states that InitiatorName is Leading > Only and that "this key MUST be provided by the initiator of the TCP > connection to the remote endpoint before the end of the login phase". > > This wording implies that InitiatorName is supplied in the leading > login only, and need not necessrily appear in the first login PDU > of the leading login. > > So which is correct? > > It seems to me that requiring that InitiatorName be present in the > first PDU of the leading login is a must, to allow targets to verify > up front whether or not they wish to proceed further with this > initiator. I don't think there's much incremental benefit to having > InitiatorName appear in the first login PDU of every login. > > Andy > -- > Andy Currid andy@windriver.com > Server Products Group http://www.windriver.com > Wind River Networks Phone : (1) 510 749 2191 > 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 > --=_alternative 00744801C2256ADF_= Content-Type: text/html; charset="us-ascii"
You are the naming team so you must be right!  The current authentication schemes do not make specific use of the InitiatorName but some authentication has to be used. What makes InitiaatorName needed that you did consider earlier?

Julo


John Hufferd@IBMUS

08-10-01 22:36


        To:        Julian Satran/Haifa/IBM@IBMIL@IBMDE, "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>, andy@windriver.com]
        cc:        ips@ece.cmu.edu
        From:        John Hufferd/San Jose/IBM@IBMUS
        Subject:        RE: iscsi - InitiatorName key during loginLink
 





Marjorie is correct.  Without the Initiator Name on all Logins  a Secondary Connection can spoof its way in.  The appendix needs to be corrected.

.
.
.
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

Sent by:        owner-ips@ece.cmu.edu

To:        ips@ece.cmu.edu
cc:        
Subject:        RE: iscsi - InitiatorName key during login



I would think InitiatorName is required on the first login PDU of every
connection - InitiatorName is required for target authentication of the
initiator, and that happens each time a connection joins the session.  To
behave otherwise seems an opportunity for identity spoofing?
In any case, this needs to be clarified in the next revision...
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: andy currid [mailto:andy@windriver.com]
> Sent: Monday, October 08, 2001 9:34 AM
> To: ips@ece.cmu.edu
> Subject: iscsi - InitiatorName key during login
>
>
>
> iSCSI version 8 is unclear as to whether InitiatorName is required
> in the first login PDU of every login in a session, or just the
> leading login.
>
> Chapter 5, Login Phase, states -
>
>  "The login phase sequence of commands and responses proceeds
> as follows:
>
>    - login initial request
>    - login partial response (optional)
>    - more login requests and responses (optional)
>    - login final-response (mandatory)
>
>   The initial login request MUST include the InitiatorName and
>   SessionType key=value pairs."
>
> Taken in the context, this wording implies that for any login, the
> first login PDU must contain the InitiatorName key.
>
> Appendix D.13, InitiatorName, states that InitiatorName is Leading
> Only and that "this key MUST be provided by the initiator of the TCP
> connection to the remote endpoint before the end of the login phase".
>
> This wording implies that InitiatorName is supplied in the leading
> login only, and need not necessrily appear in the first login PDU
> of the leading login.
>
> So which is correct?
>
> It seems to me that requiring that InitiatorName be present in the
> first PDU of the leading login is a must, to allow targets to verify
> up front whether or not they wish to proceed further with this
> initiator. I don't think there's much incremental benefit to having
> InitiatorName appear in the first login PDU of every login.
>
> Andy
> --
> Andy Currid                                       andy@windriver.com
> Server Products Group                       http://www.windriver.com
> Wind River Networks                         Phone : (1) 510 749 2191
> 500 Wind River Way, Alameda, CA 94501       Fax   : (1) 510 749 2560
>



--=_alternative 00744801C2256ADF_=-- From owner-ips@ece.cmu.edu Mon Oct 8 17:37: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 RAA02849 for ; Mon, 8 Oct 2001 17:37:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98Kwf103389 for ips-outgoing; Mon, 8 Oct 2001 16:58:41 -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 f98Kwdl03384 for ; Mon, 8 Oct 2001 16:58: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 WAA198526 for ; Mon, 8 Oct 2001 22:58: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 f98KwVS177892 for ; Mon, 8 Oct 2001 22:58:32 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi : DataPDULength can differ in each direction. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Mon, 8 Oct 2001 23:58:30 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 08/10/2001 23:58:31, Serialize complete at 08/10/2001 23:58:31 Content-Type: multipart/alternative; boundary="=_alternative 007343E2C2256ADF_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 007343E2C2256ADF_= Content-Type: text/plain; charset="us-ascii" If they cooperate they have to share goals. The parameters you quoted don't make sense per connection. PDUlength makes a lot of sense. Julo Dave Sheehy Sent by: owner-ips@ece.cmu.edu 08-10-01 22:43 Please respond to Dave Sheehy To: ips@ece.cmu.edu (IETF IP SAN Reflector) cc: Subject: Re: iscsi : DataPDULength can differ in each direction. Julian, > Implementation is not a session parameter :-) The implementation directly affects the values that a session acquire though. :-) > What do you mean by an implementation specific parameter? Is it that > every connection has a different implementation and they cooperate? That is the scenario I'm addressing. There has been discussion of late which has indicated that initiators may have several different vendors products (i.e. implementations) installed at once and that it is expected that a session may span those multiple implementations. Each of those implementations will have its own constraints and limitations. So, you either have to adopt the greatest common denominator approach (i.e. limit connections to the intersection of all individual feature sets) or you allow each connection to conform to the implementation that it resides on. Dave --=_alternative 007343E2C2256ADF_= Content-Type: text/html; charset="us-ascii"
If they cooperate they have to share goals. The parameters you quoted don't make sense per connection.
PDUlength makes a lot of sense.

Julo


Dave Sheehy <dbs@acropora.rose.agilent.com>
Sent by: owner-ips@ece.cmu.edu

08-10-01 22:43
Please respond to Dave Sheehy

       
        To:        ips@ece.cmu.edu (IETF IP SAN Reflector)
        cc:        
        Subject:        Re: iscsi : DataPDULength can differ in each direction.

       


Julian,

> Implementation is not a session parameter :-)

The implementation directly affects the values that a session acquire
though. :-)

> What do you mean by an implementation specific parameter?  Is it that
> every connection has a different implementation and they cooperate?

That is the scenario I'm addressing. There has been discussion of late
which has indicated that initiators may have several different vendors
products (i.e. implementations) installed at once and that it is expected
that a session may span those multiple implementations. Each of those
implementations will have its own constraints and limitations. So, you
either have to adopt the greatest common denominator approach (i.e. limit
connections to the intersection of all individual feature sets) or you allow
each connection to conform to the implementation that it resides on.

Dave

--=_alternative 007343E2C2256ADF_=-- From owner-ips@ece.cmu.edu Mon Oct 8 17:41: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 RAA02895 for ; Mon, 8 Oct 2001 17:41:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98KiQw02365 for ips-outgoing; Mon, 8 Oct 2001 16:44:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f98KiPl02360 for ; Mon, 8 Oct 2001 16:44:25 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 298F16ED for ; Mon, 8 Oct 2001 14:44:24 -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 C6DC98D5 for ; Mon, 8 Oct 2001 14:44:23 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id NAA13372 for ips@ece.cmu.edu; Mon, 8 Oct 2001 13:43:23 -0700 (PDT) From: Dave Sheehy Message-Id: <200110082043.NAA13372@acropora.rose.agilent.com> Subject: Re: iscsi : DataPDULength can differ in each direction. To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Mon, 08 Oct 2001 13:43:22 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, > Implementation is not a session parameter :-) The implementation directly affects the values that a session acquire though. :-) > What do you mean by an implementation specific parameter? Is it that > every connection has a different implementation and they cooperate? That is the scenario I'm addressing. There has been discussion of late which has indicated that initiators may have several different vendors products (i.e. implementations) installed at once and that it is expected that a session may span those multiple implementations. Each of those implementations will have its own constraints and limitations. So, you either have to adopt the greatest common denominator approach (i.e. limit connections to the intersection of all individual feature sets) or you allow each connection to conform to the implementation that it resides on. Dave From owner-ips@ece.cmu.edu Mon Oct 8 19:07: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 TAA03858 for ; Mon, 8 Oct 2001 19:07:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98MF6h08811 for ips-outgoing; Mon, 8 Oct 2001 18:15:06 -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 f98MF4l08804 for ; Mon, 8 Oct 2001 18:15:04 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel12.hp.com (Postfix) with ESMTP id 6D9E61F7F0; Mon, 8 Oct 2001 15:14:58 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by xparelay1.corp.hp.com (Postfix) with ESMTP id C96161F509; Mon, 8 Oct 2001 15:14:57 -0700 (PDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id <42R9TB2V>; Mon, 8 Oct 2001 15:14:57 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF1A0@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iscsi - InitiatorName key during login Date: Mon, 8 Oct 2001 15:14:05 -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 In any implementation, there may be a separation between authentication and authorization. I admit insufficient data WRT iSCSI security draft, but I am assuming that regardless what authentication scheme is in use, an implementation may or may not have some association between authentication "userId" and an initiator access control list consisting of InitiatorNames. So even if an initiator is "authenticated", this InitiatorName may not be allowed access to this target? The earlier list discussion seemed to indicate "userId" is separate from "InitiatorName" For instance, IPSec authenticates based on IP address. But there is no requirement that there be a one-one association between an IP address and an InitiatorName, so while the IP address may authenticate, the InitiatorName may not be allowed access to the target. Perhaps on a connection joining a session, it is enough that the connection knows the correct ISID, TSID? But I am thinking that requiring the correct InitiatorName is a small price to pay for an added check. ISID=1, TSID=1 is easy to "guess", but correct InitiatorName is not. Please correct me if you see a flaw in my thinking... Marjorie -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, October 08, 2001 2:10 PM To: ips@ece.cmu.edu Subject: RE: iscsi - InitiatorName key during login You are the naming team so you must be right! The current authentication schemes do not make specific use of the InitiatorName but some authentication has to be used. What makes InitiaatorName needed that you did consider earlier? Julo John Hufferd@IBMUS 08-10-01 22:36 To: Julian Satran/Haifa/IBM@IBMIL@IBMDE, "KRUEGER,MARJORIE (HP-Roseville,ex1)" , andy@windriver.com] cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: RE: iscsi - InitiatorName key during loginLink Marjorie is correct. Without the Initiator Name on all Logins a Secondary Connection can spoof its way in. The appendix needs to be corrected. . . . 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 Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iscsi - InitiatorName key during login I would think InitiatorName is required on the first login PDU of every connection - InitiatorName is required for target authentication of the initiator, and that happens each time a connection joins the session. To behave otherwise seems an opportunity for identity spoofing? In any case, this needs to be clarified in the next revision... 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: andy currid [mailto:andy@windriver.com] > Sent: Monday, October 08, 2001 9:34 AM > To: ips@ece.cmu.edu > Subject: iscsi - InitiatorName key during login > > > > iSCSI version 8 is unclear as to whether InitiatorName is required > in the first login PDU of every login in a session, or just the > leading login. > > Chapter 5, Login Phase, states - > > "The login phase sequence of commands and responses proceeds > as follows: > > - login initial request > - login partial response (optional) > - more login requests and responses (optional) > - login final-response (mandatory) > > The initial login request MUST include the InitiatorName and > SessionType key=value pairs." > > Taken in the context, this wording implies that for any login, the > first login PDU must contain the InitiatorName key. > > Appendix D.13, InitiatorName, states that InitiatorName is Leading > Only and that "this key MUST be provided by the initiator of the TCP > connection to the remote endpoint before the end of the login phase". > > This wording implies that InitiatorName is supplied in the leading > login only, and need not necessrily appear in the first login PDU > of the leading login. > > So which is correct? > > It seems to me that requiring that InitiatorName be present in the > first PDU of the leading login is a must, to allow targets to verify > up front whether or not they wish to proceed further with this > initiator. I don't think there's much incremental benefit to having > InitiatorName appear in the first login PDU of every login. > > Andy > -- > Andy Currid andy@windriver.com > Server Products Group http://www.windriver.com > Wind River Networks Phone : (1) 510 749 2191 > 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 > From owner-ips@ece.cmu.edu Mon Oct 8 19:20: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 TAA04000 for ; Mon, 8 Oct 2001 19:20:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98MEw608790 for ips-outgoing; Mon, 8 Oct 2001 18:14:58 -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 f98MEvl08784 for ; Mon, 8 Oct 2001 18:14: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 SAA50166 for ; Mon, 8 Oct 2001 18:12:31 -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 f98MEs2166958; Mon, 8 Oct 2001 16:14:54 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iscsi - InitiatorName key during login 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, 8 Oct 2001 15:14:05 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/08/2001 04:14:54 PM 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 f98MEvl08786 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, Even on Secondary connections Security Authentication is required. As part of this Authentication, the implementation needs to validate the UserID has the right to Use a specific iSCSI Initiator Name, therefore it needs to have the iSCSI Initiator Name. Now it is possible that the implementation has kept, the Initiator Node Name some where associated with the primary connection. In this case, if the other information in the PDU was sufficient to obtain the correlation to a specific Session, and thereby extract the iSCSI Initiator Name, then it would be possible to compare that to the list of iSCSI Initiators which the UserID is allowed to use. So, I guess I over spoke, it is possible to come up with an approach that works without the iSCSI Initiator Name being Sent on the Secondary Connection, but, it would be a non standard compare path with the normal ACL interaction. I still believe, however, that the iSCSI Initiator Name should be required on each connection to keep the implementations easier. . . . 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" @ece.cmu.edu on 10/08/2001 02:09:36 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iscsi - InitiatorName key during login You are the naming team so you must be right!  The current authentication schemes do not make specific use of the InitiatorName but some authentication has to be used. What makes InitiaatorName needed that you did consider earlier? Julo John Hufferd@IBMUS         To: Julian 08-10-01 22:36 Satran/Haifa/IBM@IBMI L@IBMDE, "KRUEGER,MARJORIE (HP-Roseville,ex1)" , andy@windriver.com]         cc: ips@ece.cmu.edu         From: John Hufferd/San Jose/IBM@IBMUS         Subject: RE: iscsi - InitiatorName key during loginLink Marjorie is correct.  Without the Initiator Name on all Logins  a Secondary Connection can spoof its way in.  The appendix needs to be corrected. . . . 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 Sent by:        owner-ips@ece.cmu.edu To:        ips@ece.cmu.edu cc: Subject:        RE: iscsi - InitiatorName key during login I would think InitiatorName is required on the first login PDU of every connection - InitiatorName is required for target authentication of the initiator, and that happens each time a connection joins the session.  To behave otherwise seems an opportunity for identity spoofing? In any case, this needs to be clarified in the next revision... 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: andy currid [mailto:andy@windriver.com] > Sent: Monday, October 08, 2001 9:34 AM > To: ips@ece.cmu.edu > Subject: iscsi - InitiatorName key during login > > > > iSCSI version 8 is unclear as to whether InitiatorName is required > in the first login PDU of every login in a session, or just the > leading login. > > Chapter 5, Login Phase, states - > >  "The login phase sequence of commands and responses proceeds > as follows: > >    - login initial request >    - login partial response (optional) >    - more login requests and responses (optional) >    - login final-response (mandatory) > >   The initial login request MUST include the InitiatorName and >   SessionType key=value pairs." > > Taken in the context, this wording implies that for any login, the > first login PDU must contain the InitiatorName key. > > Appendix D.13, InitiatorName, states that InitiatorName is Leading > Only and that "this key MUST be provided by the initiator of the TCP > connection to the remote endpoint before the end of the login phase". > > This wording implies that InitiatorName is supplied in the leading > login only, and need not necessrily appear in the first login PDU > of the leading login. > > So which is correct? > > It seems to me that requiring that InitiatorName be present in the > first PDU of the leading login is a must, to allow targets to verify > up front whether or not they wish to proceed further with this > initiator. I don't think there's much incremental benefit to having > InitiatorName appear in the first login PDU of every login. > > Andy > -- > Andy Currid                                       andy@windriver.com > Server Products Group                       http://www.windriver.com > Wind River Networks                         Phone : (1) 510 749 2191 > 500 Wind River Way, Alameda, CA 94501       Fax   : (1) 510 749 2560 > From owner-ips@ece.cmu.edu Mon Oct 8 20:36: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 UAA04758 for ; Mon, 8 Oct 2001 20:36:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98NfuF14248 for ips-outgoing; Mon, 8 Oct 2001 19:41:56 -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 f98Nftl14244 for ; Mon, 8 Oct 2001 19:41:55 -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 1CE6D2AA7 for ; Mon, 8 Oct 2001 17:41:51 -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 BBC271B8 for ; Mon, 8 Oct 2001 17:41:50 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id QAA13558 for ips@ece.cmu.edu; Mon, 8 Oct 2001 16:40:50 -0700 (PDT) From: Dave Sheehy Message-Id: <200110082340.QAA13558@acropora.rose.agilent.com> Subject: Re: iSCSI - revised 2.2.4 To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Mon, 08 Oct 2001 16:40:49 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Vendor specific keys have no (standard specified) default, yes? Targets can source vendor specific keys, yes? Aren't targets the originator in this case? Dave > Julian, > > I apologize upfront for being so persistent on this. > > However, it would really help if you could give some clear example of a > scenario as to why the initiator cannot be considered the originator of > a negotiation, when it offers a key value implicitly, through the use of > a default. > > Several people on this list (Paul Konning, Sanjeev, Deva, myself, and > perhaps others, that I cannot recall at the moment) have asked that the > spec must not differentiate login behaviour when the initiator offers a > key explicitly vs. when it offers a key implicitly thru the use of the > default. > > Please help us understand the need for iscsi to distingush the login > behaviour in the above case. [through some tangible scenarios and > examples]. > > Thanks, > Santosh > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Julian, > > > > I would also request an explicit definition of offering party and > > responding party. The current text still leaves ambiguity when target > > sends a key in response to implicit default key of the Intiator. In > > this case who is the offering party and who is the responding party > > > > Sanjeev > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, October 05, 2001 2:06 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI - revised 2.2.4 > > > > Here is a revised (complete) part 2.2.4 based on recent > > agreed changes: > > > > 1.1.1 Text Mode Negotiation > > > > During login and thereafter some session or connection > > parameters are negotiated through an exchange of textual > > information. > > > > All negotiations are stateless - i.e. the result MUST be > > based only on newly exchanged values. > > > > The general format of text negotiation is: > > > > Originator-> = > > Responder-> =|reject|NotUnderstood > > > > The value can be a number, a single literal constant a > > Boolean value (yes or no) or a list of comma separated > > literal constant values. > > > > In literal list negotiation, the originator sends for each > > key a list of options (literal constants which may include > > "none") in its order of preference. > > > > The responding party answers with the first value from the > > list it supports and is allowed to use for the specific > > originator. > > > > The constant "none" MUST always be used to indicate a > > missing function. However, none is a valid selection only if > > it is explicitly offered. > > > > If a target is not supporting, or not allowed to use with a > > specific originator, any of the offered options, it may use > > the constant "reject". The constants "none" and "reject" > > are reserved and must be used only as described here. Any > > key not understood is answered with "NotUnderstood". > > > > For numerical and single literal negotiations, the > > responding party MUST respond with the required key and the > > value it selects, based on the selection rule specific to > > the key, becomes the negotiation result. Selection of a > > value not admissible under the selection rules is considered > > a protocol error and handled accordingly. > > > > For Boolean negotiations (keys taking the values yes or no), > > the responding party MUST respond with the required key and > > the result of the negotiation when the received value does > > not determine that result by itself. The last value > > transmitted becomes the negotiation result. The rules for > > selecting the value to respond with are expressed as Boolean > > functions of the value received and the value that the > > responding party would select in the absence of knowledge of > > the received value. > > > > Specifically, the two cases in which responses are OPTIONAL > > are: > > > > - The Boolean function is "AND" and the value "no" is > > received. The outcome of the negotiation is "no". > > - The Boolean function is "OR" and the value "yes" is > > received. The outcome of the negotiation is "yes". > > > > Responses are REQUIRED in all other cases, and the value > > chosen and sent by the responder becomes the outcome of the > > negotiation. > > > > The value "?" with any key has the meaning of enquiry and > > should be answered with the current value or > > "NotUnderstood". > > > > 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, only the initiator can > > initiate the negotiation start (through the first Text > > request) and completion (by setting to 1 and keeping to 1 > > the F bit in a Text request). > > > > Comments ? > > > > 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 Mon Oct 8 20: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 UAA04779 for ; Mon, 8 Oct 2001 20:36:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f990CkR16196 for ips-outgoing; Mon, 8 Oct 2001 20:12:46 -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 f990Cil16191 for ; Mon, 8 Oct 2001 20:12:44 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel13.hp.com (Postfix) with ESMTP id 50FDB1F817 for ; Mon, 8 Oct 2001 17:12:38 -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 347A11F515 for ; Mon, 8 Oct 2001 17:12:35 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id <42S12Q0B>; Mon, 8 Oct 2001 17:12:35 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF1A1@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iSCSI - revised 2.2.4 Date: Mon, 8 Oct 2001 17:12: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 In which case the initiator cannot be expected to know the default - Santosh explicitly referred to behavior WRT "protocol defaults". It makes sense to me to state that an initiator that does not offer a key specified by the iSCSI protocol document to have a default has essentially "implicitly offered" that key's default. In which case, the target (even though it's the first to explicitly include the key) is the responder. When can the target assume that the initiator will not explicitly offer the key? Marjorie > -----Original Message----- > From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com] > Sent: Monday, October 08, 2001 4:41 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI - revised 2.2.4 > > > > Vendor specific keys have no (standard specified) default, > yes? Targets can > source vendor specific keys, yes? Aren't targets the > originator in this case? > > Dave > > > Julian, > > > > I apologize upfront for being so persistent on this. > > > > However, it would really help if you could give some clear > example of a > > scenario as to why the initiator cannot be considered the > originator of > > a negotiation, when it offers a key value implicitly, > through the use of > > a default. > > > > Several people on this list (Paul Konning, Sanjeev, Deva, > myself, and > > perhaps others, that I cannot recall at the moment) have > asked that the > > spec must not differentiate login behaviour when the > initiator offers a > > key explicitly vs. when it offers a key implicitly thru the > use of the > > default. > > > > Please help us understand the need for iscsi to distingush the login > > behaviour in the above case. [through some tangible scenarios and > > examples]. > > > > Thanks, > > Santosh > > > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Julian, > > > > > > I would also request an explicit definition of offering party and > > > responding party. The current text still leaves ambiguity > when target > > > sends a key in response to implicit default key of the > Intiator. In > > > this case who is the offering party and who is the > responding party > > > > > > Sanjeev > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, October 05, 2001 2:06 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI - revised 2.2.4 > > > > > > Here is a revised (complete) part 2.2.4 based on recent > > > agreed changes: > > > > > > 1.1.1 Text Mode Negotiation > > > > > > During login and thereafter some session or connection > > > parameters are negotiated through an exchange of textual > > > information. > > > > > > All negotiations are stateless - i.e. the result MUST be > > > based only on newly exchanged values. > > > > > > The general format of text negotiation is: > > > > > > Originator-> = > > > Responder-> =|reject|NotUnderstood > > > > > > The value can be a number, a single literal constant a > > > Boolean value (yes or no) or a list of comma separated > > > literal constant values. > > > > > > In literal list negotiation, the originator sends for each > > > key a list of options (literal constants which may include > > > "none") in its order of preference. > > > > > > The responding party answers with the first value from the > > > list it supports and is allowed to use for the specific > > > originator. > > > > > > The constant "none" MUST always be used to indicate a > > > missing function. However, none is a valid selection only if > > > it is explicitly offered. > > > > > > If a target is not supporting, or not allowed to use with a > > > specific originator, any of the offered options, it may use > > > the constant "reject". The constants "none" and "reject" > > > are reserved and must be used only as described here. Any > > > key not understood is answered with "NotUnderstood". > > > > > > For numerical and single literal negotiations, the > > > responding party MUST respond with the required key and the > > > value it selects, based on the selection rule specific to > > > the key, becomes the negotiation result. Selection of a > > > value not admissible under the selection rules is considered > > > a protocol error and handled accordingly. > > > > > > For Boolean negotiations (keys taking the values yes or no), > > > the responding party MUST respond with the required key and > > > the result of the negotiation when the received value does > > > not determine that result by itself. The last value > > > transmitted becomes the negotiation result. The rules for > > > selecting the value to respond with are expressed as Boolean > > > functions of the value received and the value that the > > > responding party would select in the absence of knowledge of > > > the received value. > > > > > > Specifically, the two cases in which responses are OPTIONAL > > > are: > > > > > > - The Boolean function is "AND" and the value "no" is > > > received. The outcome of the negotiation is "no". > > > - The Boolean function is "OR" and the value "yes" is > > > received. The outcome of the negotiation is "yes". > > > > > > Responses are REQUIRED in all other cases, and the value > > > chosen and sent by the responder becomes the outcome of the > > > negotiation. > > > > > > The value "?" with any key has the meaning of enquiry and > > > should be answered with the current value or > > > "NotUnderstood". > > > > > > 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, only the initiator can > > > initiate the negotiation start (through the first Text > > > request) and completion (by setting to 1 and keeping to 1 > > > the F bit in a Text request). > > > > > > Comments ? > > > > > > 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 Mon Oct 8 20:37: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 UAA04797 for ; Mon, 8 Oct 2001 20:37:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f98NtDn15096 for ips-outgoing; Mon, 8 Oct 2001 19:55:13 -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 f98NtCl15089 for ; Mon, 8 Oct 2001 19:55:12 -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 508382305 for ; Mon, 8 Oct 2001 17:55:11 -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 E2D5B212 for ; Mon, 8 Oct 2001 17:55:10 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id QAA13567 for ips@ece.cmu.edu; Mon, 8 Oct 2001 16:54:10 -0700 (PDT) From: Dave Sheehy Message-Id: <200110082354.QAA13567@acropora.rose.agilent.com> Subject: Re: iscsi : DataPDULength can differ in each direction. To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Mon, 08 Oct 2001 16:54:10 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Julo, > If they cooperate they have to share goals. The parameters you quoted > don't make sense per connection. > PDUlength makes a lot of sense. Just so I understand what you're saying you mean that > > you > > either have to adopt the greatest common denominator approach (i.e. limit > > connections to the intersection of all individual feature sets) is the approach you are advocating and each operating system vendor is going to have to develop that code if they expect to support a multi-vendor configuration with spanning sessions? Dave > Julo > > > > > Dave Sheehy > Sent by: owner-ips@ece.cmu.edu > 08-10-01 22:43 > Please respond to Dave Sheehy > > > To: ips@ece.cmu.edu (IETF IP SAN Reflector) > cc: > Subject: Re: iscsi : DataPDULength can differ in each direction. > > > > Julian, > > > Implementation is not a session parameter :-) > > The implementation directly affects the values that a session acquire > though. :-) > > > What do you mean by an implementation specific parameter? Is it that > > every connection has a different implementation and they cooperate? > > That is the scenario I'm addressing. There has been discussion of late > which has indicated that initiators may have several different vendors > products (i.e. implementations) installed at once and that it is expected > that a session may span those multiple implementations. Each of those > implementations will have its own constraints and limitations. So, you > either have to adopt the greatest common denominator approach (i.e. limit > connections to the intersection of all individual feature sets) or you > allow > each connection to conform to the implementation that it resides on. > > Dave > > > > > --=_alternative 007343E2C2256ADF_= > Content-Type: text/html; charset="us-ascii" > > >
If they cooperate they have to share goals. The parameters you quoted don't make sense per connection. >
PDUlength makes a lot of sense. >
>
Julo >
>
>
> > >
> Dave Sheehy <dbs@acropora.rose.agilent.com> >
Sent by: owner-ips@ece.cmu.edu >

08-10-01 22:43 >
Please respond to Dave Sheehy >
>

        >
        To:        ips@ece.cmu.edu (IETF IP SAN Reflector) >
        cc:         >
        Subject:        Re: iscsi : DataPDULength can differ in each direction. >
>
       
>
>
Julian,
>
> > Implementation is not a session parameter :-)
>
> The implementation directly affects the values that a session acquire
> though. :-)
>
> > What do you mean by an implementation specific parameter?  Is it that
> > every connection has a different implementation and they cooperate?
>
> That is the scenario I'm addressing. There has been discussion of late
> which has indicated that initiators may have several different vendors
> products (i.e. implementations) installed at once and that it is expected
> that a session may span those multiple implementations. Each of those
> implementations will have its own constraints and limitations. So, you
> either have to adopt the greatest common denominator approach (i.e. limit
> connections to the intersection of all individual feature sets) or you allow
> each connection to conform to the implementation that it resides on.
>
> Dave
>
> >
>
> --=_alternative 007343E2C2256ADF_=-- From owner-ips@ece.cmu.edu Mon Oct 8 21:41: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 VAA06388 for ; Mon, 8 Oct 2001 21:41:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f990fhm17912 for ips-outgoing; Mon, 8 Oct 2001 20:41:43 -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 f990ffl17906 for ; Mon, 8 Oct 2001 20:41:41 -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 97C0819DD for ; Mon, 8 Oct 2001 18:41:40 -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 3E13C2D2 for ; Mon, 8 Oct 2001 18:41:40 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id RAA13603 for ips@ece.cmu.edu; Mon, 8 Oct 2001 17:40:39 -0700 (PDT) From: Dave Sheehy Message-Id: <200110090040.RAA13603@acropora.rose.agilent.com> Subject: RE: iSCSI - revised 2.2.4 To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Mon, 08 Oct 2001 17:40:38 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Marjorie, Right, but Santosh's intent is to specify that the initiator is always the originator. If that is true then targets cannot originate keys for which there is no default. Other than a general bias in favor of simplifying the protocol I don't feel strongly about this issue one way or the other. Dave > In which case the initiator cannot be expected to know the default - Santosh > explicitly referred to behavior WRT "protocol defaults". > > It makes sense to me to state that an initiator that does not offer a key > specified by the iSCSI protocol document to have a default has essentially > "implicitly offered" that key's default. In which case, the target (even > though it's the first to explicitly include the key) is the responder. > > When can the target assume that the initiator will not explicitly offer the > key? > > Marjorie > > > -----Original Message----- > > From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com] > > Sent: Monday, October 08, 2001 4:41 PM > > To: ips@ece.cmu.edu > > Subject: Re: iSCSI - revised 2.2.4 > > > > > > > > Vendor specific keys have no (standard specified) default, > > yes? Targets can > > source vendor specific keys, yes? Aren't targets the > > originator in this case? > > > > Dave > > > > > Julian, > > > > > > I apologize upfront for being so persistent on this. > > > > > > However, it would really help if you could give some clear > > example of a > > > scenario as to why the initiator cannot be considered the > > originator of > > > a negotiation, when it offers a key value implicitly, > > through the use of > > > a default. > > > > > > Several people on this list (Paul Konning, Sanjeev, Deva, > > myself, and > > > perhaps others, that I cannot recall at the moment) have > > asked that the > > > spec must not differentiate login behaviour when the > > initiator offers a > > > key explicitly vs. when it offers a key implicitly thru the > > use of the > > > default. > > > > > > Please help us understand the need for iscsi to distingush the login > > > behaviour in the above case. [through some tangible scenarios and > > > examples]. > > > > > > Thanks, > > > Santosh > > > > > > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > > > Julian, > > > > > > > > I would also request an explicit definition of offering party and > > > > responding party. The current text still leaves ambiguity > > when target > > > > sends a key in response to implicit default key of the > > Intiator. In > > > > this case who is the offering party and who is the > > responding party > > > > > > > > Sanjeev > > > > > > > > -----Original Message----- > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > Sent: Friday, October 05, 2001 2:06 PM > > > > To: ips@ece.cmu.edu > > > > Subject: iSCSI - revised 2.2.4 > > > > > > > > Here is a revised (complete) part 2.2.4 based on recent > > > > agreed changes: > > > > > > > > 1.1.1 Text Mode Negotiation > > > > > > > > During login and thereafter some session or connection > > > > parameters are negotiated through an exchange of textual > > > > information. > > > > > > > > All negotiations are stateless - i.e. the result MUST be > > > > based only on newly exchanged values. > > > > > > > > The general format of text negotiation is: > > > > > > > > Originator-> = > > > > Responder-> =|reject|NotUnderstood > > > > > > > > The value can be a number, a single literal constant a > > > > Boolean value (yes or no) or a list of comma separated > > > > literal constant values. > > > > > > > > In literal list negotiation, the originator sends for each > > > > key a list of options (literal constants which may include > > > > "none") in its order of preference. > > > > > > > > The responding party answers with the first value from the > > > > list it supports and is allowed to use for the specific > > > > originator. > > > > > > > > The constant "none" MUST always be used to indicate a > > > > missing function. However, none is a valid selection only if > > > > it is explicitly offered. > > > > > > > > If a target is not supporting, or not allowed to use with a > > > > specific originator, any of the offered options, it may use > > > > the constant "reject". The constants "none" and "reject" > > > > are reserved and must be used only as described here. Any > > > > key not understood is answered with "NotUnderstood". > > > > > > > > For numerical and single literal negotiations, the > > > > responding party MUST respond with the required key and the > > > > value it selects, based on the selection rule specific to > > > > the key, becomes the negotiation result. Selection of a > > > > value not admissible under the selection rules is considered > > > > a protocol error and handled accordingly. > > > > > > > > For Boolean negotiations (keys taking the values yes or no), > > > > the responding party MUST respond with the required key and > > > > the result of the negotiation when the received value does > > > > not determine that result by itself. The last value > > > > transmitted becomes the negotiation result. The rules for > > > > selecting the value to respond with are expressed as Boolean > > > > functions of the value received and the value that the > > > > responding party would select in the absence of knowledge of > > > > the received value. > > > > > > > > Specifically, the two cases in which responses are OPTIONAL > > > > are: > > > > > > > > - The Boolean function is "AND" and the value "no" is > > > > received. The outcome of the negotiation is "no". > > > > - The Boolean function is "OR" and the value "yes" is > > > > received. The outcome of the negotiation is "yes". > > > > > > > > Responses are REQUIRED in all other cases, and the value > > > > chosen and sent by the responder becomes the outcome of the > > > > negotiation. > > > > > > > > The value "?" with any key has the meaning of enquiry and > > > > should be answered with the current value or > > > > "NotUnderstood". > > > > > > > > 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, only the initiator can > > > > initiate the negotiation start (through the first Text > > > > request) and completion (by setting to 1 and keeping to 1 > > > > the F bit in a Text request). > > > > > > > > Comments ? > > > > > > > > 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 Mon Oct 8 22:00: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 WAA06615 for ; Mon, 8 Oct 2001 22:00:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f991bch21256 for ips-outgoing; Mon, 8 Oct 2001 21:37:38 -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 f991bbl21252 for ; Mon, 8 Oct 2001 21:37:37 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 4935DCA8 for ; Mon, 8 Oct 2001 18:37: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 SAA05507 for ; Mon, 8 Oct 2001 18:37:29 -0700 (PDT) Message-ID: <3BC2568C.1A78927E@cup.hp.com> Date: Mon, 08 Oct 2001 18:44:44 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: ips : Negotiation Reset. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, The reject reason code "Negotiation Reset" is listed (newly) in Section 3.17.1. If one of the text commands from an initiator were to be rejected by the target for some other reason code than "Negotiation Reset", what is the effect of such a reject on the operational parameters ? Are'nt all operational parameters reset, any time a text exchange ends unsuccessfully ? I suggest the draft clearly state that ANY un-successful termination of a login/text exchange results in a reset of operational parameters. The "Negotiation Reset" reject reason code can be removed as well. 2) Also, what does the phrase "reset an operational parameter negotiation " mean ? Are the parameters reset to their default values , or are they reset to their previous values ? This needs to be explicitly clarified. 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 Mon Oct 8 22:05: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 WAA06688 for ; Mon, 8 Oct 2001 22:05:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f991Hkh20042 for ips-outgoing; Mon, 8 Oct 2001 21:17:46 -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 f991Hil20036 for ; Mon, 8 Oct 2001 21:17:44 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id DDC90E1D; Mon, 8 Oct 2001 18:17: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 SAA03982; Mon, 8 Oct 2001 18:17:39 -0700 (PDT) Message-ID: <3BC251E6.C1B324BE@cup.hp.com> Date: Mon, 08 Oct 2001 18:24:54 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Dave Sheehy Cc: IETF IP SAN Reflector Subject: Re: iSCSI - revised 2.2.4 References: <200110090040.RAA13603@acropora.rose.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave, Please take a second look at my mail below. My question was targeting all the operational keys that have a default defined for them. Specifically, that an initiator that uses the defaults must be considered the originator for that negotiation. (Incidentally, all operational keys either have defaults specified or are mandated to be explicitly sent by the initiator. Thus, for all operational keys, initiator would be the originator.) The proposal does NOT attempt to prohibit targets from originating vendor specific keys. (Though I'm not certain, what real value vendor specific target keys are going to be providing.) Thanks, Santosh Dave Sheehy wrote: > > Marjorie, > > Right, but Santosh's intent is to specify that the initiator is always > the originator. If that is true then targets cannot originate keys for > which there is no default. Other than a general bias in favor of > simplifying the protocol I don't feel strongly about this issue one way or > the other. > > Dave > > > In which case the initiator cannot be expected to know the default - Santosh > > explicitly referred to behavior WRT "protocol defaults". > > > > It makes sense to me to state that an initiator that does not offer a key > > specified by the iSCSI protocol document to have a default has essentially > > "implicitly offered" that key's default. In which case, the target (even > > though it's the first to explicitly include the key) is the responder. > > > > When can the target assume that the initiator will not explicitly offer the > > key? > > > > Marjorie > > > > > -----Original Message----- > > > From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com] > > > Sent: Monday, October 08, 2001 4:41 PM > > > To: ips@ece.cmu.edu > > > Subject: Re: iSCSI - revised 2.2.4 > > > > > > > > > > > > Vendor specific keys have no (standard specified) default, > > > yes? Targets can > > > source vendor specific keys, yes? Aren't targets the > > > originator in this case? > > > > > > Dave > > > > > > > Julian, > > > > > > > > I apologize upfront for being so persistent on this. > > > > > > > > However, it would really help if you could give some clear > > > example of a > > > > scenario as to why the initiator cannot be considered the > > > originator of > > > > a negotiation, when it offers a key value implicitly, > > > through the use of > > > > a default. > > > > > > > > Several people on this list (Paul Konning, Sanjeev, Deva, > > > myself, and > > > > perhaps others, that I cannot recall at the moment) have > > > asked that the > > > > spec must not differentiate login behaviour when the > > > initiator offers a > > > > key explicitly vs. when it offers a key implicitly thru the > > > use of the > > > > default. > > > > > > > > Please help us understand the need for iscsi to distingush the login > > > > behaviour in the above case. [through some tangible scenarios and > > > > examples]. > > > > > > > > Thanks, > > > > Santosh > > > > > > > > > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > > > > > Julian, > > > > > > > > > > I would also request an explicit definition of offering party and > > > > > responding party. The current text still leaves ambiguity > > > when target > > > > > sends a key in response to implicit default key of the > > > Intiator. In > > > > > this case who is the offering party and who is the > > > responding party > > > > > > > > > > Sanjeev > > > > > > > > > > -----Original Message----- > > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > > Sent: Friday, October 05, 2001 2:06 PM > > > > > To: ips@ece.cmu.edu > > > > > Subject: iSCSI - revised 2.2.4 > > > > > > > > > > Here is a revised (complete) part 2.2.4 based on recent > > > > > agreed changes: > > > > > > > > > > 1.1.1 Text Mode Negotiation > > > > > > > > > > During login and thereafter some session or connection > > > > > parameters are negotiated through an exchange of textual > > > > > information. > > > > > > > > > > All negotiations are stateless - i.e. the result MUST be > > > > > based only on newly exchanged values. > > > > > > > > > > The general format of text negotiation is: > > > > > > > > > > Originator-> = > > > > > Responder-> =|reject|NotUnderstood > > > > > > > > > > The value can be a number, a single literal constant a > > > > > Boolean value (yes or no) or a list of comma separated > > > > > literal constant values. > > > > > > > > > > In literal list negotiation, the originator sends for each > > > > > key a list of options (literal constants which may include > > > > > "none") in its order of preference. > > > > > > > > > > The responding party answers with the first value from the > > > > > list it supports and is allowed to use for the specific > > > > > originator. > > > > > > > > > > The constant "none" MUST always be used to indicate a > > > > > missing function. However, none is a valid selection only if > > > > > it is explicitly offered. > > > > > > > > > > If a target is not supporting, or not allowed to use with a > > > > > specific originator, any of the offered options, it may use > > > > > the constant "reject". The constants "none" and "reject" > > > > > are reserved and must be used only as described here. Any > > > > > key not understood is answered with "NotUnderstood". > > > > > > > > > > For numerical and single literal negotiations, the > > > > > responding party MUST respond with the required key and the > > > > > value it selects, based on the selection rule specific to > > > > > the key, becomes the negotiation result. Selection of a > > > > > value not admissible under the selection rules is considered > > > > > a protocol error and handled accordingly. > > > > > > > > > > For Boolean negotiations (keys taking the values yes or no), > > > > > the responding party MUST respond with the required key and > > > > > the result of the negotiation when the received value does > > > > > not determine that result by itself. The last value > > > > > transmitted becomes the negotiation result. The rules for > > > > > selecting the value to respond with are expressed as Boolean > > > > > functions of the value received and the value that the > > > > > responding party would select in the absence of knowledge of > > > > > the received value. > > > > > > > > > > Specifically, the two cases in which responses are OPTIONAL > > > > > are: > > > > > > > > > > - The Boolean function is "AND" and the value "no" is > > > > > received. The outcome of the negotiation is "no". > > > > > - The Boolean function is "OR" and the value "yes" is > > > > > received. The outcome of the negotiation is "yes". > > > > > > > > > > Responses are REQUIRED in all other cases, and the value > > > > > chosen and sent by the responder becomes the outcome of the > > > > > negotiation. > > > > > > > > > > The value "?" with any key has the meaning of enquiry and > > > > > should be answered with the current value or > > > > > "NotUnderstood". > > > > > > > > > > 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, only the initiator can > > > > > initiate the negotiation start (through the first Text > > > > > request) and completion (by setting to 1 and keeping to 1 > > > > > the F bit in a Text request). > > > > > > > > > > Comments ? > > > > > > > > > > Julo > > > > > > > > -- > > > > ################################## > > > > 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 Mon Oct 8 22:10: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 WAA06744 for ; Mon, 8 Oct 2001 22:10:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f991N9Y20404 for ips-outgoing; Mon, 8 Oct 2001 21:23:09 -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 f991N7l20397 for ; Mon, 8 Oct 2001 21:23:07 -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 B639A2ACF for ; Mon, 8 Oct 2001 19:23:06 -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 3B3D0EB for ; Mon, 8 Oct 2001 19:23:06 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id SAA13639 for ips@ece.cmu.edu; Mon, 8 Oct 2001 18:22:05 -0700 (PDT) From: Dave Sheehy Message-Id: <200110090122.SAA13639@acropora.rose.agilent.com> Subject: Re: iSCSI - revised 2.2.4 To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Mon, 08 Oct 2001 18:22:04 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, > Please take a second look at my mail below. My question was targeting > all the operational keys that have a default defined for them. > Specifically, that an initiator that uses the defaults must be > considered the originator for that negotiation. I agree with this. A default is an implicit offer to my thinking. > (Incidentally, all operational keys either have defaults specified or > are mandated to be explicitly sent by the initiator. Thus, for all > operational keys, initiator would be the originator.) Agreed. > The proposal does NOT attempt to prohibit targets from originating > vendor specific keys. > (Though I'm not certain, what real value vendor specific target keys > are going to be providing.) Me either. That's for the target vendor to decide though. :-) Dave > > Thanks, > Santosh > > > Dave Sheehy wrote: > > > > Marjorie, > > > > Right, but Santosh's intent is to specify that the initiator is always > > the originator. If that is true then targets cannot originate keys for > > which there is no default. Other than a general bias in favor of > > simplifying the protocol I don't feel strongly about this issue one way or > > the other. > > > > Dave > > > > > In which case the initiator cannot be expected to know the default - Santosh > > > explicitly referred to behavior WRT "protocol defaults". > > > > > > It makes sense to me to state that an initiator that does not offer a key > > > specified by the iSCSI protocol document to have a default has essentially > > > "implicitly offered" that key's default. In which case, the target (even > > > though it's the first to explicitly include the key) is the responder. > > > > > > When can the target assume that the initiator will not explicitly offer the > > > key? > > > > > > Marjorie > > > > > > > -----Original Message----- > > > > From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com] > > > > Sent: Monday, October 08, 2001 4:41 PM > > > > To: ips@ece.cmu.edu > > > > Subject: Re: iSCSI - revised 2.2.4 > > > > > > > > > > > > > > > > Vendor specific keys have no (standard specified) default, > > > > yes? Targets can > > > > source vendor specific keys, yes? Aren't targets the > > > > originator in this case? > > > > > > > > Dave > > > > > > > > > Julian, > > > > > > > > > > I apologize upfront for being so persistent on this. > > > > > > > > > > However, it would really help if you could give some clear > > > > example of a > > > > > scenario as to why the initiator cannot be considered the > > > > originator of > > > > > a negotiation, when it offers a key value implicitly, > > > > through the use of > > > > > a default. > > > > > > > > > > Several people on this list (Paul Konning, Sanjeev, Deva, > > > > myself, and > > > > > perhaps others, that I cannot recall at the moment) have > > > > asked that the > > > > > spec must not differentiate login behaviour when the > > > > initiator offers a > > > > > key explicitly vs. when it offers a key implicitly thru the > > > > use of the > > > > > default. > > > > > > > > > > Please help us understand the need for iscsi to distingush the login > > > > > behaviour in the above case. [through some tangible scenarios and > > > > > examples]. > > > > > > > > > > Thanks, > > > > > Santosh > > > > > > > > > > > > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > > > > > > > Julian, > > > > > > > > > > > > I would also request an explicit definition of offering party and > > > > > > responding party. The current text still leaves ambiguity > > > > when target > > > > > > sends a key in response to implicit default key of the > > > > Intiator. In > > > > > > this case who is the offering party and who is the > > > > responding party > > > > > > > > > > > > Sanjeev > > > > > > > > > > > > -----Original Message----- > > > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > > > Sent: Friday, October 05, 2001 2:06 PM > > > > > > To: ips@ece.cmu.edu > > > > > > Subject: iSCSI - revised 2.2.4 > > > > > > > > > > > > Here is a revised (complete) part 2.2.4 based on recent > > > > > > agreed changes: > > > > > > > > > > > > 1.1.1 Text Mode Negotiation > > > > > > > > > > > > During login and thereafter some session or connection > > > > > > parameters are negotiated through an exchange of textual > > > > > > information. > > > > > > > > > > > > All negotiations are stateless - i.e. the result MUST be > > > > > > based only on newly exchanged values. > > > > > > > > > > > > The general format of text negotiation is: > > > > > > > > > > > > Originator-> = > > > > > > Responder-> =|reject|NotUnderstood > > > > > > > > > > > > The value can be a number, a single literal constant a > > > > > > Boolean value (yes or no) or a list of comma separated > > > > > > literal constant values. > > > > > > > > > > > > In literal list negotiation, the originator sends for each > > > > > > key a list of options (literal constants which may include > > > > > > "none") in its order of preference. > > > > > > > > > > > > The responding party answers with the first value from the > > > > > > list it supports and is allowed to use for the specific > > > > > > originator. > > > > > > > > > > > > The constant "none" MUST always be used to indicate a > > > > > > missing function. However, none is a valid selection only if > > > > > > it is explicitly offered. > > > > > > > > > > > > If a target is not supporting, or not allowed to use with a > > > > > > specific originator, any of the offered options, it may use > > > > > > the constant "reject". The constants "none" and "reject" > > > > > > are reserved and must be used only as described here. Any > > > > > > key not understood is answered with "NotUnderstood". > > > > > > > > > > > > For numerical and single literal negotiations, the > > > > > > responding party MUST respond with the required key and the > > > > > > value it selects, based on the selection rule specific to > > > > > > the key, becomes the negotiation result. Selection of a > > > > > > value not admissible under the selection rules is considered > > > > > > a protocol error and handled accordingly. > > > > > > > > > > > > For Boolean negotiations (keys taking the values yes or no), > > > > > > the responding party MUST respond with the required key and > > > > > > the result of the negotiation when the received value does > > > > > > not determine that result by itself. The last value > > > > > > transmitted becomes the negotiation result. The rules for > > > > > > selecting the value to respond with are expressed as Boolean > > > > > > functions of the value received and the value that the > > > > > > responding party would select in the absence of knowledge of > > > > > > the received value. > > > > > > > > > > > > Specifically, the two cases in which responses are OPTIONAL > > > > > > are: > > > > > > > > > > > > - The Boolean function is "AND" and the value "no" is > > > > > > received. The outcome of the negotiation is "no". > > > > > > - The Boolean function is "OR" and the value "yes" is > > > > > > received. The outcome of the negotiation is "yes". > > > > > > > > > > > > Responses are REQUIRED in all other cases, and the value > > > > > > chosen and sent by the responder becomes the outcome of the > > > > > > negotiation. > > > > > > > > > > > > The value "?" with any key has the meaning of enquiry and > > > > > > should be answered with the current value or > > > > > > "NotUnderstood". > > > > > > > > > > > > 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, only the initiator can > > > > > > initiate the negotiation start (through the first Text > > > > > > request) and completion (by setting to 1 and keeping to 1 > > > > > > the F bit in a Text request). > > > > > > > > > > > > Comments ? > > > > > > > > > > > > Julo > > > > > > > > > > -- > > > > > ################################## > > > > > 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 Mon Oct 8 22:14: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 WAA06808 for ; Mon, 8 Oct 2001 22:14:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f991hLq21590 for ips-outgoing; Mon, 8 Oct 2001 21:43: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 f991hIl21583 for ; Mon, 8 Oct 2001 21:43: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 9805C1F7FE for ; Mon, 8 Oct 2001 18:43:09 -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 SAA05734 for ; Mon, 8 Oct 2001 18:43:04 -0700 (PDT) Message-ID: <3BC257DB.A63ED1EE@cup.hp.com> Date: Mon, 08 Oct 2001 18:50:19 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IETF IP SAN Reflector Subject: Re: iSCSI - revised 2.2.4 References: <200110090122.SAA13639@acropora.rose.agilent.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 think that's at least 6 people who're in favor of keeping login behaviour identical when the initiator uses implicit keys (thru defaults) vs. explicit keys. When do we get to call for consensus on this one ? - Santosh Dave Sheehy wrote: > > Santosh, > > > Please take a second look at my mail below. My question was targeting > > all the operational keys that have a default defined for them. > > Specifically, that an initiator that uses the defaults must be > > considered the originator for that negotiation. > > I agree with this. A default is an implicit offer to my thinking. > > > (Incidentally, all operational keys either have defaults specified or > > are mandated to be explicitly sent by the initiator. Thus, for all > > operational keys, initiator would be the originator.) > > Agreed. > > > The proposal does NOT attempt to prohibit targets from originating > > vendor specific keys. > > (Though I'm not certain, what real value vendor specific target keys > > are going to be providing.) > > Me either. That's for the target vendor to decide though. :-) > > Dave > > > > > Thanks, > > Santosh > > > > > > Dave Sheehy wrote: > > > > > > Marjorie, > > > > > > Right, but Santosh's intent is to specify that the initiator is always > > > the originator. If that is true then targets cannot originate keys for > > > which there is no default. Other than a general bias in favor of > > > simplifying the protocol I don't feel strongly about this issue one way or > > > the other. > > > > > > Dave > > > > > > > In which case the initiator cannot be expected to know the default - Santosh > > > > explicitly referred to behavior WRT "protocol defaults". > > > > > > > > It makes sense to me to state that an initiator that does not offer a key > > > > specified by the iSCSI protocol document to have a default has essentially > > > > "implicitly offered" that key's default. In which case, the target (even > > > > though it's the first to explicitly include the key) is the responder. > > > > > > > > When can the target assume that the initiator will not explicitly offer the > > > > key? > > > > > > > > Marjorie > > > > > > > > > -----Original Message----- > > > > > From: Dave Sheehy [mailto:dbs@acropora.rose.agilent.com] > > > > > Sent: Monday, October 08, 2001 4:41 PM > > > > > To: ips@ece.cmu.edu > > > > > Subject: Re: iSCSI - revised 2.2.4 > > > > > > > > > > > > > > > > > > > > Vendor specific keys have no (standard specified) default, > > > > > yes? Targets can > > > > > source vendor specific keys, yes? Aren't targets the > > > > > originator in this case? > > > > > > > > > > Dave > > > > > > > > > > > Julian, > > > > > > > > > > > > I apologize upfront for being so persistent on this. > > > > > > > > > > > > However, it would really help if you could give some clear > > > > > example of a > > > > > > scenario as to why the initiator cannot be considered the > > > > > originator of > > > > > > a negotiation, when it offers a key value implicitly, > > > > > through the use of > > > > > > a default. > > > > > > > > > > > > Several people on this list (Paul Konning, Sanjeev, Deva, > > > > > myself, and > > > > > > perhaps others, that I cannot recall at the moment) have > > > > > asked that the > > > > > > spec must not differentiate login behaviour when the > > > > > initiator offers a > > > > > > key explicitly vs. when it offers a key implicitly thru the > > > > > use of the > > > > > > default. > > > > > > > > > > > > Please help us understand the need for iscsi to distingush the login > > > > > > behaviour in the above case. [through some tangible scenarios and > > > > > > examples]. > > > > > > > > > > > > Thanks, > > > > > > Santosh > > > > > > > > > > > > > > > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > > > > > > > > > Julian, > > > > > > > > > > > > > > I would also request an explicit definition of offering party and > > > > > > > responding party. The current text still leaves ambiguity > > > > > when target > > > > > > > sends a key in response to implicit default key of the > > > > > Intiator. In > > > > > > > this case who is the offering party and who is the > > > > > responding party > > > > > > > > > > > > > > Sanjeev > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > > > > Sent: Friday, October 05, 2001 2:06 PM > > > > > > > To: ips@ece.cmu.edu > > > > > > > Subject: iSCSI - revised 2.2.4 > > > > > > > > > > > > > > Here is a revised (complete) part 2.2.4 based on recent > > > > > > > agreed changes: > > > > > > > > > > > > > > 1.1.1 Text Mode Negotiation > > > > > > > > > > > > > > During login and thereafter some session or connection > > > > > > > parameters are negotiated through an exchange of textual > > > > > > > information. > > > > > > > > > > > > > > All negotiations are stateless - i.e. the result MUST be > > > > > > > based only on newly exchanged values. > > > > > > > > > > > > > > The general format of text negotiation is: > > > > > > > > > > > > > > Originator-> = > > > > > > > Responder-> =|reject|NotUnderstood > > > > > > > > > > > > > > The value can be a number, a single literal constant a > > > > > > > Boolean value (yes or no) or a list of comma separated > > > > > > > literal constant values. > > > > > > > > > > > > > > In literal list negotiation, the originator sends for each > > > > > > > key a list of options (literal constants which may include > > > > > > > "none") in its order of preference. > > > > > > > > > > > > > > The responding party answers with the first value from the > > > > > > > list it supports and is allowed to use for the specific > > > > > > > originator. > > > > > > > > > > > > > > The constant "none" MUST always be used to indicate a > > > > > > > missing function. However, none is a valid selection only if > > > > > > > it is explicitly offered. > > > > > > > > > > > > > > If a target is not supporting, or not allowed to use with a > > > > > > > specific originator, any of the offered options, it may use > > > > > > > the constant "reject". The constants "none" and "reject" > > > > > > > are reserved and must be used only as described here. Any > > > > > > > key not understood is answered with "NotUnderstood". > > > > > > > > > > > > > > For numerical and single literal negotiations, the > > > > > > > responding party MUST respond with the required key and the > > > > > > > value it selects, based on the selection rule specific to > > > > > > > the key, becomes the negotiation result. Selection of a > > > > > > > value not admissible under the selection rules is considered > > > > > > > a protocol error and handled accordingly. > > > > > > > > > > > > > > For Boolean negotiations (keys taking the values yes or no), > > > > > > > the responding party MUST respond with the required key and > > > > > > > the result of the negotiation when the received value does > > > > > > > not determine that result by itself. The last value > > > > > > > transmitted becomes the negotiation result. The rules for > > > > > > > selecting the value to respond with are expressed as Boolean > > > > > > > functions of the value received and the value that the > > > > > > > responding party would select in the absence of knowledge of > > > > > > > the received value. > > > > > > > > > > > > > > Specifically, the two cases in which responses are OPTIONAL > > > > > > > are: > > > > > > > > > > > > > > - The Boolean function is "AND" and the value "no" is > > > > > > > received. The outcome of the negotiation is "no". > > > > > > > - The Boolean function is "OR" and the value "yes" is > > > > > > > received. The outcome of the negotiation is "yes". > > > > > > > > > > > > > > Responses are REQUIRED in all other cases, and the value > > > > > > > chosen and sent by the responder becomes the outcome of the > > > > > > > negotiation. > > > > > > > > > > > > > > The value "?" with any key has the meaning of enquiry and > > > > > > > should be answered with the current value or > > > > > > > "NotUnderstood". > > > > > > > > > > > > > > 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, only the initiator can > > > > > > > initiate the negotiation start (through the first Text > > > > > > > request) and completion (by setting to 1 and keeping to 1 > > > > > > > the F bit in a Text request). > > > > > > > > > > > > > > Comments ? > > > > > > > > > > > > > > Julo > > > > > > > > > > > > -- > > > > > > ################################## > > > > > > 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 > > ################################## > > -- ################################## 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 Mon Oct 8 23:26: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 XAA08853 for ; Mon, 8 Oct 2001 23:26:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f992LBR23807 for ips-outgoing; Mon, 8 Oct 2001 22:21:11 -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 f991bCl21206 for ; Mon, 8 Oct 2001 21:37:13 -0400 (EDT) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Oct 2001 18:37:00 -0700 Message-ID: <034670D62D19D31180990090277A37B701C1893A@mercury.corp.iready.com> From: Michael Smith To: "'ips@ece.cmu.edu'" Cc: Michael Smith Subject: iSCSI: v8 concordance Date: Mon, 8 Oct 2001 18:36:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15062.E38229A0" 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_01C15062.E38229A0 Content-Type: text/plain; charset="iso-8859-1" There have been several comments recently on this reflector about the use of terms and definitions in the current iSCSI Internet draft. I have created a concordance for the iSCSI v8 Internet draft. You may download the concordance at http://www.iready.org/iscsi/iscsi8concordanceV5.doc This is a very large file (10MB). A concordance is like an amplified index. A concordance is an ordered list of the occurence of every single word, term, and character in the iSCSI v8 spec together with it's context (the context being a certain number of words around each occurence). Why is this useful? Let's take an example from the iSCSI Internet draft concordance file. Take the term "barrier". It often occurs as the term "barrier list" in the current Internet draft. But how is this term used exactly? First, look up "barrier (exactly as I have shown it here) in the concordance and you will see the following: "BARRIER................................................................5 layer. The "barrier list" described in the following sections is a 7370 "barrier list"; 7382 a) if the "barrier list" is empty or ExpCmdSN is less than 7392 a "barrier list" including the referenced LUN (or an ALL 7420 a) if the "barrier list" is empty or ExpCmdSN is less than 7428 This means the characters "barrier appear five times (lines 7370, 7382, 7392, 7420, 7428 as numbered from the .txt version). Each time the characters "barrier occur as "barrier list". Continue now to look up just the characters barrier in the concordance. You will find: BARRIER.................................................................5 Note: for clarity, the barrier list contains "items" and the 7387 the CmdSN of the oldest item in the barrier list then 7393 b) remove the oldest barrier list item, and remove and 7395 the oldest item in the barrier list then skip to step d; 7429 b) remove the oldest barrier list item and evaluate all 7430 Thus barrier also occurs five times (lines 7387, 7393, 7395, 7429, 7430). So what? The concordance has told us: 1. If the term "barrier list" is defined the first time that it is used. (It is, sort of.) 2. If the term "barrier list" is used consistently each time. 3. That the use of quotes around barrier list is inconsistent and therefore perhaps misleading. I hope that, from this small example, you may easily extrapolate to other uses of a concordance in reading, understanding, and editing the current iSCSI Internet draft. I have found this technique useful in the past. Aloha Mike Smith CTO iReady ------_=_NextPart_001_01C15062.E38229A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable iSCSI: v8 concordance

There have been several comments recently on this = reflector about the use of terms and definitions in the current iSCSI = Internet draft.

I have created a concordance for the iSCSI v8 = Internet draft. You may download the concordance at
http://www.iready.org/iscsi/iscsi8concordanceV5.doc

This is a very large file (10MB).

A concordance is like an amplified index. A = concordance is an ordered list of the occurence of every single word, = term, and character in the iSCSI v8 spec together with it's context = (the context being a certain number of words around each = occurence).

Why is this useful? Let's take an example from the = iSCSI Internet draft concordance file. Take the term = "barrier". It often occurs as the term "barrier = list" in the current Internet draft. But how is this term used = exactly? First, look up "barrier (exactly as I have shown it here) = in the concordance and you will see the following:


"BARRIER..................................................= ..............5
          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           = layer.  The "barrier list" described in the following = sections is = a            = ;      7370 

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           = "barrier = list";          &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp;           = 7382 

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp; a) if the "barrier list" is empty or ExpCmdSN is less = than           &n= bsp;           &n= bsp; 7392 

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;         a "barrier = list" including the referenced LUN (or an = ALL           &nb= sp;       7420 

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp; a) if the "barrier list" is empty or ExpCmdSN is less = than           &n= bsp;           &n= bsp; 7428 

This means the characters "barrier appear five = times (lines 7370, 7382, 7392, 7420, 7428 as numbered from the .txt = version). Each time the characters "barrier occur as "barrier = list". Continue now to look up just the characters barrier in the = concordance. You will find:

BARRIER........................................................= .........5
          &nb= sp;           &nb= sp;           &nb= sp;            = Note: for clarity, the barrier list contains "items" and = the           &nb= sp;           &nb= sp;            = 7387 

          &nb= sp;           &nb= sp;           the = CmdSN of the oldest item in the barrier list = then           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;        7393 

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  b) remove the oldest barrier list item, and remove = and           &nb= sp;           &nb= sp;           &nb= sp;    7395 

          &nb= sp;           &nb= sp;           &nb= sp;            = the oldest item in the barrier list then skip to step = d;           &nbs= p;           &nbs= p;           &nbs= p;    7429 

          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;  b) remove the oldest barrier list item and evaluate all &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp; 7430 


Thus barrier also occurs five times (lines 7387, = 7393, 7395, 7429, 7430).

So what?

The concordance has told us:

1. If the term "barrier list" is defined = the first time that it is used. (It is, sort of.)
2. If the term "barrier list" is used = consistently each time.
3. That the use of quotes around barrier list is = inconsistent and therefore perhaps misleading.

I hope that, from this small example, you may easily = extrapolate to other uses of a concordance in reading, understanding, = and editing the current iSCSI Internet draft. I have found this = technique useful in the past.

Aloha

Mike Smith
CTO
iReady

------_=_NextPart_001_01C15062.E38229A0-- From owner-ips@ece.cmu.edu Tue Oct 9 00:54: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 AAA10231 for ; Tue, 9 Oct 2001 00:54:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9941pP28797 for ips-outgoing; Tue, 9 Oct 2001 00:01: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 f9941Yl28765; Tue, 9 Oct 2001 00:01:47 -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 GAA55792; Tue, 9 Oct 2001 06:01: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 f9941LQ47468; Tue, 9 Oct 2001 06:01:22 +0200 To: "KRUEGER,MARJORIE (HP-Roseville,ex1)" Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iscsi - InitiatorName key during login X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Oct 2001 07:01:19 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 07:01:22, Serialize complete at 09/10/2001 07:01:22 Content-Type: multipart/alternative; boundary="=_alternative 000D2218C2256AE0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 000D2218C2256AE0_= Content-Type: text/plain; charset="us-ascii" Marjorie, I am not an expert in names :-) It is up to your team to tell me what to do. I can object (as any list member) but I do not have any strong belief on this. IMHO it is an overkill to have it on any connection since this requires the target to check it against SSID but that is only an opinion (and I have been know not to agree with my own opinions sometime). Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 09-10-01 00:14 Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iscsi - InitiatorName key during login In any implementation, there may be a separation between authentication and authorization. I admit insufficient data WRT iSCSI security draft, but I am assuming that regardless what authentication scheme is in use, an implementation may or may not have some association between authentication "userId" and an initiator access control list consisting of InitiatorNames. So even if an initiator is "authenticated", this InitiatorName may not be allowed access to this target? The earlier list discussion seemed to indicate "userId" is separate from "InitiatorName" For instance, IPSec authenticates based on IP address. But there is no requirement that there be a one-one association between an IP address and an InitiatorName, so while the IP address may authenticate, the InitiatorName may not be allowed access to the target. Perhaps on a connection joining a session, it is enough that the connection knows the correct ISID, TSID? But I am thinking that requiring the correct InitiatorName is a small price to pay for an added check. ISID=1, TSID=1 is easy to "guess", but correct InitiatorName is not. Please correct me if you see a flaw in my thinking... Marjorie -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, October 08, 2001 2:10 PM To: ips@ece.cmu.edu Subject: RE: iscsi - InitiatorName key during login You are the naming team so you must be right! The current authentication schemes do not make specific use of the InitiatorName but some authentication has to be used. What makes InitiaatorName needed that you did consider earlier? Julo John Hufferd@IBMUS 08-10-01 22:36 To: Julian Satran/Haifa/IBM@IBMIL@IBMDE, "KRUEGER,MARJORIE (HP-Roseville,ex1)" , andy@windriver.com] cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: RE: iscsi - InitiatorName key during loginLink Marjorie is correct. Without the Initiator Name on all Logins a Secondary Connection can spoof its way in. The appendix needs to be corrected. . . . 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 Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iscsi - InitiatorName key during login I would think InitiatorName is required on the first login PDU of every connection - InitiatorName is required for target authentication of the initiator, and that happens each time a connection joins the session. To behave otherwise seems an opportunity for identity spoofing? In any case, this needs to be clarified in the next revision... 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: andy currid [mailto:andy@windriver.com] > Sent: Monday, October 08, 2001 9:34 AM > To: ips@ece.cmu.edu > Subject: iscsi - InitiatorName key during login > > > > iSCSI version 8 is unclear as to whether InitiatorName is required > in the first login PDU of every login in a session, or just the > leading login. > > Chapter 5, Login Phase, states - > > "The login phase sequence of commands and responses proceeds > as follows: > > - login initial request > - login partial response (optional) > - more login requests and responses (optional) > - login final-response (mandatory) > > The initial login request MUST include the InitiatorName and > SessionType key=value pairs." > > Taken in the context, this wording implies that for any login, the > first login PDU must contain the InitiatorName key. > > Appendix D.13, InitiatorName, states that InitiatorName is Leading > Only and that "this key MUST be provided by the initiator of the TCP > connection to the remote endpoint before the end of the login phase". > > This wording implies that InitiatorName is supplied in the leading > login only, and need not necessrily appear in the first login PDU > of the leading login. > > So which is correct? > > It seems to me that requiring that InitiatorName be present in the > first PDU of the leading login is a must, to allow targets to verify > up front whether or not they wish to proceed further with this > initiator. I don't think there's much incremental benefit to having > InitiatorName appear in the first login PDU of every login. > > Andy > -- > Andy Currid andy@windriver.com > Server Products Group http://www.windriver.com > Wind River Networks Phone : (1) 510 749 2191 > 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 > --=_alternative 000D2218C2256AE0_= Content-Type: text/html; charset="us-ascii"
Marjorie,

I am not an expert in names :-)
It is up to your team to tell me what to do.  I can object (as any list member) but I do not have any strong belief on this.
IMHO it is an overkill to have it on any connection since this requires the target to check it against SSID but that
is only an opinion (and I have been know not to agree with my own opinions sometime).

Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
Sent by: owner-ips@ece.cmu.edu

09-10-01 00:14
Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iscsi - InitiatorName key during login

       


In any implementation, there may be a separation between authentication and
authorization.

I admit insufficient data WRT iSCSI security draft, but I am assuming that
regardless what authentication scheme is in use, an implementation may or
may not have some association between authentication "userId" and an
initiator access control list consisting of InitiatorNames.  So even if an
initiator is "authenticated", this InitiatorName may not be allowed access
to this target?  The earlier list discussion seemed to indicate "userId" is
separate from "InitiatorName"

For instance, IPSec authenticates based on IP address.  But there is no
requirement that there be a one-one association between an IP address and an
InitiatorName, so while the IP address may authenticate, the InitiatorName
may not be allowed access to the target.  

Perhaps on a connection joining a session, it is enough that the connection
knows the correct ISID, TSID?  But I am thinking that requiring the correct
InitiatorName is a small price to pay for an added check.  ISID=1, TSID=1 is
easy to "guess", but correct InitiatorName is not.

Please correct me if you see a flaw in my thinking...

Marjorie  
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, October 08, 2001 2:10 PM
To: ips@ece.cmu.edu
Subject: RE: iscsi - InitiatorName key during login



You are the naming team so you must be right!  The current authentication
schemes do not make specific use of the InitiatorName but some
authentication has to be used. What makes InitiaatorName needed that you did
consider earlier?

Julo


John Hufferd@IBMUS
08-10-01 22:36

       To:        Julian Satran/Haifa/IBM@IBMIL@IBMDE, "KRUEGER,MARJORIE
(HP-Roseville,ex1)" <marjorie_krueger@hp.com>, andy@windriver.com]
       cc:        ips@ece.cmu.edu
       From:        John Hufferd/San Jose/IBM@IBMUS
       Subject:        RE: iscsi - InitiatorName key during loginLink
 






Marjorie is correct.  Without the Initiator Name on all Logins  a Secondary
Connection can spoof its way in.  The appendix needs to be corrected.

.
.
.
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

Sent by:        owner-ips@ece.cmu.edu
To:        ips@ece.cmu.edu
cc:        
Subject:        RE: iscsi - InitiatorName key during login



I would think InitiatorName is required on the first login PDU of every
connection - InitiatorName is required for target authentication of the
initiator, and that happens each time a connection joins the session.  To
behave otherwise seems an opportunity for identity spoofing?
In any case, this needs to be clarified in the next revision...

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: andy currid [mailto:andy@windriver.com]
> Sent: Monday, October 08, 2001 9:34 AM
> To: ips@ece.cmu.edu
> Subject: iscsi - InitiatorName key during login
>
>
>
> iSCSI version 8 is unclear as to whether InitiatorName is required
> in the first login PDU of every login in a session, or just the
> leading login.
>
> Chapter 5, Login Phase, states -
>
>  "The login phase sequence of commands and responses proceeds
> as follows:
>
>    - login initial request
>    - login partial response (optional)
>    - more login requests and responses (optional)
>    - login final-response (mandatory)
>
>   The initial login request MUST include the InitiatorName and
>   SessionType key=value pairs."
>
> Taken in the context, this wording implies that for any login, the
> first login PDU must contain the InitiatorName key.
>
> Appendix D.13, InitiatorName, states that InitiatorName is Leading
> Only and that "this key MUST be provided by the initiator of the TCP
> connection to the remote endpoint before the end of the login phase".
>
> This wording implies that InitiatorName is supplied in the leading
> login only, and need not necessrily appear in the first login PDU
> of the leading login.
>
> So which is correct?
>
> It seems to me that requiring that InitiatorName be present in the
> first PDU of the leading login is a must, to allow targets to verify
> up front whether or not they wish to proceed further with this
> initiator. I don't think there's much incremental benefit to having
> InitiatorName appear in the first login PDU of every login.
>
> Andy
> --
> Andy Currid                                       andy@windriver.com
> Server Products Group                       http://www.windriver.com
> Wind River Networks                         Phone : (1) 510 749 2191
> 500 Wind River Way, Alameda, CA 94501       Fax   : (1) 510 749 2560
>


--=_alternative 000D2218C2256AE0_=-- From owner-ips@ece.cmu.edu Tue Oct 9 03:42: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 DAA25744 for ; Tue, 9 Oct 2001 03:42:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f996tQu06116 for ips-outgoing; Tue, 9 Oct 2001 02:55:26 -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 f996tPl06112 for ; Tue, 9 Oct 2001 02:55:25 -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 7BDDC22AC for ; Tue, 9 Oct 2001 00:55:24 -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 2649E2F1 for ; Tue, 9 Oct 2001 00:55:24 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id XAA13951 for ips@ece.cmu.edu; Mon, 8 Oct 2001 23:54:23 -0700 (PDT) From: Dave Sheehy Message-Id: <200110090654.XAA13951@acropora.rose.agilent.com> Subject: iscsi: 08 Comment, framing To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Mon, 08 Oct 2001 23:54:22 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Since the following is the consensus of the framing team: > iSCSI, with minor modifications since the presentation at the IETF: > > > The Sender: > - MUST support no framing > - MUST support at least one framing solution > - MUST use the framing specified by the receiver, > if it supports that framing mode and ... > > First, a quick summary of the issues: > - Deploying iSCSI sender can be done: > - on top of an unmodified TCP stack with: > o No framing > o Marker based framing > - on top of a modified TCP stack can implement > PDU-alignment. > - The receiver trade-offs are: > o No framing - large receive reassembly buffer > (higher cost solution) > o Marker framing - receive reassembly buffer is reduced > to an eddy buffer, but requires modifications to > > TCP receive stack (medium cost solution) > o PDU-alignment - receive reassembly buffer can be > reduced > even further, but requires modifications to TCP > receive stack (lowest cost solution and enables > eventual deployment of a viable chunking protocol). > - The cost of implementing markers on unmodified TCP stacks > o sender cost is acceptable, assuming a gather list is > reasonably implemented. > o receiver cost is unacceptable > Initial implementations for initiator appear to be in two camps: > - Unmodified TCP software stacks > - Embedded TCP offload in the NIC (essentially TCP > is hidden from the host SCSI stack) > > Initial implementations for the target appear to be in two camps: > - Optimized NICs which will support framing - probably both > framing modes. Because both modes > require modifications to the receive TCP stack and > PDU-alignment is viewed as straightforward, it is > assumed that most implementations will implement > both framing solutions to allow them to transfer > data optimally with either unmodified send TCP stacks > or PDU-alignment send TCP stacks. > - Unmodified TCP software stacks > > It is primarily a receiver cost issue that motivates the framing > discussion. The primary sender issue is what, if any, optimizations can > be done for unmodified TCP send stacks? Note however, that the proposed > iSCSI requirements are not target or initiator oriented - they are > sender and receiver oriented. The receiver cost issue applies to either > a target or initiator - and they each have very different cost > trade-offs. > > Thus the best solution is to allow the receive side to control their > destiny - and require the sender to obey the receiver (within limits). > If this approach were taken, the sender would have to implement all > three framing options. Unfortunately, a highly desirable design goal is > to allow the sender (either the target or the initiator) to run on an > unmodified TCP stack. Thus the compromise in terms of sender > functionality. The iSCSI 08 draft Appendix C MUST be amended, from, "The use of markers is negotiable. The initiator and target MAY indicate their readiness to receive and/or send markers during login separately for each connection. The default is NO. In certain environments a sender not willing to supply markers to a receiver willing to accept markers MAY suffer from a considerable performance degradation." to: "The use of markers is negotiable. The initiator and target MUST indicate their readiness to receive and/or send markers during login separately for each connection. The default is NO. In certain environments a sender not willing to supply markers to a receiver willing to accept markers MAY suffer from a considerable performance degradation." and in the next paragraph: "If a receiver indicates that it desires a marker, the sender SHOULD agree (during negotiation) and provide the marker at the desired interval." MUST be changed to: "If a receiver indicates that it desires a marker, the sender MUST agree (during negotiation) and provide the marker at the desired interval." Dave Sheehy From owner-ips@ece.cmu.edu Tue Oct 9 03:44: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 DAA25757 for ; Tue, 9 Oct 2001 03:44:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f997I7X07026 for ips-outgoing; Tue, 9 Oct 2001 03:18:07 -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 f997I6l07022 for ; Tue, 9 Oct 2001 03:18:06 -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 AA07F2A3A for ; Tue, 9 Oct 2001 01:18:05 -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 3FC872F1 for ; Tue, 9 Oct 2001 01:18:05 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id AAA14039 for ips@ece.cmu.edu; Tue, 9 Oct 2001 00:17:04 -0700 (PDT) From: Dave Sheehy Message-Id: <200110090717.AAA14039@acropora.rose.agilent.com> Subject: 08 Comment To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Tue, 09 Oct 2001 0:17:03 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk For, 3.16.1 > 0-Data/R2T SNACK - requesting retransmission of a Data-In or R2T PDU In the case of a bidirectionalble command, how does one interpret this field? Is it for data or R2T? Dave From owner-ips@ece.cmu.edu Tue Oct 9 08:32: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 IAA29643 for ; Tue, 9 Oct 2001 08:32:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99BcTp28309 for ips-outgoing; Tue, 9 Oct 2001 07:38:29 -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 f99Atil26875 for ; Tue, 9 Oct 2001 06:55:59 -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 GAA26898; Tue, 9 Oct 2001 06:55:39 -0400 (EDT) Message-Id: <200110091055.GAA26898@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-fcencapsulation-03.txt Date: Tue, 09 Oct 2001 06:55:39 -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 : FC Frame Encapsulation Author(s) : R. Weber, M. Rajagopal, F. Travostino, V. Chau, M. O'Donnell, C. Monia, M. Merhar Filename : draft-ietf-ips-fcencapsulation-03.txt Pages : 15 Date : 08-Oct-01 This is the ips (IP Storage) working group draft describing the common encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates Fibre Channel (FC) frames. This draft describes a frame header containing information mandated for encapsulating, transmitting, de-encapsulating, and calculating the transit times of FC frames. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-fcencapsulation-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-fcencapsulation-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-fcencapsulation-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011008131014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-fcencapsulation-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-fcencapsulation-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011008131014.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Oct 9 10: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 KAA03950 for ; Tue, 9 Oct 2001 10:11:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99DPxU03118 for ips-outgoing; Tue, 9 Oct 2001 09:25: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 f99DPtl03103 for ; Tue, 9 Oct 2001 09:25: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 PAA12300 for ; Tue, 9 Oct 2001 15:25: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.97.1) with ESMTP id f99DPht175974 for ; Tue, 9 Oct 2001 15:25:43 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Rewording of 3.19.1 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Oct 2001 16:25:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 16:25:43, Serialize complete at 09/10/2001 16:25:43 Content-Type: multipart/alternative; boundary="=_alternative 003A85A2C2256AE0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003A85A2C2256AE0_= Content-Type: text/plain; charset="us-ascii" Thanks - Will do. Julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" 08-10-01 12:38 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL cc: Subject: Rewording of 3.19.1 Section 3.19.1 does not make sense. The functionality is correct but is just needs re-wording to: Whenever the NOP-In is sent as a "ping" to an initiator (not as a response to a NOP-Out) the StatSN field will contain as usual the next StatSN but StatSN for this connection is not advanced. Cheers Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com --=_alternative 003A85A2C2256AE0_= Content-Type: text/html; charset="us-ascii"
Thanks - Will do. Julo


"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>

08-10-01 12:38
Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"

       
        To:        ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        Rewording of 3.19.1

       


Section 3.19.1 does not make sense.  The functionality is correct but is
just needs re-wording to:

       Whenever the NOP-In is sent as a "ping" to an initiator (not as
       a response to a NOP-Out) the StatSN field will contain as usual
       the next StatSN but StatSN for this connection is not advanced.

Cheers

Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: matthewb@bri.hp.com

--=_alternative 003A85A2C2256AE0_=-- From owner-ips@ece.cmu.edu Tue Oct 9 10:11: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 KAA03996 for ; Tue, 9 Oct 2001 10:11:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99DQ8703133 for ips-outgoing; Tue, 9 Oct 2001 09:26:08 -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 f99DPul03106 for ; Tue, 9 Oct 2001 09:25: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 PAA91008 for ; Tue, 9 Oct 2001 15:25: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 f99DPit192260 for ; Tue, 9 Oct 2001 15:25:45 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Vendor specific data in Reject PDU. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Oct 2001 16:25:43 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 16:25:44, Serialize complete at 09/10/2001 16:25:44 Content-Type: multipart/alternative; boundary="=_alternative 003D3AE8C2256AE0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003D3AE8C2256AE0_= Content-Type: text/plain; charset="us-ascii" OK If there is no violent opposition it will look like: 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| 0x3f |1| Reserved | Reason | | +---------------+---------------+---------------+---------------+ 4| Reserved | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8/ Reserved / +/ / +---------------+---------------+---------------+---------------+ 24| StatSN | +---------------+---------------+---------------+---------------+ 28| ExpCmdSN | +---------------+---------------+---------------+---------------+ 32| MaxCmdSN | +---------------+---------------+---------------+---------------+ 36| DataSN or Reserved | +---------------+---------------+---------------+---------------+ 40| Reserved | +---------------+---------------+---------------+---------------+ 44| Reserved | +---------------+---------------+---------------+---------------+ 48| Digest (if any) | +---------------+---------------+---------------+---------------+ xx/ Complete Header of Bad PDU / +/ / +---------------+---------------+---------------+---------------+ yy/Vendor specific data (if any) / / / +---------------+---------------+---------------+---------------+ zz Regards, Julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" 08-10-01 12:57 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'ips@ece.cmu.edu'" , Julian Satran/Haifa/IBM@IBMIL cc: Subject: Vendor specific data in Reject PDU. The SCSI Response PDU allows Vendor Specific data (3.4.6). Can this be extended to the Reject PDU after the "Complete Header of Bad PDU"?. This will help diagnosing errors. Cheers Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com --=_alternative 003D3AE8C2256AE0_= Content-Type: text/html; charset="us-ascii"
OK

If there is no violent opposition it will look like:

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| 0x3f      |1| Reserved    | Reason        |               |
  +---------------+---------------+---------------+---------------+
 4| Reserved      | DataSegmentLength                             |
  +---------------+---------------+---------------+---------------+
 8/ Reserved                                                      /
 +/                                                               /
  +---------------+---------------+---------------+---------------+
24| StatSN                                                        |
  +---------------+---------------+---------------+---------------+
28| ExpCmdSN                                                      |
  +---------------+---------------+---------------+---------------+
32| MaxCmdSN                                                      |
  +---------------+---------------+---------------+---------------+
36| DataSN or Reserved                                            |
  +---------------+---------------+---------------+---------------+
40| Reserved                                                      |
  +---------------+---------------+---------------+---------------+
44| Reserved                                                      |
  +---------------+---------------+---------------+---------------+
48| Digest (if any)                                               |
  +---------------+---------------+---------------+---------------+
xx/ Complete Header of Bad PDU                                    /
 +/                                                               /
  +---------------+---------------+---------------+---------------+
yy/Vendor specific data (if any)                                  /
  /                                                               /
  +---------------+---------------+---------------+---------------+
zz

Regards,
Julo


"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>

08-10-01 12:57
Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"

       
        To:        "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        Vendor specific data in Reject PDU.

       


The SCSI Response PDU allows Vendor Specific data (3.4.6).  Can this be
extended to the Reject PDU after the "Complete Header of Bad PDU"?.  This
will help diagnosing errors.

Cheers

Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: matthewb@bri.hp.com

--=_alternative 003D3AE8C2256AE0_=-- From owner-ips@ece.cmu.edu Tue Oct 9 10:15: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 KAA04123 for ; Tue, 9 Oct 2001 10:15:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99DQ0E03119 for ips-outgoing; Tue, 9 Oct 2001 09:26:00 -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 f99DPul03105 for ; Tue, 9 Oct 2001 09:25: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 PAA32472 for ; Tue, 9 Oct 2001 15:25: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 f99DPit265570 for ; Tue, 9 Oct 2001 15:25:44 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI variable DataPDULength X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Oct 2001 16:25:42 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 16:25:44, Serialize complete at 09/10/2001 16:25:44 Content-Type: multipart/alternative; boundary="=_alternative 003C98ACC2256AE0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003C98ACC2256AE0_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, We will accommodate variable DataPDULength (and different in the two directions) between connections and during connection life. The change will require a stricter behavior on task reassign and recovery to a connection with lower PDUlength - SACK if any will have to be issued with "send me all" (run length 0) and on reassign we will have to give (probably) the buffer offset of the last received data-piece. Nothing else seems to be affected. We will send out the text of the changes soon. Julo --=_alternative 003C98ACC2256AE0_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

We will accommodate variable DataPDULength (and different in the two directions) between connections and during connection life.
The change will require a stricter behavior on task reassign  and recovery to a connection with lower PDUlength - SACK if any will have to be issued with "send me all" (run length 0) and on reassign we will have to give (probably) the buffer offset
of the last received data-piece. Nothing else seems to be affected.

We will send out the text of the changes soon.

Julo --=_alternative 003C98ACC2256AE0_=-- From owner-ips@ece.cmu.edu Tue Oct 9 10:23: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 KAA04270 for ; Tue, 9 Oct 2001 10:23:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99DPuf03104 for ips-outgoing; Tue, 9 Oct 2001 09:25: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 f99DPql03099 for ; Tue, 9 Oct 2001 09:25:53 -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 PAA101786 for ; Tue, 9 Oct 2001 15:25: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 f99DPgt210952 for ; Tue, 9 Oct 2001 15:25:42 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Addition of CmdSN in Data-out PDU X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Oct 2001 16:25:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 16:25:42, Serialize complete at 09/10/2001 16:25:42 Content-Type: multipart/alternative; boundary="=_alternative 003A1708C2256AE0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003A1708C2256AE0_= Content-Type: text/plain; charset="us-ascii" Matthew, As a basic rule we tried to avoid having fields that have to be checked for consistency by the reciver whenever we could. Can you be more explicit and help convince us and many others that we should make an exception here. Regards, Julo "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" 08-10-01 12:30 Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL cc: Subject: Addition of CmdSN in Data-out PDU Please can the CmdSN be added to the Data-out PDU to improve implementations when receiving unsolicited Data-out PDUs: Currently, implementations have to search the command queue list for the associated command using the ITT as the search criteria. For solicited Data-out PDUs this is not an issue as they contain the Target Task Tag. However, for unsolicated Data PDUs (Target Task Tag = 0xFFFFFFFF) the locating of the associated command can be greatly enhanced by adding the Associated CmdSN to Data-out PDU. Cheers Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com --=_alternative 003A1708C2256AE0_= Content-Type: text/html; charset="us-ascii"
Matthew,

As a basic rule we tried to avoid having fields that have to be checked for consistency by the reciver whenever we could.
Can you be more explicit and help convince us and many others that we should make an exception here.

Regards,
Julo


"BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>

08-10-01 12:30
Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)"

       
        To:        ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL
        cc:        
        Subject:        Addition of CmdSN in Data-out PDU

       


Please can the CmdSN be added to the Data-out PDU to improve implementations
when receiving unsolicited Data-out PDUs:

Currently, implementations have to search the command queue list for the
associated command using the ITT as the search criteria.  For solicited
Data-out PDUs this is not an issue as they contain the Target Task Tag.
However, for unsolicated Data PDUs (Target Task Tag = 0xFFFFFFFF) the
locating of the associated command can be greatly enhanced by adding the
Associated CmdSN to Data-out PDU.

Cheers

Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: matthewb@bri.hp.com

--=_alternative 003A1708C2256AE0_=-- From owner-ips@ece.cmu.edu Tue Oct 9 11:20: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 LAA05843 for ; Tue, 9 Oct 2001 11:20:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99EfnJ07751 for ips-outgoing; Tue, 9 Oct 2001 10:41: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 f99Efml07743 for ; Tue, 9 Oct 2001 10:41:48 -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 QAA42432 for ; Tue, 9 Oct 2001 16:41: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 f99Efat238916 for ; Tue, 9 Oct 2001 16:41:36 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi: discovery session - logout X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Oct 2001 16:41:34 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 17:41:36, Serialize complete at 09/10/2001 17:41:36 Content-Type: multipart/alternative; boundary="=_alternative 0050C1EC42256AE0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0050C1EC42256AE0_= Content-Type: text/plain; charset="us-ascii" I am not sure that you want this. You may just close the connections. The idea was that discovery may be implemented by a gateway that has not many other things. But we can add Logout if many more on the list want it (just to clean the SSID records). Julo andy currid Sent by: owner-ips@ece.cmu.edu 08-10-01 18:01 Please respond to andy currid To: ips@ece.cmu.edu cc: Subject: iscsi: discovery session - logout iSCSI version 8, sections 2.4 and and Appendix D.31, states that the only command accepted in full feature phase of a discovery session is a Text Request with the SendTargets key. Shouldn't a discovery session also accept a Logout command? Andy -- Andy Currid andy@windriver.com Server Products Group http://www.windriver.com Wind River Networks Phone : (1) 510 749 2191 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 --=_alternative 0050C1EC42256AE0_= Content-Type: text/html; charset="us-ascii"
I am not sure that you want this.
You may just close the connections.
The idea was that discovery may be implemented by a gateway that has not many other things.

But we can add Logout if many more on the list want it (just to clean the SSID records).

Julo



andy currid <andy@windriver.com>
Sent by: owner-ips@ece.cmu.edu

08-10-01 18:01
Please respond to andy currid

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iscsi: discovery session - logout

       



iSCSI version 8, sections 2.4 and and Appendix D.31, states that
the only command accepted in full feature phase of a discovery
session is a Text Request with the SendTargets key.

Shouldn't a discovery session also accept a Logout command?

Andy
--
Andy Currid                                       andy@windriver.com
Server Products Group                       http://www.windriver.com
Wind River Networks                         Phone : (1) 510 749 2191
500 Wind River Way, Alameda, CA 94501       Fax   : (1) 510 749 2560

--=_alternative 0050C1EC42256AE0_=-- From owner-ips@ece.cmu.edu Tue Oct 9 11:21: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 LAA05857 for ; Tue, 9 Oct 2001 11:21:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99EQaT06721 for ips-outgoing; Tue, 9 Oct 2001 10:26:36 -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 f99EQZl06717 for ; Tue, 9 Oct 2001 10:26:35 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id 08ECE1F6E9; Tue, 9 Oct 2001 10:24:21 -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 9BB6B1F513; Tue, 9 Oct 2001 10:26:27 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id <4MRJL8NA>; Tue, 9 Oct 2001 10:26:27 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF1A3@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Julian Satran'" Cc: ips@ece.cmu.edu Subject: RE: iscsi - InitiatorName key during login Date: Tue, 9 Oct 2001 10:26:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C150CE.5FA63E20" 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_01C150CE.5FA63E20 Content-Type: text/plain; charset="iso-8859-1" An example to support why InitiatorName is required on the leading login PDU of any connection - Suppose there are two Initiator Nodes on a system (not preferred, but not prohibited - perhaps these are two test implementations ;-) These two INs use the same IP address Both have separate sessions w/ ISID/TSID = 1/1 (possible in the current model since they are two separate initiators). The only way for the target to differentiate "which session" an incoming connection wants to join is "InitiatorName" as everything else is legitimately the same. Marjorie -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, October 08, 2001 9:01 PM To: KRUEGER,MARJORIE (HP-Roseville,ex1) Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu Subject: RE: iscsi - InitiatorName key during login Marjorie, I am not an expert in names :-) It is up to your team to tell me what to do. I can object (as any list member) but I do not have any strong belief on this. IMHO it is an overkill to have it on any connection since this requires the target to check it against SSID but that is only an opinion (and I have been know not to agree with my own opinions sometime). Julo "KRUEGER,MARJORIE (HP-Roseville,ex1)" Sent by: owner-ips@ece.cmu.edu 09-10-01 00:14 Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu cc: Subject: RE: iscsi - InitiatorName key during login In any implementation, there may be a separation between authentication and authorization. I admit insufficient data WRT iSCSI security draft, but I am assuming that regardless what authentication scheme is in use, an implementation may or may not have some association between authentication "userId" and an initiator access control list consisting of InitiatorNames. So even if an initiator is "authenticated", this InitiatorName may not be allowed access to this target? The earlier list discussion seemed to indicate "userId" is separate from "InitiatorName" For instance, IPSec authenticates based on IP address. But there is no requirement that there be a one-one association between an IP address and an InitiatorName, so while the IP address may authenticate, the InitiatorName may not be allowed access to the target. Perhaps on a connection joining a session, it is enough that the connection knows the correct ISID, TSID? But I am thinking that requiring the correct InitiatorName is a small price to pay for an added check. ISID=1, TSID=1 is easy to "guess", but correct InitiatorName is not. Please correct me if you see a flaw in my thinking... Marjorie -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Monday, October 08, 2001 2:10 PM To: ips@ece.cmu.edu Subject: RE: iscsi - InitiatorName key during login You are the naming team so you must be right! The current authentication schemes do not make specific use of the InitiatorName but some authentication has to be used. What makes InitiaatorName needed that you did consider earlier? Julo John Hufferd@IBMUS 08-10-01 22:36 To: Julian Satran/Haifa/IBM@IBMIL@IBMDE, "KRUEGER,MARJORIE (HP-Roseville,ex1)" , andy@windriver.com] cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: RE: iscsi - InitiatorName key during loginLink Marjorie is correct. Without the Initiator Name on all Logins a Secondary Connection can spoof its way in. The appendix needs to be corrected. . . . 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 Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: RE: iscsi - InitiatorName key during login I would think InitiatorName is required on the first login PDU of every connection - InitiatorName is required for target authentication of the initiator, and that happens each time a connection joins the session. To behave otherwise seems an opportunity for identity spoofing? In any case, this needs to be clarified in the next revision... 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: andy currid [mailto:andy@windriver.com] > Sent: Monday, October 08, 2001 9:34 AM > To: ips@ece.cmu.edu > Subject: iscsi - InitiatorName key during login > > > > iSCSI version 8 is unclear as to whether InitiatorName is required > in the first login PDU of every login in a session, or just the > leading login. > > Chapter 5, Login Phase, states - > > "The login phase sequence of commands and responses proceeds > as follows: > > - login initial request > - login partial response (optional) > - more login requests and responses (optional) > - login final-response (mandatory) > > The initial login request MUST include the InitiatorName and > SessionType key=value pairs." > > Taken in the context, this wording implies that for any login, the > first login PDU must contain the InitiatorName key. > > Appendix D.13, InitiatorName, states that InitiatorName is Leading > Only and that "this key MUST be provided by the initiator of the TCP > connection to the remote endpoint before the end of the login phase". > > This wording implies that InitiatorName is supplied in the leading > login only, and need not necessrily appear in the first login PDU > of the leading login. > > So which is correct? > > It seems to me that requiring that InitiatorName be present in the > first PDU of the leading login is a must, to allow targets to verify > up front whether or not they wish to proceed further with this > initiator. I don't think there's much incremental benefit to having > InitiatorName appear in the first login PDU of every login. > > Andy > -- > Andy Currid andy@windriver.com > Server Products Group http://www.windriver.com > Wind River Networks Phone : (1) 510 749 2191 > 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 > ------_=_NextPart_001_01C150CE.5FA63E20 Content-Type: text/html; charset="iso-8859-1"
An example to support why InitiatorName is required on the leading login PDU of any connection -
 
Suppose there are two Initiator Nodes on a system (not preferred, but not prohibited - perhaps these are two test implementations ;-)
These two INs use the same IP address
Both have separate sessions w/ ISID/TSID = 1/1 (possible in the current model since they are two separate initiators).
 
The only way for the target to differentiate "which session" an incoming connection wants to join is "InitiatorName" as everything else is legitimately the same.

Marjorie

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, October 08, 2001 9:01 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
Subject: RE: iscsi - InitiatorName key during login


Marjorie,

I am not an expert in names :-)
It is up to your team to tell me what to do.  I can object (as any list member) but I do not have any strong belief on this.
IMHO it is an overkill to have it on any connection since this requires the target to check it against SSID but that
is only an opinion (and I have been know not to agree with my own opinions sometime).

Julo


"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
Sent by: owner-ips@ece.cmu.edu

09-10-01 00:14
Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"

       
        To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        cc:        
        Subject:        RE: iscsi - InitiatorName key during login

       


In any implementation, there may be a separation between authentication and
authorization.

I admit insufficient data WRT iSCSI security draft, but I am assuming that
regardless what authentication scheme is in use, an implementation may or
may not have some association between authentication "userId" and an
initiator access control list consisting of InitiatorNames.  So even if an
initiator is "authenticated", this InitiatorName may not be allowed access
to this target?  The earlier list discussion seemed to indicate "userId" is
separate from "InitiatorName"

For instance, IPSec authenticates based on IP address.  But there is no
requirement that there be a one-one association between an IP address and an
InitiatorName, so while the IP address may authenticate, the InitiatorName
may not be allowed access to the target.  

Perhaps on a connection joining a session, it is enough that the connection
knows the correct ISID, TSID?  But I am thinking that requiring the correct
InitiatorName is a small price to pay for an added check.  ISID=1, TSID=1 is
easy to "guess", but correct InitiatorName is not.

Please correct me if you see a flaw in my thinking...

Marjorie  
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Monday, October 08, 2001 2:10 PM
To: ips@ece.cmu.edu
Subject: RE: iscsi - InitiatorName key during login



You are the naming team so you must be right!  The current authentication
schemes do not make specific use of the InitiatorName but some
authentication has to be used. What makes InitiaatorName needed that you did
consider earlier?

Julo


John Hufferd@IBMUS
08-10-01 22:36

       To:        Julian Satran/Haifa/IBM@IBMIL@IBMDE, "KRUEGER,MARJORIE
(HP-Roseville,ex1)" <marjorie_krueger@hp.com>, andy@windriver.com]
       cc:        ips@ece.cmu.edu
       From:        John Hufferd/San Jose/IBM@IBMUS
       Subject:        RE: iscsi - InitiatorName key during loginLink
 






Marjorie is correct.  Without the Initiator Name on all Logins  a Secondary
Connection can spoof its way in.  The appendix needs to be corrected.

.
.
.
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

Sent by:        owner-ips@ece.cmu.edu
To:        ips@ece.cmu.edu
cc:        
Subject:        RE: iscsi - InitiatorName key during login



I would think InitiatorName is required on the first login PDU of every
connection - InitiatorName is required for target authentication of the
initiator, and that happens each time a connection joins the session.  To
behave otherwise seems an opportunity for identity spoofing?

In any case, this needs to be clarified in the next revision...

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: andy currid [mailto:andy@windriver.com]
> Sent: Monday, October 08, 2001 9:34 AM
> To: ips@ece.cmu.edu
> Subject: iscsi - InitiatorName key during login
>
>
>
> iSCSI version 8 is unclear as to whether InitiatorName is required
> in the first login PDU of every login in a session, or just the
> leading login.
>
> Chapter 5, Login Phase, states -
>
>  "The login phase sequence of commands and responses proceeds
> as follows:
>
>    - login initial request
>    - login partial response (optional)
>    - more login requests and responses (optional)
>    - login final-response (mandatory)
>
>   The initial login request MUST include the InitiatorName and
>   SessionType key=value pairs."
>
> Taken in the context, this wording implies that for any login, the
> first login PDU must contain the InitiatorName key.
>
> Appendix D.13, InitiatorName, states that InitiatorName is Leading
> Only and that "this key MUST be provided by the initiator of the TCP
> connection to the remote endpoint before the end of the login phase".
>
> This wording implies that InitiatorName is supplied in the leading
> login only, and need not necessrily appear in the first login PDU
> of the leading login.
>
> So which is correct?
>
> It seems to me that requiring that InitiatorName be present in the
> first PDU of the leading login is a must, to allow targets to verify
> up front whether or not they wish to proceed further with this
> initiator. I don't think there's much incremental benefit to having
> InitiatorName appear in the first login PDU of every login.
>
> Andy
> --
> Andy Currid                                       andy@windriver.com
> Server Products Group                       http://www.windriver.com
> Wind River Networks                         Phone : (1) 510 749 2191
> 500 Wind River Way, Alameda, CA 94501       Fax   : (1) 510 749 2560
>


------_=_NextPart_001_01C150CE.5FA63E20-- From owner-ips@ece.cmu.edu Tue Oct 9 12:31: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 MAA07291 for ; Tue, 9 Oct 2001 12:31:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99Fm6c12046 for ips-outgoing; Tue, 9 Oct 2001 11:48:06 -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 f99Fm5l12041 for ; Tue, 9 Oct 2001 11:48:05 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 576981F7B6 for ; Tue, 9 Oct 2001 08:47: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 IAA05710 for ; Tue, 9 Oct 2001 08:47:54 -0700 (PDT) Message-ID: <3BC31DE0.D5253DF6@cup.hp.com> Date: Tue, 09 Oct 2001 08:55:12 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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: discovery session - logout 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 agree that a discovery session type should be capable of processing a logout command. This keeps the initiator's close_session() code the same for normal & discovery sessions. No need to special case the handling of discovery sessions. - Santosh Julian Satran wrote: > > I am not sure that you want this. > You may just close the connections. > The idea was that discovery may be implemented by a gateway that has > not many other things. > > But we can add Logout if many more on the list want it (just to clean > the SSID records). > > Julo > > andy currid > To: ips@ece.cmu.edu > Sent by: owner-ips@ece.cmu.edu cc: > Subject: iscsi: > 08-10-01 18:01 discovery session - logout > Please respond to andy currid > > > iSCSI version 8, sections 2.4 and and Appendix D.31, states that > the only command accepted in full feature phase of a discovery > session is a Text Request with the SendTargets key. > > Shouldn't a discovery session also accept a Logout command? > > Andy > -- > Andy Currid andy@windriver.com > Server Products Group http://www.windriver.com > Wind River Networks Phone : (1) 510 749 2191 > 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 -- ################################## 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 Tue Oct 9 12:33: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 MAA07354 for ; Tue, 9 Oct 2001 12:33:42 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99FgOT11718 for ips-outgoing; Tue, 9 Oct 2001 11:42: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 f99FgLl11712; Tue, 9 Oct 2001 11:42:22 -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 RAA11854; Tue, 9 Oct 2001 17:42:14 +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 f99FgE787642; Tue, 9 Oct 2001 17:42:14 +0200 To: Steve Senum Cc: ietf-ips , owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi - InitiatorName key during login X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Oct 2001 18:42:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 18:42:14, Serialize complete at 09/10/2001 18:42:14 Content-Type: multipart/alternative; boundary="=_alternative 00564F36C2256AE0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00564F36C2256AE0_= Content-Type: text/plain; charset="us-ascii" The current question is if to require it on every connection login not only the leading login. Julo Steve Senum Sent by: owner-ips@ece.cmu.edu 09-10-01 17:23 Please respond to Steve Senum To: ietf-ips cc: Subject: Re: iscsi - InitiatorName key during login I thought it was decided a while back to always require InitiatorName and, if not a discovery session, TargetName on the leading login command. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06266.html Steve Senum --=_alternative 00564F36C2256AE0_= Content-Type: text/html; charset="us-ascii"
The current question is if to require it on every connection login not only the leading login.

Julo


Steve Senum <ssenum@cisco.com>
Sent by: owner-ips@ece.cmu.edu

09-10-01 17:23
Please respond to Steve Senum

       
        To:        ietf-ips <ips@ece.cmu.edu>
        cc:        
        Subject:        Re: iscsi - InitiatorName key during login

       


I thought it was decided a while back to
always require InitiatorName and, if not a discovery
session, TargetName on the leading login command.

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06266.html

Steve Senum

--=_alternative 00564F36C2256AE0_=-- From owner-ips@ece.cmu.edu Tue Oct 9 12:35: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 MAA07398 for ; Tue, 9 Oct 2001 12:35:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99FOEH10504 for ips-outgoing; Tue, 9 Oct 2001 11:24:14 -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 f99FODl10500 for ; Tue, 9 Oct 2001 11:24:13 -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 LAA11791 for ; Tue, 9 Oct 2001 11:24:07 -0400 (EDT) Message-ID: <3BC31674.AFF267CC@cisco.com> Date: Tue, 09 Oct 2001 10:23:32 -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 - InitiatorName key during login References: <6BD67FFB937FD411A04F00D0B74FE87805CCF1A3@xrose06.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 thought it was decided a while back to always require InitiatorName and, if not a discovery session, TargetName on the leading login command. http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06266.html Steve Senum From owner-ips@ece.cmu.edu Tue Oct 9 13:56: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 NAA10627 for ; Tue, 9 Oct 2001 13:56:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99HaPS19780 for ips-outgoing; Tue, 9 Oct 2001 13:36:25 -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 f99HaLl19774; Tue, 9 Oct 2001 13:36:22 -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 TAA82422; Tue, 9 Oct 2001 19:36: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 f99HaF7153484; Tue, 9 Oct 2001 19:36:15 +0200 To: andy currid Cc: ips@ece.cmu.edu, owner-ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi - InitiatorName key during login X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 9 Oct 2001 20:36:12 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 09/10/2001 20:36:15, Serialize complete at 09/10/2001 20:36:15 Content-Type: multipart/alternative; boundary="=_alternative 0060BEC0C2256AE0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0060BEC0C2256AE0_= Content-Type: text/plain; charset="us-ascii" 08 has some contradictory statements. InitiatorName is mandatory on every first login on every connection. Julo andy currid Sent by: owner-ips@ece.cmu.edu 08-10-01 18:34 Please respond to andy currid To: ips@ece.cmu.edu cc: Subject: iscsi - InitiatorName key during login iSCSI version 8 is unclear as to whether InitiatorName is required in the first login PDU of every login in a session, or just the leading login. Chapter 5, Login Phase, states - "The login phase sequence of commands and responses proceeds as follows: - login initial request - login partial response (optional) - more login requests and responses (optional) - login final-response (mandatory) The initial login request MUST include the InitiatorName and SessionType key=value pairs." Taken in the context, this wording implies that for any login, the first login PDU must contain the InitiatorName key. Appendix D.13, InitiatorName, states that InitiatorName is Leading Only and that "this key MUST be provided by the initiator of the TCP connection to the remote endpoint before the end of the login phase". This wording implies that InitiatorName is supplied in the leading login only, and need not necessrily appear in the first login PDU of the leading login. So which is correct? It seems to me that requiring that InitiatorName be present in the first PDU of the leading login is a must, to allow targets to verify up front whether or not they wish to proceed further with this initiator. I don't think there's much incremental benefit to having InitiatorName appear in the first login PDU of every login. Andy -- Andy Currid andy@windriver.com Server Products Group http://www.windriver.com Wind River Networks Phone : (1) 510 749 2191 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 --=_alternative 0060BEC0C2256AE0_= Content-Type: text/html; charset="us-ascii"
08 has some contradictory statements. InitiatorName is mandatory on every first login on every connection.

Julo


andy currid <andy@windriver.com>
Sent by: owner-ips@ece.cmu.edu

08-10-01 18:34
Please respond to andy currid

       
        To:        ips@ece.cmu.edu
        cc:        
        Subject:        iscsi - InitiatorName key during login

       



iSCSI version 8 is unclear as to whether InitiatorName is required
in the first login PDU of every login in a session, or just the
leading login.

Chapter 5, Login Phase, states -

"The login phase sequence of commands and responses proceeds as follows:

  - login initial request
  - login partial response (optional)
  - more login requests and responses (optional)
  - login final-response (mandatory)

 The initial login request MUST include the InitiatorName and
 SessionType key=value pairs."

Taken in the context, this wording implies that for any login, the
first login PDU must contain the InitiatorName key.

Appendix D.13, InitiatorName, states that InitiatorName is Leading
Only and that "this key MUST be provided by the initiator of the TCP
connection to the remote endpoint before the end of the login phase".

This wording implies that InitiatorName is supplied in the leading
login only, and need not necessrily appear in the first login PDU
of the leading login.

So which is correct?

It seems to me that requiring that InitiatorName be present in the
first PDU of the leading login is a must, to allow targets to verify
up front whether or not they wish to proceed further with this
initiator. I don't think there's much incremental benefit to having
InitiatorName appear in the first login PDU of every login.

Andy
--
Andy Currid                                       andy@windriver.com
Server Products Group                       http://www.windriver.com
Wind River Networks                         Phone : (1) 510 749 2191
500 Wind River Way, Alameda, CA 94501       Fax   : (1) 510 749 2560

--=_alternative 0060BEC0C2256AE0_=-- From owner-ips@ece.cmu.edu Tue Oct 9 13: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 NAA10669 for ; Tue, 9 Oct 2001 13:58:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99H1NZ17126 for ips-outgoing; Tue, 9 Oct 2001 13:01:23 -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 f99H1Ll17121 for ; Tue, 9 Oct 2001 13:01:22 -0400 (EDT) Received: from russian.wrs.com (russian [147.11.45.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA29258; Tue, 9 Oct 2001 10:01:04 -0700 (PDT) From: andy currid Received: (from andy@localhost) by russian.wrs.com (8.9.1/8.9.0) id KAA21614; Tue, 9 Oct 2001 10:01:13 -0700 (PDT) Message-Id: <200110091701.KAA21614@russian.wrs.com> Subject: Re: iscsi: discovery session - logout To: Julian_Satran@il.ibm.com (Julian Satran) Date: Tue, 9 Oct 2001 10:01:12 -0700 (PDT) Cc: ips@ece.cmu.edu In-Reply-To: from "Julian Satran" at Oct 09, 2001 04:41:34 PM 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 As a target implementor, I'll certainly handle a discovery session simply having its connection closed, as I do for all sessions. As an initiator implementor, I'd like the option of closing down a discovery session the same way I close down a normal session - with a logout. It makes my code more uniform. The current spec prohibits closure of a discovery session with a logout. I think the wording should be changed to permit use of logout on discovery sessions, without requiring that it be used. That still permits lightweight gateways, etc., to not use logout if needs be. Regards Andy > I am not sure that you want this. > You may just close the connections. > The idea was that discovery may be implemented by a gateway that has not > many other things. > > But we can add Logout if many more on the list want it (just to clean the > SSID records). > > Julo > > > andy currid > Sent by: owner-ips@ece.cmu.edu > 08-10-01 18:01 > Please respond to andy currid > > To: ips@ece.cmu.edu > cc: > Subject: iscsi: discovery session - logout > > iSCSI version 8, sections 2.4 and and Appendix D.31, states that > the only command accepted in full feature phase of a discovery > session is a Text Request with the SendTargets key. > > Shouldn't a discovery session also accept a Logout command? > > Andy -- Andy Currid andy@windriver.com Server Products Group http://www.windriver.com Wind River Networks Phone : (1) 510 749 2191 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 From owner-ips@ece.cmu.edu Tue Oct 9 13:59: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 NAA10697 for ; Tue, 9 Oct 2001 13:59:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99H2BG17176 for ips-outgoing; Tue, 9 Oct 2001 13:02:11 -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 f99H29l17168 for ; Tue, 9 Oct 2001 13:02:09 -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 5D6731372 for ; Tue, 9 Oct 2001 11:02:08 -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 844DA3F0 for ; Tue, 9 Oct 2001 11:02:07 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id KAA14563 for ips@ece.cmu.edu; Tue, 9 Oct 2001 10:01:06 -0700 (PDT) From: Dave Sheehy Message-Id: <200110091701.KAA14563@acropora.rose.agilent.com> Subject: Re: iSCSI: 08 Comment, framing To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Tue, 09 Oct 2001 10:01:05 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk Julo, > We went through this several times. > Once the Framing becomes an RFC (informational) we will adjust the > appendix. I am not at all confident that framing will become an RFC prior to iSCSI being approved. I'd like to get the iSCSI spec changed now to cover that possibility. > Untill then this appendix represents the WG consensus and there no reason > to change that. So, you're saying that the framing team consensus is in conflict with the WG consensus? Dave > > Julo > > > > > > Dave Sheehy > Sent by: owner-ips@ece.cmu.edu > 09-10-01 08:54 > Please respond to Dave Sheehy > > > To: ips@ece.cmu.edu (IETF IP SAN Reflector) > cc: > Subject: iscsi: 08 Comment, framing > > > > Since the following is the consensus of the framing team: > > > iSCSI, with minor modifications since the presentation at the IETF: > > > > > > The Sender: > > - MUST support no framing > > - MUST support at least one framing > solution > > - MUST use the framing specified by the > receiver, > > if it supports that > framing mode > > and ... > > > > > First, a quick summary of the issues: > > - Deploying iSCSI sender can be done: > > - on top of an unmodified TCP stack with: > > o No framing > > o Marker based framing > > - on top of a modified TCP stack can > implement > > PDU-alignment. > > - The receiver trade-offs are: > > o No framing - large receive reassembly > buffer > > (higher cost solution) > > o Marker framing - receive reassembly > buffer is reduced > > to an eddy buffer, but > requires modifications to > > > > TCP receive stack (medium > cost solution) > > o PDU-alignment - receive reassembly > buffer can be > > reduced > > even further, but > requires modifications to TCP > > receive stack (lowest > cost solution and enables > > eventual deployment of a > viable chunking protocol). > > - The cost of implementing markers on unmodified TCP > stacks > > o sender cost is acceptable, assuming a > gather list is > > reasonably implemented. > > o receiver cost is unacceptable > > > Initial implementations for initiator appear to be in two camps: > > - Unmodified TCP software stacks > > - Embedded TCP offload in the NIC (essentially TCP > > is hidden from the host SCSI stack) > > > > Initial implementations for the target appear to be in two camps: > > - Optimized NICs which will support framing - probably > both > > framing modes. Because both modes > > require modifications to the receive TCP > stack and > > PDU-alignment is viewed as > straightforward, it is > > assumed that most implementations will > implement > > both framing solutions to allow them to > transfer > > data optimally with either unmodified > send TCP stacks > > or PDU-alignment send TCP stacks. > > - Unmodified TCP software stacks > > > > It is primarily a receiver cost issue that motivates the framing > > discussion. The primary sender issue is what, if any, optimizations can > > be done for unmodified TCP send stacks? Note however, that the proposed > > iSCSI requirements are not target or initiator oriented - they are > > sender and receiver oriented. The receiver cost issue applies to either > > a target or initiator - and they each have very different cost > > trade-offs. > > > > Thus the best solution is to allow the receive side to control their > > destiny - and require the sender to obey the receiver (within limits). > > If this approach were taken, the sender would have to implement all > > three framing options. Unfortunately, a highly desirable design goal is > > to allow the sender (either the target or the initiator) to run on an > > unmodified TCP stack. Thus the compromise in terms of sender > > functionality. > > The iSCSI 08 draft Appendix C MUST be amended, > > from, > > "The use of markers is negotiable. The initiator and target MAY > indicate their readiness to receive and/or send markers during login > separately for each connection. The default is NO. In certain > environments a sender not willing to supply markers to a receiver > willing to accept markers MAY suffer from a considerable performance > degradation." > > to: > > "The use of markers is negotiable. The initiator and target MUST > indicate their readiness to receive and/or send markers during login > separately for each connection. The default is NO. In certain > environments a sender not willing to supply markers to a receiver > willing to accept markers MAY suffer from a considerable performance > degradation." > > and in the next paragraph: > > "If a receiver indicates that it desires a marker, the > sender SHOULD agree (during negotiation) and provide the marker at > the desired interval." > > MUST be changed to: > > "If a receiver indicates that it desires a marker, the > sender MUST agree (during negotiation) and provide the marker at > the desired interval." > > Dave Sheehy > > > > > --=_alternative 004F567E42256AE0_= > Content-Type: text/html; charset="us-ascii" > > >
Dave, >
>
We went through this several times. >
Once the Framing becomes an RFC (informational) we will adjust the appendix. >
Untill then this appendix represents the WG consensus and there no reason to change that. >
>
Julo >
>
>
>
> > >
> Dave Sheehy <dbs@acropora.rose.agilent.com> >
Sent by: owner-ips@ece.cmu.edu >

09-10-01 08:54 >
Please respond to Dave Sheehy >
>

        >
        To:        ips@ece.cmu.edu (IETF IP SAN Reflector) >
        cc:         >
        Subject:        iscsi: 08 Comment, framing >
>
       
>
>
Since the following is the consensus of the framing team:
>
> > iSCSI, with minor modifications since the presentation at the IETF:
> >
> >
> >                  The Sender:
> >                                   - MUST support no framing
> >                                   - MUST support at least one framing solution
> >                                   - MUST use the framing specified by the receiver,
> >                                                    if it supports that framing mode
>
> and ...
>
> >
> > First, a quick summary of the issues:
> >                  - Deploying iSCSI sender can be done:
> >                                   - on top of an unmodified TCP stack with:
> >                                                    o No framing
> >                                                    o Marker based framing
> >                                   - on top of a modified TCP stack can implement
> >                                                    PDU-alignment.
> >                  - The receiver trade-offs are:
> >                                   o No framing - large receive reassembly buffer
> >                                                    (higher cost solution)
> >                                   o Marker framing - receive reassembly buffer is reduced
> >                                                    to an eddy buffer, but requires modifications to
> >
> >                                                    TCP receive stack (medium cost solution)
> >                                   o PDU-alignment - receive reassembly buffer can be
> > reduced
> >                                                    even further, but requires modifications to TCP
> >                                                    receive stack (lowest cost solution and enables
> >                                                    eventual deployment of a viable chunking protocol).
> >                  - The cost of implementing markers on unmodified TCP stacks
> >                                   o sender cost is acceptable, assuming a gather list is
> >                                                    reasonably implemented.
> >                                   o receiver cost is unacceptable
>
> > Initial implementations for initiator appear to be in two camps:
> >                  - Unmodified TCP software stacks
> >                  - Embedded TCP offload in the NIC (essentially TCP
> >                                   is hidden from the host SCSI stack)
> >
> > Initial implementations for the target appear to be in two camps:
> >                  - Optimized NICs which will support framing - probably both
> >                                   framing modes. Because both modes
> >                                   require modifications to the receive TCP stack and
> >                                   PDU-alignment is viewed as straightforward, it is
> >                                   assumed that most implementations will implement
> >                                   both framing solutions to allow them to transfer
> >                                   data optimally with either unmodified send TCP stacks
> >                                   or PDU-alignment send TCP stacks.
> >                  - Unmodified TCP software stacks
> >
> > It is primarily a receiver cost issue that motivates the framing
> > discussion. The primary sender issue is what, if any, optimizations can
> > be done for unmodified TCP send stacks? Note however, that the proposed
> > iSCSI requirements are not target or initiator oriented - they are
> > sender and receiver oriented. The receiver cost issue applies to either
> > a target or initiator - and they each have very different cost
> > trade-offs.
> >
> > Thus the best solution is to allow the receive side to control their
> > destiny - and require the sender to obey the receiver (within limits).
> > If this approach were taken, the sender would have to implement all
> > three framing options. Unfortunately, a highly desirable design goal is
> > to allow the sender (either the target or the initiator) to run on an
> > unmodified TCP stack. Thus the compromise in terms of sender
> > functionality.
>
> The iSCSI 08 draft Appendix C MUST be amended,
>
> from,
>
> "The use of markers is negotiable. The initiator and target MAY
> indicate their readiness to receive and/or send markers during login
> separately for each connection. The default is NO. In certain
> environments a sender not willing to supply markers to a receiver
> willing to accept markers MAY suffer from a considerable performance >
degradation."
>
> to:
>
> "The use of markers is negotiable. The initiator and target MUST
> indicate their readiness to receive and/or send markers during login
> separately for each connection. The default is NO. In certain
> environments a sender not willing to supply markers to a receiver
> willing to accept markers MAY suffer from a considerable performance
> degradation."
>
> and in the next paragraph:
>
> "If a receiver indicates that it desires a marker, the
> sender SHOULD agree (during negotiation) and provide the marker at
> the desired interval."
>
> MUST be changed to:
>
> "If a receiver indicates that it desires a marker, the
> sender MUST agree (during negotiation) and provide the marker at
> the desired interval."
>
> Dave Sheehy
>
> >
>
> --=_alternative 004F567E42256AE0_=-- > From owner-ips@ece.cmu.edu Tue Oct 9 14:04: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 OAA10843 for ; Tue, 9 Oct 2001 14:04:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99HWXq19454 for ips-outgoing; Tue, 9 Oct 2001 13:32: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 f99HWWl19450 for ; Tue, 9 Oct 2001 13:32:32 -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 NAA00571 for ; Tue, 9 Oct 2001 13:32:26 -0400 (EDT) Message-ID: <3BC33486.EF25F87D@cisco.com> Date: Tue, 09 Oct 2001 12:31:50 -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 - InitiatorName key during login References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry, I was a bit confused on that point. However, I would think all connections would require InitiatorName and TargetName. I would want to run every connection through the same authentication and authorization checks, and I need both names to assure I can do that. Steve Senum Julian Satran wrote: > > The current question is if to require it on every connection login not only > the leading login. > > Julo > > Steve Senum > Sent by: owner-ips@ece.cmu.edu To: ietf-ips > > 09-10-01 17:23 cc: > Please respond to Steve Senum Subject: Re: iscsi - > InitiatorName key during login > > > > I thought it was decided a while back to > always require InitiatorName and, if not a discovery > session, TargetName on the leading login command. > > http://www.pdl.cmu.edu/mailinglists/ips/mail/msg06266.html > > Steve Senum From owner-ips@ece.cmu.edu Tue Oct 9 15: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 PAA11817 for ; Tue, 9 Oct 2001 15:11:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99IQ8M23968 for ips-outgoing; Tue, 9 Oct 2001 14:26:08 -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 f99IQ6l23963 for ; Tue, 9 Oct 2001 14:26:06 -0400 (EDT) Received: from russian.wrs.com (russian [147.11.45.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA08271; Tue, 9 Oct 2001 11:25:50 -0700 (PDT) From: andy currid Received: (from andy@localhost) by russian.wrs.com (8.9.1/8.9.0) id LAA22228; Tue, 9 Oct 2001 11:25:58 -0700 (PDT) Message-Id: <200110091825.LAA22228@russian.wrs.com> Subject: Re: Addition of CmdSN in Data-out PDU To: Julian_Satran@il.ibm.com (Julian Satran) Date: Tue, 9 Oct 2001 11:25:58 -0700 (PDT) Cc: ips@ece.cmu.edu In-Reply-To: from "Julian Satran" at Oct 09, 2001 04:25:40 PM 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 second Matthew's request to have CmdSN present in DataOut PDUs. I'm yet to be convinced of the value of unsolicited DataOut PDUs in iSCSI, but if they're in the spec, they might as well be amenable to efficient handling by targets. When receiving unsolicited DataOut PDUs, a target must currently use the ITT to determine the command with which the DataOut is associated. In the absence of hardware assist such as a CAM, a target implementation must search a list of non-final commands currently queued within the session to match the ITT. When many such commands are queued (which ought to be the case for performant implementations), that search will relatively inefficient, no matter how the search is optimized (binary search, hash table, etc.). Placing CmdSn in DataOut will allow a target to instantly access the queued command with which an unsolicited DataOut is associated, without performing a search. Mapping from a CmdSN into a queue location within the target is almost certainly a constant time operation. I don't see any performance issues with making this change. I don't think it's a big imposition on an initiator to include the associated CmdSN in a DataOut PDU. Do any initiator implementors feel this would be a problem? On the target end, I don't think consistency checking is an issue. In a solicited data out carrying CmdSN, targets would be free to ignore CmdSN and simply use TTT as they do today. There's no obligation to verify CmdSN is consistent with the DataOut's associated command, though such a check is likely to be cheap. In an unsolicited data out, checking CmdSN is likely cheaper than the current check we are forced to do with ITT. Regards Andy > Matthew, > > As a basic rule we tried to avoid having fields that have to be checked > for consistency by the reciver whenever we could. > Can you be more explicit and help convince us and many others that we > should make an exception here. > > Regards, > Julo > > -- > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" > 08-10-01 12:30 > Please respond to "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" > > > To: ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: Addition of CmdSN in Data-out PDU > > > > Please can the CmdSN be added to the Data-out PDU to improve > implementations > when receiving unsolicited Data-out PDUs: > > Currently, implementations have to search the command queue list for the > associated command using the ITT as the search criteria. For solicited > Data-out PDUs this is not an issue as they contain the Target Task Tag. > However, for unsolicated Data PDUs (Target Task Tag = 0xFFFFFFFF) the > locating of the associated command can be greatly enhanced by adding the > Associated CmdSN to Data-out PDU. > > Cheers > > Matthew Burbridge > Senior Development Engineer > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com -- Andy Currid andy@windriver.com Server Products Group http://www.windriver.com Wind River Networks Phone : (1) 510 749 2191 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 From owner-ips@ece.cmu.edu Tue Oct 9 16:17: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 QAA12857 for ; Tue, 9 Oct 2001 16:16:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99JTJf29120 for ips-outgoing; Tue, 9 Oct 2001 15:29:19 -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 f99JTGl29108 for ; Tue, 9 Oct 2001 15:29:17 -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 2F2642D76 for ; Tue, 9 Oct 2001 13:29:16 -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 AE7E3440 for ; Tue, 9 Oct 2001 13:29:15 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id MAA14730 for ips@ece.cmu.edu; Tue, 9 Oct 2001 12:28:15 -0700 (PDT) From: Dave Sheehy Message-Id: <200110091928.MAA14730@acropora.rose.agilent.com> Subject: Re: iscsi: discovery session - logout To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Tue, 09 Oct 2001 12:28:14 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > I agree that a discovery session type should be capable of processing a > logout command. This keeps the initiator's close_session() code the same > for normal & discovery sessions. > No need to special case the handling of discovery sessions. Agreed, I don't see any compelling reason for this special case behavior. Dave > > - Santosh > > > Julian Satran wrote: > > > > I am not sure that you want this. > > You may just close the connections. > > The idea was that discovery may be implemented by a gateway that has > > not many other things. > > > > But we can add Logout if many more on the list want it (just to clean > > the SSID records). > > > > Julo > > > > andy currid > > To: ips@ece.cmu.edu > > Sent by: owner-ips@ece.cmu.edu cc: > > Subject: iscsi: > > 08-10-01 18:01 discovery session - logout > > Please respond to andy currid > > > > > > iSCSI version 8, sections 2.4 and and Appendix D.31, states that > > the only command accepted in full feature phase of a discovery > > session is a Text Request with the SendTargets key. > > > > Shouldn't a discovery session also accept a Logout command? > > > > Andy > > -- > > Andy Currid andy@windriver.com > > Server Products Group http://www.windriver.com > > Wind River Networks Phone : (1) 510 749 2191 > > 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 > > -- > ################################## > 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 Tue Oct 9 16:53: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 QAA13416 for ; Tue, 9 Oct 2001 16:53:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99K6BH02408 for ips-outgoing; Tue, 9 Oct 2001 16:06:11 -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 f99JxYl01769 for ; Tue, 9 Oct 2001 15:59:35 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f99Jx2D24446; Tue, 9 Oct 2001 15:59:02 -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 f99Jx1W24615; Tue, 9 Oct 2001 15:59:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15299.22319.659000.473461@gargle.gargle.HOWL> Date: Tue, 9 Oct 2001 15:59:43 -0400 From: Paul Koning To: andy@windriver.com Cc: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU References: <200110091825.LAA22228@russian.wrs.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 9 October 2001) by andy currid: > > Julian, all > > I second Matthew's request to have CmdSN present in DataOut PDUs. > ... > When receiving unsolicited DataOut PDUs, a target must currently use > the ITT to determine the command with which the DataOut is associated. > In the absence of hardware assist such as a CAM, a target implementation > must search a list of non-final commands currently queued within the > session to match the ITT. When many such commands are queued (which ought > to be the case for performant implementations), that search will relatively > inefficient, no matter how the search is optimized (binary search, hash > table, etc.). I'll add my voice to the set. Andy's arguments make perfect sense. Lookups on unstructured IDs are a pain. Hashing can be fast, but hash table changes typically aren't. The nasty case is a lookup on a set of unstructured IDs that changes very rapidly, which is exactly the case we have here. > Placing CmdSn in DataOut will allow a target to instantly access the > queued command with which an unsolicited DataOut is associated, without > performing a search. Mapping from a CmdSN into a queue location within > the target is almost certainly a constant time operation. Exactly. > I don't see any performance issues with making this change. I don't > think it's a big imposition on an initiator to include the associated > CmdSN in a DataOut PDU. Do any initiator implementors feel this would > be a problem? > > On the target end, I don't think consistency checking is an issue. In a > solicited data out carrying CmdSN, targets would be free to ignore CmdSN > and simply use TTT as they do today. There's no obligation to verify > CmdSN is consistent with the DataOut's associated command, though such > a check is likely to be cheap. Consistency checking could be left out entirely if we wish. That would be my inclination. Or it could be made optional -- or even, if people insist, mandatory. It's very cheap if that's done. The response to an inconsistency should be harsh (terminate the session, for example) because it will only happen if the sender is defective. paul From owner-ips@ece.cmu.edu Tue Oct 9 17:49: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 RAA14125 for ; Tue, 9 Oct 2001 17:49:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99L1Z807145 for ips-outgoing; Tue, 9 Oct 2001 17:01:35 -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 f99L1Yl07140 for ; Tue, 9 Oct 2001 17:01:34 -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 9E6181C8B; Tue, 9 Oct 2001 15:01:33 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 671554EE; Tue, 9 Oct 2001 15:01:33 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Tue, 09 Oct 2001 15:01:32 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Oct 2001 15:01:32 -0600 Message-ID: <1BEBA5E8600DD4119A50009027AF54A0083914C8@axcs04.cos.agilent.com> From: "THALER,PAT (A-Roseville,ex1)" To: Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI: Serial Number Arithmetic Date: Tue, 9 Oct 2001 15:01:30 -0600 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 suggested text: "A large absolute difference between StatSN and ExpStatSN may indicate a failed connection. Initiators undertake recovery actions if the difference is greater than an implementation defined constant that SHALL NOT exceed 2**31-1." is inconsistant with serial number arithmetic. Serial number arithmetic does not define a "difference" operation and is very specific about the operations which are defined. If we wanted to use difference to compare serial numbers, we could define "difference" in terms of the already defined serial number arithmetic operations. For instance, we could say something like the difference between A and B is equal to the value D which satisfies the following: For A < B, A + D = B or For A > B, B + A = D So the difference of A and B is greater than D if A < B and A + D < B or A > B and B + D > A However A < B and A > B are not defined for A and B when the integer value of A equals the integer value of B plus 2**31-1 or vice versa. The comparison may yield either result or it may yield an error. Therefore, this test doesn't work for difference greater than 2**31-1. Note also that there is exactly one value of StatSN for a given value of ExpStatSN that exceeds the distance 2**31-1. Mandating recovery actions to be initiated for only one value out of 2^32 possible values of StatSN doesn't seem useful. The connection could be failed without us ever seeing that particular value. If we want to initiate recovery for large differences between StatSN and ExpStatSN it would make sense to do it for a lower value of difference so that serial number arithmetic would still handle it. The alternative is to delete the text and rely on other tests to initiate recovery. Regards, Pat -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Friday, October 05, 2001 10:11 PM To: ips@ece.cmu.edu Subject: Re: iSCSI: Serial Number Arithmetic Pat - Comments in text - Thanks, Julo _____________________ Julian, The draft says serial number arithmetic as defined in RFC 1982 is to be used for comparisons and arithmetic on CmdSN but but it uses operations which are inconsistant with that statement. 2.2.2.1 (bottom half of page 26) re: the processing for MaxCmdSN and ExpCmdSN - "and with a difference bounded by 2**31-1" should be deleted (3 places). The RFC 1982 Serial Number Arithmetic rules cover the meaning of addition of a positive integer of limited range and comparison (<, > and =) for serial numbers. "Only two operations are defined upon serial numbers, addition of a positive integer of limited range, and comparison with another serial number." The operation difference is not defined for Serial Numbers. +++ will fix - 2**31-1 is implied by serial arithmetic+++ 2.2.2.2 re: "difference is greater than 2**31-1" - The operation difference is not defined for Serial number arithmetic. Even if it was defined as the inverse of addition, addition is only defined for adding a value up to 2**31-1. Is the intent of the statement that it should cover only the value where the results of StatSN > ExpStatSN and StatSN < ExpStatSN are undefined or is the intent that it cover that value plus the values where ExpStat > StatSN? The former doesn't seem useful and the latter seems rather severe. Regards, Pat Thaler ++++ StatSN follows regular mod(2**32) arithmetic. 2**31 is meant to state the limit at which recovery action becomes mandatory Here is a new 2.2.2.2 that perhaps states this clearer+++ 1.1.1.1 Response/Status Numbering and Acknowledging Responses in transit from the target to the initiator are numbered. The StatSN (Status Sequence Number) is used for this purpose. StatSN is a counter maintained per connection. ExpStatSN is used by the initiator to acknowledge status. The status sequence number space is that of 32bit integers and the arithmetic operations are the regular mod(2**32) arithmetic. Status numbering starts with the Login response to the first Login request of the connection. The Login response includes an initial value for status numbering. To enable command recovery the target MAY maintain enough state information to enable data and status recovery after a connection failure. A target can discard all the state information maintained for recovery after the status delivery is acknowledged through ExpStatSN. A large absolute difference between StatSN and ExpStatSN may indicate a failed connection. Initiators undertake recovery actions if the difference is greater than an implementation defined constant that SHALL NOT exceed 2**31-1. Initiators and Targets MUST support the response-numbering scheme. From owner-ips@ece.cmu.edu Tue Oct 9 18:27: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 SAA14416 for ; Tue, 9 Oct 2001 18:27:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99Ljb310617 for ips-outgoing; Tue, 9 Oct 2001 17:45:37 -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 f99LjZl10607 for ; Tue, 9 Oct 2001 17:45:35 -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 XAA147316 for ; Tue, 9 Oct 2001 23:45:27 +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 f99LjR7166404 for ; Tue, 9 Oct 2001 23:45:27 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Addition of CmdSN in Data-out PDU X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 10 Oct 2001 00:45:24 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 10/10/2001 00:45:27, Serialize complete at 10/10/2001 00:45:27 Content-Type: multipart/alternative; boundary="=_alternative 00778F0EC2256AE0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00778F0EC2256AE0_= Content-Type: text/plain; charset="us-ascii" Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it may have large holes and using it in an implementation is as bad as a hashed index. I you want to pursue this please forward a draft showing what the distinct application advantages are to the list. It can include pseudo-code, flowcharts or whatever else you think that you need to convince the list. Julo Paul Koning 09-10-01 21:59 Please respond to Paul Koning To: andy@windriver.com cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU Excerpt of message (sent 9 October 2001) by andy currid: > > Julian, all > > I second Matthew's request to have CmdSN present in DataOut PDUs. > ... > When receiving unsolicited DataOut PDUs, a target must currently use > the ITT to determine the command with which the DataOut is associated. > In the absence of hardware assist such as a CAM, a target implementation > must search a list of non-final commands currently queued within the > session to match the ITT. When many such commands are queued (which ought > to be the case for performant implementations), that search will relatively > inefficient, no matter how the search is optimized (binary search, hash > table, etc.). I'll add my voice to the set. Andy's arguments make perfect sense. Lookups on unstructured IDs are a pain. Hashing can be fast, but hash table changes typically aren't. The nasty case is a lookup on a set of unstructured IDs that changes very rapidly, which is exactly the case we have here. > Placing CmdSn in DataOut will allow a target to instantly access the > queued command with which an unsolicited DataOut is associated, without > performing a search. Mapping from a CmdSN into a queue location within > the target is almost certainly a constant time operation. Exactly. > I don't see any performance issues with making this change. I don't > think it's a big imposition on an initiator to include the associated > CmdSN in a DataOut PDU. Do any initiator implementors feel this would > be a problem? > > On the target end, I don't think consistency checking is an issue. In a > solicited data out carrying CmdSN, targets would be free to ignore CmdSN > and simply use TTT as they do today. There's no obligation to verify > CmdSN is consistent with the DataOut's associated command, though such > a check is likely to be cheap. Consistency checking could be left out entirely if we wish. That would be my inclination. Or it could be made optional -- or even, if people insist, mandatory. It's very cheap if that's done. The response to an inconsistency should be harsh (terminate the session, for example) because it will only happen if the sender is defective. paul --=_alternative 00778F0EC2256AE0_= Content-Type: text/html; charset="us-ascii"
Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it may have large holes and using it in an implementation is as bad as a hashed index.
I you want to pursue this please forward a draft showing what the distinct application advantages are to the list.
It can include pseudo-code, flowcharts or whatever else you think that you need to convince the list.

Julo


Paul Koning <pkoning@jlc.net>

09-10-01 21:59
Please respond to Paul Koning

       
        To:        andy@windriver.com
        cc:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        Subject:        Re: Addition of CmdSN in Data-out PDU

       


Excerpt of message (sent 9 October 2001) by andy currid:
>
> Julian, all
>
> I second Matthew's request to have CmdSN present in DataOut PDUs.
> ...
> When receiving unsolicited DataOut PDUs, a target must currently use
> the ITT to determine the command with which the DataOut is associated.
> In the absence of hardware assist such as a CAM, a target implementation
> must search a list of non-final commands currently queued within the
> session to match the ITT. When many such commands are queued (which ought
> to be the case for performant implementations), that search will relatively
> inefficient, no matter how the search is optimized (binary search, hash
> table, etc.).

I'll add my voice to the set.  Andy's arguments make perfect sense.
Lookups on unstructured IDs are a pain.  Hashing can be fast, but hash
table changes typically aren't.  The nasty case is a lookup on a set
of unstructured IDs that changes very rapidly, which is exactly the
case we have here.

> Placing CmdSn in DataOut will allow a target to instantly access the
> queued command with which an unsolicited DataOut is associated, without
> performing a search. Mapping from a CmdSN into a queue location within
> the target is almost certainly a constant time operation.

Exactly.

> I don't see any performance issues with making this change. I don't
> think it's a big imposition on an initiator to include the associated
> CmdSN in a DataOut PDU. Do any initiator implementors feel this would
> be a problem?
>
> On the target end, I don't think consistency checking is an issue. In a
> solicited data out carrying CmdSN, targets would be free to ignore CmdSN
> and simply use TTT as they do today. There's no obligation to verify
> CmdSN is consistent with the DataOut's associated command, though such
> a check is likely to be cheap.

Consistency checking could be left out entirely if we wish.  That
would be my inclination.  Or it could be made optional -- or even, if
people insist, mandatory.  It's very cheap if that's done.  The
response to an inconsistency should be harsh (terminate the session,
for example) because it will only happen if the sender is defective.

    paul

--=_alternative 00778F0EC2256AE0_=-- From owner-ips@ece.cmu.edu Tue Oct 9 18:28: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 SAA14429 for ; Tue, 9 Oct 2001 18:28:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f99Lwr011619 for ips-outgoing; Tue, 9 Oct 2001 17:58:53 -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 f99Lwol11608 for ; Tue, 9 Oct 2001 17:58: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 XAA26524 for ; Tue, 9 Oct 2001 23:58: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 f99Lwgt169746 for ; Tue, 9 Oct 2001 23:58:42 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi: 08 Comment, framing X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 10 Oct 2001 00:58:39 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 10/10/2001 00:58:42, Serialize complete at 10/10/2001 00:58:42 Content-Type: multipart/alternative; boundary="=_alternative 0078C62CC2256AE0_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0078C62CC2256AE0_= Content-Type: text/plain; charset="us-ascii" Dave, This was the consensus of the framing team - not of the IPS list. It is inappropriate for us to replace a thing that we have and is agreed to something that that is not here yet. As I stated if you want to do it independent of the ULP progress you have to reopen the issue on this list. Regards, Julo Dave Sheehy Sent by: owner-ips@ece.cmu.edu 09-10-01 08:54 Please respond to Dave Sheehy To: ips@ece.cmu.edu (IETF IP SAN Reflector) cc: Subject: iscsi: 08 Comment, framing Since the following is the consensus of the framing team: > iSCSI, with minor modifications since the presentation at the IETF: > > > The Sender: > - MUST support no framing > - MUST support at least one framing solution > - MUST use the framing specified by the receiver, > if it supports that framing mode and ... > > First, a quick summary of the issues: > - Deploying iSCSI sender can be done: > - on top of an unmodified TCP stack with: > o No framing > o Marker based framing > - on top of a modified TCP stack can implement > PDU-alignment. > - The receiver trade-offs are: > o No framing - large receive reassembly buffer > (higher cost solution) > o Marker framing - receive reassembly buffer is reduced > to an eddy buffer, but requires modifications to > > TCP receive stack (medium cost solution) > o PDU-alignment - receive reassembly buffer can be > reduced > even further, but requires modifications to TCP > receive stack (lowest cost solution and enables > eventual deployment of a viable chunking protocol). > - The cost of implementing markers on unmodified TCP stacks > o sender cost is acceptable, assuming a gather list is > reasonably implemented. > o receiver cost is unacceptable > Initial implementations for initiator appear to be in two camps: > - Unmodified TCP software stacks > - Embedded TCP offload in the NIC (essentially TCP > is hidden from the host SCSI stack) > > Initial implementations for the target appear to be in two camps: > - Optimized NICs which will support framing - probably both > framing modes. Because both modes > require modifications to the receive TCP stack and > PDU-alignment is viewed as straightforward, it is > assumed that most implementations will implement > both framing solutions to allow them to transfer > data optimally with either unmodified send TCP stacks > or PDU-alignment send TCP stacks. > - Unmodified TCP software stacks > > It is primarily a receiver cost issue that motivates the framing > discussion. The primary sender issue is what, if any, optimizations can > be done for unmodified TCP send stacks? Note however, that the proposed > iSCSI requirements are not target or initiator oriented - they are > sender and receiver oriented. The receiver cost issue applies to either > a target or initiator - and they each have very different cost > trade-offs. > > Thus the best solution is to allow the receive side to control their > destiny - and require the sender to obey the receiver (within limits). > If this approach were taken, the sender would have to implement all > three framing options. Unfortunately, a highly desirable design goal is > to allow the sender (either the target or the initiator) to run on an > unmodified TCP stack. Thus the compromise in terms of sender > functionality. The iSCSI 08 draft Appendix C MUST be amended, from, "The use of markers is negotiable. The initiator and target MAY indicate their readiness to receive and/or send markers during login separately for each connection. The default is NO. In certain environments a sender not willing to supply markers to a receiver willing to accept markers MAY suffer from a considerable performance degradation." to: "The use of markers is negotiable. The initiator and target MUST indicate their readiness to receive and/or send markers during login separately for each connection. The default is NO. In certain environments a sender not willing to supply markers to a receiver willing to accept markers MAY suffer from a considerable performance degradation." and in the next paragraph: "If a receiver indicates that it desires a marker, the sender SHOULD agree (during negotiation) and provide the marker at the desired interval." MUST be changed to: "If a receiver indicates that it desires a marker, the sender MUST agree (during negotiation) and provide the marker at the desired interval." Dave Sheehy --=_alternative 0078C62CC2256AE0_= Content-Type: text/html; charset="us-ascii"
Dave,

This was the consensus of the framing team - not of the IPS list.
It is inappropriate for us to replace a thing that we have and is agreed to something that
that is not here yet.  

As I stated if you want to do it independent of the ULP progress you have to reopen the issue on this list.

Regards,
Julo


Dave Sheehy <dbs@acropora.rose.agilent.com>
Sent by: owner-ips@ece.cmu.edu

09-10-01 08:54
Please respond to Dave Sheehy

       
        To:        ips@ece.cmu.edu (IETF IP SAN Reflector)
        cc:        
        Subject:        iscsi: 08 Comment, framing

       


Since the following is the consensus of the framing team:

> iSCSI, with minor modifications since the presentation at the IETF:
>
>
>                  The Sender:
>                                   - MUST support no framing
>                                   - MUST support at least one framing solution
>                                   - MUST use the framing specified by the receiver,
>                                                    if it supports that framing mode

and ...

>
> First, a quick summary of the issues:
>                  - Deploying iSCSI sender can be done:
>                                   - on top of an unmodified TCP stack with:
>                                                    o No framing
>                                                    o Marker based framing
>                                   - on top of a modified TCP stack can implement
>                                                    PDU-alignment.
>                  - The receiver trade-offs are:
>                                   o No framing - large receive reassembly buffer
>                                                    (higher cost solution)
>                                   o Marker framing - receive reassembly buffer is reduced
>                                                    to an eddy buffer, but requires modifications to
>
>                                                    TCP receive stack (medium cost solution)
>                                   o PDU-alignment - receive reassembly buffer can be
> reduced
>                                                    even further, but requires modifications to TCP
>                                                    receive stack (lowest cost solution and enables
>                                                    eventual deployment of a viable chunking protocol).
>                  - The cost of implementing markers on unmodified TCP stacks
>                                   o sender cost is acceptable, assuming a gather list is
>                                                    reasonably implemented.
>                                   o receiver cost is unacceptable

> Initial implementations for initiator appear to be in two camps:
>                  - Unmodified TCP software stacks
>                  - Embedded TCP offload in the NIC (essentially TCP
>                                   is hidden from the host SCSI stack)
>
> Initial implementations for the target appear to be in two camps:
>                  - Optimized NICs which will support framing - probably both
>                                   framing modes. Because both modes
>                                   require modifications to the receive TCP stack and
>                                   PDU-alignment is viewed as straightforward, it is
>                                   assumed that most implementations will implement
>                                   both framing solutions to allow them to transfer
>                                   data optimally with either unmodified send TCP stacks
>                                   or PDU-alignment send TCP stacks.
>                  - Unmodified TCP software stacks
>
> It is primarily a receiver cost issue that motivates the framing
> discussion. The primary sender issue is what, if any, optimizations can
> be done for unmodified TCP send stacks? Note however, that the proposed
> iSCSI requirements are not target or initiator oriented - they are
> sender and receiver oriented. The receiver cost issue applies to either
> a target or initiator - and they each have very different cost
> trade-offs.
>
> Thus the best solution is to allow the receive side to control their
> destiny - and require the sender to obey the receiver (within limits).
> If this approach were taken, the sender would have to implement all
> three framing options. Unfortunately, a highly desirable design goal is
> to allow the sender (either the target or the initiator) to run on an
> unmodified TCP stack. Thus the compromise in terms of sender
> functionality.

The iSCSI 08 draft Appendix C MUST be amended,

from,

"The use of markers is negotiable. The initiator and target MAY
indicate their readiness to receive and/or send markers during login
separately for each connection. The default is NO. In certain
environments a sender not willing to supply markers to a receiver
willing to accept markers MAY suffer from a considerable performance
degradation."

to:

"The use of markers is negotiable. The initiator and target MUST
indicate their readiness to receive and/or send markers during login
separately for each connection. The default is NO. In certain
environments a sender not willing to supply markers to a receiver
willing to accept markers MAY suffer from a considerable performance
degradation."

and in the next paragraph:

"If a receiver indicates that it desires a marker, the
sender SHOULD agree (during negotiation) and provide the marker at
the desired interval."

MUST be changed to:

"If a receiver indicates that it desires a marker, the
sender MUST agree (during negotiation) and provide the marker at
the desired interval."

Dave Sheehy

--=_alternative 0078C62CC2256AE0_=-- From owner-ips@ece.cmu.edu Tue Oct 9 21:25: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 VAA16466 for ; Tue, 9 Oct 2001 21:25:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9A0Qs620982 for ips-outgoing; Tue, 9 Oct 2001 20:26:54 -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 f9A0Qql20975 for ; Tue, 9 Oct 2001 20:26:52 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Oct 2001 20:28:59 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD862@CORPMX14> From: Black_David@emc.com To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: RE: iscsi: 08 Comment, framing Date: Tue, 9 Oct 2001 20:18:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15121.15E38F10" 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_01C15121.15E38F10 Content-Type: text/plain; charset="iso-8859-1" Julian is correct. In London the framing team consensus did not translate into WG rough consensus. Until it does, I think modifications to the spec are not appropriate. I suspect Framing is going to be on the Salt Lake City agenda :-(. --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: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, October 09, 2001 5:59 PM To: ips@ece.cmu.edu Subject: Re: iscsi: 08 Comment, framing Dave, This was the consensus of the framing team - not of the IPS list. It is inappropriate for us to replace a thing that we have and is agreed to something that that is not here yet. As I stated if you want to do it independent of the ULP progress you have to reopen the issue on this list. Regards, Julo Dave Sheehy Sent by: owner-ips@ece.cmu.edu 09-10-01 08:54 Please respond to Dave Sheehy To: ips@ece.cmu.edu (IETF IP SAN Reflector) cc: Subject: iscsi: 08 Comment, framing Since the following is the consensus of the framing team: > iSCSI, with minor modifications since the presentation at the IETF: > > > The Sender: > - MUST support no framing > - MUST support at least one framing solution > - MUST use the framing specified by the receiver, > if it supports that framing mode and ... > > First, a quick summary of the issues: > - Deploying iSCSI sender can be done: > - on top of an unmodified TCP stack with: > o No framing > o Marker based framing > - on top of a modified TCP stack can implement > PDU-alignment. > - The receiver trade-offs are: > o No framing - large receive reassembly buffer > (higher cost solution) > o Marker framing - receive reassembly buffer is reduced > to an eddy buffer, but requires modifications to > > TCP receive stack (medium cost solution) > o PDU-alignment - receive reassembly buffer can be > reduced > even further, but requires modifications to TCP > receive stack (lowest cost solution and enables > eventual deployment of a viable chunking protocol). > - The cost of implementing markers on unmodified TCP stacks > o sender cost is acceptable, assuming a gather list is > reasonably implemented. > o receiver cost is unacceptable > Initial implementations for initiator appear to be in two camps: > - Unmodified TCP software stacks > - Embedded TCP offload in the NIC (essentially TCP > is hidden from the host SCSI stack) > > Initial implementations for the target appear to be in two camps: > - Optimized NICs which will support framing - probably both > framing modes. Because both modes > require modifications to the receive TCP stack and > PDU-alignment is viewed as straightforward, it is > assumed that most implementations will implement > both framing solutions to allow them to transfer > data optimally with either unmodified send TCP stacks > or PDU-alignment send TCP stacks. > - Unmodified TCP software stacks > > It is primarily a receiver cost issue that motivates the framing > discussion. The primary sender issue is what, if any, optimizations can > be done for unmodified TCP send stacks? Note however, that the proposed > iSCSI requirements are not target or initiator oriented - they are > sender and receiver oriented. The receiver cost issue applies to either > a target or initiator - and they each have very different cost > trade-offs. > > Thus the best solution is to allow the receive side to control their > destiny - and require the sender to obey the receiver (within limits). > If this approach were taken, the sender would have to implement all > three framing options. Unfortunately, a highly desirable design goal is > to allow the sender (either the target or the initiator) to run on an > unmodified TCP stack. Thus the compromise in terms of sender > functionality. The iSCSI 08 draft Appendix C MUST be amended, from, "The use of markers is negotiable. The initiator and target MAY indicate their readiness to receive and/or send markers during login separately for each connection. The default is NO. In certain environments a sender not willing to supply markers to a receiver willing to accept markers MAY suffer from a considerable performance degradation." to: "The use of markers is negotiable. The initiator and target MUST indicate their readiness to receive and/or send markers during login separately for each connection. The default is NO. In certain environments a sender not willing to supply markers to a receiver willing to accept markers MAY suffer from a considerable performance degradation." and in the next paragraph: "If a receiver indicates that it desires a marker, the sender SHOULD agree (during negotiation) and provide the marker at the desired interval." MUST be changed to: "If a receiver indicates that it desires a marker, the sender MUST agree (during negotiation) and provide the marker at the desired interval." Dave Sheehy ------_=_NextPart_001_01C15121.15E38F10 Content-Type: text/html; charset="iso-8859-1"
Julian is correct.  In London the framing team consensus did not
translate into WG rough consensus.  Until it does, I think modifications
to the spec are not appropriate.  I suspect Framing is going to be on
the Salt Lake City agenda :-(.  --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: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Tuesday, October 09, 2001 5:59 PM
To: ips@ece.cmu.edu
Subject: Re: iscsi: 08 Comment, framing


Dave,

This was the consensus of the framing team - not of the IPS list.
It is inappropriate for us to replace a thing that we have and is agreed to something that
that is not here yet.  

As I stated if you want to do it independent of the ULP progress you have to reopen the issue on this list.

Regards,
Julo


Dave Sheehy <dbs@acropora.rose.agilent.com>
Sent by: owner-ips@ece.cmu.edu

09-10-01 08:54
Please respond to Dave Sheehy

       
        To:        ips@ece.cmu.edu (IETF IP SAN Reflector)
        cc:        
        Subject:        iscsi: 08 Comment, framing

       


Since the following is the consensus of the framing team:

> iSCSI, with minor modifications since the presentation at the IETF:
>
>
>                  The Sender:
>                                   - MUST support no framing
>                                   - MUST support at least one framing solution
>                                   - MUST use the framing specified by the receiver,
>                                                    if it supports that framing mode

and ...

>
> First, a quick summary of the issues:
>                  - Deploying iSCSI sender can be done:
>                                   - on top of an unmodified TCP stack with:
>                                                    o No framing
>                                                    o Marker based framing
>                                   - on top of a modified TCP stack can implement
>                                                    PDU-alignment.
>                  - The receiver trade-offs are:
>                                   o No framing - large receive reassembly buffer
>                                                    (higher cost solution)
>                                   o Marker framing - receive reassembly buffer is reduced
>                                                    to an eddy buffer, but requires modifications to
>
>                                                    TCP receive stack (medium cost solution)
>                                   o PDU-alignment - receive reassembly buffer can be
> reduced
>                                                    even further, but requires modifications to TCP
>                                                    receive stack (lowest cost solution and enables
>                                                    eventual deployment of a viable chunking protocol).
>                  - The cost of implementing markers on unmodified TCP stacks
>                                   o sender cost is acceptable, assuming a gather list is
>                                                    reasonably implemented.
>                                   o receiver cost is unacceptable

> Initial implementations for initiator appear to be in two camps:
>                  - Unmodified TCP software stacks
>                  - Embedded TCP offload in the NIC (essentially TCP
>                                   is hidden from the host SCSI stack)
>
> Initial implementations for the target appear to be in two camps:
>                  - Optimized NICs which will support framing - probably both
>                                   framing modes. Because both modes
>                                   require modifications to the receive TCP stack and
>                                   PDU-alignment is viewed as straightforward, it is
>                                   assumed that most implementations will implement
>                                   both framing solutions to allow them to transfer
>                                   data optimally with either unmodified send TCP stacks
>                                   or PDU-alignment send TCP stacks.
>                  - Unmodified TCP software stacks
>
> It is primarily a receiver cost issue that motivates the framing
> discussion. The primary sender issue is what, if any, optimizations can
> be done for unmodified TCP send stacks? Note however, that the proposed
> iSCSI requirements are not target or initiator oriented - they are
> sender and receiver oriented. The receiver cost issue applies to either
> a target or initiator - and they each have very different cost
> trade-offs.
>
> Thus the best solution is to allow the receive side to control their
> destiny - and require the sender to obey the receiver (within limits).
> If this approach were taken, the sender would have to implement all
> three framing options. Unfortunately, a highly desirable design goal is
> to allow the sender (either the target or the initiator) to run on an
> unmodified TCP stack. Thus the compromise in terms of sender
> functionality.

The iSCSI 08 draft Appendix C MUST be amended,

from,

"The use of markers is negotiable. The initiator and target MAY
indicate their readiness to receive and/or send markers during login
separately for each connection. The default is NO. In certain
environments a sender not willing to supply markers to a receiver
willing to accept markers MAY suffer from a considerable performance
degradation."

to:

"The use of markers is negotiable. The initiator and target MUST
indicate their readiness to receive and/or send markers during login
separately for each connection. The default is NO. In certain
environments a sender not willing to supply markers to a receiver
willing to accept markers MAY suffer from a considerable performance
degradation."

and in the next paragraph:

"If a receiver indicates that it desires a marker, the
sender SHOULD agree (during negotiation) and provide the marker at
the desired interval."

MUST be changed to:

"If a receiver indicates that it desires a marker, the
sender MUST agree (during negotiation) and provide the marker at
the desired interval."

Dave Sheehy



------_=_NextPart_001_01C15121.15E38F10-- From owner-ips@ece.cmu.edu Tue Oct 9 21:36: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 VAA17235 for ; Tue, 9 Oct 2001 21:36:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9A14vh23248 for ips-outgoing; Tue, 9 Oct 2001 21:04: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 f9A14ul23244 for ; Tue, 9 Oct 2001 21:04: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 50DF91F933; Tue, 9 Oct 2001 18:04: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 SAA14181; Tue, 9 Oct 2001 18:04:45 -0700 (PDT) Message-ID: <3BC3A063.B0E21C78@cup.hp.com> Date: Tue, 09 Oct 2001 18:12:03 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Paul Koning Cc: andy@windriver.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU References: <200110091825.LAA22228@russian.wrs.com> <15299.22319.659000.473461@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Andy, Paul & All, The proposed model is broken if an initiator issues a few immediate scsi commands. (such cmds will share the same cmdsn, that of the last issued non-immediate cmdsn). The only unique identifier is the initiator task tag in the case of un-solicited I/O. Thanks, Santosh Paul Koning wrote: > > Excerpt of message (sent 9 October 2001) by andy currid: > > > > Julian, all > > > > I second Matthew's request to have CmdSN present in DataOut PDUs. > > ... > > When receiving unsolicited DataOut PDUs, a target must currently use > > the ITT to determine the command with which the DataOut is associated. > > In the absence of hardware assist such as a CAM, a target implementation > > must search a list of non-final commands currently queued within the > > session to match the ITT. When many such commands are queued (which ought > > to be the case for performant implementations), that search will relatively > > inefficient, no matter how the search is optimized (binary search, hash > > table, etc.). > > I'll add my voice to the set. Andy's arguments make perfect sense. > Lookups on unstructured IDs are a pain. Hashing can be fast, but hash > table changes typically aren't. The nasty case is a lookup on a set > of unstructured IDs that changes very rapidly, which is exactly the > case we have here. > > > Placing CmdSn in DataOut will allow a target to instantly access the > > queued command with which an unsolicited DataOut is associated, without > > performing a search. Mapping from a CmdSN into a queue location within > > the target is almost certainly a constant time operation. > > Exactly. > > > I don't see any performance issues with making this change. I don't > > think it's a big imposition on an initiator to include the associated > > CmdSN in a DataOut PDU. Do any initiator implementors feel this would > > be a problem? > > > > On the target end, I don't think consistency checking is an issue. In a > > solicited data out carrying CmdSN, targets would be free to ignore CmdSN > > and simply use TTT as they do today. There's no obligation to verify > > CmdSN is consistent with the DataOut's associated command, though such > > a check is likely to be cheap. > > Consistency checking could be left out entirely if we wish. That > would be my inclination. Or it could be made optional -- or even, if > people insist, mandatory. It's very cheap if that's done. The > response to an inconsistency should be harsh (terminate the session, > for example) because it will only happen if the sender is defective. > > paul -- ################################## 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 Tue Oct 9 22:33: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 WAA18950 for ; Tue, 9 Oct 2001 22:33:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9A1j5E25589 for ips-outgoing; Tue, 9 Oct 2001 21:45:06 -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 f9A1j4l25584 for ; Tue, 9 Oct 2001 21:45:04 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Oct 2001 21:47:11 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD864@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: ISID issue summary Date: Tue, 9 Oct 2001 21:36:42 -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 For those who haven't been following the long intricate email discussion between Jim Hafner and myself, let me try to explain the issue. SCSI architecture (SAM2) is based on an intuition that SCSI ports are fixed (e.g., physical) things that have names. So far, the existence of the names has been an intellectual curiosity as they haven't mattered to any visible SCSI functionality. Single port Initiators predominate in both Parallel SCSI and Fibre Channel (e.g., a dual ported Fibre Channel HBA is usually treated as two SCSI Initiators, not a single dual-ported one). Jim tells us that T10 is about to define persistent reserve functionality that depends on the identity of the SCSI Initiator Port - in particular that under some circumstances, persistent reservations will be associated with the Initiator Port independent of the Target Port. Persistent reservations are currently bound to the Initiator Port and Target Port (as well as the LU they affect). For the rest of this message, I'm going to assume that we want to support this functionality. Assuming this and that I got the description in this paragraph right ... ... I need to take a slight detour into pragmatics. Those who configure storage networks rapidly discover the value of consistency and matching configurations. Multi-path I/O configurations tend to want to see access to the same set of LUs consistently across a set of interfaces (i.e., Ports). Between suitable configuration and the aggressive setup of connections to all possible targets, all the required connections come into existence as part of the boot process. Applying this experience to the new persistent reservation functionality, one would expect persistent reservations that are bound only to an Initiator Port to be independent of the Target Port, in that the reservation should span connections to all of the relevant Target Ports and those connections should come into existence as part of the boot process. Turning to iSCSI, the situation gets complicated by the interaction of two factors: - Parallel sessions are permitted down to the interface level (e.g., more than one iSCSI session may exist that uses IP addresses A and B to connect iSCSI Initiator I to iSCSI Target T). - SCSI disallows parallel nexii (i.e., more than one session between the same two SCSI Ports). If SCSI Ports are mapped to hardware entities such as network interfaces in iSCSI, the opportunity for parallel sessions between the same pair of network interfaces vanishes. In order to avoid that outcome, iSCSI Initiator Ports have to be mapped to software entities. To date, the ISID has been used to identify those software entities, and the only rule on their allocation is: ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal Group (SCSI target port), then can be only one session with a given ISID (identifying a SCSI initiator port). See 3.12.8. In order to get the expected outcome of the new functionality being defined by T10, the same ISID has to be used to establish all the connections that the persistent reservation is supposed to span. Unfortunately, that's above and beyond what iSCSI requires - the relevant text about doing this in -08 is: The "ISID rule" does not preclude the use of the same ISID from the same iSCSI Initiator with different Target Portal Groups on the same iSCSI target or on other iSCSI targets "does not preclude" is rather weak language for something that's essential to making a piece of SCSI functionality work. If an iSCSI implementation uses a different ISID for every session (which is also not precluded by the current text), then persistent reservations will never span Targets or Target Ports for that implementation despite T10's best efforts and intentions. IMHO, allowing that outcome is *wrong* (and this is the source of the difference of opinion between Jim and myself). The correction to this involves what Jim has called "conservative reuse" of ISIDs. This is something like for each ISID that an implementation uses, a connection with that ISID is made to every possible Target Portal Group of every possible Target. I suspect a longer explanation than this will be needed, including a discussion of the desirability of avoiding a situation in which the same ISID is used by two iSCSI implementations that are part of the same Initiator and set up sessions concurrently. IMHO, if we want to support persistent reservations at this stage that span target ports, we need to replace the "does not preclude" language with a REQUIREMENT for conservative reuse to avoid a situation in which SCSI functionality that works consistently with other transports works inconsistently with iSCSI (i.e., doesn't work with iSCSI implementations that don't do conservative reuse). Stepping back from the assumption that support for port-spanning persistent reservations is required, I observe that the conservative reuse rule impacts all implementations, even those that will never use such persistent reservations because ISID is a mandatory part of the iSCSI protocol. If a text key were used instead, only those Initiators that want to support this functionality on which T10 is "crossing a few t's and dotting a few i's" are affected (the text key is optional). The text key would be subject to a conservative reuse rule similar to the one that would be needed for ISIDs, and once T10 finishes the i's and t's, we can precisely reference the SCSI features (persistent reservation expansion) that require use of this text key. In addition, text keys have much better alternatives for dealing with conflicts than ISIDs - if a text key conflicts, it is possible to continue the negotiation with a different text key, whereas ISID conflict is fatal to one of the two sessions involved. As Jim has previously observed, changing the text key (e.g., generate a large random number in response to a conflict), results in a situation that can be dealt with by software that uses persistent reservations, although this departure from conservative reuse should only occur as a consequence of some sort of configuration mistake or bug. At the tail end of this reasoning chain is the observation that use of this text key leaves the ISID without value/purpose, and hence would call for its removal (or perhaps designation as a reserved field). Putting on my WG chair hat for a moment, I can accept either alternative outlined above: - Add conservative reuse to the ISID rule. - Use a text key for iSCSI port identification. But I'm not comfortable with the current situation in which iSCSI implementations are permitted to break T10-defined SCSI features that will work as expected in other SCSI transports. I hope this now makes sense to more people than just Jim and I, and I apologize for the length of this message, as this is a somewhat subtle issue. 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 Tue Oct 9 22:33: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 WAA18962 for ; Tue, 9 Oct 2001 22:33:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9A29Vc26911 for ips-outgoing; Tue, 9 Oct 2001 22:09:31 -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 f9A29Ul26907 for ; Tue, 9 Oct 2001 22:09:30 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id B95551F81E for ; Tue, 9 Oct 2001 19:09:24 -0700 (PDT) Received: from rose.hp.com (pal1nai162086.nsr.hp.com [15.244.162.86]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id TAA15333 for ; Tue, 9 Oct 2001 19:10:46 -0700 (PDT) Message-ID: <3BC3AF23.403D60C9@rose.hp.com> Date: Tue, 09 Oct 2001 19:14:59 -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 Subject: iSCSI: NIC interoperability Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit After seeing some of the emails on this topic from Dave Sheehy, David Black and Jim Hafner, I have some comments and questions. It appears to me that the following three are the major issues that one has to deal with for building a multi-NIC iSCSI Node, where the NICs are potentially from different vendors. A. Each NIC MUST allow the Node name to be configurable. B. Each NIC MUST allow the ISID range to be configurable (if deployed in an initiator configuration). C. In addition, if only one (initiator/target) portal group is sought to be presented (i.e. session spanning across any and all of these NICs is a requirement), each NIC MUST allow itself to be managed by an externally-resident "session manager" in some "TBD standard way". Admittedly, C is is the hardest and till the "TBD standard way" is defined to interact with a session manager, it cannot be mandated. Failure to comply with C would only create multiple portal groups in an iSCSI implementation - each portal group limited to NIC(s) from a given vendor. But, A and B above seem reasonable and in fact seem required to be mandated - both to avoid the problems as with FC Node Name, and also to address the concerns of not leaving target with a deterministic way to enforce access control mechanisms and such. I realize that the "no duplicate nexus" goal does not strictly require A (hence neither B), but I recommend that A be mandated, thus automatically making B an additional requirement for initiator configurations. Rev08 iSCSI draft seems to refer to A and B in section 9 (implementation notes) as "should". Was there a concern about the appropriateness of mandating A and B in the main modeling discussion? They appear fairly straightforward to implement. If the reasoning was not to require _any_ configuration of an iSCSI NIC, I would argue that you require some "name" to be configurable anytime you want to build a logically monolithic entity (as in a node) from smaller components (each of which can act as a logically independent entity in its own right). Comments from NDT and/or Julian would help. 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 Tue Oct 9 22:34: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 WAA18976 for ; Tue, 9 Oct 2001 22:34:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9A21tq26501 for ips-outgoing; Tue, 9 Oct 2001 22:01: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 f9A21rl26497 for ; Tue, 9 Oct 2001 22:01:54 -0400 (EDT) Received: from russian.wrs.com (russian [147.11.45.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA07610; Tue, 9 Oct 2001 19:01:37 -0700 (PDT) From: andy currid Received: (from andy@localhost) by russian.wrs.com (8.9.1/8.9.0) id TAA23887; Tue, 9 Oct 2001 19:01:46 -0700 (PDT) Message-Id: <200110100201.TAA23887@russian.wrs.com> Subject: Re: Addition of CmdSN in Data-out PDU To: santoshr@cup.hp.com (Santosh Rao) Date: Tue, 9 Oct 2001 19:01:46 -0700 (PDT) Cc: pkoning@jlc.net (Paul Koning), andy@windriver.com, Julian_Satran@il.ibm.com, ips@ece.cmu.edu In-Reply-To: <3BC3A063.B0E21C78@cup.hp.com> from "Santosh Rao" at Oct 09, 2001 06:12:03 PM 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 Santosh Thanks for pointing this out, I'd overlooked the immediate command case. I agree, this breaks the current proposal. Andy > Andy, Paul & All, > > The proposed model is broken if an initiator issues a few immediate scsi > commands. (such cmds will share the same cmdsn, that of the last issued > non-immediate cmdsn). > > The only unique identifier is the initiator task tag in the case of > un-solicited I/O. > > Thanks, > Santosh > > > Paul Koning wrote: >> >> Excerpt of message (sent 9 October 2001) by andy currid: >>> >>> Julian, all >>> >>> I second Matthew's request to have CmdSN present in DataOut PDUs. >>> ... >>> When receiving unsolicited DataOut PDUs, a target must currently use >>> the ITT to determine the command with which the DataOut is associated. >>> In the absence of hardware assist such as a CAM, a target implementation >>> must search a list of non-final commands currently queued within the >>> session to match the ITT. When many such commands are queued (which ought >>> to be the case for performant implementations), that search will relatively >>> inefficient, no matter how the search is optimized (binary search, hash >>> table, etc.). >> >> I'll add my voice to the set. Andy's arguments make perfect sense. >> Lookups on unstructured IDs are a pain. Hashing can be fast, but hash >> table changes typically aren't. The nasty case is a lookup on a set >> of unstructured IDs that changes very rapidly, which is exactly the >> case we have here. >> >>> Placing CmdSn in DataOut will allow a target to instantly access the >>> queued command with which an unsolicited DataOut is associated, without >>> performing a search. Mapping from a CmdSN into a queue location within >>> the target is almost certainly a constant time operation. >> >> Exactly. >> >>> I don't see any performance issues with making this change. I don't >>> think it's a big imposition on an initiator to include the associated >>> CmdSN in a DataOut PDU. Do any initiator implementors feel this would >>> be a problem? >>> >>> On the target end, I don't think consistency checking is an issue. In a >>> solicited data out carrying CmdSN, targets would be free to ignore CmdSN >>> and simply use TTT as they do today. There's no obligation to verify >>> CmdSN is consistent with the DataOut's associated command, though such >>> a check is likely to be cheap. >> >> Consistency checking could be left out entirely if we wish. That >> would be my inclination. Or it could be made optional -- or even, if >> people insist, mandatory. It's very cheap if that's done. The >> response to an inconsistency should be harsh (terminate the session, >> for example) because it will only happen if the sender is defective. >> >> paul -- Andy Currid andy@windriver.com Server Products Group http://www.windriver.com Wind River Networks Phone : (1) 510 749 2191 500 Wind River Way, Alameda, CA 94501 Fax : (1) 510 749 2560 From owner-ips@ece.cmu.edu Tue Oct 9 22:36: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 WAA19030 for ; Tue, 9 Oct 2001 22:36:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9A1qr726021 for ips-outgoing; Tue, 9 Oct 2001 21:52:53 -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 f9A1qpl26016 for ; Tue, 9 Oct 2001 21:52:51 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail16.vwh1.net (RS ver 1.0.60s) with SMTP id 040769681; Tue, 9 Oct 2001 21:52:09 -0400 (EDT) From: "Deva-Adaptec" To: "Julian Satran" , , Subject: RE: Addition of CmdSN in Data-out PDU Date: Tue, 9 Oct 2001 18:58:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C150F4.72B48500" 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: X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002A_01C150F4.72B48500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I agree with the reasons cited by Julian and Santosh. I think that it is not a good idea to use cmdSN in the data pdus. Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Tuesday, October 09, 2001 2:45 PM To: ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it may have large holes and using it in an implementation is as bad as a hashed index. I you want to pursue this please forward a draft showing what the distinct application advantages are to the list. It can include pseudo-code, flowcharts or whatever else you think that you need to convince the list. Julo Paul Koning 09-10-01 21:59 Please respond to Paul Koning To: andy@windriver.com cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU Excerpt of message (sent 9 October 2001) by andy currid: > > Julian, all > > I second Matthew's request to have CmdSN present in DataOut PDUs. > ... > When receiving unsolicited DataOut PDUs, a target must currently use > the ITT to determine the command with which the DataOut is associated. > In the absence of hardware assist such as a CAM, a target implementation > must search a list of non-final commands currently queued within the > session to match the ITT. When many such commands are queued (which ought > to be the case for performant implementations), that search will relatively > inefficient, no matter how the search is optimized (binary search, hash > table, etc.). I'll add my voice to the set. Andy's arguments make perfect sense. Lookups on unstructured IDs are a pain. Hashing can be fast, but hash table changes typically aren't. The nasty case is a lookup on a set of unstructured IDs that changes very rapidly, which is exactly the case we have here. > Placing CmdSn in DataOut will allow a target to instantly access the > queued command with which an unsolicited DataOut is associated, without > performing a search. Mapping from a CmdSN into a queue location within > the target is almost certainly a constant time operation. Exactly. > I don't see any performance issues with making this change. I don't > think it's a big imposition on an initiator to include the associated > CmdSN in a DataOut PDU. Do any initiator implementors feel this would > be a problem? > > On the target end, I don't think consistency checking is an issue. In a > solicited data out carrying CmdSN, targets would be free to ignore CmdSN > and simply use TTT as they do today. There's no obligation to verify > CmdSN is consistent with the DataOut's associated command, though such > a check is likely to be cheap. Consistency checking could be left out entirely if we wish. That would be my inclination. Or it could be made optional -- or even, if people insist, mandatory. It's very cheap if that's done. The response to an inconsistency should be harsh (terminate the session, for example) because it will only happen if the sender is defective. paul ------=_NextPart_000_002A_01C150F4.72B48500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 agree with the reasons cited by Julian and  Santosh. I think that = it is not=20 a good idea to use cmdSN in the data pdus.
 
Deva
Adaptec
 
 ------=_NextPart_000_002A_01C150F4.72B48500-- From owner-ips@ece.cmu.edu Wed Oct 10 09:12: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 JAA09024 for ; Wed, 10 Oct 2001 09:12:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9AC3kS09370 for ips-outgoing; Wed, 10 Oct 2001 08:03: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 f9AC3il09366 for ; Wed, 10 Oct 2001 08:03:44 -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 OAA64834 for ; Wed, 10 Oct 2001 14:03:33 +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 f9AC3WY263972 for ; Wed, 10 Oct 2001 14:03:32 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - TTT in negotiations X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 10 Oct 2001 15:03:29 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 10/10/2001 15:03:32, Serialize complete at 10/10/2001 15:03:32 Content-Type: multipart/alternative; boundary="=_alternative 003F2239C2256AE1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 003F2239C2256AE1_= Content-Type: text/plain; charset="us-ascii" Dear colleagues, It occurred to us that we may want to have a simple (more regular) way to "index" at target into ongoing text negotiations (not login) and we may want the target to be able to set it's TTT whenever the F bit is not 0 and to mandate the initiator to copy it in the next text command in the chain. This might make bookmarks and long negotiations behave similarly (and time-out,/ be reset similarly). Comments? Julo --=_alternative 003F2239C2256AE1_= Content-Type: text/html; charset="us-ascii"
Dear colleagues,

It occurred to us that we may want to have a simple (more regular) way to "index" at target into ongoing text negotiations (not login) and we may want the target to be able to set it's TTT whenever the F bit is not 0 and to mandate the initiator to copy it in the next text command in the chain.  This might make bookmarks and long negotiations behave similarly (and time-out,/ be reset similarly).

Comments?

Julo

--=_alternative 003F2239C2256AE1_=-- From owner-ips@ece.cmu.edu Wed Oct 10 11:26: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 LAA12340 for ; Wed, 10 Oct 2001 11:26:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9AEdSC19649 for ips-outgoing; Wed, 10 Oct 2001 10:39:28 -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 f9AEdQl19644 for ; Wed, 10 Oct 2001 10:39:26 -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 QAA84322 for ; Wed, 10 Oct 2001 16:39: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 f9AEdGQ109342 for ; Wed, 10 Oct 2001 16:39:17 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: ISID issue summary X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 10 Oct 2001 17:39:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 10/10/2001 17:39:16, Serialize complete at 10/10/2001 17:39:16 Content-Type: multipart/alternative; boundary="=_alternative 00508BC9C2256AE1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00508BC9C2256AE1_= Content-Type: text/plain; charset="us-ascii" ... and have as much chances to blow a session as ISID. Julo Jim Hafner/Almaden/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 10-10-01 16:27 Please respond to Jim Hafner To: Black_David@emc.com, ips@ece.cmu.edu cc: Subject: Re: iSCSI: ISID issue summary David, An excellent summary of the issues. A couple of things I want to point out about the "text key" proposal, however. a) The proposal sounds to me like iSCSI will have "optional SCSI Port names". Only when the key is used is the SCSI port named and when the key is not used, there is no such name. That's probably an acceptable situation as far as SAM-2 is concerned, but it certainly is odd. b) The proposal would require at least as much coordination above the "session manager" level as managing ISIDs, though admittedly, it need not be implemented in all cases. c) I'm concerned how to describe the model when names are optional, so as to avoid the parallel nexus problem. Is it that all initiator session endpoints that don't provide this text key have *implicit* unique names and only when the text key is presented does the name get explicit (and then possibly not be unique)? In that case, the key would have to be supplied in login next to the InitiatorName. Jim Hafner Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: ISID issue summary For those who haven't been following the long intricate email discussion between Jim Hafner and myself, let me try to explain the issue. SCSI architecture (SAM2) is based on an intuition that SCSI ports are fixed (e.g., physical) things that have names. So far, the existence of the names has been an intellectual curiosity as they haven't mattered to any visible SCSI functionality. Single port Initiators predominate in both Parallel SCSI and Fibre Channel (e.g., a dual ported Fibre Channel HBA is usually treated as two SCSI Initiators, not a single dual-ported one). Jim tells us that T10 is about to define persistent reserve functionality that depends on the identity of the SCSI Initiator Port - in particular that under some circumstances, persistent reservations will be associated with the Initiator Port independent of the Target Port. Persistent reservations are currently bound to the Initiator Port and Target Port (as well as the LU they affect). For the rest of this message, I'm going to assume that we want to support this functionality. Assuming this and that I got the description in this paragraph right ... ... I need to take a slight detour into pragmatics. Those who configure storage networks rapidly discover the value of consistency and matching configurations. Multi-path I/O configurations tend to want to see access to the same set of LUs consistently across a set of interfaces (i.e., Ports). Between suitable configuration and the aggressive setup of connections to all possible targets, all the required connections come into existence as part of the boot process. Applying this experience to the new persistent reservation functionality, one would expect persistent reservations that are bound only to an Initiator Port to be independent of the Target Port, in that the reservation should span connections to all of the relevant Target Ports and those connections should come into existence as part of the boot process. Turning to iSCSI, the situation gets complicated by the interaction of two factors: - Parallel sessions are permitted down to the interface level (e.g., more than one iSCSI session may exist that uses IP addresses A and B to connect iSCSI Initiator I to iSCSI Target T). - SCSI disallows parallel nexii (i.e., more than one session between the same two SCSI Ports). If SCSI Ports are mapped to hardware entities such as network interfaces in iSCSI, the opportunity for parallel sessions between the same pair of network interfaces vanishes. In order to avoid that outcome, iSCSI Initiator Ports have to be mapped to software entities. To date, the ISID has been used to identify those software entities, and the only rule on their allocation is: ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal Group (SCSI target port), then can be only one session with a given ISID (identifying a SCSI initiator port). See 3.12.8. In order to get the expected outcome of the new functionality being defined by T10, the same ISID has to be used to establish all the connections that the persistent reservation is supposed to span. Unfortunately, that's above and beyond what iSCSI requires - the relevant text about doing this in -08 is: The "ISID rule" does not preclude the use of the same ISID from the same iSCSI Initiator with different Target Portal Groups on the same iSCSI target or on other iSCSI targets "does not preclude" is rather weak language for something that's essential to making a piece of SCSI functionality work. If an iSCSI implementation uses a different ISID for every session (which is also not precluded by the current text), then persistent reservations will never span Targets or Target Ports for that implementation despite T10's best efforts and intentions. IMHO, allowing that outcome is *wrong* (and this is the source of the difference of opinion between Jim and myself). The correction to this involves what Jim has called "conservative reuse" of ISIDs. This is something like for each ISID that an implementation uses, a connection with that ISID is made to every possible Target Portal Group of every possible Target. I suspect a longer explanation than this will be needed, including a discussion of the desirability of avoiding a situation in which the same ISID is used by two iSCSI implementations that are part of the same Initiator and set up sessions concurrently. IMHO, if we want to support persistent reservations at this stage that span target ports, we need to replace the "does not preclude" language with a REQUIREMENT for conservative reuse to avoid a situation in which SCSI functionality that works consistently with other transports works inconsistently with iSCSI (i.e., doesn't work with iSCSI implementations that don't do conservative reuse). Stepping back from the assumption that support for port-spanning persistent reservations is required, I observe that the conservative reuse rule impacts all implementations, even those that will never use such persistent reservations because ISID is a mandatory part of the iSCSI protocol. If a text key were used instead, only those Initiators that want to support this functionality on which T10 is "crossing a few t's and dotting a few i's" are affected (the text key is optional). The text key would be subject to a conservative reuse rule similar to the one that would be needed for ISIDs, and once T10 finishes the i's and t's, we can precisely reference the SCSI features (persistent reservation expansion) that require use of this text key. In addition, text keys have much better alternatives for dealing with conflicts than ISIDs - if a text key conflicts, it is possible to continue the negotiation with a different text key, whereas ISID conflict is fatal to one of the two sessions involved. As Jim has previously observed, changing the text key (e.g., generate a large random number in response to a conflict), results in a situation that can be dealt with by software that uses persistent reservations, although this departure from conservative reuse should only occur as a consequence of some sort of configuration mistake or bug. At the tail end of this reasoning chain is the observation that use of this text key leaves the ISID without value/purpose, and hence would call for its removal (or perhaps designation as a reserved field). Putting on my WG chair hat for a moment, I can accept either alternative outlined above: - Add conservative reuse to the ISID rule. - Use a text key for iSCSI port identification. But I'm not comfortable with the current situation in which iSCSI implementations are permitted to break T10-defined SCSI features that will work as expected in other SCSI transports. I hope this now makes sense to more people than just Jim and I, and I apologize for the length of this message, as this is a somewhat subtle issue. 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 --------------------------------------------------- --=_alternative 00508BC9C2256AE1_= Content-Type: text/html; charset="us-ascii"
... and have as much chances to blow a session as ISID.

Julo


Jim Hafner/Almaden/IBM@IBMUS
Sent by: owner-ips@ece.cmu.edu

10-10-01 16:27
Please respond to Jim Hafner

       
        To:        Black_David@emc.com, ips@ece.cmu.edu
        cc:        
        Subject:        Re: iSCSI: ISID issue summary

       




David,

An excellent summary of the issues.

A couple of things I want to point out about the "text key" proposal, however.
a) The proposal sounds to me like iSCSI will have "optional SCSI Port names". Only when the key is used is the SCSI port named and when the key is not used, there is no such name. That's probably an acceptable situation as far as SAM-2 is concerned, but it certainly is odd.
b) The proposal would require at least as much coordination above the "session manager" level as managing ISIDs, though admittedly, it need not be implemented in all cases.
c) I'm concerned how to describe the model when names are optional, so as to avoid the parallel nexus problem. Is it that all initiator session endpoints that don't provide this text key have *implicit* unique names and only when the text key is presented does the name get explicit (and then possibly not be unique)? In that case, the key would have to be supplied in login next to the InitiatorName.

Jim Hafner

Sent by: owner-ips@ece.cmu.edu

To: ips@ece.cmu.edu
cc:
Subject: iSCSI: ISID issue summary



For those who haven't been following the long intricate
email discussion between Jim Hafner and myself, let me
try to explain the issue.

SCSI architecture (SAM2) is based on an intuition that SCSI
ports are fixed (e.g., physical) things that have names.  So
far, the existence of the names has been an intellectual
curiosity as they haven't mattered to any visible SCSI
functionality.  Single port Initiators predominate in
both Parallel SCSI and Fibre Channel (e.g., a dual ported
Fibre Channel HBA is usually treated as two SCSI Initiators,
not a single dual-ported one).

Jim tells us that T10 is about to define persistent reserve
functionality that depends on the identity of the SCSI Initiator
Port - in particular that under some circumstances, persistent
reservations will be associated with the Initiator Port independent
of the Target Port.  Persistent reservations are currently bound
to the Initiator Port and Target Port (as well as the LU they
affect).  For the rest of this message, I'm going to assume
that we want to support this functionality.  Assuming this and
that I got the description in this paragraph right ...

... I need to take a slight detour into pragmatics.  Those
who configure storage networks rapidly discover the value
of consistency and matching configurations.  Multi-path I/O
configurations tend to want to see access to the same set of LUs
consistently across a set of interfaces (i.e., Ports).  Between
suitable configuration and the aggressive setup of connections
to all possible targets, all the required connections come into
existence as part of the boot process.  Applying
this experience to the new persistent reservation functionality,
one would expect persistent reservations that are bound only to
an Initiator Port to be independent of the Target Port, in that
the reservation should span connections to all of the relevant
Target Ports and those connections should come into existence
as part of the boot process.

Turning to iSCSI, the situation gets complicated by the
interaction of two factors:
- Parallel sessions are permitted down to the interface
level (e.g., more than one iSCSI session may exist
that uses IP addresses A and B to connect iSCSI Initiator
I to iSCSI Target T).
- SCSI disallows parallel nexii (i.e., more than one session
between the same two SCSI Ports).
If SCSI Ports are mapped to hardware entities such as network
interfaces in iSCSI, the opportunity for parallel sessions
between the same pair of network interfaces vanishes.  In order
to avoid that outcome, iSCSI Initiator Ports have to be
mapped to software entities. To date, the ISID has been
used to identify those software entities, and the only rule
on their allocation is:

   ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal
   Group (SCSI target port), then can be only one session with a given
   ISID (identifying a SCSI initiator port).  See 3.12.8.

In order to get the expected outcome of the new functionality
being defined by T10, the same ISID has to be used to establish
all the connections that the persistent reservation is supposed
to span.  Unfortunately, that's above and beyond what iSCSI
requires - the relevant text about doing this in -08 is:

      The "ISID rule" does not preclude
      the use of the same ISID from the same iSCSI Initiator with
      different Target Portal Groups on the same iSCSI target or
      on other iSCSI targets

"does not preclude" is rather weak language for something that's
essential to making a piece of SCSI functionality work.  If an
iSCSI implementation uses a different ISID for every session
(which is also not precluded by the current text), then persistent
reservations will never span Targets or Target Ports for that
implementation despite T10's best efforts and intentions.  IMHO,
allowing that outcome is *wrong* (and this is the source of the
difference of opinion between Jim and myself).

The correction to this involves what Jim has called "conservative
reuse" of ISIDs.  This is something like for each ISID that an
implementation uses, a connection with that ISID is made to
every possible Target Portal Group of every possible Target.  I
suspect a longer explanation than this will be needed, including
a discussion of the desirability of avoiding a situation in which
the same ISID is used by two iSCSI implementations that are part
of the same Initiator and set up sessions concurrently.

IMHO, if we want to support persistent reservations at this stage
that span target ports, we need to replace the "does not preclude"
language with a REQUIREMENT for conservative reuse to avoid a
situation in which SCSI functionality that works consistently with
other transports works inconsistently with iSCSI (i.e., doesn't
work with iSCSI implementations that don't do conservative reuse).

Stepping back from the assumption that support for port-spanning
persistent reservations is required, I observe that the conservative
reuse rule impacts all implementations, even those that will never
use such persistent reservations because ISID is a mandatory part
of the iSCSI protocol.  If a text key were used instead, only those
Initiators that want to support this functionality on which T10
is "crossing a few t's and dotting a few i's" are affected (the
text key is optional).  The text key would be subject to a
conservative reuse rule similar to the one that would be needed
for ISIDs, and once T10 finishes the i's and t's, we can precisely
reference the SCSI features (persistent reservation expansion)
that require use of this text key.

In addition, text keys have much better alternatives for dealing
with conflicts than ISIDs - if a text key conflicts, it is possible
to continue  the negotiation with a different text key, whereas
ISID conflict is fatal to one of the two sessions involved.
As Jim has previously observed, changing the text key (e.g.,
generate a large random number in response to a conflict),
results in a situation that can be dealt with by software that
uses persistent reservations, although this departure from
conservative reuse should only occur as a consequence of some
sort of configuration mistake or bug.  At the tail end of this
reasoning chain is the observation that use of this text key
leaves the ISID without value/purpose, and hence would call
for its removal (or perhaps designation as a reserved field).

Putting on my WG chair hat for a moment, I can accept either
alternative outlined above:
- Add conservative reuse to the ISID rule.
- Use a text key for iSCSI port identification.
But I'm not comfortable with the current situation in which iSCSI
implementations are permitted to break T10-defined SCSI features
that will work as expected in other SCSI transports.

I hope this now makes sense to more people than just Jim and I,
and I apologize for the length of this message, as this is a
somewhat subtle issue.

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
---------------------------------------------------

--=_alternative 00508BC9C2256AE1_=-- From owner-ips@ece.cmu.edu Wed Oct 10 11: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 LAA12362 for ; Wed, 10 Oct 2001 11:27:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9AEW0W19029 for ips-outgoing; Wed, 10 Oct 2001 10:32:00 -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 f9AEVul19013 for ; Wed, 10 Oct 2001 10: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 QAA244454 for ; Wed, 10 Oct 2001 16:31: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 f9AEVfY07060 for ; Wed, 10 Oct 2001 16:31:42 +0200 Subject: Re: ips : Negotiation Reset. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 10 Oct 2001 17:27:30 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 10/10/2001 17:31:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk 8.7 has all the answers. Julo Santosh Rao hp.com> cc: Sent by: Subject: ips : Negotiation Reset. owner-ips@ece. cmu.edu 09-10-01 03:44 Please respond to Santosh Rao Julian, The reject reason code "Negotiation Reset" is listed (newly) in Section 3.17.1. If one of the text commands from an initiator were to be rejected by the target for some other reason code than "Negotiation Reset", what is the effect of such a reject on the operational parameters ? Are'nt all operational parameters reset, any time a text exchange ends unsuccessfully ? I suggest the draft clearly state that ANY un-successful termination of a login/text exchange results in a reset of operational parameters. The "Negotiation Reset" reject reason code can be removed as well. 2) Also, what does the phrase "reset an operational parameter negotiation " mean ? Are the parameters reset to their default values , or are they reset to their previous values ? This needs to be explicitly clarified. 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 Wed Oct 10 11:34: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 LAA12511 for ; Wed, 10 Oct 2001 11:34:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9AERuS18689 for ips-outgoing; Wed, 10 Oct 2001 10:27:56 -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 f9AERql18668 for ; Wed, 10 Oct 2001 10:27:53 -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 KAA74194; Wed, 10 Oct 2001 10:25:25 -0400 Received: from d03nmx42.almaden.ibm.com (d03nmx42.almaden.ibm.com [9.1.24.146]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9AERot69364; Wed, 10 Oct 2001 08:27:50 -0600 Importance: Normal Subject: Re: iSCSI: ISID issue summary To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 10 Oct 2001 07:27:47 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NMX42/03/M/IBM(Build M10_08082001 Beta 3|August 08, 2001) at 10/10/2001 07:27:49 AM MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=07BBE072DFDD55B18f9e8a93df938690918c07BBE072DFDD55B1" Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=07BBE072DFDD55B18f9e8a93df938690918c07BBE072DFDD55B1 Content-type: text/plain; charset=US-ASCII David, An excellent summary of the issues. A couple of things I want to point out about the "text key" proposal, however. a) The proposal sounds to me like iSCSI will have "optional SCSI Port names". Only when the key is used is the SCSI port named and when the key is not used, there is no such name. That's probably an acceptable situation as far as SAM-2 is concerned, but it certainly is odd. b) The proposal would require at least as much coordination above the "session manager" level as managing ISIDs, though admittedly, it need not be implemented in all cases. c) I'm concerned how to describe the model when names are optional, so as to avoid the parallel nexus problem. Is it that all initiator session endpoints that don't provide this text key have *implicit* unique names and only when the text key is presented does the name get explicit (and then possibly not be unique)? In that case, the key would have to be supplied in login next to the InitiatorName. Jim Hafner Black_David@emc.com@ece.cmu.edu on 10/09/2001 06:36:42 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI: ISID issue summary For those who haven't been following the long intricate email discussion between Jim Hafner and myself, let me try to explain the issue. SCSI architecture (SAM2) is based on an intuition that SCSI ports are fixed (e.g., physical) things that have names. So far, the existence of the names has been an intellectual curiosity as they haven't mattered to any visible SCSI functionality. Single port Initiators predominate in both Parallel SCSI and Fibre Channel (e.g., a dual ported Fibre Channel HBA is usually treated as two SCSI Initiators, not a single dual-ported one). Jim tells us that T10 is about to define persistent reserve functionality that depends on the identity of the SCSI Initiator Port - in particular that under some circumstances, persistent reservations will be associated with the Initiator Port independent of the Target Port. Persistent reservations are currently bound to the Initiator Port and Target Port (as well as the LU they affect). For the rest of this message, I'm going to assume that we want to support this functionality. Assuming this and that I got the description in this paragraph right ... ... I need to take a slight detour into pragmatics. Those who configure storage networks rapidly discover the value of consistency and matching configurations. Multi-path I/O configurations tend to want to see access to the same set of LUs consistently across a set of interfaces (i.e., Ports). Between suitable configuration and the aggressive setup of connections to all possible targets, all the required connections come into existence as part of the boot process. Applying this experience to the new persistent reservation functionality, one would expect persistent reservations that are bound only to an Initiator Port to be independent of the Target Port, in that the reservation should span connections to all of the relevant Target Ports and those connections should come into existence as part of the boot process. Turning to iSCSI, the situation gets complicated by the interaction of two factors: - Parallel sessions are permitted down to the interface level (e.g., more than one iSCSI session may exist that uses IP addresses A and B to connect iSCSI Initiator I to iSCSI Target T). - SCSI disallows parallel nexii (i.e., more than one session between the same two SCSI Ports). If SCSI Ports are mapped to hardware entities such as network interfaces in iSCSI, the opportunity for parallel sessions between the same pair of network interfaces vanishes. In order to avoid that outcome, iSCSI Initiator Ports have to be mapped to software entities. To date, the ISID has been used to identify those software entities, and the only rule on their allocation is: ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal Group (SCSI target port), then can be only one session with a given ISID (identifying a SCSI initiator port). See 3.12.8. In order to get the expected outcome of the new functionality being defined by T10, the same ISID has to be used to establish all the connections that the persistent reservation is supposed to span. Unfortunately, that's above and beyond what iSCSI requires - the relevant text about doing this in -08 is: The "ISID rule" does not preclude the use of the same ISID from the same iSCSI Initiator with different Target Portal Groups on the same iSCSI target or on other iSCSI targets "does not preclude" is rather weak language for something that's essential to making a piece of SCSI functionality work. If an iSCSI implementation uses a different ISID for every session (which is also not precluded by the current text), then persistent reservations will never span Targets or Target Ports for that implementation despite T10's best efforts and intentions. IMHO, allowing that outcome is *wrong* (and this is the source of the difference of opinion between Jim and myself). The correction to this involves what Jim has called "conservative reuse" of ISIDs. This is something like for each ISID that an implementation uses, a connection with that ISID is made to every possible Target Portal Group of every possible Target. I suspect a longer explanation than this will be needed, including a discussion of the desirability of avoiding a situation in which the same ISID is used by two iSCSI implementations that are part of the same Initiator and set up sessions concurrently. IMHO, if we want to support persistent reservations at this stage that span target ports, we need to replace the "does not preclude" language with a REQUIREMENT for conservative reuse to avoid a situation in which SCSI functionality that works consistently with other transports works inconsistently with iSCSI (i.e., doesn't work with iSCSI implementations that don't do conservative reuse). Stepping back from the assumption that support for port-spanning persistent reservations is required, I observe that the conservative reuse rule impacts all implementations, even those that will never use such persistent reservations because ISID is a mandatory part of the iSCSI protocol. If a text key were used instead, only those Initiators that want to support this functionality on which T10 is "crossing a few t's and dotting a few i's" are affected (the text key is optional). The text key would be subject to a conservative reuse rule similar to the one that would be needed for ISIDs, and once T10 finishes the i's and t's, we can precisely reference the SCSI features (persistent reservation expansion) that require use of this text key. In addition, text keys have much better alternatives for dealing with conflicts than ISIDs - if a text key conflicts, it is possible to continue the negotiation with a different text key, whereas ISID conflict is fatal to one of the two sessions involved. As Jim has previously observed, changing the text key (e.g., generate a large random number in response to a conflict), results in a situation that can be dealt with by software that uses persistent reservations, although this departure from conservative reuse should only occur as a consequence of some sort of configuration mistake or bug. At the tail end of this reasoning chain is the observation that use of this text key leaves the ISID without value/purpose, and hence would call for its removal (or perhaps designation as a reserved field). Putting on my WG chair hat for a moment, I can accept either alternative outlined above: - Add conservative reuse to the ISID rule. - Use a text key for iSCSI port identification. But I'm not comfortable with the current situation in which iSCSI implementations are permitted to break T10-defined SCSI features that will work as expected in other SCSI transports. I hope this now makes sense to more people than just Jim and I, and I apologize for the length of this message, as this is a somewhat subtle issue. 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 --------------------------------------------------- --0__=07BBE072DFDD55B18f9e8a93df938690918c07BBE072DFDD55B1 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

David,

An excellent summary of the issues.

A couple of things I want to point out about the "text key" proposal, however.
a) The proposal sounds to me like iSCSI will have "optional SCSI Port names". Only when the key is used is the SCSI port named and when the key is not used, there is no such name. That's probably an acceptable situation as far as SAM-2 is concerned, but it certainly is odd.
b) The proposal would require at least as much coordination above the "session manager" level as managing ISIDs, though admittedly, it need not be implemented in all cases.
c) I'm concerned how to describe the model when names are optional, so as to avoid the parallel nexus problem. Is it that all initiator session endpoints that don't provide this text key have *implicit* unique names and only when the text key is presented does the name get explicit (and then possibly not be unique)? In that case, the key would have to be supplied in login next to the InitiatorName.

Jim Hafner

Sent by: owner-ips@ece.cmu.edu

To: ips@ece.cmu.edu
cc:
Subject: iSCSI: ISID issue summary



For those who haven't been following the long intricate
email discussion between Jim Hafner and myself, let me
try to explain the issue.

SCSI architecture (SAM2) is based on an intuition that SCSI
ports are fixed (e.g., physical) things that have names.  So
far, the existence of the names has been an intellectual
curiosity as they haven't mattered to any visible SCSI
functionality.  Single port Initiators predominate in
both Parallel SCSI and Fibre Channel (e.g., a dual ported
Fibre Channel HBA is usually treated as two SCSI Initiators,
not a single dual-ported one).

Jim tells us that T10 is about to define persistent reserve
functionality that depends on the identity of the SCSI Initiator
Port - in particular that under some circumstances, persistent
reservations will be associated with the Initiator Port independent
of the Target Port.  Persistent reservations are currently bound
to the Initiator Port and Target Port (as well as the LU they
affect).  For the rest of this message, I'm going to assume
that we want to support this functionality.  Assuming this and
that I got the description in this paragraph right ...

... I need to take a slight detour into pragmatics.  Those
who configure storage networks rapidly discover the value
of consistency and matching configurations.  Multi-path I/O
configurations tend to want to see access to the same set of LUs
consistently across a set of interfaces (i.e., Ports).  Between
suitable configuration and the aggressive setup of connections
to all possible targets, all the required connections come into
existence as part of the boot process.  Applying
this experience to the new persistent reservation functionality,
one would expect persistent reservations that are bound only to
an Initiator Port to be independent of the Target Port, in that
the reservation should span connections to all of the relevant
Target Ports and those connections should come into existence
as part of the boot process.

Turning to iSCSI, the situation gets complicated by the
interaction of two factors:
- Parallel sessions are permitted down to the interface
level (e.g., more than one iSCSI session may exist
that uses IP addresses A and B to connect iSCSI Initiator
I to iSCSI Target T).
- SCSI disallows parallel nexii (i.e., more than one session
between the same two SCSI Ports).
If SCSI Ports are mapped to hardware entities such as network
interfaces in iSCSI, the opportunity for parallel sessions
between the same pair of network interfaces vanishes.  In order
to avoid that outcome, iSCSI Initiator Ports have to be
mapped to software entities. To date, the ISID has been
used to identify those software entities, and the only rule
on their allocation is:

    ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal
    Group (SCSI target port), then can be only one session with a given
    ISID (identifying a SCSI initiator port).  See 3.12.8.

In order to get the expected outcome of the new functionality
being defined by T10, the same ISID has to be used to establish
all the connections that the persistent reservation is supposed
to span.  Unfortunately, that's above and beyond what iSCSI
requires - the relevant text about doing this in -08 is:

       The "ISID rule" does not preclude
       the use of the same ISID from the same iSCSI Initiator with
       different Target Portal Groups on the same iSCSI target or
       on other iSCSI targets

"does not preclude" is rather weak language for something that's
essential to making a piece of SCSI functionality work.  If an
iSCSI implementation uses a different ISID for every session
(which is also not precluded by the current text), then persistent
reservations will never span Targets or Target Ports for that
implementation despite T10's best efforts and intentions.  IMHO,
allowing that outcome is *wrong* (and this is the source of the
difference of opinion between Jim and myself).

The correction to this involves what Jim has called "conservative
reuse" of ISIDs.  This is something like for each ISID that an
implementation uses, a connection with that ISID is made to
every possible Target Portal Group of every possible Target.  I
suspect a longer explanation than this will be needed, including
a discussion of the desirability of avoiding a situation in which
the same ISID is used by two iSCSI implementations that are part
of the same Initiator and set up sessions concurrently.

IMHO, if we want to support persistent reservations at this stage
that span target ports, we need to replace the "does not preclude"
language with a REQUIREMENT for conservative reuse to avoid a
situation in which SCSI functionality that works consistently with
other transports works inconsistently with iSCSI (i.e., doesn't
work with iSCSI implementations that don't do conservative reuse).

Stepping back from the assumption that support for port-spanning
persistent reservations is required, I observe that the conservative
reuse rule impacts all implementations, even those that will never
use such persistent reservations because ISID is a mandatory part
of the iSCSI protocol.  If a text key were used instead, only those
Initiators that want to support this functionality on which T10
is "crossing a few t's and dotting a few i's" are affected (the
text key is optional).  The text key would be subject to a
conservative reuse rule similar to the one that would be needed
for ISIDs, and once T10 finishes the i's and t's, we can precisely
reference the SCSI features (persistent reservation expansion)
that require use of this text key.

In addition, text keys have much better alternatives for dealing
with conflicts than ISIDs - if a text key conflicts, it is possible
to continue  the negotiation with a different text key, whereas
ISID conflict is fatal to one of the two sessions involved.
As Jim has previously observed, changing the text key (e.g.,
generate a large random number in response to a conflict),
results in a situation that can be dealt with by software that
uses persistent reservations, although this departure from
conservative reuse should only occur as a consequence of some
sort of configuration mistake or bug.  At the tail end of this
reasoning chain is the observation that use of this text key
leaves the ISID without value/purpose, and hence would call
for its removal (or perhaps designation as a reserved field).

Putting on my WG chair hat for a moment, I can accept either
alternative outlined above:
- Add conservative reuse to the ISID rule.
- Use a text key for iSCSI port identification.
But I'm not comfortable with the current situation in which iSCSI
implementations are permitted to break T10-defined SCSI features
that will work as expected in other SCSI transports.

I hope this now makes sense to more people than just Jim and I,
and I apologize for the length of this message, as this is a
somewhat subtle issue.

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
---------------------------------------------------

--0__=07BBE072DFDD55B18f9e8a93df938690918c07BBE072DFDD55B1-- From owner-ips@ece.cmu.edu Wed Oct 10 13:02: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 NAA14772 for ; Wed, 10 Oct 2001 13:02:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9AGDWH27097 for ips-outgoing; Wed, 10 Oct 2001 12:13:32 -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 f9AGDUl27085 for ; Wed, 10 Oct 2001 12:13:30 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id B38191F8F3; Wed, 10 Oct 2001 09:13:24 -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 JAA17312; Wed, 10 Oct 2001 09:13:20 -0700 (PDT) Message-ID: <3BC47558.14C0268D@cup.hp.com> Date: Wed, 10 Oct 2001 09:20:40 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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: ips : Negotiation Reset. 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 think I did'nt come across the first time. Here's another attempt !) Why is the reject reason code "Negotiation Reset" required ? Per Section 8.7, any failure of a text cmd/rsp while in FFP causes a "negotiation reset" (i.e. operational parameters are reset to thee values agreed upon during an earlier successful negotiation). So, why do you need an explicit reason called "negotiation reset" (?) Any failure of a text cmd at the target end would be conveyed through either a "data digest error" or "protocol error". The operational parameters are understood to be reset on any failure of the text sequence. Also, I suggest that the reject reason codes 0x09 & 0x0a (Bookmark Reject) be removed and replaced by a reason called "Invalid Target Transfer Tag". (now that bookmarks are gone.) Thanks, Santosh Julian Satran wrote: > > 8.7 has all the answers. Julo > > > Julian, > > The reject reason code "Negotiation Reset" is listed (newly) in Section > 3.17.1. > > If one of the text commands from an initiator were to be rejected by the > target for some other reason code than "Negotiation Reset", what is the > effect of such a reject on the operational parameters ? > > Are'nt all operational parameters reset, any time a text exchange ends > unsuccessfully ? I suggest the draft clearly state that ANY > un-successful termination of a login/text exchange results in a reset of > operational parameters. The "Negotiation Reset" reject reason code can > be removed as well. > > 2) Also, what does the phrase "reset an operational parameter > negotiation " mean ? Are the parameters reset to their default values , > or are they reset to their previous values ? This needs to be explicitly > clarified. > > 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 Wed Oct 10 13:04: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 NAA14807 for ; Wed, 10 Oct 2001 13:04:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9AFwec26019 for ips-outgoing; Wed, 10 Oct 2001 11:58:40 -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 f9AFwcl26015 for ; Wed, 10 Oct 2001 11:58: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 96F00E8E; Wed, 10 Oct 2001 08:58:37 -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 IAA16619; Wed, 10 Oct 2001 08:58:32 -0700 (PDT) Message-ID: <3BC471E0.C9CCB1E8@cup.hp.com> Date: Wed, 10 Oct 2001 09:05:52 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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 - TTT in negotiations 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 thought we already had the below mechanism in place since 7.9x and TTT in text cmd/rsp had already replaced the bookmark mechanisms. What, then, is being proposed below ?? - Santosh Julian Satran wrote: > > Dear colleagues, > > It occurred to us that we may want to have a simple (more regular) way > to "index" at target into ongoing text negotiations (not login) and we > may want the target to be able to set it's TTT whenever the F bit is > not 0 and to mandate the initiator to copy it in the next text command > in the chain. This might make bookmarks and long negotiations behave > similarly (and time-out,/ be reset similarly). > > Comments? > > 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 Wed Oct 10 13:23: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 NAA15579 for ; Wed, 10 Oct 2001 13:23:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9AGHN127375 for ips-outgoing; Wed, 10 Oct 2001 12:17: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 f9AGHKl27362 for ; Wed, 10 Oct 2001 12:17:20 -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 SAA210284 for ; Wed, 10 Oct 2001 18:17: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 f9AGH4Y15950 for ; Wed, 10 Oct 2001 18:17:04 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - TTT in negotiations X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 10 Oct 2001 19:17:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 10/10/2001 19:17:04, Serialize complete at 10/10/2001 19:17:04 Content-Type: multipart/alternative; boundary="=_alternative 00597FE3C2256AE1_=" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 00597FE3C2256AE1_= Content-Type: text/plain; charset="us-ascii" Bookmarks (TTT) are not mandated for a a general purpose negotiation (a sequence of text request responses). We created it for long responses mainly (SendTargets and futures).. What we are proposing now is to mandate it for every request/response that has F=0 and use it to reset/time-out a negotiation in general. Julo Santosh Rao Sent by: santoshr@cup.hp.com 10-10-01 18:05 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - TTT in negotiations Julian, I thought we already had the below mechanism in place since 7.9x and TTT in text cmd/rsp had already replaced the bookmark mechanisms. What, then, is being proposed below ?? - Santosh Julian Satran wrote: > > Dear colleagues, > > It occurred to us that we may want to have a simple (more regular) way > to "index" at target into ongoing text negotiations (not login) and we > may want the target to be able to set it's TTT whenever the F bit is > not 0 and to mandate the initiator to copy it in the next text command > in the chain. This might make bookmarks and long negotiations behave > similarly (and time-out,/ be reset similarly). > > Comments? > > Julo -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## --=_alternative 00597FE3C2256AE1_= Content-Type: text/html; charset="us-ascii"
Bookmarks (TTT) are not mandated for a a general purpose negotiation (a sequence of text request responses). We created it for long responses mainly (SendTargets and futures)..

What we are proposing now is to mandate it for every request/response that has F=0 and use it to reset/time-out
a negotiation in general.

Julo


Santosh Rao <santoshr@cup.hp.com>
Sent by: santoshr@cup.hp.com

10-10-01 18:05
Please respond to Santosh Rao

       
        To:        Julian Satran/Haifa/IBM@IBMIL
        cc:        ips@ece.cmu.edu
        Subject:        Re: iSCSI - TTT in negotiations

       


Julian,

I thought we already had the below mechanism in place since 7.9x and TTT
in text cmd/rsp had already replaced the bookmark mechanisms.

What, then, is being proposed below ??

- Santosh


Julian Satran wrote:
>
> Dear colleagues,
>
> It occurred to us that we may want to have a simple (more regular) way
> to "index" at target into ongoing text negotiations (not login) and we
> may want the target to be able to set it's TTT whenever the F bit is
> not 0 and to mandate the initiator to copy it in the next text command
> in the chain.  This might make bookmarks and long negotiations behave
> similarly (and time-out,/ be reset similarly).
>
> Comments?
>
> Julo

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

--=_alternative 00597FE3C2256AE1_=-- From owner-ips@ece.cmu.edu Wed Oct 10 14:05: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 OAA17092 for ; Wed, 10 Oct 2001 14:05:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9AGc0928707 for ips-outgoing; Wed, 10 Oct 2001 12:38:00 -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 f9AG64l26567 for ; Wed, 10 Oct 2001 12:06:04 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f9AG5mD26766; Wed, 10 Oct 2001 12:05:48 -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 f9AG5l019115; Wed, 10 Oct 2001 12:05:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15300.29190.739000.376119@gargle.gargle.HOWL> Date: Wed, 10 Oct 2001 12:06:30 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU 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 10 October 2001) by Julian Satran: > Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it > may have large holes and using it in an implementation is as bad as a > hashed index. Not true. CmdSN values are sequential, by definition. Yes, clearly there will be small holes because commands complete out of order. But "large" holes are unlikely. In any case, the target has control over that. I can use an array whose size is given by the number of pending commands times a correction factor to account for the likely density of holes. Then MaxCmdSN would be updated based on two considerations: the ability to handle more pending commands, and the need to keep the distance between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the size of the lookup array. So having CmdSN in the DataOut PDU allows this approach, thereby replacing a hash lookup on a rapidly changing ID space by a simple array indexing operation. Without CmdSN, you're forced to use a mechanism that has a lot more overhead (in the insert/remove or in the lookup, depending on the mechanism chosen). paul From owner-ips@ece.cmu.edu Wed Oct 10 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 OAA18248 for ; Wed, 10 Oct 2001 14:48:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9AHZI502895 for ips-outgoing; Wed, 10 Oct 2001 13:35:18 -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 f9AHZFl02889 for ; Wed, 10 Oct 2001 13:35:15 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail16.vwh1.net (RS ver 1.0.60s) with SMTP id 041767135; Wed, 10 Oct 2001 13:08:22 -0400 (EDT) From: "Deva-Adaptec" To: "Julian Satran" , Subject: RE: iSCSI - TTT in negotiations Date: Wed, 10 Oct 2001 10:15:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C15174.6F7FFEC0" 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 In-Reply-To: Importance: Normal X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C15174.6F7FFEC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Julian, If it is being done for general purpose also, how will the initiator know if a target has a long text to send and wait for it, when F bit is zero? Am I missing something? Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Wednesday, October 10, 2001 9:17 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - TTT in negotiations Bookmarks (TTT) are not mandated for a a general purpose negotiation (a sequence of text request responses). We created it for long responses mainly (SendTargets and futures).. What we are proposing now is to mandate it for every request/response that has F=0 and use it to reset/time-out a negotiation in general. Julo Santosh Rao Sent by: santoshr@cup.hp.com 10-10-01 18:05 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - TTT in negotiations Julian, I thought we already had the below mechanism in place since 7.9x and TTT in text cmd/rsp had already replaced the bookmark mechanisms. What, then, is being proposed below ?? - Santosh Julian Satran wrote: > > Dear colleagues, > > It occurred to us that we may want to have a simple (more regular) way > to "index" at target into ongoing text negotiations (not login) and we > may want the target to be able to set it's TTT whenever the F bit is > not 0 and to mandate the initiator to copy it in the next text command > in the chain. This might make bookmarks and long negotiations behave > similarly (and time-out,/ be reset similarly). > > Comments? > > Julo -- ################################## Santosh Rao Software Design Engineer, HP-UX iSCSI Driver Team, Hewlett Packard, Cupertino. email : santoshr@cup.hp.com Phone : 408-447-3751 ################################## ------=_NextPart_000_000C_01C15174.6F7FFEC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Julian,
 
If it=20 is being done for general purpose also, how will the initiator know if a = target=20 has a long text to send and wait for it, when F bit is zero? Am I = missing=20 something?
 
 
Deva
Adaptec
 
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Wednesday, October 10, 2001 9:17 = AM
To:=20 ips@ece.cmu.edu
Subject: Re: iSCSI - TTT in=20 negotiations


Bookmarks=20 (TTT) are not mandated for a a general purpose negotiation (a sequence = of text=20 request responses). We created it for long responses mainly = (SendTargets and=20 futures)..

What we are = proposing=20 now is to mandate it for every request/response that has F=3D0 and use = it to=20 reset/time-out
a = negotiation in=20 general.

Julo =


Santosh Rao=20 <santoshr@cup.hp.com>
Sent by: santoshr@cup.hp.com=20

10-10-01 18:05 =
Please respond to Santosh Rao =

        =
        To: =    =20    Julian Satran/Haifa/IBM@IBMIL
        cc: =    =20    ips@ece.cmu.edu
        Subject:     =  =20  Re: iSCSI - TTT in negotiations

      =  


Julian,

I thought we already had = the below=20 mechanism in place since 7.9x and TTT
in text cmd/rsp had already = replaced=20 the bookmark mechanisms.

What, then, is being proposed below=20 ??

- Santosh


Julian Satran wrote:
>
> = Dear=20 colleagues,
>
> It occurred to us that we may want to = have a=20 simple (more regular) way
> to "index" at target into ongoing = text=20 negotiations (not login) and we
> may want the target to be able = to set=20 it's TTT whenever the F bit is
> not 0 and to mandate the = initiator to=20 copy it in the next text command
> in the chain.  This = might make=20 bookmarks and long negotiations behave
> similarly (and = time-out,/ be=20 reset similarly).
>
> Comments?
>
> = Julo

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


------=_NextPart_000_000C_01C15174.6F7FFEC0-- From owner-ips@ece.cmu.edu Wed Oct 10 15:26: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 PAA19140 for ; Wed, 10 Oct 2001 15:26:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9AIRPg06981 for ips-outgoing; Wed, 10 Oct 2001 14:27:25 -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 f9AIRNl06970 for ; Wed, 10 Oct 2001 14:27:23 -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 UAA98176 for ; Wed, 10 Oct 2001 20:27: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 f9AIRGY291706 for ; Wed, 10 Oct 2001 20:27:16 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI - TTT in negotiations X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 10 Oct 2001 21:27:13 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 10/10/2001 21:27:16, Serialize complete at 10/10/2001 21:27:16 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk From context - the same as on a long negotiation. F 0 indicates that target hasn't finished - the context indicates what. Julo "Deva-Adaptec" 10-10-01 19:15 Please respond to "Deva-Adaptec" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: RE: iSCSI - TTT in negotiations Julian, If it is being done for general purpose also, how will the initiator know if a target has a long text to send and wait for it, when F bit is zero? Am I missing something? Deva Adaptec -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Wednesday, October 10, 2001 9:17 AM To: ips@ece.cmu.edu Subject: Re: iSCSI - TTT in negotiations Bookmarks (TTT) are not mandated for a a general purpose negotiation (a sequence of text request responses). We created it for long responses mainly (SendTargets and futures).. What we are proposing now is to mandate it for every request/response that has F=0 and use it to reset/time-out a negotiation in general. Julo Santosh Rao Sent by: santoshr@cup.hp.com 10-10-01 18:05 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - TTT in negotiations Julian, I thought we already had the below mechanism in place since 7.9x and TTT in text cmd/rsp had already replaced the bookmark mechanisms. What, then, is being proposed below ?? - Santosh Julian Satran wrote: > > Dear colleagues, > > It occurred to us that we may want to have a simple (more regular) way > to "index" at target into ongoing text negotiations (not login) and we > may want the target to be able to set it's TTT whenever the F bit is > not 0 and to mandate the initiator to copy it in the next text command > in the chain. This might make bookmarks and long negotiations behave > similarly (and time-out,/ be reset similarly). > > Comments? > > 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 Wed Oct 10 19: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 TAA23159 for ; Wed, 10 Oct 2001 19:48:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9AMvE526742 for ips-outgoing; Wed, 10 Oct 2001 18:57:14 -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 f9AMvDl26735 for ; Wed, 10 Oct 2001 18:57:13 -0400 (EDT) Received: by mxic1.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Oct 2001 18:59:24 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD86D@CORPMX14> From: Black_David@emc.com To: hafner@almaden.ibm.com, ips@ece.cmu.edu Subject: iSCSI: ISID progress Date: Wed, 10 Oct 2001 18:48: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 This message is shorter than my last one, so that's at least a superficial indication of progress ;-). Jim and Julian had four comments/objections to the notion of using a text key to indicate iSCSI Initiator Port Name. Summarizing and responding: Jim (a): Optional use of port name is ok as far as SAM-2 is concerned, but is odd. Indeed it is odd, but given the choice between an odd mapping of SAM-2 to iSCSI and allowing odd behavior of iSCSI implementations, I'll take the former. Jim (b): Would require at least as much coordination above the session level of iSCSI as ISIDs. That would be incorrect. 128 bits is sufficient to eliminate coordination. The reference for this is an expired Internet- Draft, draft-leach-uuids-guids-01.txt, that can still be found on the web at: http://casbah.org/cbRFC/misc/draft-leach-uuids-guids-01.txt http://globecom.net/ietf/draft/draft-leach-uuids-guids-01.html I'm not seriously proposing that port name generation be done in this fashion, but rather providing a widely used counter- example to Jim's statement. Note that a network interface MAC is likely to be available to many iSCSI implementations. Jim (c): How to describe model when the text key is optional? "Is it that all initiator session endpoints that don't provide this text key have *implicit* unique names and only when the text key is presented does the name get explicit (and then possibly not be unique)? In that case, the key would have to be supplied in login next to the InitiatorName. Yes and yes when it's used, in that order. Jim's comment (a) about this being odd applies. Julian: ... and have as much chances to blow a session as ISID That would also be incorrect. As previously stated, ISID conflict is fatal to one of the sessions involved (one cannot change the ISID and continue), and can occur in any system that opens parallel sessions. This text key conflict need not be fatal (one can change the text key and continue negotiation) and can only occur in systems that want to use the new port-spanning persistent reservation functionality, as other systems won't use the text key. Also see the draft noted in response to Jim (b) above; Julian's "have as much chance" language is incorrect. As previously noted, I can also deal with requiring conservative reuse of ISIDs as a means to address this situation. 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 Oct 10 19: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 TAA23211 for ; Wed, 10 Oct 2001 19:52:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9ANK2e28219 for ips-outgoing; Wed, 10 Oct 2001 19:20:02 -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 f9ANK0l28211 for ; Wed, 10 Oct 2001 19:20:00 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 70BC3D6F for ; Wed, 10 Oct 2001 16:19: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 QAA19422 for ; Wed, 10 Oct 2001 16:19:53 -0700 (PDT) Message-ID: <3BC4D952.5E91CD2E@cup.hp.com> Date: Wed, 10 Oct 2001 16:27:14 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re: ips : Negotiation Reset. 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, Further comments below. Thanks, Santosh Julian Satran wrote: > Comments in text. Julo > Why is the reject reason code "Negotiation Reset" required ? Per > Section > 8.7, any failure of a text cmd/rsp while in FFP causes a "negotiation > reset" (i.e. operational parameters are reset to thee values agreed > upon > during an earlier successful negotiation). > > +++ Today we reset with a task abort (task managemenT). The proposed > change to mandate TTT > might unify this space ++++ The parameters are reset on any of the following events (as called out in 8.7) : a) target rejects any one of the text cmds in the exchange. b) initiator timeout of any one text cmd in the text exchange. [this can cause the initiator to issue an abort task to abort the text exchange, or tear down the cxn as recovery.] Now, my question is about the *specific* reason why a reject with reason code "Negotiation Reset" is required. I presume this can only be used in case (a) contexts to reset parameters, since in case (b), the abort task completion or cxn teardown leads to parameter reset. Now, in case (a), is'nt it assumed that *ANY* reject will lead to a parameter reset ? Given this, why do we need an explicit reason code "Negotiation Reset" ? The above issue is independent of the "mandatory TTT in text" proposal, right (?). [Please help me understand by giving an example where "negotiation reset" would be returned by a tgt.] On a seperate note, the following case described in 8.7 : - None of the choices or the stated value is acceptable to one negotiating side. should not cause a reset of all the parameters ? It should only reset that specific parameter to its previous value. > So, why do you need an explicit reason called "negotiation reset" (?) > Any failure of a text cmd at the target end would be conveyed through > either a "data digest error" or "protocol error". The operational > parameters are understood to be reset on any failure of the text > sequence. > > Also, I suggest that the reject reason codes 0x09 & 0x0a (Bookmark > Reject) be removed and replaced by a reason called "Invalid Target > Transfer Tag". (now that bookmarks are gone.) > > +++ WE could if TTT becomes generalized for sequences - today t is > not +++ Again, the reason codes for "Bookmark Reject" are defined today for the long text scenario, and I suggest that they be removed and replaced with an "Invalid Target Transfer Tag". Both the former and latter are [currently] meant for long text cmds and so the change should be ok. (?) Lastly, the term "reset operational parameters" is used in several places. I suggest the specific operation associated with it be called out in places where the term 'reset' is being used. Ex : Section 3.10.3, 3.11.3, 6. -- ################################## 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 Wed Oct 10 19:57: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 TAA23320 for ; Wed, 10 Oct 2001 19:57:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9ANSlX28759 for ips-outgoing; Wed, 10 Oct 2001 19:28:47 -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 f9ANSkl28755 for ; Wed, 10 Oct 2001 19:28:46 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id A72BCEE9 for ; Wed, 10 Oct 2001 16:28:45 -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 QAA20442 for ; Wed, 10 Oct 2001 16:28:41 -0700 (PDT) Message-ID: <3BC4DB62.C0A3936E@cup.hp.com> Date: Wed, 10 Oct 2001 16:36:02 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: [Fwd: iSCSI - revised 2.2.4] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, What is the resolution on this issue ? - Santosh Santosh Rao wrote: > > Julian, > > I apologize upfront for being so persistent on this. > > However, it would really help if you could give some clear example of a > scenario as to why the initiator cannot be considered the originator of > a negotiation, when it offers a key value implicitly, through the use of > a default. > > Several people on this list (Paul Konning, Sanjeev, Deva, myself, and > perhaps others, that I cannot recall at the moment) have asked that the > spec must not differentiate login behaviour when the initiator offers a > key explicitly vs. when it offers a key implicitly thru the use of the > default. > > Please help us understand the need for iscsi to distingush the login > behaviour in the above case. [through some tangible scenarios and > examples]. > > Thanks, > Santosh > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Julian, > > > > I would also request an explicit definition of offering party and > > responding party. The current text still leaves ambiguity when target > > sends a key in response to implicit default key of the Intiator. In > > this case who is the offering party and who is the responding party > > > > Sanjeev > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, October 05, 2001 2:06 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI - revised 2.2.4 > > > > Here is a revised (complete) part 2.2.4 based on recent > > agreed changes: > > > > 1.1.1 Text Mode Negotiation > > > > During login and thereafter some session or connection > > parameters are negotiated through an exchange of textual > > information. > > > > All negotiations are stateless - i.e. the result MUST be > > based only on newly exchanged values. > > > > The general format of text negotiation is: > > > > Originator-> = > > Responder-> =|reject|NotUnderstood > > > > The value can be a number, a single literal constant a > > Boolean value (yes or no) or a list of comma separated > > literal constant values. > > > > In literal list negotiation, the originator sends for each > > key a list of options (literal constants which may include > > "none") in its order of preference. > > > > The responding party answers with the first value from the > > list it supports and is allowed to use for the specific > > originator. > > > > The constant "none" MUST always be used to indicate a > > missing function. However, none is a valid selection only if > > it is explicitly offered. > > > > If a target is not supporting, or not allowed to use with a > > specific originator, any of the offered options, it may use > > the constant "reject". The constants "none" and "reject" > > are reserved and must be used only as described here. Any > > key not understood is answered with "NotUnderstood". > > > > For numerical and single literal negotiations, the > > responding party MUST respond with the required key and the > > value it selects, based on the selection rule specific to > > the key, becomes the negotiation result. Selection of a > > value not admissible under the selection rules is considered > > a protocol error and handled accordingly. > > > > For Boolean negotiations (keys taking the values yes or no), > > the responding party MUST respond with the required key and > > the result of the negotiation when the received value does > > not determine that result by itself. The last value > > transmitted becomes the negotiation result. The rules for > > selecting the value to respond with are expressed as Boolean > > functions of the value received and the value that the > > responding party would select in the absence of knowledge of > > the received value. > > > > Specifically, the two cases in which responses are OPTIONAL > > are: > > > > - The Boolean function is "AND" and the value "no" is > > received. The outcome of the negotiation is "no". > > - The Boolean function is "OR" and the value "yes" is > > received. The outcome of the negotiation is "yes". > > > > Responses are REQUIRED in all other cases, and the value > > chosen and sent by the responder becomes the outcome of the > > negotiation. > > > > The value "?" with any key has the meaning of enquiry and > > should be answered with the current value or > > "NotUnderstood". > > > > 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, only the initiator can > > initiate the negotiation start (through the first Text > > request) and completion (by setting to 1 and keeping to 1 > > the F bit in a Text request). > > > > Comments ? > > > > Julo > > -- > ################################## > 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 Wed Oct 10 21:11: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 VAA23991 for ; Wed, 10 Oct 2001 21:11:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9B0JWi01648 for ips-outgoing; Wed, 10 Oct 2001 20:19:32 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9B0JUl01644 for ; Wed, 10 Oct 2001 20:19:30 -0400 (EDT) Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345) id 9498B2694; Wed, 10 Oct 2001 19:19:24 -0500 (CDT) Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.110.250.124]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 8ACFB26E0 for ; Wed, 10 Oct 2001 19:19:24 -0500 (CDT) Received: from cceexc17.americas.cpqcorp.net ([16.110.250.84]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 10 Oct 2001 19:19:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: iSCSI: ISID issue summary Date: Wed, 10 Oct 2001 19:19:22 -0500 Message-ID: <78AF3C342AEAEF4BA33B35A8A15668C6019E206F@cceexc17.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: iSCSI: ISID issue summary Thread-Index: AcFRLXP4xScf7b0fEdW/wgAIx7rcqAAs9sBA From: "Elliott, Robert" To: X-OriginalArrivalTime: 11 Oct 2001 00:19:23.0047 (UTC) FILETIME=[60BFE370:01C151EA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f9B0JUl01645 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit David Black wrote: > SCSI architecture (SAM2) is based on an intuition that SCSI > ports are fixed (e.g., physical) things that have names. So > far, the existence of the names has been an intellectual > curiosity as they haven't mattered to any visible SCSI > functionality. Not quite true. The Fibre Channel port's Worldwide_Name - what SAM-2 now calls the initiator port name - is used today for persistent reservations. SPC-2 has this wording: For those SCSI protocols for which the initiator port's world wide identification is available to the device server the initiator port's world wide identification shall be used to determine if the initiator identifier has changed. FCP-2 indicates that the Worldwide_Name of the Fibre Channel port serves as the "initiator port's world wide identification." (that phrase will change to "initiator port name" as Jim's (accepted) T10 name proposal is digested.) > Single port Initiators predominate in > both Parallel SCSI and Fibre Channel (e.g., a dual ported > Fibre Channel HBA is usually treated as two SCSI Initiators, > not a single dual-ported one). According to the SAM-2 multiport model, you can upgrade that "usually" to "always." The key to the multiport model is: Initiator = initator port Target = target port In FCP-2, initiator ports equal Fibre Channel ports. There's no way to treat two physical ports as the same initiator without violating the standards. The multiport model defines "initiator device" as the object that contains multiple initiator ports. The initiator device has neither an address nor a name in any existing protocol. There are no commands that rely on it. Jim wanted to start using that concept for iSCSI access controls. > Jim tells us that T10 is about to define persistent reserve > functionality that depends on the identity of the SCSI Initiator > Port - in particular that under some circumstances, persistent > reservations will be associated with the Initiator Port independent > of the Target Port. Persistent reservations are currently bound > to the Initiator Port and Target Port (as well as the LU they > affect). For the rest of this message, I'm going to assume Again, the reason for this is the multiport model that says initiator = initiator port and target = target port. > that we want to support this functionality. Assuming this and > that I got the description in this paragraph right ... > > ... I need to take a slight detour into pragmatics. Those > who configure storage networks rapidly discover the value > of consistency and matching configurations. Multi-path I/O > configurations tend to want to see access to the same set of LUs > consistently across a set of interfaces (i.e., Ports). Between > suitable configuration and the aggressive setup of connections > to all possible targets, all the required connections come into > existence as part of the boot process. Applying > this experience to the new persistent reservation functionality, > one would expect persistent reservations that are bound only to > an Initiator Port to be independent of the Target Port, in that > the reservation should span connections to all of the relevant > Target Ports and those connections should come into existence > as part of the boot process. That's the goal of one of the T10 proposals. If initiators are identified only by their port addresses, it's not safe. The two target ports could be on different fabrics, where initiators are different but happen to have the same addresses. On a fabric where the initiator port has a name that is known to be worldwide unique, this becomes a non-issue if the initiator port name is used instead of the initiator port address. > Turning to iSCSI, the situation gets complicated by the > interaction of two factors: > - Parallel sessions are permitted down to the interface > level (e.g., more than one iSCSI session may exist > that uses IP addresses A and B to connect iSCSI Initiator > I to iSCSI Target T). > - SCSI disallows parallel nexii (i.e., more than one session > between the same two SCSI Ports). > If SCSI Ports are mapped to hardware entities such as network > interfaces in iSCSI, the opportunity for parallel sessions > between the same pair of network interfaces vanishes. In order > to avoid that outcome, iSCSI Initiator Ports have to be > mapped to software entities. To date, the ISID has been > used to identify those software entities, and the only rule > on their allocation is: > > ISID RULE: Between a given iSCSI Initiator and iSCSI > Target Portal Group (SCSI target port), then can be only > one session with a given ISID (identifying a SCSI > initiator port). See 3.12.8. There's a bit more than that. The "iSCSI Name" has to be included with the ISID to identify the initiator port. Jim wanted the iSCSI name to be the "initiator device name." > In order to get the expected outcome of the new functionality > being defined by T10, the same ISID has to be used to establish > all the connections that the persistent reservation is supposed > to span. Unfortunately, that's above and beyond what iSCSI > requires - the relevant text about doing this in -08 is: > > The "ISID rule" does not preclude > the use of the same ISID from the same iSCSI Initiator with > different Target Portal Groups on the same iSCSI target or > on other iSCSI targets > > "does not preclude" is rather weak language for something that's > essential to making a piece of SCSI functionality work. If an > iSCSI implementation uses a different ISID for every session > (which is also not precluded by the current text), then persistent > reservations will never span Targets or Target Ports for that > implementation despite T10's best efforts and intentions. IMHO, > allowing that outcome is *wrong* (and this is the source of the > difference of opinion between Jim and myself). > > The correction to this involves what Jim has called "conservative > reuse" of ISIDs. This is something like for each ISID that an > implementation uses, a connection with that ISID is made to > every possible Target Portal Group of every possible Target. I > suspect a longer explanation than this will be needed, including > a discussion of the desirability of avoiding a situation in which > the same ISID is used by two iSCSI implementations that are part > of the same Initiator and set up sessions concurrently. > > IMHO, if we want to support persistent reservations at this stage > that span target ports, we need to replace the "does not preclude" > language with a REQUIREMENT for conservative reuse to avoid a > situation in which SCSI functionality that works consistently with > other transports works inconsistently with iSCSI (i.e., doesn't > work with iSCSI implementations that don't do conservative reuse). As Nick noted, the problem is where do you store these ISIDs? For that matter, where do you store the iSCSI name? With Fibre Channel, the Worldwide_name is in a ROM associated with the port. With iSCSI you have no guarantee of hardware. You can usually find an Ethernet MAC address and could base a name off of that. However, there's no guarantees. For the SCSI RDMA Protocol for InfiniBand, we chose: initiator port name = 64-bit worldwide identifier from the InfiniBand channel adapter plus 64 extra bits All software using the same InfiniBand channel adapter have to coordinate usage of the extra bits, but single-OS single-driver systems can just fill them with zeros. > Stepping back from the assumption that support for port-spanning > persistent reservations is required, I observe that the conservative > reuse rule impacts all implementations, even those that will never > use such persistent reservations because ISID is a mandatory part > of the iSCSI protocol. Persistent reservations, access controls, extended copy, third-party XOR commands, and the supporting alias commands are all potential users of port names today. Protocol bridges and management tools may also benefit from using names rather than addresses. > If a text key were used instead, only those > Initiators that want to support this functionality on which T10 > is "crossing a few t's and dotting a few i's" are affected (the > text key is optional). The text key would be subject to a > conservative reuse rule similar to the one that would be needed > for ISIDs, and once T10 finishes the i's and t's, we can precisely > reference the SCSI features (persistent reservation expansion) > that require use of this text key. > > In addition, text keys have much better alternatives for dealing > with conflicts than ISIDs - if a text key conflicts, it is possible > to continue the negotiation with a different text key, whereas > ISID conflict is fatal to one of the two sessions involved. > As Jim has previously observed, changing the text key (e.g., > generate a large random number in response to a conflict), > results in a situation that can be dealt with by software that > uses persistent reservations, although this departure from > conservative reuse should only occur as a consequence of some > sort of configuration mistake or bug. At the tail end of this > reasoning chain is the observation that use of this text key > leaves the ISID without value/purpose, and hence would call > for its removal (or perhaps designation as a reserved field). This just seems to make the names more vague and volatile. Are the iSCSI name and ISID used as part of authentication? How does a device driver prove it has the right to use a certain iSCSI name/ISID? How does it prevent some other software from using its own iSCSI name/ISID? > Putting on my WG chair hat for a moment, I can accept either > alternative outlined above: > - Add conservative reuse to the ISID rule. > - Use a text key for iSCSI port identification. > But I'm not comfortable with the current situation in which iSCSI > implementations are permitted to break T10-defined SCSI features > that will work as expected in other SCSI transports. > > I hope this now makes sense to more people than just Jim and I, > and I apologize for the length of this message, as this is a > somewhat subtle issue. > > Comments? If we didn't have ISIDs we'd still have the same debate about managing the iSCSI names. Two software implementations on the same machine could choose the same iSCSI name and conflict - the same problems result. Jim's partitioning lets the OS pick an iSCSI name (unique from any other OS on the fabric, with any luck) and requires the OS coordinate ISIDs for any iSCSI drivers sharing that iSCSI name. A dedicated iSCSI HBA could also hand out ISIDs for drivers using it. This should limit the scope of conflicts to one system rather than the whole fabric. It'd be helpful to have standards for the OS or HBAs to solve this, but that seems outside the scope of the iSCSI protocol spec. > --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 > --------------------------------------------------- > --- Rob Elliott, Compaq Server Storage Robert.Elliott@compaq.com From owner-ips@ece.cmu.edu Wed Oct 10 23:18: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 XAA26975 for ; Wed, 10 Oct 2001 23:18:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9B2W6B08918 for ips-outgoing; Wed, 10 Oct 2001 22:32: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 f9B2W4l08908 for ; Wed, 10 Oct 2001 22:32:04 -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 EAA33364 for ; Thu, 11 Oct 2001 04:31: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 f9B2VvQ279998 for ; Thu, 11 Oct 2001 04:31:57 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iscsi : byte 3 of reject. X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 11 Oct 2001 05:31:55 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 11/10/2001 05:31:57, Serialize complete at 11/10/2001 05:31:57 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk it is reserved - I've corrected it now - Julo Santosh Rao Sent by: santoshr@cup.hp.com 11-10-01 01:34 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: iscsi : byte 3 of reject. Julian, I can't remember if I asked about this [and whether you responded, if I did ask]. Is byte 3 of the reject pdu supposed to be "reserved" or is the reject reason code supposed to be 2 bytes in length ? This is'nt coming across clearly from a reading of Section 3.17 of Rev 08. 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 Oct 11 05:28: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 FAA13945 for ; Thu, 11 Oct 2001 05:28:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9B8LaY27267 for ips-outgoing; Thu, 11 Oct 2001 04:21:36 -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 f9B8LYl27261 for ; Thu, 11 Oct 2001 04:21:34 -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 63031D9; Thu, 11 Oct 2001 10:21:32 +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 JAA06006; Thu, 11 Oct 2001 09:21:31 +0100 (BST) Received: from 15.145.8.166 by loddon.br.itc.hp.com (InterScan E-Mail VirusWall NT); Thu, 11 Oct 2001 09:21:31 +0100 (GMT Daylight Time) Received: by loddon.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4L80N8G4>; Thu, 11 Oct 2001 09:21:31 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C61@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Paul Koning'" Cc: ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Date: Thu, 11 Oct 2001 09:21:29 +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 Since I started this thread I feel I must at least contribute! The reason why I proposed putting CmdSN (actually it should be RefCmdSN) in the Data-out PDUs was to enable the target to have a faster search to associate unsolicited data out PDUs with its SCSI Command PDU. Solicited Data-out PDUs do not require this as they have a Target Task Tag. If all Command PDUs were queued then I believe this would work just fine. However, as Santosh correctly pointed out they are not and without repeating what he said this mechanism would not work for immediate command PDUs. I am sure that particular implementations could make this work but the underlying argument is that it needs to work and be useful to all implementations. The only benefit I now see of having CmdSN in the data PDU is as a check as implementations must (and can only) use the initiator task tag to associated the Data-out PDU with the command PDU. Therefore, IMO it is not a good enough reason for having CmdSN in the Data-out PDUs simply for a consistency check. The benefit of having the data sent unsolicited to minimise if not eradicate round trip times far out weighs the overhead in having to perform a search on receipt of unsolicited data. If we could have developed a well defined mechanism to overcome this overhead then all well and good and that is what I attempted. Still, if someone can do this and the solution is simple and straight forward then I am sure that it will have my backing but until then ... Cheers Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Paul Koning [mailto:pkoning@jlc.net] Sent: Wednesday, October 10, 2001 5:07 PM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU Excerpt of message (sent 10 October 2001) by Julian Satran: > Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it > may have large holes and using it in an implementation is as bad as a > hashed index. Not true. CmdSN values are sequential, by definition. Yes, clearly there will be small holes because commands complete out of order. But "large" holes are unlikely. In any case, the target has control over that. I can use an array whose size is given by the number of pending commands times a correction factor to account for the likely density of holes. Then MaxCmdSN would be updated based on two considerations: the ability to handle more pending commands, and the need to keep the distance between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the size of the lookup array. So having CmdSN in the DataOut PDU allows this approach, thereby replacing a hash lookup on a rapidly changing ID space by a simple array indexing operation. Without CmdSN, you're forced to use a mechanism that has a lot more overhead (in the insert/remove or in the lookup, depending on the mechanism chosen). paul From owner-ips@ece.cmu.edu Thu Oct 11 11:52: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 LAA18410 for ; Thu, 11 Oct 2001 11:52:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BEU6G28402 for ips-outgoing; Thu, 11 Oct 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 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 f9BEU3l28397 for ; Thu, 11 Oct 2001 10:30:03 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Thu Oct 11 10:25:41 EDT 2001 Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id f9BETek67818; Thu, 11 Oct 2001 10:29:40 -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 KAA29109; Thu, 11 Oct 2001 10:29:36 -0400 (EDT) Message-ID: <3BC5ACD0.20B278BE@research.bell-labs.com> Date: Thu, 11 Oct 2001 10:29:36 -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: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" CC: "'Paul Koning'" , ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU References: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C61@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 If we use the fact that the ITT-ordering of the unsolicited Data-out PDUs is identical to the ITT-ordering of the commands sent *within* a connection, then it should be possible to resolve the Data-out PDUs in a constant-time operation[*1] No hash and no cmdSN is required keep a per-connection chain within the command queue and look at its head. [*1]There are a couple of exceptions, due to the leeway the standard provides the initiator on Data-out PDUs. -Sandeep "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > Since I started this thread I feel I must at least contribute! > > The reason why I proposed putting CmdSN (actually it should be RefCmdSN) in > the Data-out PDUs was to enable the target to have a faster search to > associate unsolicited data out PDUs with its SCSI Command PDU. Solicited > Data-out PDUs do not require this as they have a Target Task Tag. > > If all Command PDUs were queued then I believe this would work just fine. > However, as Santosh correctly pointed out they are not and without repeating > what he said this mechanism would not work for immediate command PDUs. > > I am sure that particular implementations could make this work but the > underlying argument is that it needs to work and be useful to all > implementations. The only benefit I now see of having CmdSN in the data PDU > is as a check as implementations must (and can only) use the initiator task > tag to associated the Data-out PDU with the command PDU. Therefore, IMO it > is not a good enough reason for having CmdSN in the Data-out PDUs simply for > a consistency check. > > The benefit of having the data sent unsolicited to minimise if not eradicate > round trip times far out weighs the overhead in having to perform a search > on receipt of unsolicited data. If we could have developed a well defined > mechanism to overcome this overhead then all well and good and that is what > I attempted. Still, if someone can do this and the solution is simple and > straight forward then I am sure that it will have my backing but until then > ... > > Cheers > > Matthew Burbridge > Senior Development Engineer > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > > -----Original Message----- > From: Paul Koning [mailto:pkoning@jlc.net] > Sent: Wednesday, October 10, 2001 5:07 PM > To: Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: Re: Addition of CmdSN in Data-out PDU > > Excerpt of message (sent 10 October 2001) by Julian Satran: > > Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it > > may have large holes and using it in an implementation is as bad as a > > hashed index. > > Not true. > > CmdSN values are sequential, by definition. Yes, clearly there will > be small holes because commands complete out of order. But "large" > holes are unlikely. > > In any case, the target has control over that. I can use an array > whose size is given by the number of pending commands times a > correction factor to account for the likely density of holes. Then > MaxCmdSN would be updated based on two considerations: the ability to > handle more pending commands, and the need to keep the distance > between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the > size of the lookup array. > > So having CmdSN in the DataOut PDU allows this approach, thereby > replacing a hash lookup on a rapidly changing ID space by a simple > array indexing operation. Without CmdSN, you're forced to use a > mechanism that has a lot more overhead (in the insert/remove or in the > lookup, depending on the mechanism chosen). > > paul From owner-ips@ece.cmu.edu Thu Oct 11 11:56: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 LAA18502 for ; Thu, 11 Oct 2001 11:56:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BF6P901174 for ips-outgoing; Thu, 11 Oct 2001 11:06: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 f9BF6Nl01169 for ; Thu, 11 Oct 2001 11:06:23 -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 f9BF6hh13805; Thu, 11 Oct 2001 11:06:43 -0400 (EDT) From: "Eddy Quicksall" To: "'BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)'" , Subject: RE: Addition of CmdSN in Data-out PDU Date: Thu, 11 Oct 2001 11:06:29 -0400 Message-ID: <001f01c15266$52f14550$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 V6.00.2600.0000 In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C61@dickens.bri.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit To support this, wouldn't we have to limit the number of outstanding commands? This is because commands are passed to the SCSI layer as soon as the CmdSN's are in order. But, the unsolicited data may still be due. As soon as a command is passed to the SCSI layer, the ExpCmdSN is incremented and the MaxCmdSN is computed to make best use of the buckets. There would be a limited number of buckets. If you use MaxCmdSN for this purpose, you would severely limit the number of outstanding commands (to the size of your iSCSI command buckets). Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, October 11, 2001 04:21 AM To: 'Paul Koning' Cc: ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Since I started this thread I feel I must at least contribute! The reason why I proposed putting CmdSN (actually it should be RefCmdSN) in the Data-out PDUs was to enable the target to have a faster search to associate unsolicited data out PDUs with its SCSI Command PDU. Solicited Data-out PDUs do not require this as they have a Target Task Tag. If all Command PDUs were queued then I believe this would work just fine. However, as Santosh correctly pointed out they are not and without repeating what he said this mechanism would not work for immediate command PDUs. I am sure that particular implementations could make this work but the underlying argument is that it needs to work and be useful to all implementations. The only benefit I now see of having CmdSN in the data PDU is as a check as implementations must (and can only) use the initiator task tag to associated the Data-out PDU with the command PDU. Therefore, IMO it is not a good enough reason for having CmdSN in the Data-out PDUs simply for a consistency check. The benefit of having the data sent unsolicited to minimise if not eradicate round trip times far out weighs the overhead in having to perform a search on receipt of unsolicited data. If we could have developed a well defined mechanism to overcome this overhead then all well and good and that is what I attempted. Still, if someone can do this and the solution is simple and straight forward then I am sure that it will have my backing but until then ... Cheers Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Paul Koning [mailto:pkoning@jlc.net] Sent: Wednesday, October 10, 2001 5:07 PM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU Excerpt of message (sent 10 October 2001) by Julian Satran: > Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it > may have large holes and using it in an implementation is as bad as a > hashed index. Not true. CmdSN values are sequential, by definition. Yes, clearly there will be small holes because commands complete out of order. But "large" holes are unlikely. In any case, the target has control over that. I can use an array whose size is given by the number of pending commands times a correction factor to account for the likely density of holes. Then MaxCmdSN would be updated based on two considerations: the ability to handle more pending commands, and the need to keep the distance between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the size of the lookup array. So having CmdSN in the DataOut PDU allows this approach, thereby replacing a hash lookup on a rapidly changing ID space by a simple array indexing operation. Without CmdSN, you're forced to use a mechanism that has a lot more overhead (in the insert/remove or in the lookup, depending on the mechanism chosen). paul From owner-ips@ece.cmu.edu Thu Oct 11 12:44: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 MAA19499 for ; Thu, 11 Oct 2001 12:44:10 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BFrwk05072 for ips-outgoing; Thu, 11 Oct 2001 11:53:58 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9BFrul05063 for ; Thu, 11 Oct 2001 11:53:56 -0400 (EDT) Received: from fmsmsxvs040.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id PAA01723 for ; Thu, 11 Oct 2001 15:53:50 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001101108532725157 for ; Thu, 11 Oct 2001 08:53:27 -0700 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id <4LAWS3SP>; Thu, 11 Oct 2001 08:51:55 -0700 Message-ID: From: "Wheat, Stephen R" To: ips@ece.cmu.edu Subject: remove Date: Thu, 11 Oct 2001 08:53:42 -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 remove From owner-ips@ece.cmu.edu Thu Oct 11 12:46: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 MAA19548 for ; Thu, 11 Oct 2001 12:46:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BGDUp06616 for ips-outgoing; Thu, 11 Oct 2001 12:13:30 -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 f9BGDSl06612 for ; Thu, 11 Oct 2001 12:13:28 -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 f9BGCsh01765; Thu, 11 Oct 2001 12:12:54 -0400 (EDT) From: "Eddy Quicksall" To: "'Sandeep Joshi'" , "'BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)'" Cc: "'Paul Koning'" , Subject: RE: Addition of CmdSN in Data-out PDU Date: Thu, 11 Oct 2001 12:12:38 -0400 Message-ID: <002301c1526f$923e2bc0$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 V6.00.2600.0000 In-Reply-To: <3BC5ACD0.20B278BE@research.bell-labs.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit You can't assume the ITT takes a specific order. Eddy -----Original Message----- From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] Sent: Thursday, October 11, 2001 10:30 AM To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) Cc: 'Paul Koning'; ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU If we use the fact that the ITT-ordering of the unsolicited Data-out PDUs is identical to the ITT-ordering of the commands sent *within* a connection, then it should be possible to resolve the Data-out PDUs in a constant-time operation[*1] No hash and no cmdSN is required keep a per-connection chain within the command queue and look at its head. [*1]There are a couple of exceptions, due to the leeway the standard provides the initiator on Data-out PDUs. -Sandeep "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > Since I started this thread I feel I must at least contribute! > > The reason why I proposed putting CmdSN (actually it should be RefCmdSN) in > the Data-out PDUs was to enable the target to have a faster search to > associate unsolicited data out PDUs with its SCSI Command PDU. Solicited > Data-out PDUs do not require this as they have a Target Task Tag. > > If all Command PDUs were queued then I believe this would work just fine. > However, as Santosh correctly pointed out they are not and without repeating > what he said this mechanism would not work for immediate command PDUs. > > I am sure that particular implementations could make this work but the > underlying argument is that it needs to work and be useful to all > implementations. The only benefit I now see of having CmdSN in the data PDU > is as a check as implementations must (and can only) use the initiator task > tag to associated the Data-out PDU with the command PDU. Therefore, IMO it > is not a good enough reason for having CmdSN in the Data-out PDUs simply for > a consistency check. > > The benefit of having the data sent unsolicited to minimise if not eradicate > round trip times far out weighs the overhead in having to perform a search > on receipt of unsolicited data. If we could have developed a well defined > mechanism to overcome this overhead then all well and good and that is what > I attempted. Still, if someone can do this and the solution is simple and > straight forward then I am sure that it will have my backing but until then > ... > > Cheers > > Matthew Burbridge > Senior Development Engineer > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > > -----Original Message----- > From: Paul Koning [mailto:pkoning@jlc.net] > Sent: Wednesday, October 10, 2001 5:07 PM > To: Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: Re: Addition of CmdSN in Data-out PDU > > Excerpt of message (sent 10 October 2001) by Julian Satran: > > Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it > > may have large holes and using it in an implementation is as bad as a > > hashed index. > > Not true. > > CmdSN values are sequential, by definition. Yes, clearly there will > be small holes because commands complete out of order. But "large" > holes are unlikely. > > In any case, the target has control over that. I can use an array > whose size is given by the number of pending commands times a > correction factor to account for the likely density of holes. Then > MaxCmdSN would be updated based on two considerations: the ability to > handle more pending commands, and the need to keep the distance > between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the > size of the lookup array. > > So having CmdSN in the DataOut PDU allows this approach, thereby > replacing a hash lookup on a rapidly changing ID space by a simple > array indexing operation. Without CmdSN, you're forced to use a > mechanism that has a lot more overhead (in the insert/remove or in the > lookup, depending on the mechanism chosen). > > paul From owner-ips@ece.cmu.edu Thu Oct 11 12:46: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 MAA19559 for ; Thu, 11 Oct 2001 12:46:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BGMBf07213 for ips-outgoing; Thu, 11 Oct 2001 12:22:11 -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 f9BGMAl07206 for ; Thu, 11 Oct 2001 12:22:10 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Oct 11 12:17: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 f9BGLJl17416; Thu, 11 Oct 2001 12:21:19 -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 MAA08019; Thu, 11 Oct 2001 12:21:18 -0400 (EDT) Message-ID: <3BC5C6FE.16039AB2@research.bell-labs.com> Date: Thu, 11 Oct 2001 12:21: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: Eddy Quicksall CC: ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU References: <002301c1526f$923e2bc0$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 Eddy, I was referring to Sec 2.2.5 Unsolicited data MUST be sent on every connection in the same order in which commands were sent -Sandeep Eddy Quicksall wrote: > > You can't assume the ITT takes a specific order. > > Eddy > > -----Original Message----- > From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] > Sent: Thursday, October 11, 2001 10:30 AM > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > Cc: 'Paul Koning'; ips@ece.cmu.edu > Subject: Re: Addition of CmdSN in Data-out PDU > > If we use the fact that the ITT-ordering of the unsolicited > Data-out PDUs is identical to the ITT-ordering of the commands > sent *within* a connection, then it should be possible to > resolve the Data-out PDUs in a constant-time operation[*1] > No hash and no cmdSN is required keep a per-connection > chain within the command queue and look at its head. > > [*1]There are a couple of exceptions, due to the leeway the > standard provides the initiator on Data-out PDUs. > > -Sandeep > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > Since I started this thread I feel I must at least contribute! > > > > The reason why I proposed putting CmdSN (actually it should be > RefCmdSN) in > > the Data-out PDUs was to enable the target to have a faster search to > > associate unsolicited data out PDUs with its SCSI Command PDU. > Solicited > > Data-out PDUs do not require this as they have a Target Task Tag. > > > > If all Command PDUs were queued then I believe this would work just > fine. > > However, as Santosh correctly pointed out they are not and without > repeating > > what he said this mechanism would not work for immediate command PDUs. > > > > I am sure that particular implementations could make this work but the > > underlying argument is that it needs to work and be useful to all > > implementations. The only benefit I now see of having CmdSN in the > data PDU > > is as a check as implementations must (and can only) use the initiator > task > > tag to associated the Data-out PDU with the command PDU. Therefore, > IMO it > > is not a good enough reason for having CmdSN in the Data-out PDUs > simply for > > a consistency check. > > > > The benefit of having the data sent unsolicited to minimise if not > eradicate > > round trip times far out weighs the overhead in having to perform a > search > > on receipt of unsolicited data. If we could have developed a well > defined > > mechanism to overcome this overhead then all well and good and that is > what > > I attempted. Still, if someone can do this and the solution is simple > and > > straight forward then I am sure that it will have my backing but until > then > > ... > > > > Cheers > > > > Matthew Burbridge > > Senior Development Engineer > > NIS-Bristol > > Hewlett Packard > > Telnet: 312 7010 > > E-mail: matthewb@bri.hp.com > > > > > > -----Original Message----- > > From: Paul Koning [mailto:pkoning@jlc.net] > > Sent: Wednesday, October 10, 2001 5:07 PM > > To: Julian_Satran@il.ibm.com > > Cc: ips@ece.cmu.edu > > Subject: Re: Addition of CmdSN in Data-out PDU > > > > Excerpt of message (sent 10 October 2001) by Julian Satran: > > > Inconsistency can be legitimate. CmdSN is ephemeral. It can be > reused, it > > > may have large holes and using it in an implementation is as bad as > a > > > hashed index. > > > > Not true. > > > > CmdSN values are sequential, by definition. Yes, clearly there will > > be small holes because commands complete out of order. But "large" > > holes are unlikely. > > > > In any case, the target has control over that. I can use an array > > whose size is given by the number of pending commands times a > > correction factor to account for the likely density of holes. Then > > MaxCmdSN would be updated based on two considerations: the ability to > > handle more pending commands, and the need to keep the distance > > between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the > > size of the lookup array. > > > > So having CmdSN in the DataOut PDU allows this approach, thereby > > replacing a hash lookup on a rapidly changing ID space by a simple > > array indexing operation. Without CmdSN, you're forced to use a > > mechanism that has a lot more overhead (in the insert/remove or in the > > lookup, depending on the mechanism chosen). > > > > paul From owner-ips@ece.cmu.edu Thu Oct 11 12:47: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 MAA19610 for ; Thu, 11 Oct 2001 12:47:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BFwuu05441 for ips-outgoing; Thu, 11 Oct 2001 11:58: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 f9BFwql05434 for ; Thu, 11 Oct 2001 11:58:52 -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 LAA43992; Thu, 11 Oct 2001 11:56:22 -0400 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9BFwh057296; Thu, 11 Oct 2001 09:58:43 -0600 Importance: Normal Subject: Re: iSCSI: ISID progress To: Black_David@emc.com, ips@ece.cmu.edu From: "Jim Hafner" Date: Thu, 11 Oct 2001 08:58:41 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/11/2001 08:58:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk David, More comments in line Jim Hafner Black_David@emc.com on 10/10/2001 03:48:55 pm To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: iSCSI: ISID progress This message is shorter than my last one, so that's at least a superficial indication of progress ;-). Jim and Julian had four comments/objections to the notion of using a text key to indicate iSCSI Initiator Port Name. Summarizing and responding: Jim (a): Optional use of port name is ok as far as SAM-2 is concerned, but is odd. Indeed it is odd, but given the choice between an odd mapping of SAM-2 to iSCSI and allowing odd behavior of iSCSI implementations, I'll take the former. I'm not sure what "odd behavior of iSCSI implementations" you're referring to here. Jim (b): Would require at least as much coordination above the session level of iSCSI as ISIDs. That would be incorrect. 128 bits is sufficient to eliminate coordination. The reference for this is an expired Internet- Draft, draft-leach-uuids-guids-01.txt, that can still be found on the web at: http://casbah.org/cbRFC/misc/draft-leach-uuids-guids-01.txt http://globecom.net/ietf/draft/draft-leach-uuids-guids-01.html I'm not seriously proposing that port name generation be done in this fashion, but rather providing a widely used counter- example to Jim's statement. Note that a network interface MAC is likely to be available to many iSCSI implementations. I glanced through that draft and certainly don't think it is the right approach to this problem. However, if you/we believe that by simply making the equivalent of the ISID field or portname text value big enough, we can find a solution to the "coordination problem", why can't we just *require* that sessions have a SCSI port name (extension to iSCSI Name) that is long enough to solve the weak or no coordination problem, instead of making this "TBD"? I've argued that having the SCSI Portname is valuable. I've argued that there wasn't any net value in putting the name in a key because I already had the ISID field as part of the "name space for the session endpoint". But if the claim is simply the ISID isn't big enough, then I don't have a problem with effectively making them bigger (either in the header or in a key value). I've even suggested one way to do that by embedding the initiator portal group tag in the value. But another way is to embed the OUI of the HBA (except for the cases where there isn't an HBA) or embed one of the MACs of one of the nics (except for the cases where there isn't a nic, e.g., dialup), etc. But we'd have to solve all the possible cases (all of which the NDT had to deal with for iSCSI Names in the first place). So, are we at the point where (for this alternative proposal): (a) we just need a bigger (than 2byte ISID) field for the SCSI portname extension (b) we just need an algorithm that lets each component that wants to generate such a name can do so without collision concerns? Jim (c): How to describe model when the text key is optional? "Is it that all initiator session endpoints that don't provide this text key have *implicit* unique names and only when the text key is presented does the name get explicit (and then possibly not be unique)? In that case, the key would have to be supplied in login next to the InitiatorName. Yes and yes when it's used, in that order. Jim's comment (a) about this being odd applies. Julian: ... and have as much chances to blow a session as ISID That would also be incorrect. As previously stated, ISID conflict is fatal to one of the sessions involved (one cannot change the ISID and continue), and can occur in any system that opens parallel sessions. This text key conflict need not be fatal (one can change the text key and continue negotiation) and can only occur in systems that want to use the new port-spanning persistent reservation functionality, as other systems won't use the text key. Also see the draft noted in response to Jim (b) above; Julian's "have as much chance" language is incorrect. I think this is somewhat misleading about the cost ("fatal"). If we could find a reasonable model for "reject: ISID in use" (rather than "blow away the old session"), then the "fatal to one of the sessions" is a nit. This would happen on the first exchange of a connection so starting over isn't any big deal (we may not even have to require connection drop, just restart of the initial message with new ISID). The same would happen with the key as that would have to be somewhere in the pre-full feature phase (but in this case it could happen anywhere in that phase). As previously noted, I can also deal with requiring conservative reuse of ISIDs as a means to address this situation. 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 Oct 11 12:51: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 MAA19737 for ; Thu, 11 Oct 2001 12:51:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BFkHY04458 for ips-outgoing; Thu, 11 Oct 2001 11:46: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 f9BFkFl04454 for ; Thu, 11 Oct 2001 11:46:15 -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 RAA67892; Thu, 11 Oct 2001 17:46:07 +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 f9BFjxY159144; Thu, 11 Oct 2001 17:46:05 +0200 Importance: Normal Subject: Re: ISCSI: Error in 10.3.3 of iscsi-08 To: Paul Koning Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Thu, 11 Oct 2001 18:47:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 11/10/2001 18:46:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, Sorry for the delay, I was on vacation. You are right of course, I had Bernard (who brought up this issue) review your suggestion and your second suggested text will be used. Thanks, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Paul Koning @ece.cmu.edu on 02/10/2001 19:16:55 Please respond to Paul Koning Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: ISCSI: Error in 10.3.3 of iscsi-08 The last paragraph of section 10.3.3 is badly misleading. 10.3.3 says about pre-shared key: "the only practical usage under this configuration is a group pre-shared key". That is clearly false. Standard practice for IPsec is that a pre-shared key is unique to a given pair of communicating entities. The only exception is when dynamic addresses are used, as discussed accurately in the security draft, section 5.8.2). As a minimum, 10.3.3 needs to be reworded so it describes the real world. The following text would do this: IKE main mode with pre-shared key authentication method SHOULD NOT be used (while pre-shared keys in many cases offer good security, situations where dynamically assigned addresses are used force the use of a group pre-shared key which creates vulnerability to man-in-the-middle attack). Preferably, the requirement should be changed so the reasoning for the restriction matches the restriction. The following text achieves this: IKE main mode with pre-shared key authentication method SHOULD NOT be used when either the initiator or the target uses dynamically assigned IP addresses (while pre-shared keys in many cases offer good security, situations where dynamically assigned addresses are used force the use of a group pre-shared key which creates vulnerability to man-in-the-middle attack). If this second solution is adopted, section 2.3 in the security spec also needs a corresponding change (first two sentences of page 10). paul From owner-ips@ece.cmu.edu Thu Oct 11 14:06: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 OAA21512 for ; Thu, 11 Oct 2001 14:06:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BGwKn09921 for ips-outgoing; Thu, 11 Oct 2001 12:58:20 -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 f9BGwIl09915 for ; Thu, 11 Oct 2001 12:58:18 -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 f9BGwUh23741; Thu, 11 Oct 2001 12:58:30 -0400 (EDT) From: "Eddy Quicksall" To: "'Sandeep Joshi'" Cc: Subject: RE: Addition of CmdSN in Data-out PDU Date: Thu, 11 Oct 2001 12:58:19 -0400 Message-ID: <003501c15275$efee2ee0$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 V6.00.2600.0000 In-Reply-To: <3BC5C6FE.16039AB2@research.bell-labs.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks, Now I see your point. Eddy -----Original Message----- From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] Sent: Thursday, October 11, 2001 12:21 PM To: Eddy Quicksall Cc: ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU Eddy, I was referring to Sec 2.2.5 Unsolicited data MUST be sent on every connection in the same order in which commands were sent -Sandeep Eddy Quicksall wrote: > > You can't assume the ITT takes a specific order. > > Eddy > > -----Original Message----- > From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] > Sent: Thursday, October 11, 2001 10:30 AM > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > Cc: 'Paul Koning'; ips@ece.cmu.edu > Subject: Re: Addition of CmdSN in Data-out PDU > > If we use the fact that the ITT-ordering of the unsolicited > Data-out PDUs is identical to the ITT-ordering of the commands > sent *within* a connection, then it should be possible to > resolve the Data-out PDUs in a constant-time operation[*1] > No hash and no cmdSN is required keep a per-connection > chain within the command queue and look at its head. > > [*1]There are a couple of exceptions, due to the leeway the > standard provides the initiator on Data-out PDUs. > > -Sandeep > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > Since I started this thread I feel I must at least contribute! > > > > The reason why I proposed putting CmdSN (actually it should be > RefCmdSN) in > > the Data-out PDUs was to enable the target to have a faster search to > > associate unsolicited data out PDUs with its SCSI Command PDU. > Solicited > > Data-out PDUs do not require this as they have a Target Task Tag. > > > > If all Command PDUs were queued then I believe this would work just > fine. > > However, as Santosh correctly pointed out they are not and without > repeating > > what he said this mechanism would not work for immediate command PDUs. > > > > I am sure that particular implementations could make this work but the > > underlying argument is that it needs to work and be useful to all > > implementations. The only benefit I now see of having CmdSN in the > data PDU > > is as a check as implementations must (and can only) use the initiator > task > > tag to associated the Data-out PDU with the command PDU. Therefore, > IMO it > > is not a good enough reason for having CmdSN in the Data-out PDUs > simply for > > a consistency check. > > > > The benefit of having the data sent unsolicited to minimise if not > eradicate > > round trip times far out weighs the overhead in having to perform a > search > > on receipt of unsolicited data. If we could have developed a well > defined > > mechanism to overcome this overhead then all well and good and that is > what > > I attempted. Still, if someone can do this and the solution is simple > and > > straight forward then I am sure that it will have my backing but until > then > > ... > > > > Cheers > > > > Matthew Burbridge > > Senior Development Engineer > > NIS-Bristol > > Hewlett Packard > > Telnet: 312 7010 > > E-mail: matthewb@bri.hp.com > > > > > > -----Original Message----- > > From: Paul Koning [mailto:pkoning@jlc.net] > > Sent: Wednesday, October 10, 2001 5:07 PM > > To: Julian_Satran@il.ibm.com > > Cc: ips@ece.cmu.edu > > Subject: Re: Addition of CmdSN in Data-out PDU > > > > Excerpt of message (sent 10 October 2001) by Julian Satran: > > > Inconsistency can be legitimate. CmdSN is ephemeral. It can be > reused, it > > > may have large holes and using it in an implementation is as bad as > a > > > hashed index. > > > > Not true. > > > > CmdSN values are sequential, by definition. Yes, clearly there will > > be small holes because commands complete out of order. But "large" > > holes are unlikely. > > > > In any case, the target has control over that. I can use an array > > whose size is given by the number of pending commands times a > > correction factor to account for the likely density of holes. Then > > MaxCmdSN would be updated based on two considerations: the ability to > > handle more pending commands, and the need to keep the distance > > between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the > > size of the lookup array. > > > > So having CmdSN in the DataOut PDU allows this approach, thereby > > replacing a hash lookup on a rapidly changing ID space by a simple > > array indexing operation. Without CmdSN, you're forced to use a > > mechanism that has a lot more overhead (in the insert/remove or in the > > lookup, depending on the mechanism chosen). > > > > paul From owner-ips@ece.cmu.edu Thu Oct 11 14:56: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 OAA22578 for ; Thu, 11 Oct 2001 14:56:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BHseD14437 for ips-outgoing; Thu, 11 Oct 2001 13:54:40 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from antigonus.hosting.pacbell.net (antigonus.hosting.pacbell.net [216.100.98.13]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9BHsbl14432 for ; Thu, 11 Oct 2001 13:54:38 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by antigonus.hosting.pacbell.net id NAA16830; Thu, 11 Oct 2001 13:53:51 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "Sandeep Joshi" , "Eddy Quicksall" Cc: Subject: RE: Addition of CmdSN in Data-out PDU Date: Thu, 11 Oct 2001 10:52:16 -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: <3BC5C6FE.16039AB2@research.bell-labs.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sandeep, You are right. The target has knowledge of whether a Data-out PDU will be received, and also the order in which they will be received. This allows the target to determine the command with which the data is associated without having to search by the ITT. A mismatch would indicate a missing pdu due to digest error, or a protocol violation. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Sandeep Joshi > Sent: Thursday, October 11, 2001 9:21 AM > To: Eddy Quicksall > Cc: ips@ece.cmu.edu > Subject: Re: Addition of CmdSN in Data-out PDU > > > > Eddy, > > I was referring to Sec 2.2.5 > > Unsolicited data MUST be sent on every connection in the > same order in which commands were sent > > -Sandeep > > Eddy Quicksall wrote: > > > > You can't assume the ITT takes a specific order. > > > > Eddy > > > > -----Original Message----- > > From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] > > Sent: Thursday, October 11, 2001 10:30 AM > > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > Cc: 'Paul Koning'; ips@ece.cmu.edu > > Subject: Re: Addition of CmdSN in Data-out PDU > > > > If we use the fact that the ITT-ordering of the unsolicited > > Data-out PDUs is identical to the ITT-ordering of the commands > > sent *within* a connection, then it should be possible to > > resolve the Data-out PDUs in a constant-time operation[*1] > > No hash and no cmdSN is required keep a per-connection > > chain within the command queue and look at its head. > > > > [*1]There are a couple of exceptions, due to the leeway the > > standard provides the initiator on Data-out PDUs. > > > > -Sandeep > > > > "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > > > > > Since I started this thread I feel I must at least contribute! > > > > > > The reason why I proposed putting CmdSN (actually it should be > > RefCmdSN) in > > > the Data-out PDUs was to enable the target to have a faster search to > > > associate unsolicited data out PDUs with its SCSI Command PDU. > > Solicited > > > Data-out PDUs do not require this as they have a Target Task Tag. > > > > > > If all Command PDUs were queued then I believe this would work just > > fine. > > > However, as Santosh correctly pointed out they are not and without > > repeating > > > what he said this mechanism would not work for immediate command PDUs. > > > > > > I am sure that particular implementations could make this work but the > > > underlying argument is that it needs to work and be useful to all > > > implementations. The only benefit I now see of having CmdSN in the > > data PDU > > > is as a check as implementations must (and can only) use the initiator > > task > > > tag to associated the Data-out PDU with the command PDU. Therefore, > > IMO it > > > is not a good enough reason for having CmdSN in the Data-out PDUs > > simply for > > > a consistency check. > > > > > > The benefit of having the data sent unsolicited to minimise if not > > eradicate > > > round trip times far out weighs the overhead in having to perform a > > search > > > on receipt of unsolicited data. If we could have developed a well > > defined > > > mechanism to overcome this overhead then all well and good and that is > > what > > > I attempted. Still, if someone can do this and the solution is simple > > and > > > straight forward then I am sure that it will have my backing but until > > then > > > ... > > > > > > Cheers > > > > > > Matthew Burbridge > > > Senior Development Engineer > > > NIS-Bristol > > > Hewlett Packard > > > Telnet: 312 7010 > > > E-mail: matthewb@bri.hp.com > > > > > > > > > -----Original Message----- > > > From: Paul Koning [mailto:pkoning@jlc.net] > > > Sent: Wednesday, October 10, 2001 5:07 PM > > > To: Julian_Satran@il.ibm.com > > > Cc: ips@ece.cmu.edu > > > Subject: Re: Addition of CmdSN in Data-out PDU > > > > > > Excerpt of message (sent 10 October 2001) by Julian Satran: > > > > Inconsistency can be legitimate. CmdSN is ephemeral. It can be > > reused, it > > > > may have large holes and using it in an implementation is as bad as > > a > > > > hashed index. > > > > > > Not true. > > > > > > CmdSN values are sequential, by definition. Yes, clearly there will > > > be small holes because commands complete out of order. But "large" > > > holes are unlikely. > > > > > > In any case, the target has control over that. I can use an array > > > whose size is given by the number of pending commands times a > > > correction factor to account for the likely density of holes. Then > > > MaxCmdSN would be updated based on two considerations: the ability to > > > handle more pending commands, and the need to keep the distance > > > between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the > > > size of the lookup array. > > > > > > So having CmdSN in the DataOut PDU allows this approach, thereby > > > replacing a hash lookup on a rapidly changing ID space by a simple > > > array indexing operation. Without CmdSN, you're forced to use a > > > mechanism that has a lot more overhead (in the insert/remove or in the > > > lookup, depending on the mechanism chosen). > > > > > > paul > From owner-ips@ece.cmu.edu Thu Oct 11 17:06: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 RAA25455 for ; Thu, 11 Oct 2001 17:06:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BJsfm23262 for ips-outgoing; Thu, 11 Oct 2001 15:54:41 -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 f9BJscl23257 for ; Thu, 11 Oct 2001 15:54:38 -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 PAA80352 for ; Thu, 11 Oct 2001 15:52:05 -0400 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9BJsTC230782 for ; Thu, 11 Oct 2001 13:54:29 -0600 Importance: Normal Subject: iSCSI: SCSI Iniitator port: a simple approach, acceptable? To: ips@ece.cmu.edu From: "Jim Hafner" Date: Thu, 11 Oct 2001 12:54:27 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/11/2001 12:54:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, I'm curious to know from this group whether the following is an acceptable alternative to the complex issues we're battling with the definition and behavior of SCSI Initiator Port (viz a viz, ISID, key=value,etc.). Make the SCSI Initiator Port = initiator portal group, named by iSCSI Name + portal group tag (which would be presented during login). Pros: a) the model is completely symmetric on the initiator and the target side b) namespace is managed by any mechanism to identify the portal group tag. (For example, the tag could be the position in the SCSI port/module load sequence (/dev/scsi[x]) OR one could derive the portal group tag from either a MAC or from ipaddress of one of the interfaces in the portal group). c) the drivers present exactly one channel (SCSI initiator port) for each initiator portal group to the upper layers in the OS (how that is named/identified to the upper layers may be independent of how it is named on the wire, i.e., independent of the portal group tag). d) completely static/stable configuration on each boot (though it may change, as it can today, between boots if components fail or are changed in any way). Cons: a) we *prohibit more than one session* between an initiator portal group and a target portal group (to avoid parallel nexus). This has the side consequence of making it harder to be a bad net-citizen by opening too many connections through the same set of network interfaces (you open what you want within a session only). I've always avoided this approach as I expected the "cons" would not be acceptable, but I've never actually asked this of the group. So, what's the 'acceptability' of this approach? Jim Hafner Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 10/11/2001 08:58:41 am Sent by: owner-ips@ece.cmu.edu To: Black_David@emc.com, ips@ece.cmu.edu cc: Subject: Re: iSCSI: ISID progress David, More comments in line Jim Hafner Black_David@emc.com on 10/10/2001 03:48:55 pm To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu cc: Subject: iSCSI: ISID progress This message is shorter than my last one, so that's at least a superficial indication of progress ;-). Jim and Julian had four comments/objections to the notion of using a text key to indicate iSCSI Initiator Port Name. Summarizing and responding: Jim (a): Optional use of port name is ok as far as SAM-2 is concerned, but is odd. Indeed it is odd, but given the choice between an odd mapping of SAM-2 to iSCSI and allowing odd behavior of iSCSI implementations, I'll take the former. I'm not sure what "odd behavior of iSCSI implementations" you're referring to here. Jim (b): Would require at least as much coordination above the session level of iSCSI as ISIDs. That would be incorrect. 128 bits is sufficient to eliminate coordination. The reference for this is an expired Internet- Draft, draft-leach-uuids-guids-01.txt, that can still be found on the web at: http://casbah.org/cbRFC/misc/draft-leach-uuids-guids-01.txt http://globecom.net/ietf/draft/draft-leach-uuids-guids-01.html I'm not seriously proposing that port name generation be done in this fashion, but rather providing a widely used counter- example to Jim's statement. Note that a network interface MAC is likely to be available to many iSCSI implementations. I glanced through that draft and certainly don't think it is the right approach to this problem. However, if you/we believe that by simply making the equivalent of the ISID field or portname text value big enough, we can find a solution to the "coordination problem", why can't we just *require* that sessions have a SCSI port name (extension to iSCSI Name) that is long enough to solve the weak or no coordination problem, instead of making this "TBD"? I've argued that having the SCSI Portname is valuable. I've argued that there wasn't any net value in putting the name in a key because I already had the ISID field as part of the "name space for the session endpoint". But if the claim is simply the ISID isn't big enough, then I don't have a problem with effectively making them bigger (either in the header or in a key value). I've even suggested one way to do that by embedding the initiator portal group tag in the value. But another way is to embed the OUI of the HBA (except for the cases where there isn't an HBA) or embed one of the MACs of one of the nics (except for the cases where there isn't a nic, e.g., dialup), etc. But we'd have to solve all the possible cases (all of which the NDT had to deal with for iSCSI Names in the first place). So, are we at the point where (for this alternative proposal): (a) we just need a bigger (than 2byte ISID) field for the SCSI portname extension (b) we just need an algorithm that lets each component that wants to generate such a name can do so without collision concerns? Jim (c): How to describe model when the text key is optional? "Is it that all initiator session endpoints that don't provide this text key have *implicit* unique names and only when the text key is presented does the name get explicit (and then possibly not be unique)? In that case, the key would have to be supplied in login next to the InitiatorName. Yes and yes when it's used, in that order. Jim's comment (a) about this being odd applies. Julian: ... and have as much chances to blow a session as ISID That would also be incorrect. As previously stated, ISID conflict is fatal to one of the sessions involved (one cannot change the ISID and continue), and can occur in any system that opens parallel sessions. This text key conflict need not be fatal (one can change the text key and continue negotiation) and can only occur in systems that want to use the new port-spanning persistent reservation functionality, as other systems won't use the text key. Also see the draft noted in response to Jim (b) above; Julian's "have as much chance" language is incorrect. I think this is somewhat misleading about the cost ("fatal"). If we could find a reasonable model for "reject: ISID in use" (rather than "blow away the old session"), then the "fatal to one of the sessions" is a nit. This would happen on the first exchange of a connection so starting over isn't any big deal (we may not even have to require connection drop, just restart of the initial message with new ISID). The same would happen with the key as that would have to be somewhere in the pre-full feature phase (but in this case it could happen anywhere in that phase). As previously noted, I can also deal with requiring conservative reuse of ISIDs as a means to address this situation. 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 Oct 11 17:06: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 RAA25477 for ; Thu, 11 Oct 2001 17:06:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BKMss25059 for ips-outgoing; Thu, 11 Oct 2001 16:22:54 -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 f9BKMql25054 for ; Thu, 11 Oct 2001 16:22: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 f9BKN6h10415; Thu, 11 Oct 2001 16:23:06 -0400 (EDT) From: "Eddy Quicksall" To: , Subject: iSCSI: FirstBurstSize, etc Date: Thu, 11 Oct 2001 16:22:50 -0400 Message-ID: <004101c15292$83f88650$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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am wondering about the following statement: FirstBurstSize MUST NOT exceed MaximumBurstSize. It doesn't seem to fit the various definitions. I made the following diagram from the definitions and FirstBurstSize came out larger then MaxBurstSize. Here are the definitions I am going by: 25 FirstBurstSize Initiator and target negotiate the maximum amount of unsolicited data an iSCSI initiator may send to the target, during the execution of a single SCSI command, in units of 512 bytes. 24 MaxBurstSize Initiator and target negotiate 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. I get the definition of a sequence from "2.2.2.3 Data Sequencing": For output data PDUs, DataSN starts with 0 for the first data PDU of a sequence (the initial unsolicited sequence or any data PDU sequence issued to satisfy an R2T) and advances by 1 for each subsequent data PDU. |<------------------ Unsolicited data ------------------->| | |<------------ Sequence ------------>| |Command | Immediate Data | |<---- Remaining unsolicited ------->| |========|=================| |================| |F===============| |<-DataPDULength->| | DataPDULength | | DataPDULength | |<--------- MaxBurstSize ----------->| |<------------------- FirstBurstSize -------------------->| Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Thu Oct 11 18:05: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 SAA26769 for ; Thu, 11 Oct 2001 18:05:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BLXx229882 for ips-outgoing; Thu, 11 Oct 2001 17:33:59 -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 f9BLXvl29875 for ; Thu, 11 Oct 2001 17:33:57 -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 RAA35070; Thu, 11 Oct 2001 17:31:30 -0400 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9BLXtC259754; Thu, 11 Oct 2001 15:33:55 -0600 Importance: Normal Subject: Re: iSCSI: SCSI Iniitator port: a simple approach, acceptable? To: Santosh Rao , ips@ece.cmu.edu From: "Jim Hafner" Date: Thu, 11 Oct 2001 14:33:52 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/11/2001 02:33:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, I agree we haven't really solved the problem exactly (about what has to be configured per HBA, though I hinted at an implementation of portal group tag assignment that is based on network stuff, that might make it easier. It's your last comment that I was expecting to get solicited. But I'll ask why is it so important to have several sessions in parallel? If I can have multiple connections per session, doesn't that suffice for multiplexing? If the target says only one connection per session, then isn't that a hint that it has limited network resources and it would be bad form to build too many sessions just to bypass this? I'm not strongly advocating this, playing devil's advocate. Jim Hafner Santosh Rao @cup.hp.com on 10/11/2001 02:10:56 pm Sent by: santoshr@cup.hp.com To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: SCSI Iniitator port: a simple approach, acceptable? Jim, I am not in favor of the below proposal and would rather see the ISID model, for the reason you mention under "Cons". Up until now, the concept of "initiator portal groups" has not held any significant importance in the protocol, unlike target portal groups which is formal information exchanged b/n initiator and target, and which governs the session end points. How is the initiator portal group now going to be communicated to the iscsi HBAs ? In essence, we've just moved the piece of information that needs to be co-ordinated across HBAs, from being an ISID to being a portal group tag. For single connection sessions, it is essential that several sessions be allowed in parallel b/n portal groups. Regards, Santosh Jim Hafner wrote: > > Folks, > > I'm curious to know from this group whether the following is an acceptable > alternative to the complex issues we're battling with the definition and > behavior of SCSI Initiator Port (viz a viz, ISID, key=value,etc.). > > Make the SCSI Initiator Port = initiator portal group, named by iSCSI Name > + portal group tag (which would be presented during login). > > Pros: > a) the model is completely symmetric on the initiator and the target side > b) namespace is managed by any mechanism to identify the portal group tag. > (For example, the tag could be the position in the SCSI port/module load > sequence (/dev/scsi[x]) OR one could derive the portal group tag from > either a MAC or from ipaddress of one of the interfaces in the portal > group). > c) the drivers present exactly one channel (SCSI initiator port) for each > initiator portal group to the upper layers in the OS (how that is > named/identified to the upper layers may be independent of how it is named > on the wire, i.e., independent of the portal group tag). > d) completely static/stable configuration on each boot (though it may > change, as it can today, between boots if components fail or are changed in > any way). > > Cons: > a) we *prohibit more than one session* between an initiator portal group > and a target portal group (to avoid parallel nexus). This has the side > consequence of making it harder to be a bad net-citizen by opening too many > connections through the same set of network interfaces (you open what you > want within a session only). > > I've always avoided this approach as I expected the "cons" would not be > acceptable, but I've never actually asked this of the group. > > So, what's the 'acceptability' of this approach? > > Jim Hafner > > Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 10/11/2001 08:58:41 am > > Sent by: owner-ips@ece.cmu.edu > > To: Black_David@emc.com, ips@ece.cmu.edu > cc: > Subject: Re: iSCSI: ISID progress > > David, > > More comments in line > > Jim Hafner > > Black_David@emc.com on 10/10/2001 03:48:55 pm > > To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu > cc: > Subject: iSCSI: ISID progress > > This message is shorter than my last one, so that's > at least a superficial indication of progress ;-). > > Jim and Julian had four comments/objections to the > notion of using a text key to indicate iSCSI Initiator > Port Name. Summarizing and responding: > > Jim (a): Optional use of port name is ok as far as SAM-2 is > concerned, but is odd. > > Indeed it is odd, but given the choice between an odd > mapping of SAM-2 to iSCSI and allowing odd behavior of > iSCSI implementations, I'll take the former. > > I'm not sure what "odd behavior of iSCSI implementations" you're referring > to here. > > > Jim (b): Would require at least as much coordination above > the session level of iSCSI as ISIDs. > > That would be incorrect. 128 bits is sufficient to eliminate > coordination. The reference for this is an expired Internet- > Draft, draft-leach-uuids-guids-01.txt, that can still be found > on the web at: > > http://casbah.org/cbRFC/misc/draft-leach-uuids-guids-01.txt > http://globecom.net/ietf/draft/draft-leach-uuids-guids-01.html > > I'm not seriously proposing that port name generation be done > in this fashion, but rather providing a widely used counter- > example to Jim's statement. Note that a network interface > MAC is likely to be available to many iSCSI implementations. > > I glanced through that draft and certainly don't think it is the right > approach to this problem. However, if you/we believe that by simply making > the equivalent of the ISID field or portname text value big enough, we can > find a solution to the "coordination problem", why can't we just *require* > that sessions have a SCSI port name (extension to iSCSI Name) that is long > enough to solve the weak or no coordination problem, instead of making this > "TBD"? > > I've argued that having the SCSI Portname is valuable. I've argued that > there wasn't any net value in putting the name in a key because I already > had the ISID field as part of the "name space for the session endpoint". > But if the claim is simply the ISID isn't big enough, then I don't have a > problem with effectively making them bigger (either in the header or in a > key value). I've even suggested one way to do that by embedding the > initiator portal group tag in the value. But another way is to embed the > OUI of the HBA (except for the cases where there isn't an HBA) or embed one > of the MACs of one of the nics (except for the cases where there isn't a > nic, e.g., dialup), etc. But we'd have to solve all the possible cases > (all of which the NDT had to deal with for iSCSI Names in the first place). > > So, are we at the point where (for this alternative proposal): > (a) we just need a bigger (than 2byte ISID) field for the SCSI portname > extension > (b) we just need an algorithm that lets each component that wants to > generate such a name can do so without collision concerns? > > > Jim (c): How to describe model when the text key is optional? > "Is it that all initiator session endpoints that don't > provide this text key have *implicit* unique names and > only when the text key is presented does the name get > explicit (and then possibly not be unique)? In that case, > the key would have to be supplied in login next to the > InitiatorName. > > Yes and yes when it's used, in that order. Jim's comment (a) > about this being odd applies. > > Julian: ... and have as much chances to blow a session as ISID > > That would also be incorrect. As previously stated, ISID conflict > is fatal to one of the sessions involved (one cannot change the > ISID and continue), and can occur in any system that opens parallel > sessions. This text key conflict need not be fatal (one can > change the text key and continue negotiation) and can only occur > in systems that want to use the new port-spanning persistent > reservation functionality, as other systems won't use the text > key. Also see the draft noted in response to Jim (b) above; > Julian's "have as much chance" language is incorrect. > > I think this is somewhat misleading about the cost ("fatal"). If we could > find a reasonable model for "reject: ISID in use" (rather than "blow away > the old session"), then the "fatal to one of the sessions" is a nit. This > would happen on the first exchange of a connection so starting over isn't > any big deal (we may not even have to require connection drop, just restart > of the initial message with new ISID). The same would happen with the key > as that would have to be somewhere in the pre-full feature phase (but in > this case it could happen anywhere in that phase). > > > As previously noted, I can also deal with requiring conservative > reuse of ISIDs as a means to address this situation. > > 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 > --------------------------------------------------- -- ################################## 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 Oct 11 18:06: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 SAA26818 for ; Thu, 11 Oct 2001 18:06:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BL3ju27855 for ips-outgoing; Thu, 11 Oct 2001 17:03: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 f9BL3il27851 for ; Thu, 11 Oct 2001 17:03: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 4035C1F613; Thu, 11 Oct 2001 14:03:38 -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 OAA15120; Thu, 11 Oct 2001 14:03:33 -0700 (PDT) Message-ID: <3BC60AE0.2BA5792D@cup.hp.com> Date: Thu, 11 Oct 2001 14:10:56 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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: SCSI Iniitator port: a simple approach, acceptable? 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, I am not in favor of the below proposal and would rather see the ISID model, for the reason you mention under "Cons". Up until now, the concept of "initiator portal groups" has not held any significant importance in the protocol, unlike target portal groups which is formal information exchanged b/n initiator and target, and which governs the session end points. How is the initiator portal group now going to be communicated to the iscsi HBAs ? In essence, we've just moved the piece of information that needs to be co-ordinated across HBAs, from being an ISID to being a portal group tag. For single connection sessions, it is essential that several sessions be allowed in parallel b/n portal groups. Regards, Santosh Jim Hafner wrote: > > Folks, > > I'm curious to know from this group whether the following is an acceptable > alternative to the complex issues we're battling with the definition and > behavior of SCSI Initiator Port (viz a viz, ISID, key=value,etc.). > > Make the SCSI Initiator Port = initiator portal group, named by iSCSI Name > + portal group tag (which would be presented during login). > > Pros: > a) the model is completely symmetric on the initiator and the target side > b) namespace is managed by any mechanism to identify the portal group tag. > (For example, the tag could be the position in the SCSI port/module load > sequence (/dev/scsi[x]) OR one could derive the portal group tag from > either a MAC or from ipaddress of one of the interfaces in the portal > group). > c) the drivers present exactly one channel (SCSI initiator port) for each > initiator portal group to the upper layers in the OS (how that is > named/identified to the upper layers may be independent of how it is named > on the wire, i.e., independent of the portal group tag). > d) completely static/stable configuration on each boot (though it may > change, as it can today, between boots if components fail or are changed in > any way). > > Cons: > a) we *prohibit more than one session* between an initiator portal group > and a target portal group (to avoid parallel nexus). This has the side > consequence of making it harder to be a bad net-citizen by opening too many > connections through the same set of network interfaces (you open what you > want within a session only). > > I've always avoided this approach as I expected the "cons" would not be > acceptable, but I've never actually asked this of the group. > > So, what's the 'acceptability' of this approach? > > Jim Hafner > > Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 10/11/2001 08:58:41 am > > Sent by: owner-ips@ece.cmu.edu > > To: Black_David@emc.com, ips@ece.cmu.edu > cc: > Subject: Re: iSCSI: ISID progress > > David, > > More comments in line > > Jim Hafner > > Black_David@emc.com on 10/10/2001 03:48:55 pm > > To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu > cc: > Subject: iSCSI: ISID progress > > This message is shorter than my last one, so that's > at least a superficial indication of progress ;-). > > Jim and Julian had four comments/objections to the > notion of using a text key to indicate iSCSI Initiator > Port Name. Summarizing and responding: > > Jim (a): Optional use of port name is ok as far as SAM-2 is > concerned, but is odd. > > Indeed it is odd, but given the choice between an odd > mapping of SAM-2 to iSCSI and allowing odd behavior of > iSCSI implementations, I'll take the former. > > I'm not sure what "odd behavior of iSCSI implementations" you're referring > to here. > > > Jim (b): Would require at least as much coordination above > the session level of iSCSI as ISIDs. > > That would be incorrect. 128 bits is sufficient to eliminate > coordination. The reference for this is an expired Internet- > Draft, draft-leach-uuids-guids-01.txt, that can still be found > on the web at: > > http://casbah.org/cbRFC/misc/draft-leach-uuids-guids-01.txt > http://globecom.net/ietf/draft/draft-leach-uuids-guids-01.html > > I'm not seriously proposing that port name generation be done > in this fashion, but rather providing a widely used counter- > example to Jim's statement. Note that a network interface > MAC is likely to be available to many iSCSI implementations. > > I glanced through that draft and certainly don't think it is the right > approach to this problem. However, if you/we believe that by simply making > the equivalent of the ISID field or portname text value big enough, we can > find a solution to the "coordination problem", why can't we just *require* > that sessions have a SCSI port name (extension to iSCSI Name) that is long > enough to solve the weak or no coordination problem, instead of making this > "TBD"? > > I've argued that having the SCSI Portname is valuable. I've argued that > there wasn't any net value in putting the name in a key because I already > had the ISID field as part of the "name space for the session endpoint". > But if the claim is simply the ISID isn't big enough, then I don't have a > problem with effectively making them bigger (either in the header or in a > key value). I've even suggested one way to do that by embedding the > initiator portal group tag in the value. But another way is to embed the > OUI of the HBA (except for the cases where there isn't an HBA) or embed one > of the MACs of one of the nics (except for the cases where there isn't a > nic, e.g., dialup), etc. But we'd have to solve all the possible cases > (all of which the NDT had to deal with for iSCSI Names in the first place). > > So, are we at the point where (for this alternative proposal): > (a) we just need a bigger (than 2byte ISID) field for the SCSI portname > extension > (b) we just need an algorithm that lets each component that wants to > generate such a name can do so without collision concerns? > > > Jim (c): How to describe model when the text key is optional? > "Is it that all initiator session endpoints that don't > provide this text key have *implicit* unique names and > only when the text key is presented does the name get > explicit (and then possibly not be unique)? In that case, > the key would have to be supplied in login next to the > InitiatorName. > > Yes and yes when it's used, in that order. Jim's comment (a) > about this being odd applies. > > Julian: ... and have as much chances to blow a session as ISID > > That would also be incorrect. As previously stated, ISID conflict > is fatal to one of the sessions involved (one cannot change the > ISID and continue), and can occur in any system that opens parallel > sessions. This text key conflict need not be fatal (one can > change the text key and continue negotiation) and can only occur > in systems that want to use the new port-spanning persistent > reservation functionality, as other systems won't use the text > key. Also see the draft noted in response to Jim (b) above; > Julian's "have as much chance" language is incorrect. > > I think this is somewhat misleading about the cost ("fatal"). If we could > find a reasonable model for "reject: ISID in use" (rather than "blow away > the old session"), then the "fatal to one of the sessions" is a nit. This > would happen on the first exchange of a connection so starting over isn't > any big deal (we may not even have to require connection drop, just restart > of the initial message with new ISID). The same would happen with the key > as that would have to be somewhere in the pre-full feature phase (but in > this case it could happen anywhere in that phase). > > > As previously noted, I can also deal with requiring conservative > reuse of ISIDs as a means to address this situation. > > 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 > --------------------------------------------------- -- ################################## 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 Oct 11 18:21: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 SAA27322 for ; Thu, 11 Oct 2001 18:21:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BL8I428172 for ips-outgoing; Thu, 11 Oct 2001 17:08:18 -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 f9BL8Hl28168 for ; Thu, 11 Oct 2001 17:08:17 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 34C0AD51; Thu, 11 Oct 2001 14:08:16 -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 OAA15365; Thu, 11 Oct 2001 14:08:11 -0700 (PDT) Message-ID: <3BC60BF7.5D4BE0C5@cup.hp.com> Date: Thu, 11 Oct 2001 14:15:35 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Eddy Quicksall Cc: julian_satran@il.ibm.com, ips@ece.cmu.edu Subject: Re: iSCSI: FirstBurstSize, etc References: <004101c15292$83f88650$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 Julian, I believe the definition of an outbound data sequence must be modified to factor in the initial immediate data sent in the scsi command pdu. The current definition of an outbound data sequence implies that it starts from a data-out pdu and therefore, excludes the immediate data component. As a result, Eddy's diagram shows FirstBurstSize to be > MaxBurstSize, since the data sequence does not include the immediate data. - Santosh Eddy Quicksall wrote: > > I am wondering about the following statement: > > FirstBurstSize MUST NOT exceed MaximumBurstSize. > > It doesn't seem to fit the various definitions. I made the following diagram > from the definitions and FirstBurstSize came out larger then MaxBurstSize. > > Here are the definitions I am going by: > > 25 FirstBurstSize > Initiator and target negotiate the maximum amount of unsolicited data > an iSCSI initiator may send to the target, during the execution of a > single SCSI command, in units of 512 bytes. > > 24 MaxBurstSize > Initiator and target negotiate 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. > > I get the definition of a sequence from "2.2.2.3 Data Sequencing": > > For output data PDUs, DataSN starts with 0 for the first data PDU of a > sequence (the initial unsolicited sequence or any data PDU sequence > issued to satisfy an R2T) and advances by 1 for each subsequent data > PDU. > > |<------------------ Unsolicited data ------------------->| > | |<------------ Sequence ------------>| > |Command | Immediate Data | |<---- Remaining unsolicited ------->| > |========|=================| |================| |F===============| > |<-DataPDULength->| | DataPDULength | | DataPDULength | > |<--------- MaxBurstSize ----------->| > |<------------------- FirstBurstSize -------------------->| > > Eddy_Quicksall@iVivity.com -- ################################## 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 Oct 11 18:47: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 SAA27957 for ; Thu, 11 Oct 2001 18:47:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BM8JP02017 for ips-outgoing; Thu, 11 Oct 2001 18:08: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 f9BM7vl01976 for ; Thu, 11 Oct 2001 18:08:17 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id 51C741E55 for ; Thu, 11 Oct 2001 18:07:56 -0400 (EDT) Received: from rose.hp.com (ros55621lap.rose.hp.com [15.43.209.180]) by core.rose.hp.com with ESMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id PAA15967 for ; Thu, 11 Oct 2001 15:09:19 -0700 (PDT) Message-ID: <3BC6198F.EA083930@rose.hp.com> Date: Thu, 11 Oct 2001 15:13:35 -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 Subject: iSCSI: data ACKs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Consequent to the London consensus on keeping SNACKs in the protocol, I believe it is fair to enable targets desirous of efficiently managing their buffers, by way of a data acknowledgement request-response mechanism in iSCSI (under certain constraints, as below) as earlier requested by Matthew Burbridge on this list. The current solution of allowing targets to re-access the medium to satisfy data transfer retransmission presents problems in the following cases - - any target in general that attempts to prevent reaccessing the medium in view of cache management complexities, or wanting to conserve backend SCSI bandwidth (only if the error rate is high). - tapes supporting queued commands, that want to free up memory to work on subsequent commands. - iSCSI "middle boxes" supporting multiple tape devices behind, and wanting to decrease buffer requirements. - the SCSI-legitimate (but perhaps highly unlikely) case of write-after-read to the same LBAs. I propose the following means to enable a data ACK mechanism - target requests an ACK by setting a TBD bit (say A-bit, for ACK) on read data PDU. It MAY set the A-bit once at most every MaxBurstSize bytes, and MUST NOT do so any more frequently than that. - an initiator generates a SNACK of type "ACK" (per Julian's earlier proposal) on reception of an A-bit data PDU. If there were pending data retransmissions in the burst, the generation of ACK is deferred till the holes are filled. - target processes the SNACK and frees up the acknowledged buffers. The reason a new A-bit is proposed to be used (in stead of the F-bit) is that there may be unrelated reasons for setting the F-bit by a target (may be to enable opposite data flow for a bidirectional command, for ex.). I believe that the implementation complexity in the above proposal is minimal, while the runtime cost is non-existent for all "short" (< MaxBurstSize) transfers, and the same for "long" transfers (> MaxBurstSize) is very reasonable. You will note that the onus is on targets to generate ACK requests and process ACKs, if they want to manage their buffers efficiently. Finally, the ack scheme should be applicable only to sessions where the operational ErrorRecoveryLevel >= 1. Comments? -- 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 Thu Oct 11 18:47: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 SAA27977 for ; Thu, 11 Oct 2001 18:47:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BLl2d00727 for ips-outgoing; Thu, 11 Oct 2001 17:47:02 -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 f9BLl0l00722 for ; Thu, 11 Oct 2001 17:47:00 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 36D6CA39; Thu, 11 Oct 2001 14:46: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 OAA18530; Thu, 11 Oct 2001 14:46:54 -0700 (PDT) Message-ID: <3BC61509.BA5C124A@cup.hp.com> Date: Thu, 11 Oct 2001 14:54:17 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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: SCSI Iniitator port: a simple approach, acceptable? 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: > > Santosh, > > I agree we haven't really solved the problem exactly (about what has to be > configured per HBA, though I hinted at an implementation of portal group > tag assignment that is based on network stuff, that might make it easier. > > It's your last comment that I was expecting to get solicited. But I'll ask > why is it so important to have several sessions in parallel? > If I can have multiple connections per session, doesn't that suffice for > multiplexing? If the target says only one connection per session, then > isn't that a hint that it has limited network resources and it would be bad > form to build too many sessions just to bypass this? Jim, I suspect you already know the answers to your questions ;) We've been through these questions already in the past. isci needs to continue to support operation of wedge drivers. There will exist both initiator and target implementations that do only single connection sessions. Such implementations can attempt to establish sessions to each TgtAddr advertised by the target, and several of these TgtAddr may belong to the same target portal group. Also, if a target supports session spanning across all of its controller ports, it may well export a single target portal group. Similarly, an initiator with no specific constraints (such as different vendor type implementations) has no reason to define more than 1 initiator portal group and may well be oblivious to the very concept of an initiator portal group. In such cases, the initiator will create multiple sessions from a single initiator portal group to multiple TgtAddr's within a single Target Portal Group. I believe it was the ISID based initiator port model that prevented the "parallel nexus" from occurring in the above scenario. - Santosh > > I'm not strongly advocating this, playing devil's advocate. > > Jim Hafner > > Santosh Rao @cup.hp.com on 10/11/2001 02:10:56 pm > > Sent by: santoshr@cup.hp.com > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: SCSI Iniitator port: a simple approach, acceptable? > > Jim, > > I am not in favor of the below proposal and would rather see the ISID > model, for the reason you mention under "Cons". > > Up until now, the concept of "initiator portal groups" has not held any > significant importance in the protocol, unlike target portal groups > which is formal information exchanged b/n initiator and target, and > which governs the session end points. > > How is the initiator portal group now going to be communicated to the > iscsi HBAs ? In essence, we've just moved the piece of information that > needs to be co-ordinated across HBAs, from being an ISID to being a > portal group tag. > > For single connection sessions, it is essential that several sessions be > allowed in parallel b/n portal groups. > > Regards, > Santosh > > Jim Hafner wrote: > > > > Folks, > > > > I'm curious to know from this group whether the following is an > acceptable > > alternative to the complex issues we're battling with the definition and > > behavior of SCSI Initiator Port (viz a viz, ISID, key=value,etc.). > > > > Make the SCSI Initiator Port = initiator portal group, named by iSCSI > Name > > + portal group tag (which would be presented during login). > > > > Pros: > > a) the model is completely symmetric on the initiator and the target side > > b) namespace is managed by any mechanism to identify the portal group > tag. > > (For example, the tag could be the position in the SCSI port/module load > > sequence (/dev/scsi[x]) OR one could derive the portal group tag from > > either a MAC or from ipaddress of one of the interfaces in the portal > > group). > > c) the drivers present exactly one channel (SCSI initiator port) for each > > initiator portal group to the upper layers in the OS (how that is > > named/identified to the upper layers may be independent of how it is > named > > on the wire, i.e., independent of the portal group tag). > > d) completely static/stable configuration on each boot (though it may > > change, as it can today, between boots if components fail or are changed > in > > any way). > > > > Cons: > > a) we *prohibit more than one session* between an initiator portal group > > and a target portal group (to avoid parallel nexus). This has the side > > consequence of making it harder to be a bad net-citizen by opening too > many > > connections through the same set of network interfaces (you open what you > > want within a session only). > > > > I've always avoided this approach as I expected the "cons" would not be > > acceptable, but I've never actually asked this of the group. > > > > So, what's the 'acceptability' of this approach? > > > > Jim Hafner > > > > Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 10/11/2001 08:58:41 am > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: Black_David@emc.com, ips@ece.cmu.edu > > cc: > > Subject: Re: iSCSI: ISID progress > > > > David, > > > > More comments in line > > > > Jim Hafner > > > > Black_David@emc.com on 10/10/2001 03:48:55 pm > > > > To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu > > cc: > > Subject: iSCSI: ISID progress > > > > This message is shorter than my last one, so that's > > at least a superficial indication of progress ;-). > > > > Jim and Julian had four comments/objections to the > > notion of using a text key to indicate iSCSI Initiator > > Port Name. Summarizing and responding: > > > > Jim (a): Optional use of port name is ok as far as SAM-2 is > > concerned, but is odd. > > > > Indeed it is odd, but given the choice between an odd > > mapping of SAM-2 to iSCSI and allowing odd behavior of > > iSCSI implementations, I'll take the former. > > > > I'm not sure what "odd behavior of iSCSI implementations" you're > referring > > to here. > > > > > > Jim (b): Would require at least as much coordination above > > the session level of iSCSI as ISIDs. > > > > That would be incorrect. 128 bits is sufficient to eliminate > > coordination. The reference for this is an expired Internet- > > Draft, draft-leach-uuids-guids-01.txt, that can still be found > > on the web at: > > > > http://casbah.org/cbRFC/misc/draft-leach-uuids-guids-01.txt > > http://globecom.net/ietf/draft/draft-leach-uuids-guids-01.html > > > > I'm not seriously proposing that port name generation be done > > in this fashion, but rather providing a widely used counter- > > example to Jim's statement. Note that a network interface > > MAC is likely to be available to many iSCSI implementations. > > > > I glanced through that draft and certainly don't think it is the right > > approach to this problem. However, if you/we believe that by simply > making > > the equivalent of the ISID field or portname text value big enough, we > can > > find a solution to the "coordination problem", why can't we just > *require* > > that sessions have a SCSI port name (extension to iSCSI Name) that is > long > > enough to solve the weak or no coordination problem, instead of making > this > > "TBD"? > > > > I've argued that having the SCSI Portname is valuable. I've argued that > > there wasn't any net value in putting the name in a key because I already > > had the ISID field as part of the "name space for the session endpoint". > > But if the claim is simply the ISID isn't big enough, then I don't have a > > problem with effectively making them bigger (either in the header or in a > > key value). I've even suggested one way to do that by embedding the > > initiator portal group tag in the value. But another way is to embed the > > OUI of the HBA (except for the cases where there isn't an HBA) or embed > one > > of the MACs of one of the nics (except for the cases where there isn't a > > nic, e.g., dialup), etc. But we'd have to solve all the possible cases > > (all of which the NDT had to deal with for iSCSI Names in the first > place). > > > > So, are we at the point where (for this alternative proposal): > > (a) we just need a bigger (than 2byte ISID) field for the SCSI portname > > extension > > (b) we just need an algorithm that lets each component that wants to > > generate such a name can do so without collision concerns? > > > > > > Jim (c): How to describe model when the text key is optional? > > "Is it that all initiator session endpoints that don't > > provide this text key have *implicit* unique names and > > only when the text key is presented does the name get > > explicit (and then possibly not be unique)? In that case, > > the key would have to be supplied in login next to the > > InitiatorName. > > > > Yes and yes when it's used, in that order. Jim's comment (a) > > about this being odd applies. > > > > Julian: ... and have as much chances to blow a session as ISID > > > > That would also be incorrect. As previously stated, ISID conflict > > is fatal to one of the sessions involved (one cannot change the > > ISID and continue), and can occur in any system that opens parallel > > sessions. This text key conflict need not be fatal (one can > > change the text key and continue negotiation) and can only occur > > in systems that want to use the new port-spanning persistent > > reservation functionality, as other systems won't use the text > > key. Also see the draft noted in response to Jim (b) above; > > Julian's "have as much chance" language is incorrect. > > > > I think this is somewhat misleading about the cost ("fatal"). If we > could > > find a reasonable model for "reject: ISID in use" (rather than "blow away > > the old session"), then the "fatal to one of the sessions" is a nit. > This > > would happen on the first exchange of a connection so starting over isn't > > any big deal (we may not even have to require connection drop, just > restart > > of the initial message with new ISID). The same would happen with the > key > > as that would have to be somewhere in the pre-full feature phase (but in > > this case it could happen anywhere in that phase). > > > > > > As previously noted, I can also deal with requiring conservative > > reuse of ISIDs as a means to address this situation. > > > > Thanks, > > --David -- ################################## 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 Oct 11 19:49: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 TAA28793 for ; Thu, 11 Oct 2001 19:49:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9BMouj04383 for ips-outgoing; Thu, 11 Oct 2001 18:50:56 -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 f9BMosl04378 for ; Thu, 11 Oct 2001 18:50:54 -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 AAA208458 for ; Fri, 12 Oct 2001 00:50: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 f9BMolL209374 for ; Fri, 12 Oct 2001 00:50:47 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: FirstBurstSize, etc X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Fri, 12 Oct 2001 01:50:45 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 12/10/2001 01:50:48, Serialize complete at 12/10/2001 01:50:48 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, I am going to make some changes related to PDUsize. I will fix this discrepancy and publish the suggested 09 text soon. Thanks, Julo "Eddy Quicksall" 11-10-01 22:22 Please respond to "Eddy Quicksall" To: Julian Satran/Haifa/IBM@IBMIL, cc: Subject: iSCSI: FirstBurstSize, etc I am wondering about the following statement: FirstBurstSize MUST NOT exceed MaximumBurstSize. It doesn't seem to fit the various definitions. I made the following diagram from the definitions and FirstBurstSize came out larger then MaxBurstSize. Here are the definitions I am going by: 25 FirstBurstSize Initiator and target negotiate the maximum amount of unsolicited data an iSCSI initiator may send to the target, during the execution of a single SCSI command, in units of 512 bytes. 24 MaxBurstSize Initiator and target negotiate 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. I get the definition of a sequence from "2.2.2.3 Data Sequencing": For output data PDUs, DataSN starts with 0 for the first data PDU of a sequence (the initial unsolicited sequence or any data PDU sequence issued to satisfy an R2T) and advances by 1 for each subsequent data PDU. |<------------------ Unsolicited data ------------------->| | |<------------ Sequence ------------>| |Command | Immediate Data | |<---- Remaining unsolicited ------->| |========|=================| |================| |F===============| |<-DataPDULength->| | DataPDULength | | DataPDULength | |<--------- MaxBurstSize ----------->| |<------------------- FirstBurstSize -------------------->| Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Fri Oct 12 11:02: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 LAA00570 for ; Fri, 12 Oct 2001 11:02:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9CDjwc23614 for ips-outgoing; Fri, 12 Oct 2001 09:45:58 -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 f9CDjul23606 for ; Fri, 12 Oct 2001 09:45:56 -0400 (EDT) Received: by apollo.pirus.com with Internet Mail Service (5.5.2650.21) id ; Fri, 12 Oct 2001 09:50:10 -0400 Message-ID: From: "Binford, Charles" To: ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Date: Fri, 12 Oct 2001 09:49:52 -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 have not verify version 8 is still the same, but version 07-97 had a rule that unsolicited data MUST be sent in the same order as the commands. Thus, there is no need for a search on the ITT. The target just needs to keep of linked list of I/Os waiting on unsolicited data. New commands are added to the tail, any unsolicited data *should* be associated with the I/O at the head of the list. The ITT is used as a sanity check and you're done. What am I missing? Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, October 11, 2001 3:21 AM To: 'Paul Koning' Cc: ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Since I started this thread I feel I must at least contribute! The reason why I proposed putting CmdSN (actually it should be RefCmdSN) in the Data-out PDUs was to enable the target to have a faster search to associate unsolicited data out PDUs with its SCSI Command PDU. Solicited Data-out PDUs do not require this as they have a Target Task Tag. If all Command PDUs were queued then I believe this would work just fine. However, as Santosh correctly pointed out they are not and without repeating what he said this mechanism would not work for immediate command PDUs. I am sure that particular implementations could make this work but the underlying argument is that it needs to work and be useful to all implementations. The only benefit I now see of having CmdSN in the data PDU is as a check as implementations must (and can only) use the initiator task tag to associated the Data-out PDU with the command PDU. Therefore, IMO it is not a good enough reason for having CmdSN in the Data-out PDUs simply for a consistency check. The benefit of having the data sent unsolicited to minimise if not eradicate round trip times far out weighs the overhead in having to perform a search on receipt of unsolicited data. If we could have developed a well defined mechanism to overcome this overhead then all well and good and that is what I attempted. Still, if someone can do this and the solution is simple and straight forward then I am sure that it will have my backing but until then ... Cheers Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Paul Koning [mailto:pkoning@jlc.net] Sent: Wednesday, October 10, 2001 5:07 PM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU Excerpt of message (sent 10 October 2001) by Julian Satran: > Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it > may have large holes and using it in an implementation is as bad as a > hashed index. Not true. CmdSN values are sequential, by definition. Yes, clearly there will be small holes because commands complete out of order. But "large" holes are unlikely. In any case, the target has control over that. I can use an array whose size is given by the number of pending commands times a correction factor to account for the likely density of holes. Then MaxCmdSN would be updated based on two considerations: the ability to handle more pending commands, and the need to keep the distance between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the size of the lookup array. So having CmdSN in the DataOut PDU allows this approach, thereby replacing a hash lookup on a rapidly changing ID space by a simple array indexing operation. Without CmdSN, you're forced to use a mechanism that has a lot more overhead (in the insert/remove or in the lookup, depending on the mechanism chosen). paul From owner-ips@ece.cmu.edu Fri Oct 12 11:55: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 LAA02113 for ; Fri, 12 Oct 2001 11:55:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9CEquI27623 for ips-outgoing; Fri, 12 Oct 2001 10:52:56 -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 f9CEqrl27616 for ; Fri, 12 Oct 2001 10:52:53 -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 70EB913D; Fri, 12 Oct 2001 16:52:51 +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 PAA18380; Fri, 12 Oct 2001 15:52:49 +0100 (BST) Received: from 15.145.8.186 by fowey.BR.ITC.HP.COM (InterScan E-Mail VirusWall NT); Fri, 12 Oct 2001 15:52:49 +0100 (GMT Daylight Time) Received: by fowey.br.itc.hp.com with Internet Mail Service (5.5.2653.19) id <4SJLFH6X>; Fri, 12 Oct 2001 15:52:49 +0100 Message-ID: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C69@dickens.bri.hp.com> From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" To: "'Binford, Charles'" , ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Date: Fri, 12 Oct 2001 15:52:48 +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 Charles, As you have described the spec states that "that unsolicited data MUST be sent in the same order as the commands". This is not the same as unsolicited data must follow the command associated with it: For example: (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The x in all the example can be the ITT. It is not the CmdSN. This is allowed: C1 C2 C3 D1 D2 C4 D3 D4 and the target will have to use the ITT to associate the data with the command. Matthew -----Original Message----- From: Binford, Charles [mailto:CBinford@pirus.com] Sent: Friday, October 12, 2001 2:50 PM To: ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU I have not verify version 8 is still the same, but version 07-97 had a rule that unsolicited data MUST be sent in the same order as the commands. Thus, there is no need for a search on the ITT. The target just needs to keep of linked list of I/Os waiting on unsolicited data. New commands are added to the tail, any unsolicited data *should* be associated with the I/O at the head of the list. The ITT is used as a sanity check and you're done. What am I missing? Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, October 11, 2001 3:21 AM To: 'Paul Koning' Cc: ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Since I started this thread I feel I must at least contribute! The reason why I proposed putting CmdSN (actually it should be RefCmdSN) in the Data-out PDUs was to enable the target to have a faster search to associate unsolicited data out PDUs with its SCSI Command PDU. Solicited Data-out PDUs do not require this as they have a Target Task Tag. If all Command PDUs were queued then I believe this would work just fine. However, as Santosh correctly pointed out they are not and without repeating what he said this mechanism would not work for immediate command PDUs. I am sure that particular implementations could make this work but the underlying argument is that it needs to work and be useful to all implementations. The only benefit I now see of having CmdSN in the data PDU is as a check as implementations must (and can only) use the initiator task tag to associated the Data-out PDU with the command PDU. Therefore, IMO it is not a good enough reason for having CmdSN in the Data-out PDUs simply for a consistency check. The benefit of having the data sent unsolicited to minimise if not eradicate round trip times far out weighs the overhead in having to perform a search on receipt of unsolicited data. If we could have developed a well defined mechanism to overcome this overhead then all well and good and that is what I attempted. Still, if someone can do this and the solution is simple and straight forward then I am sure that it will have my backing but until then ... Cheers Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Paul Koning [mailto:pkoning@jlc.net] Sent: Wednesday, October 10, 2001 5:07 PM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU Excerpt of message (sent 10 October 2001) by Julian Satran: > Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it > may have large holes and using it in an implementation is as bad as a > hashed index. Not true. CmdSN values are sequential, by definition. Yes, clearly there will be small holes because commands complete out of order. But "large" holes are unlikely. In any case, the target has control over that. I can use an array whose size is given by the number of pending commands times a correction factor to account for the likely density of holes. Then MaxCmdSN would be updated based on two considerations: the ability to handle more pending commands, and the need to keep the distance between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the size of the lookup array. So having CmdSN in the DataOut PDU allows this approach, thereby replacing a hash lookup on a rapidly changing ID space by a simple array indexing operation. Without CmdSN, you're forced to use a mechanism that has a lot more overhead (in the insert/remove or in the lookup, depending on the mechanism chosen). paul From owner-ips@ece.cmu.edu Fri Oct 12 16:43: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 QAA09145 for ; Fri, 12 Oct 2001 16:43:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9CJZM520340 for ips-outgoing; Fri, 12 Oct 2001 15:35:22 -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 f9CJZJl20335 for ; Fri, 12 Oct 2001 15:35:19 -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 f9CJZYh22104; Fri, 12 Oct 2001 15:35:34 -0400 (EDT) From: "Eddy Quicksall" To: "'BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)'" , Subject: RE: Addition of CmdSN in Data-out PDU Date: Fri, 12 Oct 2001 15:34:51 -0400 Message-ID: <000101c15355$00f0c830$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: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C69@dickens.bri.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Matthew, The statement would also imply the following would be legal, do you agree? Cx = SCSI Command w/ITT=x, Dxyz = unsolicited data w/ITT=x and DataSN=y and Final=z C1 C2 D11 D21 D22 D12F D23F i.e., the only rule is that the data for an ITT can't come before the command for the same ITT. Eddy -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Friday, October 12, 2001 10:53 AM To: 'Binford, Charles'; ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Charles, As you have described the spec states that "that unsolicited data MUST be sent in the same order as the commands". This is not the same as unsolicited data must follow the command associated with it: For example: (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The x in all the example can be the ITT. It is not the CmdSN. This is allowed: C1 C2 C3 D1 D2 C4 D3 D4 and the target will have to use the ITT to associate the data with the command. Matthew -----Original Message----- From: Binford, Charles [mailto:CBinford@pirus.com] Sent: Friday, October 12, 2001 2:50 PM To: ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU I have not verify version 8 is still the same, but version 07-97 had a rule that unsolicited data MUST be sent in the same order as the commands. Thus, there is no need for a search on the ITT. The target just needs to keep of linked list of I/Os waiting on unsolicited data. New commands are added to the tail, any unsolicited data *should* be associated with the I/O at the head of the list. The ITT is used as a sanity check and you're done. What am I missing? Charles Binford Pirus Networks 316.315.0382 x222 -----Original Message----- From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) [mailto:matthew_burbridge@hp.com] Sent: Thursday, October 11, 2001 3:21 AM To: 'Paul Koning' Cc: ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Since I started this thread I feel I must at least contribute! The reason why I proposed putting CmdSN (actually it should be RefCmdSN) in the Data-out PDUs was to enable the target to have a faster search to associate unsolicited data out PDUs with its SCSI Command PDU. Solicited Data-out PDUs do not require this as they have a Target Task Tag. If all Command PDUs were queued then I believe this would work just fine. However, as Santosh correctly pointed out they are not and without repeating what he said this mechanism would not work for immediate command PDUs. I am sure that particular implementations could make this work but the underlying argument is that it needs to work and be useful to all implementations. The only benefit I now see of having CmdSN in the data PDU is as a check as implementations must (and can only) use the initiator task tag to associated the Data-out PDU with the command PDU. Therefore, IMO it is not a good enough reason for having CmdSN in the Data-out PDUs simply for a consistency check. The benefit of having the data sent unsolicited to minimise if not eradicate round trip times far out weighs the overhead in having to perform a search on receipt of unsolicited data. If we could have developed a well defined mechanism to overcome this overhead then all well and good and that is what I attempted. Still, if someone can do this and the solution is simple and straight forward then I am sure that it will have my backing but until then ... Cheers Matthew Burbridge Senior Development Engineer NIS-Bristol Hewlett Packard Telnet: 312 7010 E-mail: matthewb@bri.hp.com -----Original Message----- From: Paul Koning [mailto:pkoning@jlc.net] Sent: Wednesday, October 10, 2001 5:07 PM To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU Excerpt of message (sent 10 October 2001) by Julian Satran: > Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it > may have large holes and using it in an implementation is as bad as a > hashed index. Not true. CmdSN values are sequential, by definition. Yes, clearly there will be small holes because commands complete out of order. But "large" holes are unlikely. In any case, the target has control over that. I can use an array whose size is given by the number of pending commands times a correction factor to account for the likely density of holes. Then MaxCmdSN would be updated based on two considerations: the ability to handle more pending commands, and the need to keep the distance between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the size of the lookup array. So having CmdSN in the DataOut PDU allows this approach, thereby replacing a hash lookup on a rapidly changing ID space by a simple array indexing operation. Without CmdSN, you're forced to use a mechanism that has a lot more overhead (in the insert/remove or in the lookup, depending on the mechanism chosen). paul From owner-ips@ece.cmu.edu Fri Oct 12 18:57: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 SAA10705 for ; Fri, 12 Oct 2001 18:57:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9CLr7n29813 for ips-outgoing; Fri, 12 Oct 2001 17:53:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from philotas.hosting.pacbell.net (philotas.hosting.pacbell.net [216.100.99.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9CLr5l29806 for ; Fri, 12 Oct 2001 17:53:05 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by philotas.hosting.pacbell.net id RAA12108; Fri, 12 Oct 2001 17:52:53 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)" , "'Binford, Charles'" , Subject: RE: Addition of CmdSN in Data-out PDU Date: Fri, 12 Oct 2001 14:51:15 -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.6700 Importance: Normal In-Reply-To: <0B9A57FF1D57D411B47500D0B73E5CC104FF1C69@dickens.bri.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Matthew, Since the unsolicited data does not follow the command, you need the link list. But since the unsolicited data must be sent in the same order as the commands, a link list is enough. Let us say that you have 8 commands. The ones for which we expect unsolicted data are marked as Cnn(ud). And I have marked the unsolicted data PDUs as UD(nn). The (nn) with data implies that it is implicit and not actually carried with the PDU itself. C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> --> UD(07) C08(ud) UD(08) ---> After the target receives the command C01, C02, and C03 for which it expects unsolicited data, it puts them in a link list. It also receives C04 and C05 for which unsolicited data is not expected and they don't go on the list. It then receives C06 for which unsolicited data is expected, and it is added to then end of the list. Then an unsolicited data PDU is received. It must go with the command at the head of the list which is C01. Use the ITT to make sure and you can then take C01 off the list and so on. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > Sent: Friday, October 12, 2001 7:53 AM > To: 'Binford, Charles'; ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > Charles, > > As you have described the spec states that "that unsolicited data MUST be > sent in the same order as the commands". This is not the same as > unsolicited data must follow the command associated with it: For example: > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The x in all the > example can be the ITT. It is not the CmdSN. > > This is allowed: > > C1 C2 C3 D1 D2 C4 D3 D4 > > and the target will have to use the ITT to associate the data with the > command. > > Matthew > > > -----Original Message----- > From: Binford, Charles [mailto:CBinford@pirus.com] > Sent: Friday, October 12, 2001 2:50 PM > To: ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > I have not verify version 8 is still the same, but version 07-97 > had a rule > that unsolicited data MUST be sent in the same order as the commands. > > Thus, there is no need for a search on the ITT. The target just needs to > keep of linked list of I/Os waiting on unsolicited data. New commands are > added to the tail, any unsolicited data *should* be associated > with the I/O > at the head of the list. The ITT is used as a sanity check and > you're done. > > What am I missing? > > Charles Binford > Pirus Networks > 316.315.0382 x222 > > > -----Original Message----- > From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > [mailto:matthew_burbridge@hp.com] > Sent: Thursday, October 11, 2001 3:21 AM > To: 'Paul Koning' > Cc: ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > Since I started this thread I feel I must at least contribute! > > The reason why I proposed putting CmdSN (actually it should be > RefCmdSN) in > the Data-out PDUs was to enable the target to have a faster search to > associate unsolicited data out PDUs with its SCSI Command PDU. Solicited > Data-out PDUs do not require this as they have a Target Task Tag. > > If all Command PDUs were queued then I believe this would work just fine. > However, as Santosh correctly pointed out they are not and > without repeating > what he said this mechanism would not work for immediate command PDUs. > > I am sure that particular implementations could make this work but the > underlying argument is that it needs to work and be useful to all > implementations. The only benefit I now see of having CmdSN in > the data PDU > is as a check as implementations must (and can only) use the > initiator task > tag to associated the Data-out PDU with the command PDU. > Therefore, IMO it > is not a good enough reason for having CmdSN in the Data-out PDUs > simply for > a consistency check. > > The benefit of having the data sent unsolicited to minimise if > not eradicate > round trip times far out weighs the overhead in having to perform a search > on receipt of unsolicited data. If we could have developed a well defined > mechanism to overcome this overhead then all well and good and > that is what > I attempted. Still, if someone can do this and the solution is simple and > straight forward then I am sure that it will have my backing but > until then > ... > > Cheers > > Matthew Burbridge > Senior Development Engineer > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > > > -----Original Message----- > From: Paul Koning [mailto:pkoning@jlc.net] > Sent: Wednesday, October 10, 2001 5:07 PM > To: Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: Re: Addition of CmdSN in Data-out PDU > > > Excerpt of message (sent 10 October 2001) by Julian Satran: > > Inconsistency can be legitimate. CmdSN is ephemeral. It can be > reused, it > > may have large holes and using it in an implementation is as bad as a > > hashed index. > > Not true. > > CmdSN values are sequential, by definition. Yes, clearly there will > be small holes because commands complete out of order. But "large" > holes are unlikely. > > In any case, the target has control over that. I can use an array > whose size is given by the number of pending commands times a > correction factor to account for the likely density of holes. Then > MaxCmdSN would be updated based on two considerations: the ability to > handle more pending commands, and the need to keep the distance > between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the > size of the lookup array. > > So having CmdSN in the DataOut PDU allows this approach, thereby > replacing a hash lookup on a rapidly changing ID space by a simple > array indexing operation. Without CmdSN, you're forced to use a > mechanism that has a lot more overhead (in the insert/remove or in the > lookup, depending on the mechanism chosen). > > paul > From owner-ips@ece.cmu.edu Fri Oct 12 19: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 TAA11099 for ; Fri, 12 Oct 2001 19:22:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9CN2Ux04226 for ips-outgoing; Fri, 12 Oct 2001 19:02:30 -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 f9CN2Sl04222 for ; Fri, 12 Oct 2001 19:02: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 43FF1755; Fri, 12 Oct 2001 16:02:27 -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 QAA04189; Fri, 12 Oct 2001 16:02:23 -0700 (PDT) Message-ID: <3BC7783D.98F9A888@cup.hp.com> Date: Fri, 12 Oct 2001 16:09:49 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: somesh_gupta@silverbacksystems.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: SCSI Iniitator port: a simple approach, acceptable? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Somesh, I don't understand your concern voiced below. A session spanning multiple adapters requires the host resident session manager to co-ordinate assignment of initiator task tag, cmdsn, exp_cmdsn & max_cmdsn, [over and beyond the usual initiator name & ISID/TSID]. The initiator task tag & cmdsn can be passed down from the session manager to the HBA in a mailbox command, as a part of issuing a new iscsi command, and the (exp_cmdsn, max_cmdsn) values can be updated to the host resident session manager by the HBA as a part of conveying a mailbox command completion. There are no extra host interrupts in normal I/O paths due to the presence of a host resident session manager. If you're referring to locking overheads, then, these can be optimized out. I don't see why a host resident session manager affects performance of a multi-connection session ? Regards, Santosh Somesh Gupta wrote: > > Jim, > > Multiple connections, especially when spread across multiple > adapters will give performance that will be much less than > that of multiple sessions in parallel (of course when there > are multiple connections/session over multiple adapters - the > adapters have to be able to take the session id from the > host software - I obviously don't get the point of the debate). > > There is no way a common synchronization point for > command sequencing and flow control at the host level will not > cause sub-standard performance. I have argued this point > many times before, only to have it be brushed aside. Of course, > only time will tell. > > Somesh > -- ################################## 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 Oct 12 19:23: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 TAA11111 for ; Fri, 12 Oct 2001 19:23:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9CMumT03845 for ips-outgoing; Fri, 12 Oct 2001 18:56:48 -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 f9CMuTl03826 for ; Fri, 12 Oct 2001 18:56:30 -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 PAA16570; Fri, 12 Oct 2001 15:56:07 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWV5CXZ>; Fri, 12 Oct 2001 15:56:07 -0700 Message-ID: From: Robert Snively To: "'somesh_gupta@silverbacksystems.com'" , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Binford, Charles'" , ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Date: Fri, 12 Oct 2001 15:56:06 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I have two small questions that would help me understand this. How do you know that unsolicited data is expected? By nature, unsolicited data is received as a "maximum surprise" which can only be determined after unpacking and parsing at least a part of the command structure, possibly even including the SCSI command (although there are some hints contained in the command header information). How can you constrain a generic system to posting the unsolicited data in the same order that the commands were emitted? In general, I would have expected the system to be emitting command followed immediately by the corresponding unsolicited data. If that is not the case, it means that there was a delay in obtaining the unsolicited data for transfer and that the delay was sufficient to allow the insertion of commands. If the delay is that large (and probably variable), the enforcement of transfer of unsolicited data in the same order as the commands are emitted seems to me to be a significant challenge, and certainly shouldn't be required as normal behavior. While it would make things simpler for targets (already challenged by unsolicited data), it seems to me that it would make things much more complex for initiators. Bob > -----Original Message----- > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > Sent: Friday, October 12, 2001 2:51 PM > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > Matthew, > > Since the unsolicited data does not follow the > command, you need the link list. But since the > unsolicited data must be sent in the same order > as the commands, a link list is enough. > > Let us say that you have 8 commands. The ones > for which we expect unsolicted data are marked > as Cnn(ud). And I have marked the unsolicted > data PDUs as UD(nn). The (nn) with data implies > that it is implicit and not actually carried with > the PDU itself. > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > --> UD(07) C08(ud) UD(08) ---> > > After the target receives the command C01, C02, and C03 > for which it expects unsolicited data, it puts them in > a link list. It also receives C04 and C05 for which > unsolicited data is not expected and they don't go > on the list. It then receives C06 for which unsolicited > data is expected, and it is added to then end of the list. > Then an unsolicited data PDU is received. It must go > with the command at the head of the list which is C01. > Use the ITT to make sure and you can then take C01 off > the list and so on. > > Somesh > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > Sent: Friday, October 12, 2001 7:53 AM > > To: 'Binford, Charles'; ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Charles, > > > > As you have described the spec states that "that > unsolicited data MUST be > > sent in the same order as the commands". This is not the same as > > unsolicited data must follow the command associated with > it: For example: > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > x in all the > > example can be the ITT. It is not the CmdSN. > > > > This is allowed: > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > and the target will have to use the ITT to associate the > data with the > > command. > > > > Matthew > > > > > > -----Original Message----- > > From: Binford, Charles [mailto:CBinford@pirus.com] > > Sent: Friday, October 12, 2001 2:50 PM > > To: ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > I have not verify version 8 is still the same, but version 07-97 > > had a rule > > that unsolicited data MUST be sent in the same order as the > commands. > > > > Thus, there is no need for a search on the ITT. The target > just needs to > > keep of linked list of I/Os waiting on unsolicited data. > New commands are > > added to the tail, any unsolicited data *should* be associated > > with the I/O > > at the head of the list. The ITT is used as a sanity check and > > you're done. > > > > What am I missing? > > > > Charles Binford > > Pirus Networks > > 316.315.0382 x222 From owner-ips@ece.cmu.edu Fri Oct 12 19:24: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 TAA11172 for ; Fri, 12 Oct 2001 19:24:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9CMXAF02520 for ips-outgoing; Fri, 12 Oct 2001 18:33:10 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from eumenes.hosting.pacbell.net (eumenes.hosting.pacbell.net [216.100.98.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9CMX8l02515 for ; Fri, 12 Oct 2001 18:33:08 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by eumenes.hosting.pacbell.net id SAA03792; Fri, 12 Oct 2001 18:33:03 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: Subject: RE: iSCSI: SCSI Iniitator port: a simple approach, acceptable? Date: Fri, 12 Oct 2001 15:31:25 -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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim, Multiple connections, especially when spread across multiple adapters will give performance that will be much less than that of multiple sessions in parallel (of course when there are multiple connections/session over multiple adapters - the adapters have to be able to take the session id from the host software - I obviously don't get the point of the debate). There is no way a common synchronization point for command sequencing and flow control at the host level will not cause sub-standard performance. I have argued this point many times before, only to have it be brushed aside. Of course, only time will tell. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Jim Hafner > Sent: Thursday, October 11, 2001 2:34 PM > To: Santosh Rao; ips@ece.cmu.edu > Subject: Re: iSCSI: SCSI Iniitator port: a simple approach, acceptable? > > > > Santosh, > > I agree we haven't really solved the problem exactly (about what has to be > configured per HBA, though I hinted at an implementation of portal group > tag assignment that is based on network stuff, that might make it easier. > > It's your last comment that I was expecting to get solicited. > But I'll ask > why is it so important to have several sessions in parallel? > If I can have multiple connections per session, doesn't that suffice for > multiplexing? If the target says only one connection per session, then > isn't that a hint that it has limited network resources and it > would be bad > form to build too many sessions just to bypass this? > > I'm not strongly advocating this, playing devil's advocate. > > Jim Hafner > > > Santosh Rao @cup.hp.com on 10/11/2001 02:10:56 pm > > Sent by: santoshr@cup.hp.com > > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: SCSI Iniitator port: a simple approach, acceptable? > > > > Jim, > > I am not in favor of the below proposal and would rather see the ISID > model, for the reason you mention under "Cons". > > Up until now, the concept of "initiator portal groups" has not held any > significant importance in the protocol, unlike target portal groups > which is formal information exchanged b/n initiator and target, and > which governs the session end points. > > How is the initiator portal group now going to be communicated to the > iscsi HBAs ? In essence, we've just moved the piece of information that > needs to be co-ordinated across HBAs, from being an ISID to being a > portal group tag. > > For single connection sessions, it is essential that several sessions be > allowed in parallel b/n portal groups. > > Regards, > Santosh > > > Jim Hafner wrote: > > > > Folks, > > > > I'm curious to know from this group whether the following is an > acceptable > > alternative to the complex issues we're battling with the definition and > > behavior of SCSI Initiator Port (viz a viz, ISID, key=value,etc.). > > > > Make the SCSI Initiator Port = initiator portal group, named by iSCSI > Name > > + portal group tag (which would be presented during login). > > > > Pros: > > a) the model is completely symmetric on the initiator and the > target side > > b) namespace is managed by any mechanism to identify the portal group > tag. > > (For example, the tag could be the position in the SCSI port/module load > > sequence (/dev/scsi[x]) OR one could derive the portal group tag from > > either a MAC or from ipaddress of one of the interfaces in the portal > > group). > > c) the drivers present exactly one channel (SCSI initiator > port) for each > > initiator portal group to the upper layers in the OS (how that is > > named/identified to the upper layers may be independent of how it is > named > > on the wire, i.e., independent of the portal group tag). > > d) completely static/stable configuration on each boot (though it may > > change, as it can today, between boots if components fail or are changed > in > > any way). > > > > Cons: > > a) we *prohibit more than one session* between an initiator > portal group > > and a target portal group (to avoid parallel nexus). This has the side > > consequence of making it harder to be a bad net-citizen by opening too > many > > connections through the same set of network interfaces (you > open what you > > want within a session only). > > > > I've always avoided this approach as I expected the "cons" would not be > > acceptable, but I've never actually asked this of the group. > > > > So, what's the 'acceptability' of this approach? > > > > Jim Hafner > > > > Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 10/11/2001 08:58:41 am > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: Black_David@emc.com, ips@ece.cmu.edu > > cc: > > Subject: Re: iSCSI: ISID progress > > > > David, > > > > More comments in line > > > > Jim Hafner > > > > Black_David@emc.com on 10/10/2001 03:48:55 pm > > > > To: Jim Hafner/Almaden/IBM@IBMUS, ips@ece.cmu.edu > > cc: > > Subject: iSCSI: ISID progress > > > > This message is shorter than my last one, so that's > > at least a superficial indication of progress ;-). > > > > Jim and Julian had four comments/objections to the > > notion of using a text key to indicate iSCSI Initiator > > Port Name. Summarizing and responding: > > > > Jim (a): Optional use of port name is ok as far as SAM-2 is > > concerned, but is odd. > > > > Indeed it is odd, but given the choice between an odd > > mapping of SAM-2 to iSCSI and allowing odd behavior of > > iSCSI implementations, I'll take the former. > > > > I'm not sure what "odd behavior of iSCSI implementations" you're > referring > > to here. > > > > > > Jim (b): Would require at least as much coordination above > > the session level of iSCSI as ISIDs. > > > > That would be incorrect. 128 bits is sufficient to eliminate > > coordination. The reference for this is an expired Internet- > > Draft, draft-leach-uuids-guids-01.txt, that can still be found > > on the web at: > > > > http://casbah.org/cbRFC/misc/draft-leach-uuids-guids-01.txt > > http://globecom.net/ietf/draft/draft-leach-uuids-guids-01.html > > > > I'm not seriously proposing that port name generation be done > > in this fashion, but rather providing a widely used counter- > > example to Jim's statement. Note that a network interface > > MAC is likely to be available to many iSCSI implementations. > > > > I glanced through that draft and certainly don't think it is the right > > approach to this problem. However, if you/we believe that by simply > making > > the equivalent of the ISID field or portname text value big enough, we > can > > find a solution to the "coordination problem", why can't we just > *require* > > that sessions have a SCSI port name (extension to iSCSI Name) that is > long > > enough to solve the weak or no coordination problem, instead of making > this > > "TBD"? > > > > I've argued that having the SCSI Portname is valuable. I've argued that > > there wasn't any net value in putting the name in a key because > I already > > had the ISID field as part of the "name space for the session endpoint". > > But if the claim is simply the ISID isn't big enough, then I > don't have a > > problem with effectively making them bigger (either in the > header or in a > > key value). I've even suggested one way to do that by embedding the > > initiator portal group tag in the value. But another way is to > embed the > > OUI of the HBA (except for the cases where there isn't an HBA) or embed > one > > of the MACs of one of the nics (except for the cases where there isn't a > > nic, e.g., dialup), etc. But we'd have to solve all the possible cases > > (all of which the NDT had to deal with for iSCSI Names in the first > place). > > > > So, are we at the point where (for this alternative proposal): > > (a) we just need a bigger (than 2byte ISID) field for the SCSI portname > > extension > > (b) we just need an algorithm that lets each component that wants to > > generate such a name can do so without collision concerns? > > > > > > Jim (c): How to describe model when the text key is optional? > > "Is it that all initiator session endpoints that don't > > provide this text key have *implicit* unique names and > > only when the text key is presented does the name get > > explicit (and then possibly not be unique)? In that case, > > the key would have to be supplied in login next to the > > InitiatorName. > > > > Yes and yes when it's used, in that order. Jim's comment (a) > > about this being odd applies. > > > > Julian: ... and have as much chances to blow a session as ISID > > > > That would also be incorrect. As previously stated, ISID conflict > > is fatal to one of the sessions involved (one cannot change the > > ISID and continue), and can occur in any system that opens parallel > > sessions. This text key conflict need not be fatal (one can > > change the text key and continue negotiation) and can only occur > > in systems that want to use the new port-spanning persistent > > reservation functionality, as other systems won't use the text > > key. Also see the draft noted in response to Jim (b) above; > > Julian's "have as much chance" language is incorrect. > > > > I think this is somewhat misleading about the cost ("fatal"). If we > could > > find a reasonable model for "reject: ISID in use" (rather than > "blow away > > the old session"), then the "fatal to one of the sessions" is a nit. > This > > would happen on the first exchange of a connection so starting > over isn't > > any big deal (we may not even have to require connection drop, just > restart > > of the initial message with new ISID). The same would happen with the > key > > as that would have to be somewhere in the pre-full feature phase (but in > > this case it could happen anywhere in that phase). > > > > > > As previously noted, I can also deal with requiring conservative > > reuse of ISIDs as a means to address this situation. > > > > 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 > > --------------------------------------------------- > > -- > ################################## > 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 Oct 12 20:33: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 UAA12110 for ; Fri, 12 Oct 2001 20:33:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9D0Ci108105 for ips-outgoing; Fri, 12 Oct 2001 20:12:44 -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 f9D0Cgl08098 for ; Fri, 12 Oct 2001 20:12:43 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 0BA72BD1; Fri, 12 Oct 2001 17:12:42 -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 RAA08150; Fri, 12 Oct 2001 17:12:32 -0700 (PDT) Message-ID: <3BC788AF.D12D9073@cup.hp.com> Date: Fri, 12 Oct 2001 17:19:59 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: somesh_gupta@silverbacksystems.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: SCSI Iniitator port: a simple approach, acceptable? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Somesh Gupta wrote: > > The initiator task tag & cmdsn can be passed down from the session > > manager to the HBA in a mailbox command, as a part of issuing a new > > iscsi command, and the (exp_cmdsn, max_cmdsn) values can be updated to > > the host resident session manager by the HBA as a part of conveying a > > mailbox command completion. There are no extra host interrupts in normal > > I/O paths due to the presence of a host resident session manager. > > > > If you're referring to locking overheads, then, these can be optimized > > out. > > You sort of answered the question yourself. As a cache line (containing > common numbers) ping-pongs > between processors that handle interrupts for different adapters, its > adds significant overhead. A 2GHz processor in a CC-Numa box sharing > cache lines between multiple processors? I think the above can be optimized out by some proper design. I don't think locking or cache thrashing are significant performance inhibitors that cannot be worked around in this case. > > This does not include the cost/complexity of managing multiple queues, > (and additional cache lines to share) What multiple queues ? (I don't see any major issues here either.) > and the fact that the "rare" retransmit has the potential to slow > everything down to the speed of the slowest connection. But, this is not a drawback of multi-connection session. It is a drawback due to the fact that the iscsi protocol chose to impose strict command ordering across the session [,which is not really required. But, I won't start that thread again !]. > > > > > > > > Somesh Gupta wrote: > > > > > > Jim, > > > > > > Multiple connections, especially when spread across multiple > > > adapters will give performance that will be much less than > > > that of multiple sessions in parallel (of course when there > > > are multiple connections/session over multiple adapters - the > > > adapters have to be able to take the session id from the > > > host software - I obviously don't get the point of the debate). > > > > > > There is no way a common synchronization point for > > > command sequencing and flow control at the host level will not > > > cause sub-standard performance. I have argued this point > > > many times before, only to have it be brushed aside. Of course, > > > only time will tell. > > > > > > Somesh > > > -- ################################## 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 Oct 12 20:33: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 UAA12121 for ; Fri, 12 Oct 2001 20:33:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9CNccS06240 for ips-outgoing; Fri, 12 Oct 2001 19:38:38 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from eumenes.hosting.pacbell.net (eumenes.hosting.pacbell.net [216.100.98.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9CNcal06235 for ; Fri, 12 Oct 2001 19:38:36 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by eumenes.hosting.pacbell.net id TAA17435; Fri, 12 Oct 2001 19:38:31 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "Robert Snively" , "BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)" , "'Binford, Charles'" , Subject: RE: Addition of CmdSN in Data-out PDU Date: Fri, 12 Oct 2001 16:36:54 -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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Robert Snively [mailto:rsnively@brocade.com] > Sent: Friday, October 12, 2001 3:56 PM > To: 'somesh_gupta@silverbacksystems.com'; BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2); 'Binford, Charles'; ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > I have two small questions that would help me understand this. > > How do you know that unsolicited data is expected? By nature, > unsolicited data is received as a "maximum surprise" which can > only be determined after unpacking and parsing at least a > part of the command structure, possibly even including the > SCSI command (although there are some hints contained in the > command header information). The F bit in the cmd PDU indicates whether unsolicited data PDUs should be expected for a particular SCSI command or not. There can be multiple unsolicited data PDUs for a particular command, and the last unsolicited data PDU for a command should have the F bit set. I assume that we use TTT = 0xffffffff to determine that this is an unsolicited data PDU. So yes, it would not be possible to do unsynchronized parallel processing of a packet containing a command and a packet containing unsolicited data for it. > > How can you constrain a generic system to posting the > unsolicited data in the same order that the commands were > emitted? That is a protocol requirement. > In general, I would have expected the system to > be emitting command followed immediately by the corresponding > unsolicited data. If that is not the case, it means that there > was a delay in obtaining the unsolicited data for transfer and > that the delay was sufficient to allow the insertion of commands. > If the delay is that large (and probably variable), the enforcement > of transfer of unsolicited data in the same order as the > commands are emitted seems to me to be a significant challenge, > and certainly shouldn't be required as normal behavior. While it > would make things simpler for targets (already challenged by > unsolicited data), it seems to me that it would make things > much more complex for initiators. I am not quite sure why we have the restriction. Julian should be able to shed more light on it. I think Costa had some deadlock scenario if ordering was not enforced (but I think that was before a command credit mechanism was mandated). However with multiple data PDUs, if some sort of ordering/completion rules are not mandated, there will be deadlock. One scenario that you do not mention is where an adapter might allow commands to pass data to reduce latency. > > Bob > > > -----Original Message----- > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > > Sent: Friday, October 12, 2001 2:51 PM > > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > > ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Matthew, > > > > Since the unsolicited data does not follow the > > command, you need the link list. But since the > > unsolicited data must be sent in the same order > > as the commands, a link list is enough. > > > > Let us say that you have 8 commands. The ones > > for which we expect unsolicted data are marked > > as Cnn(ud). And I have marked the unsolicted > > data PDUs as UD(nn). The (nn) with data implies > > that it is implicit and not actually carried with > > the PDU itself. > > > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > > --> UD(07) C08(ud) UD(08) ---> > > > > After the target receives the command C01, C02, and C03 > > for which it expects unsolicited data, it puts them in > > a link list. It also receives C04 and C05 for which > > unsolicited data is not expected and they don't go > > on the list. It then receives C06 for which unsolicited > > data is expected, and it is added to then end of the list. > > Then an unsolicited data PDU is received. It must go > > with the command at the head of the list which is C01. > > Use the ITT to make sure and you can then take C01 off > > the list and so on. > > > > Somesh > > > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > > Sent: Friday, October 12, 2001 7:53 AM > > > To: 'Binford, Charles'; ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > Charles, > > > > > > As you have described the spec states that "that > > unsolicited data MUST be > > > sent in the same order as the commands". This is not the same as > > > unsolicited data must follow the command associated with > > it: For example: > > > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > > x in all the > > > example can be the ITT. It is not the CmdSN. > > > > > > This is allowed: > > > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > > > and the target will have to use the ITT to associate the > > data with the > > > command. > > > > > > Matthew > > > > > > > > > -----Original Message----- > > > From: Binford, Charles [mailto:CBinford@pirus.com] > > > Sent: Friday, October 12, 2001 2:50 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > I have not verify version 8 is still the same, but version 07-97 > > > had a rule > > > that unsolicited data MUST be sent in the same order as the > > commands. > > > > > > Thus, there is no need for a search on the ITT. The target > > just needs to > > > keep of linked list of I/Os waiting on unsolicited data. > > New commands are > > > added to the tail, any unsolicited data *should* be associated > > > with the I/O > > > at the head of the list. The ITT is used as a sanity check and > > > you're done. > > > > > > What am I missing? > > > > > > Charles Binford > > > Pirus Networks > > > 316.315.0382 x222 > From owner-ips@ece.cmu.edu Fri Oct 12 20:38: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 UAA12178 for ; Fri, 12 Oct 2001 20:38:14 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9CNR6a05569 for ips-outgoing; Fri, 12 Oct 2001 19:27:06 -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 f9CNQxl05563 for ; Fri, 12 Oct 2001 19:27: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 C06581F6EA; Fri, 12 Oct 2001 16:26: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 QAA06652; Fri, 12 Oct 2001 16:26:49 -0700 (PDT) Message-ID: <3BC77DF7.B96416A9@cup.hp.com> Date: Fri, 12 Oct 2001 16:34:15 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Robert Snively Cc: ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert Snively wrote: > > I have two small questions that would help me understand this. > > How do you know that unsolicited data is expected? By nature, > unsolicited data is received as a "maximum surprise" which can > only be determined after unpacking and parsing at least a > part of the command structure, possibly even including the > SCSI command (although there are some hints contained in the > command header information). Un-solicited data is expected when the scsi command pdu does not have the F bit set. When you crack open the header and find the F bit not set, you add the command control block onto this additional "un-solicited data linked list" that is being discussed. > > How can you constrain a generic system to posting the > unsolicited data in the same order that the commands were > emitted? In general, I would have expected the system to > be emitting command followed immediately by the corresponding > unsolicited data. If that is not the case, it means that there > was a delay in obtaining the unsolicited data for transfer and > that the delay was sufficient to allow the insertion of commands. > If the delay is that large (and probably variable), the enforcement > of transfer of unsolicited data in the same order as the > commands are emitted seems to me to be a significant challenge, > and certainly shouldn't be required as normal behavior. While it > would make things simpler for targets (already challenged by > unsolicited data), it seems to me that it would make things > much more complex for initiators. I agree. I don't quite understand why the restriction exists, to enforce ordering of un-solicited data to be the same as the order of the corresponding commands. A dis-advantage of enforcing such strict ordering is that when the F bit data-out PDU of one of the un-solicited data sequences is dropped, the order of data received at the target violates the command order. Currently, the spec requires session recovery to be performed (tear down session on order violation of un-solicited data) on this order violation. For those who tape fans out there who were planning on using un-solicited data, this would be a nasty side effect, since the "within-command-recovery" is un-usable when a digest error occurs on un-solicited data and the session would be torn down. Since SNACK was included primarily for the tape application support, it seems like it would'nt serve much purpose to such tape applications if a digest error were to occur on un-solicited data. I suggest that this strict ordering of data with commands rule be removed. Regards, Santosh > > Bob > > > -----Original Message----- > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > > Sent: Friday, October 12, 2001 2:51 PM > > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > > ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Matthew, > > > > Since the unsolicited data does not follow the > > command, you need the link list. But since the > > unsolicited data must be sent in the same order > > as the commands, a link list is enough. > > > > Let us say that you have 8 commands. The ones > > for which we expect unsolicted data are marked > > as Cnn(ud). And I have marked the unsolicted > > data PDUs as UD(nn). The (nn) with data implies > > that it is implicit and not actually carried with > > the PDU itself. > > > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > > --> UD(07) C08(ud) UD(08) ---> > > > > After the target receives the command C01, C02, and C03 > > for which it expects unsolicited data, it puts them in > > a link list. It also receives C04 and C05 for which > > unsolicited data is not expected and they don't go > > on the list. It then receives C06 for which unsolicited > > data is expected, and it is added to then end of the list. > > Then an unsolicited data PDU is received. It must go > > with the command at the head of the list which is C01. > > Use the ITT to make sure and you can then take C01 off > > the list and so on. > > > > Somesh > > > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > > Sent: Friday, October 12, 2001 7:53 AM > > > To: 'Binford, Charles'; ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > Charles, > > > > > > As you have described the spec states that "that > > unsolicited data MUST be > > > sent in the same order as the commands". This is not the same as > > > unsolicited data must follow the command associated with > > it: For example: > > > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > > x in all the > > > example can be the ITT. It is not the CmdSN. > > > > > > This is allowed: > > > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > > > and the target will have to use the ITT to associate the > > data with the > > > command. > > > > > > Matthew > > > > > > > > > -----Original Message----- > > > From: Binford, Charles [mailto:CBinford@pirus.com] > > > Sent: Friday, October 12, 2001 2:50 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > I have not verify version 8 is still the same, but version 07-97 > > > had a rule > > > that unsolicited data MUST be sent in the same order as the > > commands. > > > > > > Thus, there is no need for a search on the ITT. The target > > just needs to > > > keep of linked list of I/Os waiting on unsolicited data. > > New commands are > > > added to the tail, any unsolicited data *should* be associated > > > with the I/O > > > at the head of the list. The ITT is used as a sanity check and > > > you're done. > > > > > > What am I missing? > > > > > > Charles Binford > > > Pirus Networks > > > 316.315.0382 x222 -- ################################## 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 Oct 12 20:38: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 UAA12189 for ; Fri, 12 Oct 2001 20:38:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9D02Qu07529 for ips-outgoing; Fri, 12 Oct 2001 20:02:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from eumenes.hosting.pacbell.net (eumenes.hosting.pacbell.net [216.100.98.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9D02Ol07524 for ; Fri, 12 Oct 2001 20:02:25 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by eumenes.hosting.pacbell.net id TAA03022; Fri, 12 Oct 2001 19:55:20 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: Cc: Subject: RE: iSCSI: SCSI Iniitator port: a simple approach, acceptable? Date: Fri, 12 Oct 2001 16:53:43 -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) In-Reply-To: <3BC7783D.98F9A888@cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: santoshr@cup.hp.com [mailto:santoshr@cup.hp.com] > Sent: Friday, October 12, 2001 4:10 PM > To: somesh_gupta@silverbacksystems.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: SCSI Iniitator port: a simple approach, acceptable? > > > Somesh, > > I don't understand your concern voiced below. > > A session spanning multiple adapters requires the host resident session > manager to co-ordinate assignment of initiator task tag, cmdsn, > exp_cmdsn & max_cmdsn, [over and beyond the usual initiator name & > ISID/TSID]. > > The initiator task tag & cmdsn can be passed down from the session > manager to the HBA in a mailbox command, as a part of issuing a new > iscsi command, and the (exp_cmdsn, max_cmdsn) values can be updated to > the host resident session manager by the HBA as a part of conveying a > mailbox command completion. There are no extra host interrupts in normal > I/O paths due to the presence of a host resident session manager. > > If you're referring to locking overheads, then, these can be optimized > out. You sort of answered the question yourself. As a cache line (containing common numbers) ping-pongs between processors that handle interrupts for different adapters, its adds significant overhead. A 2GHz processor in a CC-Numa box sharing cache lines between multiple processors? This does not include the cost/complexity of managing multiple queues, (and additional cache lines to share) and the fact that the "rare" retransmit has the potential to slow everything down to the speed of the slowest connection. We will see. I don't think this debate is going to be solved by discussion. People will even obtain different results from experiments. > > I don't see why a host resident session manager affects performance of a > multi-connection session ? > > Regards, > Santosh > > > > Somesh Gupta wrote: > > > > Jim, > > > > Multiple connections, especially when spread across multiple > > adapters will give performance that will be much less than > > that of multiple sessions in parallel (of course when there > > are multiple connections/session over multiple adapters - the > > adapters have to be able to take the session id from the > > host software - I obviously don't get the point of the debate). > > > > There is no way a common synchronization point for > > command sequencing and flow control at the host level will not > > cause sub-standard performance. I have argued this point > > many times before, only to have it be brushed aside. Of course, > > only time will tell. > > > > Somesh > > > > > -- > ################################## > 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 Oct 12 20:40: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 UAA12224 for ; Fri, 12 Oct 2001 20:40:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9D02Ac07509 for ips-outgoing; Fri, 12 Oct 2001 20:02: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 f9D023l07502 for ; Fri, 12 Oct 2001 20:02:03 -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 TAA58010; Fri, 12 Oct 2001 19:59:35 -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 f9D021g276240; Fri, 12 Oct 2001 18:02:01 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: Addition of CmdSN in Data-out PDU To: Robert Snively Cc: "'somesh_gupta@silverbacksystems.com'" , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Binford, Charles'" , ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 12 Oct 2001 17:01:08 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/12/2001 06:02:00 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, I think that an Initiator being able to send a waiting Read command, without having to wait for many large write segments -- that are being sent (as unsolicited data) -- is very useful. And that would mean, the unsolicited data is waiting to be sent until the Read Commands are sent. This might be a very frequent case. . . . 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 10/12/2001 03:56:06 PM Sent by: owner-ips@ece.cmu.edu To: "'somesh_gupta@silverbacksystems.com'" , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Binford, Charles'" , ips@ece.cmu.edu cc: Subject: RE: Addition of CmdSN in Data-out PDU I have two small questions that would help me understand this. How do you know that unsolicited data is expected? By nature, unsolicited data is received as a "maximum surprise" which can only be determined after unpacking and parsing at least a part of the command structure, possibly even including the SCSI command (although there are some hints contained in the command header information). How can you constrain a generic system to posting the unsolicited data in the same order that the commands were emitted? In general, I would have expected the system to be emitting command followed immediately by the corresponding unsolicited data. If that is not the case, it means that there was a delay in obtaining the unsolicited data for transfer and that the delay was sufficient to allow the insertion of commands. If the delay is that large (and probably variable), the enforcement of transfer of unsolicited data in the same order as the commands are emitted seems to me to be a significant challenge, and certainly shouldn't be required as normal behavior. While it would make things simpler for targets (already challenged by unsolicited data), it seems to me that it would make things much more complex for initiators. Bob > -----Original Message----- > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > Sent: Friday, October 12, 2001 2:51 PM > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > Matthew, > > Since the unsolicited data does not follow the > command, you need the link list. But since the > unsolicited data must be sent in the same order > as the commands, a link list is enough. > > Let us say that you have 8 commands. The ones > for which we expect unsolicted data are marked > as Cnn(ud). And I have marked the unsolicted > data PDUs as UD(nn). The (nn) with data implies > that it is implicit and not actually carried with > the PDU itself. > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > --> UD(07) C08(ud) UD(08) ---> > > After the target receives the command C01, C02, and C03 > for which it expects unsolicited data, it puts them in > a link list. It also receives C04 and C05 for which > unsolicited data is not expected and they don't go > on the list. It then receives C06 for which unsolicited > data is expected, and it is added to then end of the list. > Then an unsolicited data PDU is received. It must go > with the command at the head of the list which is C01. > Use the ITT to make sure and you can then take C01 off > the list and so on. > > Somesh > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > Sent: Friday, October 12, 2001 7:53 AM > > To: 'Binford, Charles'; ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Charles, > > > > As you have described the spec states that "that > unsolicited data MUST be > > sent in the same order as the commands". This is not the same as > > unsolicited data must follow the command associated with > it: For example: > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > x in all the > > example can be the ITT. It is not the CmdSN. > > > > This is allowed: > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > and the target will have to use the ITT to associate the > data with the > > command. > > > > Matthew > > > > > > -----Original Message----- > > From: Binford, Charles [mailto:CBinford@pirus.com] > > Sent: Friday, October 12, 2001 2:50 PM > > To: ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > I have not verify version 8 is still the same, but version 07-97 > > had a rule > > that unsolicited data MUST be sent in the same order as the > commands. > > > > Thus, there is no need for a search on the ITT. The target > just needs to > > keep of linked list of I/Os waiting on unsolicited data. > New commands are > > added to the tail, any unsolicited data *should* be associated > > with the I/O > > at the head of the list. The ITT is used as a sanity check and > > you're done. > > > > What am I missing? > > > > Charles Binford > > Pirus Networks > > 316.315.0382 x222 From owner-ips@ece.cmu.edu Fri Oct 12 20: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 UAA12366 for ; Fri, 12 Oct 2001 20:53:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9D0QSJ08849 for ips-outgoing; Fri, 12 Oct 2001 20:26:28 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from eumenes.hosting.pacbell.net (eumenes.hosting.pacbell.net [216.100.98.24]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9D0QQl08842 for ; Fri, 12 Oct 2001 20:26:26 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by eumenes.hosting.pacbell.net id UAA22540; Fri, 12 Oct 2001 20:19:46 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: Cc: Subject: RE: iSCSI: SCSI Iniitator port: a simple approach, acceptable? Date: Fri, 12 Oct 2001 17:18: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) In-Reply-To: <3BC788AF.D12D9073@cup.hp.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, As I said, this is an endless debate. I don't think everything can be optimized out of the code path. I apologise in advance for not responding any more to this thread. Somesh > -----Original Message----- > From: santoshr@cup.hp.com [mailto:santoshr@cup.hp.com] > Sent: Friday, October 12, 2001 5:20 PM > To: somesh_gupta@silverbacksystems.com > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: SCSI Iniitator port: a simple approach, acceptable? > > > Somesh Gupta wrote: > > > > The initiator task tag & cmdsn can be passed down from the session > > > manager to the HBA in a mailbox command, as a part of issuing a new > > > iscsi command, and the (exp_cmdsn, max_cmdsn) values can be updated to > > > the host resident session manager by the HBA as a part of conveying a > > > mailbox command completion. There are no extra host > interrupts in normal > > > I/O paths due to the presence of a host resident session manager. > > > > > > If you're referring to locking overheads, then, these can be optimized > > > out. > > > > You sort of answered the question yourself. As a cache line > (containing > > common numbers) ping-pongs > > between processors that handle interrupts for different adapters, its > > adds significant overhead. A 2GHz processor in a CC-Numa box sharing > > cache lines between multiple processors? > > I think the above can be optimized out by some proper design. I don't > think locking or cache thrashing are significant performance inhibitors > that cannot be worked around in this case. > > > > > > This does not include the cost/complexity of managing multiple queues, > > (and additional cache lines to share) > > What multiple queues ? (I don't see any major issues here either.) > > > and the fact that the "rare" retransmit has the potential to slow > > everything down to the speed of the slowest connection. > > But, this is not a drawback of multi-connection session. It is a > drawback due to the fact that the iscsi protocol chose to impose strict > command ordering across the session [,which is not really required. But, > I won't start that thread again !]. > > > > > > > > > > > > > > Somesh Gupta wrote: > > > > > > > > Jim, > > > > > > > > Multiple connections, especially when spread across multiple > > > > adapters will give performance that will be much less than > > > > that of multiple sessions in parallel (of course when there > > > > are multiple connections/session over multiple adapters - the > > > > adapters have to be able to take the session id from the > > > > host software - I obviously don't get the point of the debate). > > > > > > > > There is no way a common synchronization point for > > > > command sequencing and flow control at the host level will not > > > > cause sub-standard performance. I have argued this point > > > > many times before, only to have it be brushed aside. Of course, > > > > only time will tell. > > > > > > > > Somesh > > > > > > > > -- > ################################## > 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 Oct 12 23:22: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 XAA15719 for ; Fri, 12 Oct 2001 23:22:32 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9D1uuW13514 for ips-outgoing; Fri, 12 Oct 2001 21:56:56 -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 f9D1usl13509 for ; Fri, 12 Oct 2001 21:56:54 -0400 (EDT) Received: by mxic2.us.dg.com with Internet Mail Service (5.5.2653.19) id <4W47XZTT>; Fri, 12 Oct 2001 21:53:46 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD891@CORPMX14> From: Black_David@emc.com To: Robert.Elliott@compaq.com, ips@ece.cmu.edu Subject: RE: iSCSI: ISID issue summary Date: Fri, 12 Oct 2001 21:48:31 -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 Rob, > As Nick noted, the problem is where do you store these ISIDs? > For that matter, where do you store the iSCSI name? [..snip..] > With iSCSI you have no guarantee of hardware. Software-based implementations will have access to a file or registry or something like that. Boot involves BIOS nonsense and pain of varying forms and has access to BIOS parameter store (may be battery-backed RAM rather than flash) if needed. Booting over a software implementation can be very difficult - in essence, the iSCSI software gets added to the main system BIOS (not something to be done lightly, especially as there are existing protocols that can retrieve a boot image over IP). > For the SCSI RDMA Protocol for InfiniBand, we chose: > initiator port name = 64-bit worldwide identifier from > the InfiniBand channel adapter plus > 64 extra bits > All software using the same InfiniBand channel adapter have to > coordinate usage of the extra bits, but single-OS single-driver > systems can just fill them with zeros. But SRP only needs to coordinate within "the same InfiniBand channel adapter". iSCSI currently requires the ISID to be coordinated across adapters/network interfaces. That's an important difference. > Persistent reservations, access controls, extended copy, > third-party XOR commands, and the supporting alias commands > are all potential users of port names today. Protocol bridges > and management tools may also benefit from using names > rather than addresses. I'll take that as a strong hint from the T10 direction that this set of issues cannot be deferred (matching Jim's comments). > Are the iSCSI name and ISID used as part of authentication? > How does a device driver prove it has the right to use > a certain iSCSI name/ISID? How does it prevent some other > software from using its own iSCSI name/ISID? Only the iSCSI name is used, and iSCSI inband authentication (which requires state on the target) is used to deal with both of the latter questions. > If we didn't have ISIDs we'd still have the same debate about > managing the iSCSI names. Two software implementations > on the same machine could choose the same iSCSI name and > conflict - the same problems result. Actually, the iSCSI name has to be statically configured - it's somewhat akin to an IP address in that using the same one twice on two different independent systems will have unintended (and potentially unpleasant) results. Picking the name dynamically is not anticipated because that name is expected to show up in the configuration of LUN masking/ mapping access controls on the Targets. > Jim's partitioning lets the OS pick an iSCSI name (unique > from any other OS on the fabric, with any luck) and requires > the OS coordinate ISIDs for any iSCSI drivers sharing > that iSCSI name. A dedicated iSCSI HBA could also hand > out ISIDs for drivers using it. With the exception of having "the OS pick an iSCSI name", that's correct. The problem is one system with two HBAs that don't know about each other. Also, unlike InfiniBand, one can expect an iSCSI HBA to have a dedicated driver. > This should limit the > scope of conflicts to one system rather than the whole > fabric. It'd be helpful to have standards for the OS > or HBAs to solve this, but that seems outside the scope > of the iSCSI protocol spec. A solution that works here is to statically configure the ISIDs along with the iSCSI name and write the "conservative reuse" rule into the iSCSI protocol specification. Thanks, --David > -----Original Message----- > From: Elliott, Robert [mailto:Robert.Elliott@compaq.com] > Sent: Wednesday, October 10, 2001 8:19 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: ISID issue summary > > > David Black wrote: > > > SCSI architecture (SAM2) is based on an intuition that SCSI > > ports are fixed (e.g., physical) things that have names. So > > far, the existence of the names has been an intellectual > > curiosity as they haven't mattered to any visible SCSI > > functionality. > > Not quite true. The Fibre Channel port's Worldwide_Name - > what SAM-2 now calls the initiator port name - is used > today for persistent reservations. SPC-2 has this wording: > > For those SCSI protocols for which the initiator port's > world wide identification is available to the device > server the initiator port's world wide identification > shall be used to determine if the initiator identifier > has changed. > > FCP-2 indicates that the Worldwide_Name of the Fibre Channel > port serves as the "initiator port's world wide > identification." (that phrase will change to "initiator > port name" as Jim's (accepted) T10 name proposal is > digested.) > > > Single port Initiators predominate in > > both Parallel SCSI and Fibre Channel (e.g., a dual ported > > Fibre Channel HBA is usually treated as two SCSI Initiators, > > not a single dual-ported one). > > According to the SAM-2 multiport model, you can upgrade that > "usually" to "always." The key to the multiport model is: > > Initiator = initator port > Target = target port > > In FCP-2, initiator ports equal Fibre Channel ports. There's > no way to treat two physical ports as the same initiator > without violating the standards. > > The multiport model defines "initiator device" as the object > that contains multiple initiator ports. The initiator device > has neither an address nor a name in any existing protocol. > There are no commands that rely on it. Jim wanted to start > using that concept for iSCSI access controls. > > > Jim tells us that T10 is about to define persistent reserve > > functionality that depends on the identity of the SCSI Initiator > > Port - in particular that under some circumstances, persistent > > reservations will be associated with the Initiator Port independent > > of the Target Port. Persistent reservations are currently bound > > to the Initiator Port and Target Port (as well as the LU they > > affect). For the rest of this message, I'm going to assume > > Again, the reason for this is the multiport model that says > initiator = initiator port and target = target port. > > > that we want to support this functionality. Assuming this and > > that I got the description in this paragraph right ... > > > > ... I need to take a slight detour into pragmatics. Those > > who configure storage networks rapidly discover the value > > of consistency and matching configurations. Multi-path I/O > > configurations tend to want to see access to the same set of LUs > > consistently across a set of interfaces (i.e., Ports). Between > > suitable configuration and the aggressive setup of connections > > to all possible targets, all the required connections come into > > existence as part of the boot process. Applying > > this experience to the new persistent reservation functionality, > > one would expect persistent reservations that are bound only to > > an Initiator Port to be independent of the Target Port, in that > > the reservation should span connections to all of the relevant > > Target Ports and those connections should come into existence > > as part of the boot process. > > That's the goal of one of the T10 proposals. If initiators > are identified only by their port addresses, it's not safe. > The two target ports could be on different fabrics, where > initiators are different but happen to have the same > addresses. On a fabric where the initiator port has a name > that is known to be worldwide unique, this becomes a > non-issue if the initiator port name is used instead of the > initiator port address. > > > Turning to iSCSI, the situation gets complicated by the > > interaction of two factors: > > - Parallel sessions are permitted down to the interface > > level (e.g., more than one iSCSI session may exist > > that uses IP addresses A and B to connect iSCSI Initiator > > I to iSCSI Target T). > > - SCSI disallows parallel nexii (i.e., more than one session > > between the same two SCSI Ports). > > If SCSI Ports are mapped to hardware entities such as network > > interfaces in iSCSI, the opportunity for parallel sessions > > between the same pair of network interfaces vanishes. In order > > to avoid that outcome, iSCSI Initiator Ports have to be > > mapped to software entities. To date, the ISID has been > > used to identify those software entities, and the only rule > > on their allocation is: > > > > ISID RULE: Between a given iSCSI Initiator and iSCSI > > Target Portal Group (SCSI target port), then can be only > > one session with a given ISID (identifying a SCSI > > initiator port). See 3.12.8. > > There's a bit more than that. The "iSCSI Name" has to > be included with the ISID to identify the initiator port. > Jim wanted the iSCSI name to be the "initiator device name." > > > In order to get the expected outcome of the new functionality > > being defined by T10, the same ISID has to be used to establish > > all the connections that the persistent reservation is supposed > > to span. Unfortunately, that's above and beyond what iSCSI > > requires - the relevant text about doing this in -08 is: > > > > The "ISID rule" does not preclude > > the use of the same ISID from the same iSCSI Initiator with > > different Target Portal Groups on the same iSCSI target or > > on other iSCSI targets > > > > "does not preclude" is rather weak language for something that's > > essential to making a piece of SCSI functionality work. If an > > iSCSI implementation uses a different ISID for every session > > (which is also not precluded by the current text), then persistent > > reservations will never span Targets or Target Ports for that > > implementation despite T10's best efforts and intentions. IMHO, > > allowing that outcome is *wrong* (and this is the source of the > > difference of opinion between Jim and myself). > > > > The correction to this involves what Jim has called "conservative > > reuse" of ISIDs. This is something like for each ISID that an > > implementation uses, a connection with that ISID is made to > > every possible Target Portal Group of every possible Target. I > > suspect a longer explanation than this will be needed, including > > a discussion of the desirability of avoiding a situation in which > > the same ISID is used by two iSCSI implementations that are part > > of the same Initiator and set up sessions concurrently. > > > > IMHO, if we want to support persistent reservations at this stage > > that span target ports, we need to replace the "does not preclude" > > language with a REQUIREMENT for conservative reuse to avoid a > > situation in which SCSI functionality that works consistently with > > other transports works inconsistently with iSCSI (i.e., doesn't > > work with iSCSI implementations that don't do conservative reuse). > > As Nick noted, the problem is where do you store these ISIDs? > For that matter, where do you store the iSCSI name? With > Fibre Channel, the Worldwide_name is in a ROM associated with > the port. With iSCSI you have no guarantee of hardware. You > can usually find an Ethernet MAC address and could base a > name off of that. However, there's no guarantees. > > For the SCSI RDMA Protocol for InfiniBand, we chose: > initiator port name = 64-bit worldwide identifier from > the InfiniBand channel adapter plus > 64 extra bits > All software using the same InfiniBand channel adapter have to > coordinate usage of the extra bits, but single-OS single-driver > systems can just fill them with zeros. > > > Stepping back from the assumption that support for port-spanning > > persistent reservations is required, I observe that the conservative > > reuse rule impacts all implementations, even those that will never > > use such persistent reservations because ISID is a mandatory part > > of the iSCSI protocol. > > Persistent reservations, access controls, extended copy, > third-party XOR commands, and the supporting alias commands > are all potential users of port names today. Protocol bridges > and management tools may also benefit from using names > rather than addresses. > > > If a text key were used instead, only those > > Initiators that want to support this functionality on which T10 > > is "crossing a few t's and dotting a few i's" are affected (the > > text key is optional). The text key would be subject to a > > conservative reuse rule similar to the one that would be needed > > for ISIDs, and once T10 finishes the i's and t's, we can precisely > > reference the SCSI features (persistent reservation expansion) > > that require use of this text key. > > > > In addition, text keys have much better alternatives for dealing > > with conflicts than ISIDs - if a text key conflicts, it is possible > > to continue the negotiation with a different text key, whereas > > ISID conflict is fatal to one of the two sessions involved. > > As Jim has previously observed, changing the text key (e.g., > > generate a large random number in response to a conflict), > > results in a situation that can be dealt with by software that > > uses persistent reservations, although this departure from > > conservative reuse should only occur as a consequence of some > > sort of configuration mistake or bug. At the tail end of this > > reasoning chain is the observation that use of this text key > > leaves the ISID without value/purpose, and hence would call > > for its removal (or perhaps designation as a reserved field). > > This just seems to make the names more vague and volatile. > > Are the iSCSI name and ISID used as part of authentication? > How does a device driver prove it has the right to use > a certain iSCSI name/ISID? How does it prevent some other > software from using its own iSCSI name/ISID? > > > Putting on my WG chair hat for a moment, I can accept either > > alternative outlined above: > > - Add conservative reuse to the ISID rule. > > - Use a text key for iSCSI port identification. > > But I'm not comfortable with the current situation in which iSCSI > > implementations are permitted to break T10-defined SCSI features > > that will work as expected in other SCSI transports. > > > > I hope this now makes sense to more people than just Jim and I, > > and I apologize for the length of this message, as this is a > > somewhat subtle issue. > > > > Comments? > > If we didn't have ISIDs we'd still have the same debate about > managing the iSCSI names. Two software implementations > on the same machine could choose the same iSCSI name and > conflict - the same problems result. > > Jim's partitioning lets the OS pick an iSCSI name (unique > from any other OS on the fabric, with any luck) and requires > the OS coordinate ISIDs for any iSCSI drivers sharing > that iSCSI name. A dedicated iSCSI HBA could also hand > out ISIDs for drivers using it. This should limit the > scope of conflicts to one system rather than the whole > fabric. It'd be helpful to have standards for the OS > or HBAs to solve this, but that seems outside the scope > of the iSCSI protocol spec. > > > --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 > > --------------------------------------------------- > > > --- > Rob Elliott, Compaq Server Storage > Robert.Elliott@compaq.com > From owner-ips@ece.cmu.edu Sat Oct 13 07:59: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 HAA02968 for ; Sat, 13 Oct 2001 07:59:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9DB8Vh20384 for ips-outgoing; Sat, 13 Oct 2001 07:08: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 f9DB8Sl20378 for ; Sat, 13 Oct 2001 07:08:28 -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 NAA29862 for ; Sat, 13 Oct 2001 13:08:22 +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 f9DB8LY69788 for ; Sat, 13 Oct 2001 13:08:21 +0200 Subject: Re: typo To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 13 Oct 2001 10:37:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/10/2001 14:08:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Sorry the whole sentence should be deleted. It is a residue that remained after one of the word crashes that I failed to catch. The Data text is: 1.1.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 the data stream in sequences does not affect DataSN counting on Data-In PDUs. It MAY be used as a "change direction" indication for Bidirectional operations that need such a change. 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. 1.1.2 A (Acknowledge) bit For sessions with ErrorRecoveryLevel 1 or higher the target sets this bit to 1 to indicate that it requests from the initiator a positive acknowledgement for the data received. The target MAY set the A-bit to 1 once at most every MaxBurstSize bytes, and MUST NOT do so any more frequently than that. On receiving a Data-In PDU with the A bit set to 1 the initiator MUST issued a SNACK of type DataACK. If the initiator has detected holes in the input sequence, it MAY postpone issuing the SNACK of type ACKN until the holes are filled. Thanks, Julo "Eddy Quicksall" cc: Subject: typo 11-10-01 01:59 Please respond to "Eddy Quicksall" Section 3.7.1 A target that implements ErrorRecoveryLevel 1 or higher MUST use the F bit to indicate the end-of-sequence of Data-In PDUs is it is going to discard. Sounds funny. Should it be: end-of-sequence of Data-In PDUs it is going to discard. ? Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Sat Oct 13 07:59: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 HAA02979 for ; Sat, 13 Oct 2001 07:59:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9DB8Gx20351 for ips-outgoing; Sat, 13 Oct 2001 07:08:16 -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 f9DB8El20343 for ; Sat, 13 Oct 2001 07:08:14 -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 NAA100534 for ; Sat, 13 Oct 2001 13:08:07 +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 f9DB86Y75992 for ; Sat, 13 Oct 2001 13:08:06 +0200 Subject: Re: iSCSI: NIC interoperability To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 13 Oct 2001 08:03:11 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/10/2001 14:08:06 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, I have repeatedly stated that from a practical point of view we are spending a lot of ink on a non-issue. I have even insisted on mandating C in the draft. Some of the list members/readers/authors seem to consider such a requirement as "excessive" - as it implies resorting to a higher authority on every session creation - and that might not be strictly necessary (although it will be sufficient). Adding a text key is neither simpler nor easier nor will it solve the conflict problem. And I have very little time and patience left for pages of debate on the merits of one or other port naming script. Julo "Mallikarjun C." To: ips Subject: iSCSI: NIC interoperability Sent by: owner-ips@ece. cmu.edu 10-10-01 04:14 Please respond to cbm After seeing some of the emails on this topic from Dave Sheehy, David Black and Jim Hafner, I have some comments and questions. It appears to me that the following three are the major issues that one has to deal with for building a multi-NIC iSCSI Node, where the NICs are potentially from different vendors. A. Each NIC MUST allow the Node name to be configurable. B. Each NIC MUST allow the ISID range to be configurable (if deployed in an initiator configuration). C. In addition, if only one (initiator/target) portal group is sought to be presented (i.e. session spanning across any and all of these NICs is a requirement), each NIC MUST allow itself to be managed by an externally-resident "session manager" in some "TBD standard way". Admittedly, C is is the hardest and till the "TBD standard way" is defined to interact with a session manager, it cannot be mandated. Failure to comply with C would only create multiple portal groups in an iSCSI implementation - each portal group limited to NIC(s) from a given vendor. But, A and B above seem reasonable and in fact seem required to be mandated - both to avoid the problems as with FC Node Name, and also to address the concerns of not leaving target with a deterministic way to enforce access control mechanisms and such. I realize that the "no duplicate nexus" goal does not strictly require A (hence neither B), but I recommend that A be mandated, thus automatically making B an additional requirement for initiator configurations. Rev08 iSCSI draft seems to refer to A and B in section 9 (implementation notes) as "should". Was there a concern about the appropriateness of mandating A and B in the main modeling discussion? They appear fairly straightforward to implement. If the reasoning was not to require _any_ configuration of an iSCSI NIC, I would argue that you require some "name" to be configurable anytime you want to build a logically monolithic entity (as in a node) from smaller components (each of which can act as a logically independent entity in its own right). Comments from NDT and/or Julian would help. 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 Sat Oct 13 08:00: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 IAA02998 for ; Sat, 13 Oct 2001 08:00:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9DB87P20335 for ips-outgoing; Sat, 13 Oct 2001 07:08: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 f9DB85l20328 for ; Sat, 13 Oct 2001 07:08:05 -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 NAA88226 for ; Sat, 13 Oct 2001 13:07:58 +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 f9DB7vY166126 for ; Sat, 13 Oct 2001 13:07:57 +0200 Subject: Re: 08 Comment To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 13 Oct 2001 05:58:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/10/2001 14:07:57 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dave, The input sequence is "undifferentiated" and the target should know what to resend. I will add the following statement to 2.2.2.3 to clarify this point. For bidirectional commands the target uses the DataSN/R2TSN to sequence Data-In and R2T PDUs in one continuous sequence (undifferentiated). Julo Dave Sheehy cc: Sent by: Subject: 08 Comment owner-ips@ece.cmu.edu 09-10-01 09:17 Please respond to Dave Sheehy For, 3.16.1 > 0-Data/R2T SNACK - requesting retransmission of a Data-In or R2T PDU In the case of a bidirectionalble command, how does one interpret this field? Is it for data or R2T? Dave From owner-ips@ece.cmu.edu Sat Oct 13 08:00: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 IAA03009 for ; Sat, 13 Oct 2001 08:00:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9DB8SV20376 for ips-outgoing; Sat, 13 Oct 2001 07:08:28 -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 f9DB8Ql20370 for ; Sat, 13 Oct 2001 07:08:26 -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 NAA165474 for ; Sat, 13 Oct 2001 13:08: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 f9DB8JY140128 for ; Sat, 13 Oct 2001 13:08:19 +0200 Subject: Re: ips : Negotiation Reset. To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 13 Oct 2001 10:29:15 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/10/2001 14:08:19 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Comments in text. Julo Santosh Rao hp.com> cc: Sent by: Subject: Re: ips : Negotiation Reset. owner-ips@ece. cmu.edu 11-10-01 01:27 Please respond to Santosh Rao Julian, Further comments below. Thanks, Santosh Julian Satran wrote: > Comments in text. Julo > Why is the reject reason code "Negotiation Reset" required ? Per > Section > 8.7, any failure of a text cmd/rsp while in FFP causes a "negotiation > reset" (i.e. operational parameters are reset to thee values agreed > upon > during an earlier successful negotiation). > > +++ Today we reset with a task abort (task managemenT). The proposed > change to mandate TTT > might unify this space ++++ The parameters are reset on any of the following events (as called out in 8.7) : a) target rejects any one of the text cmds in the exchange. b) initiator timeout of any one text cmd in the text exchange. [this can cause the initiator to issue an abort task to abort the text exchange, or tear down the cxn as recovery.] Now, my question is about the *specific* reason why a reject with reason code "Negotiation Reset" is required. I presume this can only be used in case (a) contexts to reset parameters, since in case (b), the abort task completion or cxn teardown leads to parameter reset. Now, in case (a), is'nt it assumed that *ANY* reject will lead to a parameter reset ? Given this, why do we need an explicit reason code "Negotiation Reset" ? The above issue is independent of the "mandatory TTT in text" proposal, right (?). [Please help me understand by giving an example where "negotiation reset" would be returned by a tgt.] +++ the initiator has a clear way to reset/reject a parameter set or negotiation. For target Reject is the "universal" method +++ On a seperate note, the following case described in 8.7 : - None of the choices or the stated value is acceptable to one negotiating side. should not cause a reset of all the parameters ? It should only reset that specific parameter to its previous value. > So, why do you need an explicit reason called "negotiation reset" (?) > Any failure of a text cmd at the target end would be conveyed through > either a "data digest error" or "protocol error". The operational > parameters are understood to be reset on any failure of the text > sequence. > > Also, I suggest that the reject reason codes 0x09 & 0x0a (Bookmark > Reject) be removed and replaced by a reason called "Invalid Target > Transfer Tag". (now that bookmarks are gone.) > > +++ WE could if TTT becomes generalized for sequences - today t is > not +++ Again, the reason codes for "Bookmark Reject" are defined today for the long text scenario, and I suggest that they be removed and replaced with an "Invalid Target Transfer Tag". Both the former and latter are [currently] meant for long text cmds and so the change should be ok. (?) Lastly, the term "reset operational parameters" is used in several places. I suggest the specific operation associated with it be called out in places where the term 'reset' is being used. Ex : Section 3.10.3, 3.11.3, 6. -- ################################## 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 Oct 13 08: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 IAA03044 for ; Sat, 13 Oct 2001 08:01:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9DB7uM20308 for ips-outgoing; Sat, 13 Oct 2001 07:07: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 f9DB7sl20300 for ; Sat, 13 Oct 2001 07:07:54 -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 NAA86286 for ; Sat, 13 Oct 2001 13:07:46 +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 f9DB7jW64066 for ; Sat, 13 Oct 2001 13:07:45 +0200 Subject: iSCSI - changes - PDULength and related To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 12 Oct 2001 23:51:03 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/10/2001 14:07:45 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C2256AE300715A498f9e8a93df938690918cC2256AE300715A49" Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=C2256AE300715A498f9e8a93df938690918cC2256AE300715A49 Content-type: text/plain; charset=us-ascii Dear colleagues, It was the an (almost) general agreement on the list that having a more flexible "PDULength" would be beneficial. This can be achieved without dramatically affecting the draft and implementation. The areas mostly affected are related to recovery. The proposed changes are attached (DataPDULength has changed name and semantic to MaxRecvPDULength). In addition text request and response key+value strings are not required to be confined to a single PDU (as we PDULength can be a low as 64 bytes!) Comments? (See attached file: changes-PDULength.txt) --0__=C2256AE300715A498f9e8a93df938690918cC2256AE300715A49 Content-type: text/plain; name="changes-PDULength.txt" Content-Transfer-Encoding: base64 UERVTGVuZ3RoIHJlbGF0ZWQgY2hhbmdlczoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CjMuMTYgIFNOQUNLIFJlcXVlc3QNCg0KDQpCeXRlIC8gICAgMCAgICAgICB8ICAgICAgIDEgICAg ICAgfCAgICAgICAyICAgICAgIHwgICAgICAgMyAgICAgICB8DQogICAvICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8DQogIHw3IDYg NSA0IDMgMiAxIDB8NyA2IDUgNCAzIDIgMSAwfDcgNiA1IDQgMyAyIDEgMHw3IDYgNSA0IDMgMiAx IDB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0rDQogMHwwfDF8IDB4MTAgICAgICB8MXxSc3J2ZHwgVHlwZSAgfCBSZXNl cnZlZCAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQogNC8gUmVzZXJ2ZWQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvDQogKy8g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAvDQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0rDQoxNnwgSW5pdGlhdG9yIFRhc2sgVGFnIG9yIDB4ZmZmZmZmZmYg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoyMHwgQmVnUnVuICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0rDQoyNHwgUnVuTGVuZ3RoICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoyOHwgRXhwU3RhdFNOICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0r DQozMnwgUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQozNnwgRXhwRGF0YVNOIG9yIFJlc2VydmVkICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQozMi8gUmVz ZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAvDQogKy8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAvDQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQo0OA0KDQpTdXBwb3J0IGZvciBTTkFDSyBpcyBv cHRpb25hbC4NCg0KU05BQ0sgcmVxdWVzdCBpcyB1c2VkIHRvIHJlcXVlc3QgcmV0cmFuc21pc3Np b24gb2YgbnVtYmVyZWQtcmVzcG9uc2VzLCBkYXRhIG9yIFIyVCBQRFVzIGZyb20gdGhlIHRhcmdl dC4gIFRoZSBTTkFDSyByZXF1ZXN0IGluZGljYXRlcyB0byB0aGUgdGFyZ2V0IHRoZSBtaXNzZWQg bnVtYmVyZWQtcmVzcG9uc2Ugb3IgZGF0YSBydW4sIHdoZXJlIHRoZSBydW4gaXMgY29tcG9zZWQg b2YgYW4gaW5pdGlhbCBtaXNzZWQgU3RhdFNOLCBEYXRhU04gb3IgUjJUU04gYW5kIHRoZSBudW1i ZXIgb2YgYWRkaXRpb25hbCBtaXNzZWQgU3RhdHVzLCBEYXRhIG9yIFIyVCBQRFVzICgwIG1lYW5z IG9ubHkgdGhlIGluaXRpYWwpLg0KDQpUaGUgbnVtYmVyZWQtcmVzcG9uc2Ugb3IgUjJUIHJlcXVl c3RlZCBieSBhIFNOQUNLIGhhdmUgdG8gYmUgZGVsaXZlcmVkIGFzIGV4YWN0IHJlcGxpY2FzIG9m IHRoZSBvbmVzIHRoZSBpbml0aWF0b3IgbWlzc2VkIGluY2x1ZGluZyBhbGwgaXRzIGZsYWdzLiAN Cg0KVGhlIG51bWJlcmVkIERhdGEtSW4gUERVcyBpbmRpdmlkdWFsbHkgcmVxdWVzdGVkIGJ5IGEg U05BQ0sgaGF2ZSB0byBiZSBkZWxpdmVyZWQgYXMgZXhhY3QgcmVwbGljYXMgb2YgdGhlIG9uZXMg dGhlIGluaXRpYXRvciBtaXNzZWQgaW5jbHVkaW5nIGFsbCBpdHMgZmxhZ3MuICBEYXRhLUluIFBE VXMgcmVxdWVzdGVkIHdpdGggUnVuTGVuZ3RoIDAgKG1lYW5pbmcgYWxsIGFmdGVyIHRoaXMgbnVt YmVyKSBtYXkgYmUgZGlmZmVyZW50IGZyb20gdGhlIG9uZXMgb3JpZ2luYWxseSBzZW50IGluIG9y ZGVyIHRvIHJlZmxlY3QgY2hhbmdlcyBpbiBNYXhSZWN2UERVTGVuZ3RoLiANCg0KQW55IFNOQUNL IHJlcXVlc3RpbmcgYSBudW1iZXJlZC1yZXNwb25zZSwgRGF0YSBvciBSMlQgdGhhdCB3YXMgbm90 IHNlbnQgYnkgdGhlIHRhcmdldCBNVVNUIGJlIHJlamVjdGVkIHdpdGggYSByZWFzb24gY29kZSBv ZiAiSW52YWxpZCBTTkFDSyIuDQoNCg0KMy4xNi4xIFR5cGUNCg0KVGhpcyBmaWVsZCBlbmNvZGVz IHRoZSBTTkFDSyBmdW5jdGlvbiBhcyBmb2xsb3dzOg0KDQowLURhdGEvUjJUIFNOQUNLIC0gcmVx dWVzdGluZyByZXRyYW5zbWlzc2lvbiBvZiBhIERhdGEtSW4gb3IgUjJUIFBEVQ0KMS1TdGF0dXMg U05BQ0sgLSByZXF1ZXN0aW5nIHJldHJhbnNtaXNzaW9uIG9mIGEgbnVtYmVyZWQgcmVzcG9uc2UN Cg0KQWxsIG90aGVyIHZhbHVlcyBhcmUgcmVzZXJ2ZWQuDQoNCkRhdGEvUjJUIFNOQUNLIGZvciBh IGNvbW1hbmQgTVVTVCBwcmVjZWRlIHN0YXR1cyBhY2tub3dsZWRnZW1lbnQgZm9yIHRoZSBnaXZl biBjb21tYW5kLg0KDQpGb3IgYSBEYXRhL1IyVCBTTkFDSyB0aGUgSW5pdGlhdG9yIFRhc2sgVGFn IE1VU1QgYmUgc2V0IHRvIHRoZSBJbml0aWF0b3IgVGFzayBUYWcgb2YgdGhlIHJlZmVyZW5jZWQg Q29tbWFuZC4gT3RoZXJ3aXNlLCBpdCBpcyByZXNlcnZlZC4NCg0KRm9yIGEgU3RhdHVzIFNOQUNL IHRoZSBFeHBEYXRhU04gZmllbGQgaXMgcmVzZXJ2ZWQuDQoNCkFuIGlTQ1NJIHRhcmdldCB0aGF0 IGRvZXMgbm90IHN1cHBvcnQgcmVjb3Zlcnkgd2l0aGluIGNvbm5lY3Rpb24gTUFZIGRpc2NhcmQg c3RhdHVzIFNOQUNLLiBJZiB0aGUgdGFyZ2V0IHN1cHBvcnRzIGNvbW1hbmQgcmVjb3Zlcnkgd2l0 aGluIHNlc3Npb24gaXQgTUFZIGRpc2NhcmQgdGhlIFNOQUNLIGFmdGVyIHdoaWNoIGl0IE1VU1Qg aXNzdWUgYW4gQXN5bmNocm9ub3VzIE1lc3NhZ2UgUERVIHdpdGggYW4gaVNDU0kgZXZlbnQgaW5k aWNhdGluZyAiUmVxdWVzdCBMb2dvdXQiLg0KDQozLjE2LjIgQmVnUnVuDQoNCkZpcnN0IG1pc3Nl ZCBEYXRhU04sIFIyVFNOIG9yIFN0YXRTTg0KDQozLjE2LjMgUnVuTGVuZ3RoDQoNClJ1bkxlbmd0 aCBpcyB0aGUgbnVtYmVyIG9mIHNlcXVlbnRpYWwgbWlzc2VkIERhdGFTTiwgUjJUU04gb3IgU3Rh dFNOLiBSdW5MZW5ndGggMCBzaWduYWxzIHRoYXQgYWxsIERhdGEtSW4sIFIyVCBvciBSZXNwb25z ZSBQRFVzIGNhcnJ5aW5nIG51bWJlcnMgZXF1YWwgb3IgZ3JlYXRlciB0byBCZWdSdW4gaGF2ZSB0 byBiZSByZXNlbnQuDQoNClRoZSBmaXJzdCBkYXRhIFNOQUNLIGFmdGVyIGEgVGFzayBNYW5hZ2Vt ZW50IHJlcXVlc3Qgb2YgVEFTSyBSRUFTU0lHTiAoc2VlIDMuNS4xKSBmb3IgYSBjb21tYW5kIHdo b3NlIGNvbm5lY3Rpb24gYWxsZWdpYW5jZSB3YXMganVzdCBjaGFuZ2VkIE1VU1QgdXNlIFJ1bkxl bmd0aCAiMCIgdG8gcmVxdWVzdCByZXRyYW5zbWlzc2lvbiBvZiBhbnkgbnVtYmVyIG9mIFBEVXMg KGluY2x1ZGluZyBvbmUpLiAgVGhlIG51bWJlciBvZiByZXRyYW5zbWl0dGVkIFBEVXMgaW4gdGhp cyBjYXNlLCBtYXkgb3IgbWF5IG5vdCBiZSB0aGUgc2FtZSBhcyB0aGUgb3JpZ2luYWwgdHJhbnNt aXNzaW9uLCBkZXBlbmRpbmcgb24gaWYgdGhlcmUgd2FzIGEgY2hhbmdlIGluIE1heFJlY3ZQRFVM ZW5ndGggaW4gdGhlIHJlYXNzaWdubWVudC4NCg0KVGhlIGZpcnN0IGRhdGEgU05BQ0sgYWZ0ZXIg YSBNYXhSZWN2UERVTGVuZ3RoIGRlY3JlYXNlIGZvciBhIGNvbW1hbmQgaXNzdWVkIG9uIHRoZSBz YW1lIGNvbm5lY3Rpb24gYmVmb3JlIHRoZSBjaGFuZ2UgaW4gTWF4UmVjdlBEVUxlbmd0aCBNVVNU IHVzZSBSdW5MZW5ndGggIjAiIHRvIHJlcXVlc3QgcmV0cmFuc21pc3Npb24gb2YgYW55IG51bWJl ciBvZiBQRFVzIChpbmNsdWRpbmcgb25lKS4gIFRoZSBudW1iZXIgb2YgcmV0cmFuc21pdHRlZCBQ RFVzIGluIHRoaXMgY2FzZSwgbWF5IG9yIG1heSBub3QgYmUgdGhlIHNhbWUgYXMgdGhlIG9yaWdp bmFsIHRyYW5zbWlzc2lvbiwgZGVwZW5kaW5nIGlmIHRoZSBsb3NzIHdhcyBiZWZvcmUgb3IgYWZ0 ZXIgdGhlIE1heFJlY3ZQRFVMZW5ndGggd2FzIHNlbnNlcyBhdCB0aGUgdGFyZ2V0IG9yIG5vdC4N Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KMjMgTWF4UmVjdlBEVUxlbmd0aA0KDQpVc2U6IEFs bA0KV2hvIGNhbiBzZW5kOiBJbml0aWF0b3IgYW5kIFRhcmdldA0KDQpNYXhSZWN2UERVTGVuZ3Ro PTwwfG51bWJlci02NC10by0yKioyND4gDQoNCkRlZmF1bHQgaXMgODE5MiBieXRlcy4NCg0KVGhp cyBpcyBhIGNvbm5lY3Rpb24gc3BlY2lmaWMgcGFyYW1ldGVyLg0KSW5pdGlhdG9yIG9yIHRhcmdl dCBkZWNsYXJlcyB0aGUgbWF4aW11bSBkYXRhIHNlZ21lbnQgbGVuZ3RoIGluIGJ5dGVzIHRoZXkg Y2FuIHJlY2VpdmUgaW4gYW4gaVNDU0kgUERVLiANCg0KQSB2YWx1ZSBvZiAwIGluZGljYXRlcyBu byBsaW1pdC4NCg0KMjQgTWF4QnVyc3RTaXplDQoNClVzZTogTE8NCldobyBjYW4gc2VuZDogSW5p dGlhdG9yIGFuZCBUYXJnZXQNCg0KTWF4QnVyc3RTaXplPTwwfG51bWJlci02NC10by0yKioyND4g DQoNCkRlZmF1bHQgaXMgMjU2IEtieXRlcy4NCg0KSW5pdGlhdG9yIGFuZCB0YXJnZXQgbmVnb3Rp YXRlIG1heGltdW0gU0NTSSBkYXRhIHBheWxvYWQgaW4gYnl0ZXMgaW4gYW4gRGF0YS1JbiBvciBh IHNvbGljaXRlZCBEYXRhLU91dCBpU0NTSSBzZXF1ZW5jZSAoYSBzZXF1ZW5jZSBvZiBEYXRhLUlu IG9yIERhdGEtT3V0IFBEVXMgZW5kaW5nIHdpdGggYSBEYXRhLUluIG9yIERhdGEtT3V0IFBEVSB3 aXRoIHRoZSBGIGJpdCBzZXQgdG8gb25lKS4gDQoNCkEgdmFsdWUgb2YgMCBpbmRpY2F0ZXMgbm8g bGltaXQgKHRoZSBsYXJnZXN0IHBvc3NpYmxlIG51bWJlcikuDQoNClRoZSBtaW5pbXVtIG9mIHRo ZSAyIG51bWJlcnMgaXMgc2VsZWN0ZWQuIA0KDQoNCjI1IEZpcnN0QnVyc3RTaXplDQoNClVzZTog TE8NCldobyBjYW4gc2VuZDogSW5pdGlhdG9yIGFuZCBUYXJnZXQNCg0KRmlyc3RCdXJzdFNpemU9 PDB8bnVtYmVyLTY0LXRvLTIqKjI0PiAgDQoNCkRlZmF1bHQgaXMgNjQgS2J5dGVzLg0KDQpJbml0 aWF0b3IgYW5kIHRhcmdldCBuZWdvdGlhdGUgdGhlIG1heGltdW0gYW1vdW50IGluIGJ5dGVzIG9m IHVuc29saWNpdGVkIGRhdGEgYW4gaVNDU0kgaW5pdGlhdG9yIG1heSBzZW5kIHRvIHRoZSB0YXJn ZXQsIGR1cmluZyB0aGUgZXhlY3V0aW9uIG9mIGEgc2luZ2xlIFNDU0kgY29tbWFuZC4gVGhpcyBj b3ZlcnMgdGhlIGltbWVkaWF0ZSBkYXRhIChpZiBhbnkpIGFuZCB0aGUgc2VxdWVuY2Ugb2YgdW5z b2xpY2l0ZWQgRGF0YS1PdXQgUERVcyAoaWYgYW55KSB0aGF0IGZvbGxvdyB0aGUgY29tbWFuZC4N Cg0KQSB2YWx1ZSBvZiAwIGluZGljYXRlcyBubyBsaW1pdCAodGhlIGxhcmdlc3QgcG9zc2libGUg bnVtYmVyKS4NCg0KVGhlIG1pbmltdW0gb2YgdGhlIDIgbnVtYmVycyBpcyBzZWxlY3RlZC4gDQoN CkZpcnN0QnVyc3RTaXplIE1VU1QgTk9UIGV4Y2VlZCBNYXhpbXVtQnVyc3RTaXplLg0KDQoNCg0K DQo= --0__=C2256AE300715A498f9e8a93df938690918cC2256AE300715A49-- From owner-ips@ece.cmu.edu Sat Oct 13 08:01: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 IAA03055 for ; Sat, 13 Oct 2001 08:01:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9DB9r720456 for ips-outgoing; Sat, 13 Oct 2001 07:09:53 -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 f9DB9ql20451 for ; Sat, 13 Oct 2001 07:09:52 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id EAA11026; Sat, 13 Oct 2001 04:09:25 -0700 (PDT) From: "Rod Harrison" To: "John Hufferd" , "Robert Snively" Cc: , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Binford, Charles'" , Subject: RE: Addition of CmdSN in Data-out PDU Date: Sat, 13 Oct 2001 12:12:03 +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 Even more common would be the DMA latency. As an initiator I would send the command PDU as soon as I could if there were no immediate data, then queue the DMA for the unsolicited data. Since there could be many other DMAs queued ahead of the unsolicited data it is quite possible that other commands, both read and write, will be sent before the DMA completes. You are spot one when you say the delay in obtaining the unsolicited data may be large and variable. If there are multiple DMA engines it does become a challenge for the initiator to ensure the correct ordering of the unsolicited data. Note that since there may be multiple unsolicited data PDUs in the same burst, and those may be filled with separate DMAs the ordering problem propagates down to within individual commands. I don't believe it is a particularly difficult problem for the initiator to solve, but I do agree things would be easier for the initiator if the ordering requirement were removed. And more so if the requirement to send in dataSN order were also removed, but this is probably too much pain for the target. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of John Hufferd Sent: Saturday, October 13, 2001 1:01 AM To: Robert Snively Cc: 'somesh_gupta@silverbacksystems.com'; BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Robert, I think that an Initiator being able to send a waiting Read command, without having to wait for many large write segments -- that are being sent (as unsolicited data) -- is very useful. And that would mean, the unsolicited data is waiting to be sent until the Read Commands are sent. This might be a very frequent case. . . . 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 10/12/2001 03:56:06 PM Sent by: owner-ips@ece.cmu.edu To: "'somesh_gupta@silverbacksystems.com'" , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Binford, Charles'" , ips@ece.cmu.edu cc: Subject: RE: Addition of CmdSN in Data-out PDU I have two small questions that would help me understand this. How do you know that unsolicited data is expected? By nature, unsolicited data is received as a "maximum surprise" which can only be determined after unpacking and parsing at least a part of the command structure, possibly even including the SCSI command (although there are some hints contained in the command header information). How can you constrain a generic system to posting the unsolicited data in the same order that the commands were emitted? In general, I would have expected the system to be emitting command followed immediately by the corresponding unsolicited data. If that is not the case, it means that there was a delay in obtaining the unsolicited data for transfer and that the delay was sufficient to allow the insertion of commands. If the delay is that large (and probably variable), the enforcement of transfer of unsolicited data in the same order as the commands are emitted seems to me to be a significant challenge, and certainly shouldn't be required as normal behavior. While it would make things simpler for targets (already challenged by unsolicited data), it seems to me that it would make things much more complex for initiators. Bob > -----Original Message----- > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > Sent: Friday, October 12, 2001 2:51 PM > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > Matthew, > > Since the unsolicited data does not follow the > command, you need the link list. But since the > unsolicited data must be sent in the same order > as the commands, a link list is enough. > > Let us say that you have 8 commands. The ones > for which we expect unsolicted data are marked > as Cnn(ud). And I have marked the unsolicted > data PDUs as UD(nn). The (nn) with data implies > that it is implicit and not actually carried with > the PDU itself. > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > --> UD(07) C08(ud) UD(08) ---> > > After the target receives the command C01, C02, and C03 > for which it expects unsolicited data, it puts them in > a link list. It also receives C04 and C05 for which > unsolicited data is not expected and they don't go > on the list. It then receives C06 for which unsolicited > data is expected, and it is added to then end of the list. > Then an unsolicited data PDU is received. It must go > with the command at the head of the list which is C01. > Use the ITT to make sure and you can then take C01 off > the list and so on. > > Somesh > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > Sent: Friday, October 12, 2001 7:53 AM > > To: 'Binford, Charles'; ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Charles, > > > > As you have described the spec states that "that > unsolicited data MUST be > > sent in the same order as the commands". This is not the same as > > unsolicited data must follow the command associated with > it: For example: > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > x in all the > > example can be the ITT. It is not the CmdSN. > > > > This is allowed: > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > and the target will have to use the ITT to associate the > data with the > > command. > > > > Matthew > > > > > > -----Original Message----- > > From: Binford, Charles [mailto:CBinford@pirus.com] > > Sent: Friday, October 12, 2001 2:50 PM > > To: ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > I have not verify version 8 is still the same, but version 07-97 > > had a rule > > that unsolicited data MUST be sent in the same order as the > commands. > > > > Thus, there is no need for a search on the ITT. The target > just needs to > > keep of linked list of I/Os waiting on unsolicited data. > New commands are > > added to the tail, any unsolicited data *should* be associated > > with the I/O > > at the head of the list. The ITT is used as a sanity check and > > you're done. > > > > What am I missing? > > > > Charles Binford > > Pirus Networks > > 316.315.0382 x222 From owner-ips@ece.cmu.edu Sat Oct 13 08:02: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 IAA03075 for ; Sat, 13 Oct 2001 08:02:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9DB86f20329 for ips-outgoing; Sat, 13 Oct 2001 07:08:06 -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 f9DB83l20318 for ; Sat, 13 Oct 2001 07:08:03 -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 NAA165470 for ; Sat, 13 Oct 2001 13:07:56 +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 f9DB7tY75982 for ; Sat, 13 Oct 2001 13:07:55 +0200 Subject: iSCSI - change - negotiation reset To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 13 Oct 2001 02:43:59 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/10/2001 14:07:55 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C2256AE30081C26A8f9e8a93df938690918cC2256AE30081C26A" Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=C2256AE30081C26A8f9e8a93df938690918cC2256AE30081C26A Content-type: text/plain; charset=us-ascii Dear colleagues, I suggested earlier a slight modification in the way a text negotiation is reset. The current text (08) assumes that this is done through a Task Management request of ABORT TASK. We amy want to use a simpler mechanism that is already defined for long text responses - and extend it to long text exchanges in general. The (slightly) modified text is attached. Comments? Julo (See attached file: Change-negotiation-reset.txt) --0__=C2256AE30081C26A8f9e8a93df938690918cC2256AE30081C26A Content-type: text/plain; name="Change-negotiation-reset.txt" Content-Transfer-Encoding: base64 Q2hhbmdlIFRleHQgTmVnb3RpYXRpb24gUmVzZXQNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQozLjEwIFRleHQgUmVxdWVzdA0KDQpUaGUgVGV4dCBSZXF1ZXN0IGlzIHByb3ZpZGVkIHRv IGFsbG93IHRoZSBleGNoYW5nZSBvZiBpbmZvcm1hdGlvbiBhbmQgZm9yIGZ1dHVyZSBleHRlbnNp b25zLiBJdCBwZXJtaXRzIHRoZSBpbml0aWF0b3IgdG8gaW5mb3JtIGEgdGFyZ2V0IG9mIGl0cyBj YXBhYmlsaXRpZXMgb3IgdG8gcmVxdWVzdCBzb21lIHNwZWNpYWwgb3BlcmF0aW9ucy4NCg0KQW4g aW5pdGlhdG9yIE1VU1QgaGF2ZSBvbmx5IG9uZSBvdXRzdGFuZGluZyBUZXh0IFJlcXVlc3Qgb24g YSBjb25uZWN0aW9uIGF0IGFueSBnaXZlbiB0aW1lLg0KDQoNCg0KQnl0ZSAvICAgIDAgICAgICAg fCAgICAgICAxICAgICAgIHwgICAgICAgMiAgICAgICB8ICAgICAgIDMgICAgICAgfA0KICAgLyAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgfA0KICB8NyA2IDUgNCAzIDIgMSAwfDcgNiA1IDQgMyAyIDEgMHw3IDYgNSA0IDMgMiAxIDB8 NyA2IDUgNCAzIDIgMSAwfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDB8WHxJfCAweDA0ICAgICAgfEZ8IFJlc2Vy dmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDR8 IFJlc2VydmVkICAgICAgfCBEYXRhU2VnbWVudExlbmd0aCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tKw0KIDh8IFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw0KMTJ8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tKw0KMTZ8IEluaXRpYXRvciBUYXNrIFRhZyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjB8IFRhcmdldCBUcmFuc2ZlciBU YWcgb3IgMHhmZmZmZmZmZiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t Kw0KMjR8IENtZFNOICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjh8IEV4cFN0YXRTTiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMzIvIFJl c2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLw0KICsvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLw0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KNDh8IERpZ2VzdHMgaWYgYW55Li4uICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KICAv IERhdGFTZWdtZW50IChUZXh0KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgLw0KICsvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLw0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KDQoNCjMuMTAuMSBGIChGaW5hbCkgQml0 DQoNCldoZW4gc2V0IHRvIDEgaXQgaW5kaWNhdGVzIHRoYXQgdGhpcyBpcyB0aGUgbGFzdCBvciBv bmx5IHRleHQgcmVxdWVzdCBpbiBhIHNlcXVlbmNlIG9mIGNvbW1hbmRzOyBvdGhlcndpc2UgaXQg aW5kaWNhdGVzIHRoYXQgbW9yZSBjb21tYW5kcyB3aWxsIGZvbGxvdy4NCg0KDQozLjEwLjIgSW5p dGlhdG9yIFRhc2sgVGFnDQoNClRoZSBpbml0aWF0b3IgYXNzaWduZWQgaWRlbnRpZmllciBmb3Ig dGhpcyBUZXh0IFJlcXVlc3QuDQpJZiB0aGUgY29tbWFuZCBpcyBzZW50IGFzIHBhcnQgb2YgYSBz ZXF1ZW5jZSBvZiB0ZXh0IHJlcXVlc3RzIGFuZCByZXNwb25zZXMsIHRoZSBJbml0aWF0b3IgVGFz ayBUYWcgTVVTVCBiZSB0aGUgc2FtZSBmb3IgYWxsIHRoZSByZXF1ZXN0cyB3aXRoaW4gdGhlIHNl cXVlbmNlIChzaW1pbGFyIHRvIGxpbmtlZCBTQ1NJIGNvbW1hbmRzKS4NCg0KMy4xMC4zIFRhcmdl dCBUcmFuc2ZlciBUYWcNCg0KV2hlbiB0aGUgVGFyZ2V0IFRyYW5zZmVyIFRhZyBpcyBzZXQgdG8g dGhlIHJlc2VydmVkIHZhbHVlIDB4ZmZmZmZmZmYsIGl0IHRlbGxzIHRoZSB0YXJnZXQgdGhhdCB0 aGlzIGlzIGEgbmV3IHJlcXVlc3QgYW5kIHRoZSB0YXJnZXQgc2hvdWxkIHJlc2V0IGFueSBpbnRl cm5hbCBzdGF0ZSBhc3NvY2lhdGVkIHdpdGggdGhlIEluaXRpYXRvciBUYXNrIFRhZy4NCg0KVGhl IHRhcmdldCBzZXRzIGluIGEgdGV4dCByZXNwb25zZSB0aGUgVGFyZ2V0IFRyYW5zZmVyIFRhZyB0 byBhIHZhbHVlIG90aGVyIHRoYW4gdGhlIHJlc2VydmVkIHZhbHVlIDB4ZmZmZmZmZmYgd2hlbmV2 ZXIgaXQgaW5kaWNhdGVzIHRoYXQgaXQgaGFzIG1vcmUgZGF0YSB0byBzZW5kIG9yIG1vcmUgb3Bl cmF0aW9ucyB0byBwZXJmb3JtIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3BlY2lmaWVkIEluaXRpYXRv ciBUYXNrIFRhZyAoaXQgTVVTVCBkbyBzbyB3aGVuZXZlciBpdCBzZXRzIHRoZSBGIGJpdCB0byAw IGluIHRoZSByZXNwb25zZSkuIEJ5IGNvcHlpbmcgdGhlIFRhcmdldCBUcmFuc2ZlciBUYWcgZnJv bSB0aGUgcmVzcG9uc2UgdG8gdGhlIG5leHQgVGV4dCBSZXF1ZXN0LCB0aGUgaW5pdGlhdG9yIHRl bGxzIHRoZSB0YXJnZXQgdG8gY29udGludWUgdGhlIG9wZXJhdGlvbiBmb3IgdGhlIHNwZWNpZmlj IEluaXRpYXRvciBUYXNrIFRhZy4NCg0KVGhpcyBtZWNoYW5pc20gYWxsb3dzIHRoZSBpbml0aWF0 b3IgYW5kIHRhcmdldCB0byB0cmFuc2ZlciBhIGxhcmdlIGFtb3VudCBvZiB0ZXh0dWFsIGRhdGEg b3ZlciBhIHNlcXVlbmNlIG9mIHRleHQtY29tbWFuZC90ZXh0LXJlc3BvbnNlIGV4Y2hhbmdlIG9y IHRvIHBlcmZvcm0gZXh0ZW5kZWQgbmVnb3RpYXRpb24gc2VxdWVuY2VzICANCg0KQSB0YXJnZXQg TUFZIHJlc2V0IGl0cyBpbnRlcm5hbCBzdGF0ZSBpZiBhbiBleGNoYW5nZSBpcyBzdGFsbGVkIGJ5 IHRoZSBpbml0aWF0b3IgZm9yIGEgbG9uZyB0aW1lIG9yIGlmIGl0IGlzIHJ1bm5pbmcgb3V0IG9m IHJlc291cmNlcy4NCg0KTG9uZyB0ZXh0IHJlc3BvbnNlcyBhcmUgaGFuZGxlZCBhcyBpbiB0aGUg Zm9sbG93aW5nIGV4YW1wbGU6DQoNCkktPlQgVGV4dCBTZW5kVGFyZ2V0cz1hbGwgKEY9MSxUVFQ9 MHhmZmZmZmZmZikNClQtPkkgVGV4dCA8cGFydCAxPiAoRj0wLFRUVD0weDEyMzQ1Njc4KSANCkkt PlQgVGV4dCA8ZW1wdHk+IChGPTEsIFRUVD0weDEyMzQ1Njc4KQ0KVC0+SSBUZXh0IDxwYXJ0IDI+ IChGPTAsIFRUVD0weDEyMzQ1Njc4KSANCkktPlQgVGV4dCA8ZW1wdHk+IChGPTEsIFRUVD0weDEy MzQ1Njc4KQ0KLi4uDQpULT5JIFRleHQgPHBhcnQgbj4gKEY9MSwgVFRUPTB4ZmZmZmZmZmYpIA0K DQozLjEwLjQgVGV4dA0KDQpUaGUgaW5pdGlhdG9yIHNlbmRzIHRoZSB0YXJnZXQgYSBzZXQgb2Yg a2V5PXZhbHVlIG9yIGtleT1saXN0IHBhaXJzIGVuY29kZWQgaW4gVVRGLTggVW5pY29kZS4gQWxs IHRoZSB0ZXh0IGtleXMgYW5kIHRleHQgdmFsdWVzIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50 IGFyZSB0byBiZSBwcmVzZW50ZWQgYW5kIGludGVycHJldGVkIGluIHRoZSBjYXNlIHRoZXkgYXBw ZWFyIGluIHRoaXMgZG9jdW1lbnQgKHRoZXkgYXJlIGNhc2Ugc2Vuc2l0aXZlKS4gVGhlIGtleSBh bmQgdmFsdWUgYXJlIHNlcGFyYXRlZCBieSBhICc9JyAoMHgzZCkgZGVsaW1pdGVyLiBFdmVyeSBr ZXk9dmFsdWUgcGFpciAoaW5jbHVkaW5nIHRoZSBsYXN0IG9yIG9ubHkgcGFpcikgTVVTVCBiZSBm b2xsb3dlZCBieSBhdCBsZWFzdCBvbmUgbnVsbCAoMHgwMCkgZGVsaW1pdGVyLiAgQSBsaXN0IGlz IGEgc2V0IG9mIHZhbHVlcyBzZXBhcmF0ZWQgYnkgY29tbWEgKDB4MmMpLiANCg0KQ2hhcmFjdGVy IHN0cmluZ3MgYXJlIHJlcHJlc2VudGVkIGFzIHBsYWluIHRleHQuIEJpbmFyeSBpdGVtcyBjYW4g YmUgZW5jb2RlZCB1c2luZyB0aGVpciBkZWNpbWFsIHJlcHJlc2VudGF0aW9uICh3aXRoIG9yIHdp dGhvdXQgbGVhZGluZyB6ZXJvcykgb3IgaGV4YWRlY2ltYWwgcmVwcmVzZW50YXRpb24gKGUuZy4s IDgxOTAgaXMgMHgxZmZlKS4gIFVwcGVyIGFuZCBsb3dlciBjYXNlIGxldHRlcnMgbWF5IGJlIHVz ZWQgaW50ZXJjaGFuZ2VhYmx5IGluIGhleGFkZWNpbWFsIG5vdGF0aW9uIChpLmUuLCAweDFhQmMs IDB4MUFiQywgMFgxYUJjIGFuZCAweDFBQkMgYXJlIGVxdWl2YWxlbnQpLiBCaW5hcnkgaXRlbXMg Y2FuIGFsc28gYmUgZW5jb2RlZCB1c2luZyB0aGUgbW9yZSBjb21wYWN0IEJhc2U2NCBlbmNvZGlu ZyBhcyBzcGVjaWZpZWQgYnkgW1JGQzIwNDVdIHByZWNlZGVkIGJ5IHRoZSAwYi4gIEtleSBuYW1l cyBNVVNUIE5PVCBleGNlZWQgNjMgYnl0ZXMuDQoNCklmIG5vdCBzcGVjaWZpZWQgb3RoZXJ3aXNl IHRoZSBtYXhpbXVtIGxlbmd0aCBvZiBhbiBpbmRpdmlkdWFsIHZhbHVlIChub3QgaXRzIGVuY29k ZWQgcmVwcmVzZW50YXRpb24pIGlzIDI1NSBieXRlcyBub3QgaW5jbHVkaW5nIHRoZSBkZWxpbWl0 ZXIgKGNvbW1hIG9yIG51bGwpLg0KDQpUaGUgZGF0YSBsZW5ndGhzIG9mIGEgdGV4dCByZXF1ZXN0 IG9yIHJlc3BvbnNlIE1VU1QgTk9UIGV4Y2VlZCBNYXhSZWN2UERVTGVuZ3RoIChhIHBlciBjb25u ZWN0aW9uIG5lZ290aWF0ZWQgcGFyYW1ldGVyKS4gIA0KDQpBIEtleT12YWx1ZSBwYWlyIGNhbiBz cGFuIFRleHQgcmVxdWVzdCBvciByZXNwb25zZSBib3VuZGFyaWVzIChpLmUuIGEga2V5PXZhbHVl IHBhaXIgY2FuIHN0YXJ0IGluIG9uZSBQRFUgYW5kIGNvbnRpbnVlIG9uIHRoZSBuZXh0KS4NCg0K VGhlIHRhcmdldCByZXNwb25kcyBieSBzZW5kaW5nIGl0cyByZXNwb25zZSBiYWNrIHRvIHRoZSBp bml0aWF0b3IuIFRoZSByZXNwb25zZSB0ZXh0IGZvcm1hdCBpcyBzaW1pbGFyIHRvIHRoZSByZXF1 ZXN0IHRleHQgZm9ybWF0LiANCg0KU29tZSBiYXNpYyBrZXk9dmFsdWUgcGFpcnMgYXJlIGRlc2Ny aWJlZCBpbiBBcHBlbmRpeCBELiBBbGwga2V5cyBpbiBBcHBlbmRpeCBELCBleGNlcHQgZm9yIHRo ZSBYLSBleHRlbnNpb24gZm9ybWF0LCBNVVNUIGJlIHN1cHBvcnRlZCBieSBpU0NTSSBpbml0aWF0 b3JzIGFuZCB0YXJnZXRzLiANCg0KTWFudWZhY3R1cmVycyBtYXkgaW50cm9kdWNlIG5ldyBrZXlz IGJ5IHByZWZpeGluZyB0aGVtIHdpdGggWC0gZm9sbG93ZWQgYnkgdGhlaXIgKHJldmVyc2VkKSBk b21haW4gbmFtZSwgZm9yIGV4YW1wbGUgdGhlIGNvbXBhbnkgb3duaW5nIHRoZSBkb21haW4gYWNt ZS5jb20gY2FuIGlzc3VlOiANCg0KWC1jb20uYWNtZS5iYXIuZm9vLmRvX3NvbWV0aGluZz0zDQoN CkFueSBvdGhlciBrZXkgbm90IHVuZGVyc3Rvb2QgYnkgdGhlIHRhcmdldCBtYXkgYmUgaWdub3Jl ZCBieSB0aGUgdGFyZ2V0IHdpdGhvdXQgYWZmZWN0aW5nIGJhc2ljIGZ1bmN0aW9uLiBIb3dldmVy IHRoZSBUZXh0IFJlc3BvbnNlIGZvciBhIGtleSB0aGF0IHdhcyBub3QgdW5kZXJzdG9vZCBNVVNU IGJlIGtleT1Ob3RVbmRlcnN0b29kLg0KDQpUZXh0IG9wZXJhdGlvbnMgYXJlIHVzdWFsbHkgbWVh bnQgZm9yIHBhcmFtZXRlciBzZXR0aW5nL25lZ290aWF0aW9ucyBidXQgY2FuIGJlIHVzZWQgYWxz byB0byBwZXJmb3JtIHNvbWUgbG9uZyBsYXN0aW5nIG9wZXJhdGlvbnMuDQoNClRleHQgb3BlcmF0 aW9ucyB0aGF0IHdpbGwgdGFrZSBhIGxvbmcgdGltZSBzaG91bGQgYmUgcGxhY2VkIGluIHRoZWly IG93biBUZXh0IHJlcXVlc3QuICANCg0KIA0KMy4xMSBUZXh0IFJlc3BvbnNlDQoNClRoZSBUZXh0 IFJlc3BvbnNlIFBEVSBjb250YWlucyB0aGUgdGFyZ2V0J3MgcmVzcG9uc2VzIHRvIHRoZSBpbml0 aWF0b3IncyBUZXh0IHJlcXVlc3QuIFRoZSBmb3JtYXQgb2YgdGhlIFRleHQgZmllbGQgbWF0Y2hl cyB0aGF0IG9mIHRoZSBUZXh0IHJlcXVlc3QuDQoNCg0KQnl0ZSAvICAgIDAgICAgICAgfCAgICAg ICAxICAgICAgIHwgICAgICAgMiAgICAgICB8ICAgICAgIDMgICAgICAgfA0KICAgLyAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfA0K ICB8NyA2IDUgNCAzIDIgMSAwfDcgNiA1IDQgMyAyIDEgMHw3IDYgNSA0IDMgMiAxIDB8NyA2IDUg NCAzIDIgMSAwfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDB8MXwxfCAweDI0ICAgICAgfEZ8IFJlc2VydmVkICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDR8IFJlc2Vy dmVkICAgICAgfCBEYXRhU2VnbWVudExlbmd0aCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tKw0KIDh8IFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKw0KMTJ8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tKw0KMTZ8IEluaXRpYXRvciBUYXNrIFRhZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjB8IFRhcmdldCBUcmFuc2ZlciBUYWcgb3Ig MHhmZmZmZmZmZiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjR8 IFN0YXRTTiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tKw0KMjh8IEV4cENtZFNOICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMzJ8IE1heENtZFNO ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tKw0KMzYvIFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLw0KICsvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KICArLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KNDh8IERpZ2Vz dHMgaWYgYW55Li4uICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tKw0KICAvIERhdGFTZWdtZW50IChUZXh0KSAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLw0KICsvICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KICArLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KDQozLjEx LjEgRiAoRmluYWwpIEJpdA0KDQpXaGVuIHNldCB0byAxIGluIHJlc3BvbnNlIHRvIGEgdGV4dCBy ZXF1ZXN0IHdpdGggdGhlIEZpbmFsIGJpdCBzZXQgdG8gMSB0aGUgRiBiaXQgaW5kaWNhdGVzIHRo YXQgdGhlIHRhcmdldCBoYXMgZmluaXNoZWQgdGhlIHdob2xlIG9wZXJhdGlvbi4gIE90aGVyd2lz ZSwgaWYgc2V0IHRvIDAgaW4gcmVzcG9uc2UgdG8gYSB0ZXh0IHJlcXVlc3Qgd2l0aCB0aGUgRmlu YWwgQml0IHNldCB0byAxIGl0IGluZGljYXRlcyB0aGF0IHRoZSB0YXJnZXQgaGFzIG1vcmUgd29y ayB0byBkbyAoaW52aXRlcyBhIGZvbGxvdy1vbiB0ZXh0IHJlcXVlc3QpLiAgQSB0ZXh0IHJlc3Bv bnNlIHdpdGggdGhlIEYgYml0IHNldCB0byAxIGluIHJlc3BvbnNlIHRvIGEgdGV4dCByZXF1ZXN0 IHdpdGggdGhlIEYgYml0IHNldCB0byAwIGlzIGEgcHJvdG9jb2wgZXJyb3IuIA0KDQpBIHRleHQg cmVzcG9uc2Ugd2l0aCB0aGUgRiBiaXQgc2V0IHRvIDEgTVVTVCBOT1QgY29udGFpbiBrZXk9dmFs dWUgcGFpcnMgdGhhdCBtYXkgcmVxdWlyZSBhZGRpdGlvbmFsIGFuc3dlcnMgZnJvbSB0aGUgaW5p dGlhdG9yLg0KDQpBIHRleHQgcmVzcG9uc2Ugd2l0aCB0aGUgRiBiaXQgc2V0IHRvIDAgTVVTVCBo YXZlIGEgVGFyZ2V0IFRyYW5zZmVyIFRhZyBmaWVsZCBzZXQgdG8gYSB2YWx1ZSBkaWZmZXJlbnQg dGhhbiB0aGUgcmVzZXJ2ZWQgMHhmZmZmZmZmZi4NCg0KMy4xMS4yIEluaXRpYXRvciBUYXNrIFRh Zw0KDQpUaGUgSW5pdGlhdG9yIFRhc2sgVGFnIG1hdGNoZXMgdGhlIHRhZyB1c2VkIGluIHRoZSBp bml0aWFsIFRleHQgcmVxdWVzdC4NCg0KMy4xMS4zIFRhcmdldCBUcmFuc2ZlciBUYWcNCg0KV2hl biBhIHRhcmdldCBoYXMgbW9yZSB3b3JrIHRvIGRvIChlLmcuLCBjYW4ndCB0cmFuc2ZlciBhbGwg dGhlIHJlbWFpbmluZyB0ZXh0IGRhdGEgaW4gYSBzaW5nbGUgVGV4dCByZXNwb25zZSBvciBoYXMg dG8gY29udGludWUgdGhlIG5lZ290aWF0aW9uKSBhbmQgaGFzIGVub3VnaCByZXNvdXJjZXMgdG8g cHJvY2VlZCBpdCBNVVNUIHNldCB0aGUgVGFyZ2V0IFRyYW5zZmVyIFRhZyB0byBhIHZhbHVlIGRp ZmZlcmVudCBmcm9tIHRoZSByZXNlcnZlZCB2YWx1ZSBvZiAweGZmZmZmZmZmLiAgDQoNClRoZSBp bml0aWF0b3IgTVVTVCBjb3B5IHRoaXMgVGFyZ2V0IFRyYW5zZmVyIFRhZyBpbiBpdHMgbmV4dCBy ZXF1ZXN0IHRvIGluZGljYXRlIHRoYXQgaXQgd2FudHMgdGhlIHJlc3Qgb2YgdGhlIGRhdGEuDQoN CklmIHRoZSB0YXJnZXQgcmVjZWl2ZXMgYSBUZXh0IFJlcXVlc3Qgd2l0aCB0aGUgVGFyZ2V0IFRh c2sgVGFnIHNldCB0byB0aGUgcmVzZXJ2ZWQgdmFsdWUgb2YgMHhmZmZmZmZmZiBpdCByZXNldHMg aXRzIGludGVybmFsIHN0YXRlIGFzc29jaWF0ZWQgd2l0aCB0aGUgZ2l2ZW4gSW5pdGlhdG9yIFRh c2sgVGFnLiAgDQoNCldoZW4gYSB0YXJnZXQgY2FuJ3QgZmluaXNoIHRoZSBvcGVyYXRpb24gaW4g c2luZ2xlIHRleHQgcmVzcG9uc2UgYnV0IGhhcyBub3QgZW5vdWdoIHJlc291cmNlcyB0byBjb250 aW51ZSBpdCByZWplY3RzIHRoZSBUZXh0IHJlcXVlc3Qgd2l0aCBhbiBhcHByb3ByaWF0ZSBSZWpl Y3QgY29kZS4gQSB0YXJnZXQgbWF5IHJlc2V0IGl0cyBpbnRlcm5hbCBpdHMgaW50ZXJuYWwgc3Rh dGUgYXNzb2NpYXRlZCB3aXRoIGFuIEluaXRpYXRvciBUYXNrIFRhZyBhbmQgZXhwcmVzc2VkIHRo cm91Z2ggdGhlIFRhcmdldCBUcmFuc2ZlciBUYWcsIGlmIHRoZSBpbml0aWF0b3IgZmFpbHMgdG8g Y29udGludWUgdGhlIGV4Y2hhbmdlIGZvciBzb21lIHRpbWUsIGFuZCByZWplY3Qgc3Vic2VxdWVu dCBUZXh0IHJlcXVlc3RzIHdpdGggdGhlIFRhcmdldCBUcmFuc2ZlciBUYWcgc2V0IHRvIHRoZSAi c3RhbGUiIHZhbHVlLg0KDQozLjExLjQgVGV4dCBSZXNwb25zZSBEYXRhDQoNClRoZSBUZXh0IFJl c3BvbnNlIERhdGEgU2VnbWVudCBjb250YWlucyByZXNwb25zZXMgaW4gdGhlIHNhbWUga2V5PXZh bHVlIGZvcm1hdCBhcyB0aGUgVGV4dCByZXF1ZXN0IGFuZCB3aXRoIHRoZSBzYW1lIGxlbmd0aCBh bmQgY29kaW5nIGNvbnN0cmFpbnRzLiBBcHBlbmRpeCBBIGFuZCBBcHBlbmRpeCBEIGxpc3RzIHNv bWUgYmFzaWMgVGV4dCByZXF1ZXN0cyBhbmQgdGhlaXIgUmVzcG9uc2VzLiAgDQoNCkFsdGhvdWdo IHRoZSBpbml0aWF0b3IgaXMgdGhlIHJlcXVlc3RpbmcgcGFydHkgYW5kIGNvbnRyb2xzIHRoZSBy ZXF1ZXN0LXJlc3BvbnNlIGluaXRpYXRpb24gYW5kIHRlcm1pbmF0aW9uIHRoZSB0YXJnZXQgY2Fu IG9mZmVyIGtleT12YWx1ZSBwYWlycyBvZiBpdHMgb3duIGFzIHBhcnQgb2YgYSBzZXF1ZW5jZSBh bmQgbm90IG9ubHkgaW4gcmVzcG9uc2UgdG8gdGhlIGluaXRpYXRvci4NCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCjMuMTcgUmVqZWN0DQoNCg0KQnl0ZSAvICAgIDAgICAg ICAgfCAgICAgICAxICAgICAgIHwgICAgICAgMiAgICAgICB8ICAgICAgIDMgICAgICAgfA0KICAg LyAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgfA0KICB8NyA2IDUgNCAzIDIgMSAwfDcgNiA1IDQgMyAyIDEgMHw3IDYgNSA0IDMgMiAx IDB8NyA2IDUgNCAzIDIgMSAwfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDB8MXwxfCAweDNmICAgICAgfDF8IFJl c2VydmVkICAgIHwgUmVhc29uICAgICAgICB8IFJlc2VydmVkICAgICAgfA0KICArLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K IDR8IFJlc2VydmVkICAgICAgfCBEYXRhU2VnbWVudExlbmd0aCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDgvIFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KICsvICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KICArLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t Kw0KMjR8IFN0YXRTTiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjh8IEV4cENtZFNOICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMzJ8IE1h eENtZFNOICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tKw0KMzZ8IERhdGFTTiBvciBSZXNlcnZlZCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KNDB8IFJlc2VydmVkICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAr LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tKw0KNDR8IFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KNDh8IERpZ2VzdCAoaWYgYW55KSAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K eHgvIENvbXBsZXRlIEhlYWRlciBvZiBCYWQgUERVICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLw0KICsvICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLw0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KeXkvVmVuZG9yIHNwZWNpZmljIGRh dGEgKGlmIGFueSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KICAvICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Lw0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tKw0KenoNCg0KUmVqZWN0IGlzIHVzZWQgdG8gaW5kaWNhdGUgYW4gaVNDU0kg ZXJyb3IgY29uZGl0aW9uIChwcm90b2NvbCwgdW5zdXBwb3J0ZWQgb3B0aW9uIGV0Yy4pLg0KDQoz LjE3LjEgUmVhc29uDQoNClRoZSByZWplY3QgUmVhc29uIGlzIGNvZGVkIGFzIGZvbGxvd3M6DQog DQoNCistLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tKw0KfCBDb2RlIHwgRXhwbGFuYXRpb24gICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgQ2FuIHRoZSBvcmlnaW5hbCB8DQp8IChoZXgpfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCBQRFUgYmUgcmUtc2VudD8gIHwNCistLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0t Kw0KfCAweDAxIHwgRnVsbCBGZWF0dXJlIFBoYXNlIENvbW1hbmQgYmVmb3JlIGxvZ2luIHwgbm8g ICAgICAgICAgICAgICB8DQp8ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwNCnwgMHgwMiB8IERhdGEgKHBheWxvYWQpIERp Z2VzdCBFcnJvciAgICAgICAgICAgICB8IHllcyAgKE5vdGUgMSkgICAgfA0KfCAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICB8 DQp8IDB4MDMgfCBEYXRhLVNOQUNLIFJlamVjdCAgICAgICAgICAgICAgICAgICAgICAgfCB5ZXMg ICAgICAgICAgICAgIHwNCnwgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgfA0KfCAweDA0IHwgUHJvdG9jb2wgRXJyb3IgKGUu Zy4sIFNOQUNLIHJlcXVlc3QgZm9yIHwgbm8gICAgICAgICAgICAgICB8DQp8ICAgICAgfCBhIHN0 YXR1cyB0aGF0IHdhcyBhbHJlYWR5IGFja25vd2xlZGdlZCkgfCAgICAgICAgICAgICAgICAgIHwN CnwgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgfA0KfCAweDA1IHwgQ29tbWFuZCBub3Qgc3VwcG9ydGVkIGluIHRoaXMgc2Vz c2lvbiAgIHwgbm8gICAgICAgICAgICAgICB8DQp8ICAgICAgfCB0eXBlICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwNCnwgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgfA0K fCAweDA2IHwgSW1tZWRpYXRlIENvbW1hbmQgUmVqZWN0IC0gdG9vIG1hbnkgICAgIHwgeWVzICAg ICAgICAgICAgICB8DQp8ICAgICAgfCBpbW1lZGlhdGUgY29tbWFuZHMgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgIHwNCnwgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgfA0KfCAweDA3IHwgVGFzayBp biBwcm9ncmVzcyAgICAgICAgICAgICAgICAgICAgICAgIHwgbm8gICAgICAgICAgICAgICB8DQp8 ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgIHwNCnwgMHgwOCB8IEludmFsaWQgU05BQ0sgICAgICAgICAgICAgICAgICAgICAg ICAgICB8IG5vICAgICAgICAgICAgICAgfA0KfCAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICB8DQp8IDB4MDkgfCBUYXJnZXQg VHJhbnNmZXIgVGFnIFJlamVjdCBmb3IgdGhpcyAgICAgfCBubyAgICAgICAgICAgICAgIHwNCnwg ICAgICB8IEluaXRpYXRvciBUYXNrIFRhZyAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgfA0KfCAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICB8DQp8IDB4MGEgfCBMb25nIE9wZXJhdGlvbiBSZWplY3Qg LSBDYW4ndCBnZW5lcmF0ZSAgfCB5ZXMgICAgICAgICAgICAgIHwNCnwgICAgICB8IFRhcmdldCBU cmFuc2ZlciBUYWcgLSBvdXQgb2YgcmVzb3VyY2VzICB8ICAgICAgICAgICAgICAgICAgfA0KfCAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICB8DQp8IDB4MGIgfCBOZWdvdGlhdGlvbiBSZXNldCAgICAgICAgICAgICAgICAgICAg ICAgfCBubyAgICAgICAgICAgICAgfA0KKy0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0rDQoNCk5vdGUgMTogRm9yIGlTQ1NJ IGRhdGEgUERVUywgdGhpcyBpcyBkb25lIG9ubHkgaWYgdGFyZ2V0IHJlcXVlc3RzIHJldHJhbnNt aXNzaW9uIHdpdGggYSByZWNvdmVyeSBSMlQuICAgIEhvd2V2ZXIsIGlmIHRoaXMgaXMgdGhlIGRh dGEgZGlnZXN0IGVycm9yIG9uIGltbWVkaWF0ZSBkYXRhLCBubyBzaWduYWwgZnJvbSB0aGUgdGFy Z2V0IGlzIG5lY2Vzc2FyeSBmb3IgUERVIHJldHJhbnNtaXNzaW9uIGlmIGRlc2lyZWQgc28gYnkg dGhlIGluaXRpYXRvci4NCg0KQWxsIG90aGVyIHZhbHVlcyBmb3IgcmVhc29uIGFyZSByZXNlcnZl ZC4NCg0KSW4gYWxsIHRoZSBjYXNlcyBpbiB3aGljaCBhIHByZS1pbnN0YW50aWF0ZWQgU0NTSSB0 YXNrIGlzIHRlcm1pbmF0ZWQgYmVjYXVzZSBvZiB0aGUgcmVqZWN0LCB0aGUgdGFyZ2V0IG11c3Qg aXNzdWUgYSBwcm9wZXIgU0NTSSBjb21tYW5kIHJlc3BvbnNlIHdpdGggQ0hFQ0sgQ09ORElUSU9O IGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuNC4zLiAgSWYgdGhlIGVycm9yIGlzIGRldGVjdGVk IHdoaWxlIGRhdGEgZnJvbSB0aGUgaW5pdGlhdG9yIGlzIHN0aWxsIGV4cGVjdGVkICh0aGUgY29t bWFuZCBQRFUgZGlkIG5vdCBjb250YWluIGFsbCB0aGUgZGF0YSBhbmQgdGhlIHRhcmdldCBoYXMg bm90IHJlY2VpdmVkIGEgRGF0YS1vdXQgUERVIHdpdGggdGhlIGZpbmFsIGJpdCBTZXQpIHRoZSB0 YXJnZXQgTVVTVCB3YWl0IHVudGlsIGl0IHJlY2VpdmVzIHRoZSBEYXRhLW91dCBQRFUgd2l0aCB0 aGUgRiBiaXQgc2V0IGJlZm9yZSBzZW5kaW5nIHRoZSBSZXNwb25zZSBQRFUuICANCg0KRm9yIGFk ZGl0aW9uYWwgdXNhZ2Ugc2VtYW50aWNzIG9mIFJlamVjdCBQRFUsIHBsZWFzZSBzZWUgc2VjdGlv biA4LjIuDQoNCjMuMTcuMiBEYXRhU04NCg0KVGhpcyBmaWVsZCBpcyB2YWxpZCBvbmx5IGlmIHRo ZSBSZWFzb24gY29kZSBpcyAiSW52YWxpZCBTTkFDSyIgYW5kIHRoZSBTTkFDSyB3YXMgYSBkYXRh IFNOQUNLLiAgVGhlIERhdGFTTiBpcyB0aGUgbGFzdCBzZXF1ZW5jZSBudW1iZXIgdGhhdCB0aGUg dGFyZ2V0IHNlbnQgZm9yIHRoZSB0YXNrLg0KDQozLjE3LjMgQ29tcGxldGUgSGVhZGVyIG9mIEJh ZCBQRFUNCg0KVGhlIHRhcmdldCByZXR1cm5zIHRoZSBoZWFkZXIgKG5vdCBpbmNsdWRpbmcgZGln ZXN0KSBvZiB0aGUgUERVIGluIGVycm9yIGFzIHRoZSBkYXRhIG9mIHRoZSByZXNwb25zZS4NCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KNi4gT3BlcmF0aW9uYWwgUGFyYW1l dGVyIE5lZ290aWF0aW9uIE91dHNpZGUgdGhlIExvZ2luIFBoYXNlDQoNClNvbWUgb3BlcmF0aW9u YWwgcGFyYW1ldGVycyBNQVkgYmUgbmVnb3RpYXRlZCBvdXRzaWRlIChhZnRlcikgdGhlIGxvZ2lu IHBoYXNlLg0KDQpQYXJhbWV0ZXIgbmVnb3RpYXRpb24gaW4gZnVsbCBmZWF0dXJlIHBoYXNlIGlz IGRvbmUgdGhyb3VnaCBUZXh0IHJlcXVlc3RzIGFuZCByZXNwb25zZXMuDQoNCk9wZXJhdGlvbmFs IHBhcmFtZXRlciBuZWdvdGlhdGlvbiBNQVkgaW52b2x2ZSBzZXZlcmFsIHRleHQgcmVxdWVzdC1y ZXNwb25zZSBleGNoYW5nZXMgYWx3YXlzIHN0YXJ0ZWQgYW5kIHRlcm1pbmF0ZWQgYnkgdGhlIGlu aXRpYXRvci4gVGhlIGluaXRpYXRvciBNVVNUIGluZGljYXRlIGl0cyBpbnRlbnQgdG8gdGVybWlu YXRlIHRoZSBuZWdvdGlhdGlvbiBieSBzZXR0aW5nIHRoZSBGIGJpdCB0byAxOyB0aGUgdGFyZ2V0 IHNldHMgdGhlIEYgYml0IHRvIDEgb24gdGhlIGxhc3QgcmVzcG9uc2UuDQoNCklmIHRoZSB0YXJn ZXQgcmVzcG9uZHMgdG8gYSB0ZXh0IHJlcXVlc3Qgd2l0aCB0aGUgRiBiaXQgc2V0IHRvIDEsIHdp dGggYSB0ZXh0IHJlc3BvbnNlIHdpdGggdGhlIEYgYml0IHNldCB0byAwLCB0aGUgaW5pdGlhdG9y IG11c3Qga2VlcCBzZW5kaW5nIHRoZSB0ZXh0IHJlcXVlc3QgKGV2ZW4gZW1wdHkpIHdpdGggdGhl IEYgYml0IHNldCB0byAxIHVudGlsIGl0IGdldHMgdGhlIHRleHQgcmVzcG9uc2Ugd2l0aCB0aGUg RiBiaXQgc2V0IHRvIDEuIFJlc3BvbmRpbmcgdG8gYSB0ZXh0IHJlcXVlc3Qgd2l0aCB0aGUgRiBi aXQgc2V0IHRvIDEgd2l0aCBhbiBlbXB0eSAobm8ga2V5PXZhbHVlIHBhaXJzKSBpcyBub3QgYW4g ZXJyb3IgYnV0IGlzIGRpc2NvdXJhZ2VkLg0KDQpJbiBhIG5lZ290aWF0aW9uIHNlcXVlbmNlLCB0 aGUgRiBiaXQgc2V0dGluZ3MgaW4gb25lIHBhaXIgb2YgdGV4dCByZXF1ZXN0LXJlc3BvbnNlcyBo YXZlIG5vIGJlYXJpbmcgb24gdGhlIEYgYml0IHNldHRpbmdzIG9mIHRoZSBuZXh0IHBhaXIuICBB biBpbml0aWF0b3IgaGF2aW5nIHRoZSBGIGJpdCBzZXQgdG8gMSBpbiBhIHJlcXVlc3QgYW5kIGJl aW5nIGFuc3dlcmVkIHdpdGggYW4gRiBiaXQgc2V0dGluZyBvZiAwIG1heSBoYXZlIHRoZSBuZXh0 IHJlcXVlc3QgaXNzdWVkIHdpdGggdGhlIEYgYml0IHNldCB0byAwLiAgDQoNCldoZW5ldmVyIHBh cmFtZXRlciBhY3Rpb24gb3IgYWNjZXB0YW5jZSBpcyBkZXBlbmRlbnQgb24gb3RoZXIgcGFyYW1l dGVycywgdGhlIGRlcGVuZGVudCBwYXJhbWV0ZXJzIE1VU1QgYmUgc2VudCBhZnRlciB0aGUgcGFy YW1ldGVycyB0aGV5IGRlcGVuZCBvbjsgaWYgdGhleSBhcmUgc2VudCB3aXRoaW4gdGhlIHNhbWUg Y29tbWFuZCBhIHJlc3BvbnNlIGZvciBhIHBhcmFtZXRlciBtaWdodCBpbXBseSByZXNwb25zZXMg Zm9yIG90aGVycy4NCg0KV2hlbmV2ZXIgdGhlIHRhcmdldCByZXNwb25kcyB3aXRoIHRoZSBGIGJp dCBzZXQgdG8gMCBpdCBNVVNUIHNldCB0aGUgVGFyZ2V0IFRyYW5zZmVyIFRhZyB0byBhIHZhbHVl IG90aGVyIHRoYW4gdGhlIGRlZmF1bHQgMHhmZmZmZmZmZi4NCg0KQW4gaW5pdGlhdG9yIE1BWSBy ZXNldCBhbiBvcGVyYXRpb25hbCBwYXJhbWV0ZXIgbmVnb3RpYXRpb24gYnkgaXNzdWluZyBhIFRl eHQgcmVxdWVzdCB3aXRoIHRoZSBUYXJnZXQgVHJhbnNmZXIgVGFnIHNldCB0byB0aGUgdmFsdWUg MHhmZmZmZmZmZiBhZnRlciByZWNlaXZpbmcgYSByZXNwb25zZSB3aXRoIHRoZSBUYXJnZXQgVHJh bnNmZXIgVGFnIHNldCB0byBhIHZhbHVlIG90aGVyIHRoYW4gMHhmZmZmZmZmZi4gIEEgdGFyZ2V0 IG1heSByZXNldCBhbiBvcGVyYXRpb25hbCBwYXJhbWV0ZXIgbmVnb3RpYXRpb24gYnkgYW5zd2Vy aW5nIGEgVGV4dCByZXF1ZXN0IHdpdGggYSBSZWplY3QuDQoNCg== --0__=C2256AE30081C26A8f9e8a93df938690918cC2256AE30081C26A-- From owner-ips@ece.cmu.edu Sat Oct 13 08:02: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 IAA03086 for ; Sat, 13 Oct 2001 08:02:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9DB8Ec20344 for ips-outgoing; Sat, 13 Oct 2001 07:08: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 f9DB8Bl20338 for ; Sat, 13 Oct 2001 07:08:12 -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 NAA86294 for ; Sat, 13 Oct 2001 13:08: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 f9DB85Y291536 for ; Sat, 13 Oct 2001 13:08:05 +0200 Subject: Re: iSCSI: data ACKs To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sat, 13 Oct 2001 07:10:04 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/10/2001 14:08:04 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=C2256AE40016B1928f9e8a93df938690918cC2256AE40016B192" Content-Disposition: inline Sender: owner-ips@ece.cmu.edu Precedence: bulk --0__=C2256AE40016B1928f9e8a93df938690918cC2256AE40016B192 Content-type: text/plain; charset=us-ascii Excellent. Here are the proposed changes: (See attached file: Changes-Data-ACK.txt) Comments? Julo "Mallikarjun C." To: ips Subject: iSCSI: data ACKs Sent by: owner-ips@ece. cmu.edu 12-10-01 00:13 Please respond to cbm Julian, Consequent to the London consensus on keeping SNACKs in the protocol, I believe it is fair to enable targets desirous of efficiently managing their buffers, by way of a data acknowledgement request-response mechanism in iSCSI (under certain constraints, as below) as earlier requested by Matthew Burbridge on this list. The current solution of allowing targets to re-access the medium to satisfy data transfer retransmission presents problems in the following cases - - any target in general that attempts to prevent reaccessing the medium in view of cache management complexities, or wanting to conserve backend SCSI bandwidth (only if the error rate is high). - tapes supporting queued commands, that want to free up memory to work on subsequent commands. - iSCSI "middle boxes" supporting multiple tape devices behind, and wanting to decrease buffer requirements. - the SCSI-legitimate (but perhaps highly unlikely) case of write-after-read to the same LBAs. I propose the following means to enable a data ACK mechanism - target requests an ACK by setting a TBD bit (say A-bit, for ACK) on read data PDU. It MAY set the A-bit once at most every MaxBurstSize bytes, and MUST NOT do so any more frequently than that. - an initiator generates a SNACK of type "ACK" (per Julian's earlier proposal) on reception of an A-bit data PDU. If there were pending data retransmissions in the burst, the generation of ACK is deferred till the holes are filled. - target processes the SNACK and frees up the acknowledged buffers. The reason a new A-bit is proposed to be used (in stead of the F-bit) is that there may be unrelated reasons for setting the F-bit by a target (may be to enable opposite data flow for a bidirectional command, for ex.). I believe that the implementation complexity in the above proposal is minimal, while the runtime cost is non-existent for all "short" (< MaxBurstSize) transfers, and the same for "long" transfers (> MaxBurstSize) is very reasonable. You will note that the onus is on targets to generate ACK requests and process ACKs, if they want to manage their buffers efficiently. Finally, the ack scheme should be applicable only to sessions where the operational ErrorRecoveryLevel >= 1. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com --0__=C2256AE40016B1928f9e8a93df938690918cC2256AE40016B192 Content-type: text/plain; name="Changes-Data-ACK.txt" Content-Transfer-Encoding: base64 Q2hhbmdlcyBmb3IgRGF0YSBBQ0sNCl9fX19fX19fX19fX19fX19fX19fX18NCg0KVGhlIFNDU0kg RGF0YS1pbiBQRFUgZm9yIFJFQUQgb3BlcmF0aW9ucyBoYXMgdGhlIGZvbGxvd2luZyBmb3JtYXQ6 DQoNCg0KVGhlIFNDU0kgRGF0YS1pbiBQRFUgZm9yIFJFQUQgb3BlcmF0aW9ucyBoYXMgdGhlIGZv bGxvd2luZyBmb3JtYXQ6DQoNCg0KQnl0ZSAvICAgIDAgICAgICAgfCAgICAgICAxICAgICAgIHwg ICAgICAgMiAgICAgICB8ICAgICAgIDMgICAgICAgfA0KICAgLyAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfA0KICB8NyA2IDUgNCAz IDIgMSAwfDcgNiA1IDQgMyAyIDEgMHw3IDYgNSA0IDMgMiAxIDB8NyA2IDUgNCAzIDIgMSAwfA0K ICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tKw0KIDB8MXwxfCAweDI1ICAgICAgfEZ8QXwwIDAgMHxPfFV8U3wgUmVzZXJ2ZWQg ICAgICB8U3RhdHVzIG9yIFJzdmQgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KIDR8IFJlc2VydmVkICAgICAgfCBE YXRhU2VnbWVudExlbmd0aCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t Kw0KIDh8IFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKw0KMTJ8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMTZ8IElu aXRpYXRvciBUYXNrIFRhZyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tKw0KMjB8IFJlc2lkdWFsIENvdW50ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMjR8IFN0YXRTTiBvciBS ZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAr LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tKw0KMjh8IEV4cENtZFNOICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KMzJ8IE1heENtZFNOICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K MzZ8IERhdGFTTiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KNDB8IEJ1ZmZlciBPZmZzZXQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KNDR8IFJlc2Vy dmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tKw0KNDh8IEhlYWRlciBEaWdlc3QgKGlmIGFueSkgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KICAvIERhdGFTZWdtZW50IChh bmQgZGlnZXN0IGlmIGFueSkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLw0KICsvICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLw0KICArLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLS0tKw0KDQoNClN0YXR1cyBjYW4gYWNjb21wYW55IHRoZSBsYXN0IERhdGEt aW4gUERVIGlmIHRoZSBjb21tYW5kIGRpZCBub3QgZW5kIHdpdGggYW4gZXhjZXB0aW9uLiAgUHJl c2VuY2Ugb2Ygc3RhdHVzIChhbmQgb2YgYSByZXNpZHVhbCBjb3VudCkgaXMgc2lnbmFsZWQgdGhv dWdoIHRoZSBTIGZsYWcgYml0LiAgQWx0aG91Z2ggdGFyZ2V0cyBNQVkgY2hvb3NlIHRvIHNlbmQg ZXZlbiBub24tZXhjZXB0aW9uIHN0YXR1cyBpbiBzZXBhcmF0ZSByZXNwb25zZXMgaW5pdGlhdG9y cyBNVVNUIHN1cHBvcnQgbm9uLWV4Y2VwdGlvbiBzdGF0dXMgaW4gRGF0YS1JbiBQRFVzLg0KDQoz LjcuMSBGIChGaW5hbCkgQml0DQoNCkZvciBvdXRnb2luZyBkYXRhLCB0aGlzIGJpdCBpcyAxIGZv ciB0aGUgbGFzdCBQRFUgb2YgdW5zb2xpY2l0ZWQgZGF0YSBvciB0aGUgbGFzdCBQRFUgb2YgYSBz ZXF1ZW5jZSBhbnN3ZXJpbmcgYW4gUjJULg0KDQpGb3IgaW5jb21pbmcgZGF0YSwgdGhpcyBiaXQg aXMgMSBmb3IgdGhlIGxhc3QgaW5wdXQgKHJlYWQpIGRhdGEgUERVIG9mIGEgc2VxdWVuY2UuICBJ bnB1dCBjYW4gYmUgc3BsaXQgaW4gc2V2ZXJhbCBzZXF1ZW5jZXMgZWFjaCBvbmUgaGF2aW5nIGl0 J3Mgb3duIEYgYml0LiBTcGxpdHRpbmcgdGhlIGRhdGEgc3RyZWFtIGluIHNlcXVlbmNlcyBkb2Vz IG5vdCBhZmZlY3QgRGF0YVNOIGNvdW50aW5nIG9uIERhdGEtSW4gUERVcy4gSXQgTUFZIGJlIHVz ZWQgYXMgYSAiY2hhbmdlIGRpcmVjdGlvbiIgaW5kaWNhdGlvbiBmb3IgQmlkaXJlY3Rpb25hbCBv cGVyYXRpb25zIHRoYXQgbmVlZCBzdWNoIGEgY2hhbmdlLiAgQSB0YXJnZXQgdGhhdCBpbXBsZW1l bnRzIEVycm9yUmVjb3ZlcnlMZXZlbCAxIG9yIGhpZ2hlciBNVVNUIHVzZSB0aGUgRiBiaXQgdG8g aW5kaWNhdGUgdGhlIGVuZC1vZi1zZXF1ZW5jZSBvZiBEYXRhLUluIFBEVXMgaXMgaXQgaXMgZ29p bmcgdG8gZGlzY2FyZC4NCg0KRm9yIEJpZGlyZWN0aW9uYWwgb3BlcmF0aW9ucywgdGhlIEYgYml0 IGlzIDEgYm90aCBmb3IgdGhlIGVuZCBvZiB0aGUgaW5wdXQgc2VxdWVuY2VzIGFzIHdlbGwgYXMg dGhlIGVuZCBvZiB0aGUgb3V0cHV0IHNlcXVlbmNlcy4gDQoNCjMuNy4yIEEgKEFja25vd2xlZGdl KSBiaXQNCg0KRm9yIHNlc3Npb25zIHdpdGggRXJyb3JSZWNvdmVyeUxldmVsIDEgb3IgaGlnaGVy IHRoZSB0YXJnZXQgc2V0cyB0aGlzIGJpdCB0byAxIHRvIGluZGljYXRlIHRoYXQgaXQgcmVxdWVz dHMgZnJvbSB0aGUgaW5pdGlhdG9yIGEgcG9zaXRpdmUgYWNrbm93bGVkZ2VtZW50IGZvciB0aGUg ZGF0YSByZWNlaXZlZC4gIFRoZSB0YXJnZXQgTUFZIHNldCB0aGUgQS1iaXQgdG8gMSBvbmNlIGF0 IG1vc3QgZXZlcnkgTWF4QnVyc3RTaXplIGJ5dGVzLCBhbmQgTVVTVCBOT1QgZG8gc28gYW55IG1v cmUgZnJlcXVlbnRseSB0aGFuIHRoYXQuDQoNCk9uIHJlY2VpdmluZyBhIERhdGEtSW4gUERVIHdp dGggdGhlIEEgYml0IHNldCB0byAxIHRoZSBpbml0aWF0b3IgTVVTVCBpc3N1ZWQgYSBTTkFDSyBv ZiB0eXBlIERhdGFBQ0suICBJZiB0aGUgaW5pdGlhdG9yIGhhcyBkZXRlY3RlZCBob2xlcyBpbiB0 aGUgaW5wdXQgc2VxdWVuY2UsIGl0IE1BWSBwb3N0cG9uZSBpc3N1aW5nIHRoZSBTTkFDSyBvZiB0 eXBlIEFDS04gdW50aWwgdGhlIGhvbGVzIGFyZSBmaWxsZWQuDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCjMuMTYgIFNOQUNLIFJlcXVlc3QNCg0KDQpCeXRlIC8gICAgMCAg ICAgICB8ICAgICAgIDEgICAgICAgfCAgICAgICAyICAgICAgIHwgICAgICAgMyAgICAgICB8DQog ICAvICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICB8DQogIHw3IDYgNSA0IDMgMiAxIDB8NyA2IDUgNCAzIDIgMSAwfDcgNiA1IDQgMyAy IDEgMHw3IDYgNSA0IDMgMiAxIDB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQogMHwwfDF8IDB4MTAgICAgICB8MXxS c3J2ZHwgVHlwZSAgfCBSZXNlcnZlZCAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0t LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0r DQogNC8gUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAvDQogKy8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAvDQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoxNnwgSW5pdGlhdG9yIFRhc2sg VGFnIG9yIDB4ZmZmZmZmZmYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0rDQoyMHwgQmVnUnVuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoyNHwgUnVuTGVuZ3RoICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQoyOHwg RXhwU3RhdFNOICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0rDQozMnwgUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICstLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQozNnwgRXhwRGF0YVNO IG9yIFJlc2VydmVkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQog ICstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0rDQozMi8gUmVzZXJ2ZWQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAvDQogKy8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAvDQogICstLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQo0OA0KDQpTdXBw b3J0IGZvciBTTkFDSyBpcyBvcHRpb25hbC4NCg0KU05BQ0sgcmVxdWVzdCBpcyB1c2VkIHRvIHJl cXVlc3QgcmV0cmFuc21pc3Npb24gb2YgbnVtYmVyZWQtcmVzcG9uc2VzLCBkYXRhIG9yIFIyVCBQ RFVzIGZyb20gdGhlIHRhcmdldC4gIFRoZSBTTkFDSyByZXF1ZXN0IGluZGljYXRlcyB0byB0aGUg dGFyZ2V0IHRoZSBtaXNzZWQgbnVtYmVyZWQtcmVzcG9uc2Ugb3IgZGF0YSBydW4sIHdoZXJlIHRo ZSBydW4gaXMgY29tcG9zZWQgb2YgYW4gaW5pdGlhbCBtaXNzZWQgU3RhdFNOLCBEYXRhU04gb3Ig UjJUU04gYW5kIHRoZSBudW1iZXIgb2YgYWRkaXRpb25hbCBtaXNzZWQgU3RhdHVzLCBEYXRhIG9y IFIyVCBQRFVzICgwIG1lYW5zIG9ubHkgdGhlIGluaXRpYWwpLg0KDQpUaGUgbnVtYmVyZWQtcmVz cG9uc2Ugb3IgUjJUIHJlcXVlc3RlZCBieSBhIFNOQUNLIGhhdmUgdG8gYmUgZGVsaXZlcmVkIGFz IGV4YWN0IHJlcGxpY2FzIG9mIHRoZSBvbmVzIHRoZSBpbml0aWF0b3IgbWlzc2VkIGluY2x1ZGlu ZyBhbGwgaXRzIGZsYWdzLiANCg0KVGhlIG51bWJlcmVkIERhdGEtSW4gUERVcyBpbmRpdmlkdWFs bHkgcmVxdWVzdGVkIGJ5IGEgU05BQ0sgaGF2ZSB0byBiZSBkZWxpdmVyZWQgYXMgZXhhY3QgcmVw bGljYXMgb2YgdGhlIG9uZXMgdGhlIGluaXRpYXRvciBtaXNzZWQgaW5jbHVkaW5nIGFsbCBpdHMg ZmxhZ3MuICBEYXRhLUluIFBEVXMgcmVxdWVzdGVkIHdpdGggUnVuTGVuZ3RoIDAgKG1lYW5pbmcg YWxsIGFmdGVyIHRoaXMgbnVtYmVyKSBtYXkgYmUgZGlmZmVyZW50IGZyb20gdGhlIG9uZXMgb3Jp Z2luYWxseSBzZW50IGluIG9yZGVyIHRvIHJlZmxlY3QgY2hhbmdlcyBpbiBNYXhSZWN2UERVTGVu Z3RoLiANCg0KQW55IFNOQUNLIHJlcXVlc3RpbmcgYSBudW1iZXJlZC1yZXNwb25zZSwgRGF0YSBv ciBSMlQgdGhhdCB3YXMgbm90IHNlbnQgYnkgdGhlIHRhcmdldCBNVVNUIGJlIHJlamVjdGVkIHdp dGggYSByZWFzb24gY29kZSBvZiAiSW52YWxpZCBTTkFDSyIuDQoNCg0KMy4xNi4xIFR5cGUNCg0K VGhpcyBmaWVsZCBlbmNvZGVzIHRoZSBTTkFDSyBmdW5jdGlvbiBhcyBmb2xsb3dzOg0KDQowLURh dGEvUjJUIFNOQUNLIC0gcmVxdWVzdGluZyByZXRyYW5zbWlzc2lvbiBvZiBhIERhdGEtSW4gb3Ig UjJUIFBEVQ0KMS1TdGF0dXMgU05BQ0sgLSByZXF1ZXN0aW5nIHJldHJhbnNtaXNzaW9uIG9mIGEg bnVtYmVyZWQgcmVzcG9uc2UNCjItRGF0YUFDSyAtIHBvc2l0aXZlbHkgYWNrbm93bGVkZ2VzIERh dGEtSW4gUERVcyANCg0KQWxsIG90aGVyIHZhbHVlcyBhcmUgcmVzZXJ2ZWQuDQoNCkRhdGEvUjJU IFNOQUNLIGZvciBhIGNvbW1hbmQgTVVTVCBwcmVjZWRlIHN0YXR1cyBhY2tub3dsZWRnZW1lbnQg Zm9yIHRoZSBnaXZlbiBjb21tYW5kLg0KDQpGb3IgYSBEYXRhL1IyVCBTTkFDSyB0aGUgSW5pdGlh dG9yIFRhc2sgVGFnIE1VU1QgYmUgc2V0IHRvIHRoZSBJbml0aWF0b3IgVGFzayBUYWcgb2YgdGhl IHJlZmVyZW5jZWQgQ29tbWFuZC4gT3RoZXJ3aXNlLCBpdCBpcyByZXNlcnZlZC4NCg0KRm9yIGEg U3RhdHVzIFNOQUNLIHRoZSBFeHBEYXRhU04gZmllbGQgaXMgcmVzZXJ2ZWQuDQoNCkFuIGlTQ1NJ IHRhcmdldCB0aGF0IGRvZXMgbm90IHN1cHBvcnQgcmVjb3Zlcnkgd2l0aGluIGNvbm5lY3Rpb24g TUFZIGRpc2NhcmQgc3RhdHVzIFNOQUNLLiBJZiB0aGUgdGFyZ2V0IHN1cHBvcnRzIGNvbW1hbmQg cmVjb3Zlcnkgd2l0aGluIHNlc3Npb24gaXQgTUFZIGRpc2NhcmQgdGhlIFNOQUNLIGFmdGVyIHdo aWNoIGl0IE1VU1QgaXNzdWUgYW4gQXN5bmNocm9ub3VzIE1lc3NhZ2UgUERVIHdpdGggYW4gaVND U0kgZXZlbnQgaW5kaWNhdGluZyAiUmVxdWVzdCBMb2dvdXQiLg0KDQpJZiBhbiBpbml0aWF0b3Ig b3BlcmF0ZXMgYXQgRXJyb3JSZWNvdmVyeUxldmVsIDEgb3IgaGlnaGVyIGl0IE1VU1QgaXNzdWUg YSBTTkFDSyBvZiB0eXBlIERhdGFBQ0sgYWZ0ZXIgcmVjZWl2aW5nIGEgRGF0YS1JbiBQRFUgd2l0 aCB0aGUgQSBiaXQgc2V0IHRvIDEuICBIb3dldmVyIGlmIHRoZSBpbml0aWF0b3IgaGFzIGRldGVj dGVkIGhvbGVzIGluIHRoZSBpbnB1dCBzZXF1ZW5jZSwgaXQgTUFZIHBvc3Rwb25lIGlzc3Vpbmcg dGhlIFNOQUNLIG9mIHR5cGUgRGF0YUFDSyB1bnRpbCB0aGUgaG9sZXMgYXJlIGZpbGxlZC4gVGhl IERhdGFBQ0sgaXMgdXNlZCB0byBmcmVlIHJlc291cmNlcyBhdCB0YXJnZXQgYW5kIG5vdCB0byBy ZXF1ZXN0IG9yIGltcGx5IGRhdGEgcmV0cmFuc21pc3Npb24uDQoNCg0K --0__=C2256AE40016B1928f9e8a93df938690918cC2256AE40016B192-- From owner-ips@ece.cmu.edu Sat Oct 13 08:03: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 IAA03098 for ; Sat, 13 Oct 2001 08:03:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9DBNe121100 for ips-outgoing; Sat, 13 Oct 2001 07:23:40 -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 f9DBNcl21096 for ; Sat, 13 Oct 2001 07:23:38 -0400 (EDT) Received: from london ([10.95.10.3]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id EAA12840; Sat, 13 Oct 2001 04:23:11 -0700 (PDT) From: "Rod Harrison" To: , , Subject: RE: iSCSI: ISID issue summary Date: Sat, 13 Oct 2001 12:25:48 +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) In-Reply-To: <277DD60FB639D511AC0400B0D068B71ECAD891@CORPMX14> 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 the 'statically configure the ISIDs along with the iSCSI name and write the "conservative reuse" rule into the iSCSI protocol specification' approach. One thing I would like to see happen here is to allow iSCSI HBAs to be used with existing SCSI drivers. Many vendors have well tested drivers in the field, and it is currently a relatively easy job to make an iSCSI HBA look like an existing SCSI HBA. Doing so is a time to market win and should also slightly ease customers new technology fears. There is a clear advantage to being able to tell customers that they can fit an iSCSI HBA into systems alongside their existing SCSI HBAs and have them "just work" after some initial configuration. Setting ISID ranges can easily be done as part of this initial configuration, as can setting the iSCSI name, IP address, DHCP use, or whatever else an iSCSI HBA needs to know. I'm not against having to have some coordinating entity on the host as long as that is optional, and preferably only needed for more complex installations. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Black_David@emc.com Sent: Saturday, October 13, 2001 2:49 AM To: Robert.Elliott@compaq.com; ips@ece.cmu.edu Subject: RE: iSCSI: ISID issue summary Rob, > As Nick noted, the problem is where do you store these ISIDs? > For that matter, where do you store the iSCSI name? [..snip..] > With iSCSI you have no guarantee of hardware. Software-based implementations will have access to a file or registry or something like that. Boot involves BIOS nonsense and pain of varying forms and has access to BIOS parameter store (may be battery-backed RAM rather than flash) if needed. Booting over a software implementation can be very difficult - in essence, the iSCSI software gets added to the main system BIOS (not something to be done lightly, especially as there are existing protocols that can retrieve a boot image over IP). > For the SCSI RDMA Protocol for InfiniBand, we chose: > initiator port name = 64-bit worldwide identifier from > the InfiniBand channel adapter plus > 64 extra bits > All software using the same InfiniBand channel adapter have to > coordinate usage of the extra bits, but single-OS single-driver > systems can just fill them with zeros. But SRP only needs to coordinate within "the same InfiniBand channel adapter". iSCSI currently requires the ISID to be coordinated across adapters/network interfaces. That's an important difference. > Persistent reservations, access controls, extended copy, > third-party XOR commands, and the supporting alias commands > are all potential users of port names today. Protocol bridges > and management tools may also benefit from using names > rather than addresses. I'll take that as a strong hint from the T10 direction that this set of issues cannot be deferred (matching Jim's comments). > Are the iSCSI name and ISID used as part of authentication? > How does a device driver prove it has the right to use > a certain iSCSI name/ISID? How does it prevent some other > software from using its own iSCSI name/ISID? Only the iSCSI name is used, and iSCSI inband authentication (which requires state on the target) is used to deal with both of the latter questions. > If we didn't have ISIDs we'd still have the same debate about > managing the iSCSI names. Two software implementations > on the same machine could choose the same iSCSI name and > conflict - the same problems result. Actually, the iSCSI name has to be statically configured - it's somewhat akin to an IP address in that using the same one twice on two different independent systems will have unintended (and potentially unpleasant) results. Picking the name dynamically is not anticipated because that name is expected to show up in the configuration of LUN masking/ mapping access controls on the Targets. > Jim's partitioning lets the OS pick an iSCSI name (unique > from any other OS on the fabric, with any luck) and requires > the OS coordinate ISIDs for any iSCSI drivers sharing > that iSCSI name. A dedicated iSCSI HBA could also hand > out ISIDs for drivers using it. With the exception of having "the OS pick an iSCSI name", that's correct. The problem is one system with two HBAs that don't know about each other. Also, unlike InfiniBand, one can expect an iSCSI HBA to have a dedicated driver. > This should limit the > scope of conflicts to one system rather than the whole > fabric. It'd be helpful to have standards for the OS > or HBAs to solve this, but that seems outside the scope > of the iSCSI protocol spec. A solution that works here is to statically configure the ISIDs along with the iSCSI name and write the "conservative reuse" rule into the iSCSI protocol specification. Thanks, --David > -----Original Message----- > From: Elliott, Robert [mailto:Robert.Elliott@compaq.com] > Sent: Wednesday, October 10, 2001 8:19 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: ISID issue summary > > > David Black wrote: > > > SCSI architecture (SAM2) is based on an intuition that SCSI > > ports are fixed (e.g., physical) things that have names. So > > far, the existence of the names has been an intellectual > > curiosity as they haven't mattered to any visible SCSI > > functionality. > > Not quite true. The Fibre Channel port's Worldwide_Name - > what SAM-2 now calls the initiator port name - is used > today for persistent reservations. SPC-2 has this wording: > > For those SCSI protocols for which the initiator port's > world wide identification is available to the device > server the initiator port's world wide identification > shall be used to determine if the initiator identifier > has changed. > > FCP-2 indicates that the Worldwide_Name of the Fibre Channel > port serves as the "initiator port's world wide > identification." (that phrase will change to "initiator > port name" as Jim's (accepted) T10 name proposal is > digested.) > > > Single port Initiators predominate in > > both Parallel SCSI and Fibre Channel (e.g., a dual ported > > Fibre Channel HBA is usually treated as two SCSI Initiators, > > not a single dual-ported one). > > According to the SAM-2 multiport model, you can upgrade that > "usually" to "always." The key to the multiport model is: > > Initiator = initator port > Target = target port > > In FCP-2, initiator ports equal Fibre Channel ports. There's > no way to treat two physical ports as the same initiator > without violating the standards. > > The multiport model defines "initiator device" as the object > that contains multiple initiator ports. The initiator device > has neither an address nor a name in any existing protocol. > There are no commands that rely on it. Jim wanted to start > using that concept for iSCSI access controls. > > > Jim tells us that T10 is about to define persistent reserve > > functionality that depends on the identity of the SCSI Initiator > > Port - in particular that under some circumstances, persistent > > reservations will be associated with the Initiator Port independent > > of the Target Port. Persistent reservations are currently bound > > to the Initiator Port and Target Port (as well as the LU they > > affect). For the rest of this message, I'm going to assume > > Again, the reason for this is the multiport model that says > initiator = initiator port and target = target port. > > > that we want to support this functionality. Assuming this and > > that I got the description in this paragraph right ... > > > > ... I need to take a slight detour into pragmatics. Those > > who configure storage networks rapidly discover the value > > of consistency and matching configurations. Multi-path I/O > > configurations tend to want to see access to the same set of LUs > > consistently across a set of interfaces (i.e., Ports). Between > > suitable configuration and the aggressive setup of connections > > to all possible targets, all the required connections come into > > existence as part of the boot process. Applying > > this experience to the new persistent reservation functionality, > > one would expect persistent reservations that are bound only to > > an Initiator Port to be independent of the Target Port, in that > > the reservation should span connections to all of the relevant > > Target Ports and those connections should come into existence > > as part of the boot process. > > That's the goal of one of the T10 proposals. If initiators > are identified only by their port addresses, it's not safe. > The two target ports could be on different fabrics, where > initiators are different but happen to have the same > addresses. On a fabric where the initiator port has a name > that is known to be worldwide unique, this becomes a > non-issue if the initiator port name is used instead of the > initiator port address. > > > Turning to iSCSI, the situation gets complicated by the > > interaction of two factors: > > - Parallel sessions are permitted down to the interface > > level (e.g., more than one iSCSI session may exist > > that uses IP addresses A and B to connect iSCSI Initiator > > I to iSCSI Target T). > > - SCSI disallows parallel nexii (i.e., more than one session > > between the same two SCSI Ports). > > If SCSI Ports are mapped to hardware entities such as network > > interfaces in iSCSI, the opportunity for parallel sessions > > between the same pair of network interfaces vanishes. In order > > to avoid that outcome, iSCSI Initiator Ports have to be > > mapped to software entities. To date, the ISID has been > > used to identify those software entities, and the only rule > > on their allocation is: > > > > ISID RULE: Between a given iSCSI Initiator and iSCSI > > Target Portal Group (SCSI target port), then can be only > > one session with a given ISID (identifying a SCSI > > initiator port). See 3.12.8. > > There's a bit more than that. The "iSCSI Name" has to > be included with the ISID to identify the initiator port. > Jim wanted the iSCSI name to be the "initiator device name." > > > In order to get the expected outcome of the new functionality > > being defined by T10, the same ISID has to be used to establish > > all the connections that the persistent reservation is supposed > > to span. Unfortunately, that's above and beyond what iSCSI > > requires - the relevant text about doing this in -08 is: > > > > The "ISID rule" does not preclude > > the use of the same ISID from the same iSCSI Initiator with > > different Target Portal Groups on the same iSCSI target or > > on other iSCSI targets > > > > "does not preclude" is rather weak language for something that's > > essential to making a piece of SCSI functionality work. If an > > iSCSI implementation uses a different ISID for every session > > (which is also not precluded by the current text), then persistent > > reservations will never span Targets or Target Ports for that > > implementation despite T10's best efforts and intentions. IMHO, > > allowing that outcome is *wrong* (and this is the source of the > > difference of opinion between Jim and myself). > > > > The correction to this involves what Jim has called "conservative > > reuse" of ISIDs. This is something like for each ISID that an > > implementation uses, a connection with that ISID is made to > > every possible Target Portal Group of every possible Target. I > > suspect a longer explanation than this will be needed, including > > a discussion of the desirability of avoiding a situation in which > > the same ISID is used by two iSCSI implementations that are part > > of the same Initiator and set up sessions concurrently. > > > > IMHO, if we want to support persistent reservations at this stage > > that span target ports, we need to replace the "does not preclude" > > language with a REQUIREMENT for conservative reuse to avoid a > > situation in which SCSI functionality that works consistently with > > other transports works inconsistently with iSCSI (i.e., doesn't > > work with iSCSI implementations that don't do conservative reuse). > > As Nick noted, the problem is where do you store these ISIDs? > For that matter, where do you store the iSCSI name? With > Fibre Channel, the Worldwide_name is in a ROM associated with > the port. With iSCSI you have no guarantee of hardware. You > can usually find an Ethernet MAC address and could base a > name off of that. However, there's no guarantees. > > For the SCSI RDMA Protocol for InfiniBand, we chose: > initiator port name = 64-bit worldwide identifier from > the InfiniBand channel adapter plus > 64 extra bits > All software using the same InfiniBand channel adapter have to > coordinate usage of the extra bits, but single-OS single-driver > systems can just fill them with zeros. > > > Stepping back from the assumption that support for port-spanning > > persistent reservations is required, I observe that the conservative > > reuse rule impacts all implementations, even those that will never > > use such persistent reservations because ISID is a mandatory part > > of the iSCSI protocol. > > Persistent reservations, access controls, extended copy, > third-party XOR commands, and the supporting alias commands > are all potential users of port names today. Protocol bridges > and management tools may also benefit from using names > rather than addresses. > > > If a text key were used instead, only those > > Initiators that want to support this functionality on which T10 > > is "crossing a few t's and dotting a few i's" are affected (the > > text key is optional). The text key would be subject to a > > conservative reuse rule similar to the one that would be needed > > for ISIDs, and once T10 finishes the i's and t's, we can precisely > > reference the SCSI features (persistent reservation expansion) > > that require use of this text key. > > > > In addition, text keys have much better alternatives for dealing > > with conflicts than ISIDs - if a text key conflicts, it is possible > > to continue the negotiation with a different text key, whereas > > ISID conflict is fatal to one of the two sessions involved. > > As Jim has previously observed, changing the text key (e.g., > > generate a large random number in response to a conflict), > > results in a situation that can be dealt with by software that > > uses persistent reservations, although this departure from > > conservative reuse should only occur as a consequence of some > > sort of configuration mistake or bug. At the tail end of this > > reasoning chain is the observation that use of this text key > > leaves the ISID without value/purpose, and hence would call > > for its removal (or perhaps designation as a reserved field). > > This just seems to make the names more vague and volatile. > > Are the iSCSI name and ISID used as part of authentication? > How does a device driver prove it has the right to use > a certain iSCSI name/ISID? How does it prevent some other > software from using its own iSCSI name/ISID? > > > Putting on my WG chair hat for a moment, I can accept either > > alternative outlined above: > > - Add conservative reuse to the ISID rule. > > - Use a text key for iSCSI port identification. > > But I'm not comfortable with the current situation in which iSCSI > > implementations are permitted to break T10-defined SCSI features > > that will work as expected in other SCSI transports. > > > > I hope this now makes sense to more people than just Jim and I, > > and I apologize for the length of this message, as this is a > > somewhat subtle issue. > > > > Comments? > > If we didn't have ISIDs we'd still have the same debate about > managing the iSCSI names. Two software implementations > on the same machine could choose the same iSCSI name and > conflict - the same problems result. > > Jim's partitioning lets the OS pick an iSCSI name (unique > from any other OS on the fabric, with any luck) and requires > the OS coordinate ISIDs for any iSCSI drivers sharing > that iSCSI name. A dedicated iSCSI HBA could also hand > out ISIDs for drivers using it. This should limit the > scope of conflicts to one system rather than the whole > fabric. It'd be helpful to have standards for the OS > or HBAs to solve this, but that seems outside the scope > of the iSCSI protocol spec. > > > --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 > > --------------------------------------------------- > > > --- > Rob Elliott, Compaq Server Storage > Robert.Elliott@compaq.com > From owner-ips@ece.cmu.edu Sat Oct 13 17:07: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 RAA06593 for ; Sat, 13 Oct 2001 17:07:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9DKA4B15323 for ips-outgoing; Sat, 13 Oct 2001 16:10: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 f9DK9rl15307; Sat, 13 Oct 2001 16:09:53 -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 WAA04118; Sat, 13 Oct 2001 22:09: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 f9DK9JY171550; Sat, 13 Oct 2001 22:09:20 +0200 To: "John Hufferd" Cc: "'Binford, Charles'" , ips@ece.cmu.edu, "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , owner-ips@ece.cmu.edu, Robert Snively , "'somesh_gupta@silverbacksystems.com'" MIME-Version: 1.0 Subject: RE: Addition of CmdSN in Data-out PDU X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 13 Oct 2001 23:09:14 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 13/10/2001 23:09:32, Serialize complete at 13/10/2001 23:09:32 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, The reason for the rule is limiting restrictions to what is logically mandated and leaving all the rest to the implementer. The ordering rule is there to help avoid the trivial deadlock where commands start asking for solicited data and the windows is closed by unsolicited data and having to resort to dropping data to reopen the TCP window. Having data immediately follow the command is admisible but some implementer might choose to have and launch as many commands as possible to get the data transfer overlap with positioning operations. The targets are supposed to consider out of order delivery of data a protocol error. Regards, Julo John Hufferd/San Jose/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 13-10-01 02:01 Please respond to John Hufferd To: Robert Snively cc: "'somesh_gupta@silverbacksystems.com'" , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Binford, Charles'" , ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Robert, I think that an Initiator being able to send a waiting Read command, without having to wait for many large write segments -- that are being sent (as unsolicited data) -- is very useful. And that would mean, the unsolicited data is waiting to be sent until the Read Commands are sent. This might be a very frequent case. . . . 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 10/12/2001 03:56:06 PM Sent by: owner-ips@ece.cmu.edu To: "'somesh_gupta@silverbacksystems.com'" , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Binford, Charles'" , ips@ece.cmu.edu cc: Subject: RE: Addition of CmdSN in Data-out PDU I have two small questions that would help me understand this. How do you know that unsolicited data is expected? By nature, unsolicited data is received as a "maximum surprise" which can only be determined after unpacking and parsing at least a part of the command structure, possibly even including the SCSI command (although there are some hints contained in the command header information). How can you constrain a generic system to posting the unsolicited data in the same order that the commands were emitted? In general, I would have expected the system to be emitting command followed immediately by the corresponding unsolicited data. If that is not the case, it means that there was a delay in obtaining the unsolicited data for transfer and that the delay was sufficient to allow the insertion of commands. If the delay is that large (and probably variable), the enforcement of transfer of unsolicited data in the same order as the commands are emitted seems to me to be a significant challenge, and certainly shouldn't be required as normal behavior. While it would make things simpler for targets (already challenged by unsolicited data), it seems to me that it would make things much more complex for initiators. Bob > -----Original Message----- > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > Sent: Friday, October 12, 2001 2:51 PM > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > Matthew, > > Since the unsolicited data does not follow the > command, you need the link list. But since the > unsolicited data must be sent in the same order > as the commands, a link list is enough. > > Let us say that you have 8 commands. The ones > for which we expect unsolicted data are marked > as Cnn(ud). And I have marked the unsolicted > data PDUs as UD(nn). The (nn) with data implies > that it is implicit and not actually carried with > the PDU itself. > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > --> UD(07) C08(ud) UD(08) ---> > > After the target receives the command C01, C02, and C03 > for which it expects unsolicited data, it puts them in > a link list. It also receives C04 and C05 for which > unsolicited data is not expected and they don't go > on the list. It then receives C06 for which unsolicited > data is expected, and it is added to then end of the list. > Then an unsolicited data PDU is received. It must go > with the command at the head of the list which is C01. > Use the ITT to make sure and you can then take C01 off > the list and so on. > > Somesh > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > Sent: Friday, October 12, 2001 7:53 AM > > To: 'Binford, Charles'; ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Charles, > > > > As you have described the spec states that "that > unsolicited data MUST be > > sent in the same order as the commands". This is not the same as > > unsolicited data must follow the command associated with > it: For example: > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > x in all the > > example can be the ITT. It is not the CmdSN. > > > > This is allowed: > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > and the target will have to use the ITT to associate the > data with the > > command. > > > > Matthew > > > > > > -----Original Message----- > > From: Binford, Charles [mailto:CBinford@pirus.com] > > Sent: Friday, October 12, 2001 2:50 PM > > To: ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > I have not verify version 8 is still the same, but version 07-97 > > had a rule > > that unsolicited data MUST be sent in the same order as the > commands. > > > > Thus, there is no need for a search on the ITT. The target > just needs to > > keep of linked list of I/Os waiting on unsolicited data. > New commands are > > added to the tail, any unsolicited data *should* be associated > > with the I/O > > at the head of the list. The ITT is used as a sanity check and > > you're done. > > > > What am I missing? > > > > Charles Binford > > Pirus Networks > > 316.315.0382 x222 From owner-ips@ece.cmu.edu Sat Oct 13 20:46: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 UAA07636 for ; Sat, 13 Oct 2001 20:46:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9DNK5124740 for ips-outgoing; Sat, 13 Oct 2001 19:20: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 f9DNK2l24736 for ; Sat, 13 Oct 2001 19:20:02 -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 BAA04162 for ; Sun, 14 Oct 2001 01:19: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 f9DNJtW287046 for ; Sun, 14 Oct 2001 01:19:55 +0200 Subject: Re: [Fwd: iSCSI - revised 2.2.4] To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 14 Oct 2001 02:17:38 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 14/10/2001 02:19:55 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, The reason I am hesitant on accepting this change proposal as is that it might makes the negotiation very much state dependent and different for keys that have a default and keys that don't have one. In addition it may change login behavior for different versions of the protocol that may have different defaults. I admit that it has appeal for the login (where the defaults are relevant) by shortening some negotiations. However the issues it raises are multiple. Assume that you have the following sequence: I->T key1=x T->I key1=z,key2=a I->T key2=b .... Observe that the initiator designer was very conservative and probably intended to negotiate the keys one at a time while the target is aggressive and wants to set everything as soon as possible. With the defaults rule the results are harder to define. With the rules we have now the results are hardly dependent on sequence. Add to this that with the new rules about PDULength exchanges are hardly "self contained" - i.e. key=value pairs can span sequences (that was another reasons I did not like this but framing at high speeds has precedence!). However we might perhaps want to consider the following loose rule for defaults in the context of operational parameter negotiation at login only (leaving the negotiation rules as they are): If the initiator issues a login request with the F bit set to 1 is assumed to have an imaginary content including all the operational keys that have a default value and where not sent yet by the initiator during login and their values set to the default value. Comments? Julo PS - and a procedural thing - nagging me repeatedly on a subject is annoying and quoting the number of agreements before attempting different scenarios is even more so Santosh Rao hp.com> cc: Sent by: Subject: [Fwd: iSCSI - revised 2.2.4] owner-ips@ece. cmu.edu 11-10-01 01:36 Please respond to Santosh Rao Julian, What is the resolution on this issue ? - Santosh Santosh Rao wrote: > > Julian, > > I apologize upfront for being so persistent on this. > > However, it would really help if you could give some clear example of a > scenario as to why the initiator cannot be considered the originator of > a negotiation, when it offers a key value implicitly, through the use of > a default. > > Several people on this list (Paul Konning, Sanjeev, Deva, myself, and > perhaps others, that I cannot recall at the moment) have asked that the > spec must not differentiate login behaviour when the initiator offers a > key explicitly vs. when it offers a key implicitly thru the use of the > default. > > Please help us understand the need for iscsi to distingush the login > behaviour in the above case. [through some tangible scenarios and > examples]. > > Thanks, > Santosh > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > Julian, > > > > I would also request an explicit definition of offering party and > > responding party. The current text still leaves ambiguity when target > > sends a key in response to implicit default key of the Intiator. In > > this case who is the offering party and who is the responding party > > > > Sanjeev > > > > -----Original Message----- > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > Sent: Friday, October 05, 2001 2:06 PM > > To: ips@ece.cmu.edu > > Subject: iSCSI - revised 2.2.4 > > > > Here is a revised (complete) part 2.2.4 based on recent > > agreed changes: > > > > 1.1.1 Text Mode Negotiation > > > > During login and thereafter some session or connection > > parameters are negotiated through an exchange of textual > > information. > > > > All negotiations are stateless - i.e. the result MUST be > > based only on newly exchanged values. > > > > The general format of text negotiation is: > > > > Originator-> = > > Responder-> =|reject|NotUnderstood > > > > The value can be a number, a single literal constant a > > Boolean value (yes or no) or a list of comma separated > > literal constant values. > > > > In literal list negotiation, the originator sends for each > > key a list of options (literal constants which may include > > "none") in its order of preference. > > > > The responding party answers with the first value from the > > list it supports and is allowed to use for the specific > > originator. > > > > The constant "none" MUST always be used to indicate a > > missing function. However, none is a valid selection only if > > it is explicitly offered. > > > > If a target is not supporting, or not allowed to use with a > > specific originator, any of the offered options, it may use > > the constant "reject". The constants "none" and "reject" > > are reserved and must be used only as described here. Any > > key not understood is answered with "NotUnderstood". > > > > For numerical and single literal negotiations, the > > responding party MUST respond with the required key and the > > value it selects, based on the selection rule specific to > > the key, becomes the negotiation result. Selection of a > > value not admissible under the selection rules is considered > > a protocol error and handled accordingly. > > > > For Boolean negotiations (keys taking the values yes or no), > > the responding party MUST respond with the required key and > > the result of the negotiation when the received value does > > not determine that result by itself. The last value > > transmitted becomes the negotiation result. The rules for > > selecting the value to respond with are expressed as Boolean > > functions of the value received and the value that the > > responding party would select in the absence of knowledge of > > the received value. > > > > Specifically, the two cases in which responses are OPTIONAL > > are: > > > > - The Boolean function is "AND" and the value "no" is > > received. The outcome of the negotiation is "no". > > - The Boolean function is "OR" and the value "yes" is > > received. The outcome of the negotiation is "yes". > > > > Responses are REQUIRED in all other cases, and the value > > chosen and sent by the responder becomes the outcome of the > > negotiation. > > > > The value "?" with any key has the meaning of enquiry and > > should be answered with the current value or > > "NotUnderstood". > > > > 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, only the initiator can > > initiate the negotiation start (through the first Text > > request) and completion (by setting to 1 and keeping to 1 > > the F bit in a Text request). > > > > Comments ? > > > > Julo > > -- > ################################## > 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 Oct 13 23:39: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 XAA12000 for ; Sat, 13 Oct 2001 23:39:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9E2dNj04232 for ips-outgoing; Sat, 13 Oct 2001 22:39: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 f9E2dLl04226; Sat, 13 Oct 2001 22:39: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 EAA88694; Sun, 14 Oct 2001 04: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 f9E2cfW206016; Sun, 14 Oct 2001 04:38:41 +0200 To: "Eddy Quicksall" Cc: ips@ece.cmu.edu, "'BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)'" , owner-ips@ece.cmu.edu, "'Paul Koning'" , "'Sandeep Joshi'" MIME-Version: 1.0 Subject: RE: Addition of CmdSN in Data-out PDU X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sun, 14 Oct 2001 05:38:36 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 14/10/2001 05:38:56, Serialize complete at 14/10/2001 05:38:56 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, That was good advise and free. Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 11-10-01 18:12 Please respond to "Eddy Quicksall" To: "'Sandeep Joshi'" , "'BURBRIDGE,MATTHEW \(HP-UnitedKingdom,ex2\)'" cc: "'Paul Koning'" , Subject: RE: Addition of CmdSN in Data-out PDU You can't assume the ITT takes a specific order. Eddy -----Original Message----- From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com] Sent: Thursday, October 11, 2001 10:30 AM To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) Cc: 'Paul Koning'; ips@ece.cmu.edu Subject: Re: Addition of CmdSN in Data-out PDU If we use the fact that the ITT-ordering of the unsolicited Data-out PDUs is identical to the ITT-ordering of the commands sent *within* a connection, then it should be possible to resolve the Data-out PDUs in a constant-time operation[*1] No hash and no cmdSN is required keep a per-connection chain within the command queue and look at its head. [*1]There are a couple of exceptions, due to the leeway the standard provides the initiator on Data-out PDUs. -Sandeep "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" wrote: > > Since I started this thread I feel I must at least contribute! > > The reason why I proposed putting CmdSN (actually it should be RefCmdSN) in > the Data-out PDUs was to enable the target to have a faster search to > associate unsolicited data out PDUs with its SCSI Command PDU. Solicited > Data-out PDUs do not require this as they have a Target Task Tag. > > If all Command PDUs were queued then I believe this would work just fine. > However, as Santosh correctly pointed out they are not and without repeating > what he said this mechanism would not work for immediate command PDUs. > > I am sure that particular implementations could make this work but the > underlying argument is that it needs to work and be useful to all > implementations. The only benefit I now see of having CmdSN in the data PDU > is as a check as implementations must (and can only) use the initiator task > tag to associated the Data-out PDU with the command PDU. Therefore, IMO it > is not a good enough reason for having CmdSN in the Data-out PDUs simply for > a consistency check. > > The benefit of having the data sent unsolicited to minimise if not eradicate > round trip times far out weighs the overhead in having to perform a search > on receipt of unsolicited data. If we could have developed a well defined > mechanism to overcome this overhead then all well and good and that is what > I attempted. Still, if someone can do this and the solution is simple and > straight forward then I am sure that it will have my backing but until then > ... > > Cheers > > Matthew Burbridge > Senior Development Engineer > NIS-Bristol > Hewlett Packard > Telnet: 312 7010 > E-mail: matthewb@bri.hp.com > > > -----Original Message----- > From: Paul Koning [mailto:pkoning@jlc.net] > Sent: Wednesday, October 10, 2001 5:07 PM > To: Julian_Satran@il.ibm.com > Cc: ips@ece.cmu.edu > Subject: Re: Addition of CmdSN in Data-out PDU > > Excerpt of message (sent 10 October 2001) by Julian Satran: > > Inconsistency can be legitimate. CmdSN is ephemeral. It can be reused, it > > may have large holes and using it in an implementation is as bad as a > > hashed index. > > Not true. > > CmdSN values are sequential, by definition. Yes, clearly there will > be small holes because commands complete out of order. But "large" > holes are unlikely. > > In any case, the target has control over that. I can use an array > whose size is given by the number of pending commands times a > correction factor to account for the likely density of holes. Then > MaxCmdSN would be updated based on two considerations: the ability to > handle more pending commands, and the need to keep the distance > between oldest (lowest) still active CmdSN and MaxCmdSN bounded by the > size of the lookup array. > > So having CmdSN in the DataOut PDU allows this approach, thereby > replacing a hash lookup on a rapidly changing ID space by a simple > array indexing operation. Without CmdSN, you're forced to use a > mechanism that has a lot more overhead (in the insert/remove or in the > lookup, depending on the mechanism chosen). > > paul From owner-ips@ece.cmu.edu Sun Oct 14 20:02: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 UAA02308 for ; Sun, 14 Oct 2001 20:02:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9EMiRk12504 for ips-outgoing; Sun, 14 Oct 2001 18:44: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 f9EMiPl12499 for ; Sun, 14 Oct 2001 18:44: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 AAA174378 for ; Mon, 15 Oct 2001 00:44:18 +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 f9EMiH3291566 for ; Mon, 15 Oct 2001 00:44:17 +0200 Subject: RE: Addition of CmdSN in Data-out PDU To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 14 Oct 2001 23:29:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 15/10/2001 01:44:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Immediate data are not mandatory (even if enabled). Having one or ten DMAs does not change the fact that they share a TCP "pipe" and a decent transmitter will ship the TCP data in order - otherwise it just throws his problems in the receiver's lap. Our additional requirement on order should make no difference. And it would be time to change the name of the thread. Julo "Rod Harrison" Snively" Sent by: cc: , owner-ips@ece.cmu. "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" edu , "'Binford, Charles'" , Subject: RE: Addition of CmdSN in Data-out PDU 13-10-01 13:12 Please respond to "Rod Harrison" Even more common would be the DMA latency. As an initiator I would send the command PDU as soon as I could if there were no immediate data, then queue the DMA for the unsolicited data. Since there could be many other DMAs queued ahead of the unsolicited data it is quite possible that other commands, both read and write, will be sent before the DMA completes. You are spot one when you say the delay in obtaining the unsolicited data may be large and variable. If there are multiple DMA engines it does become a challenge for the initiator to ensure the correct ordering of the unsolicited data. Note that since there may be multiple unsolicited data PDUs in the same burst, and those may be filled with separate DMAs the ordering problem propagates down to within individual commands. I don't believe it is a particularly difficult problem for the initiator to solve, but I do agree things would be easier for the initiator if the ordering requirement were removed. And more so if the requirement to send in dataSN order were also removed, but this is probably too much pain for the target. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of John Hufferd Sent: Saturday, October 13, 2001 1:01 AM To: Robert Snively Cc: 'somesh_gupta@silverbacksystems.com'; BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Robert, I think that an Initiator being able to send a waiting Read command, without having to wait for many large write segments -- that are being sent (as unsolicited data) -- is very useful. And that would mean, the unsolicited data is waiting to be sent until the Read Commands are sent. This might be a very frequent case. . . . 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 10/12/2001 03:56:06 PM Sent by: owner-ips@ece.cmu.edu To: "'somesh_gupta@silverbacksystems.com'" , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Binford, Charles'" , ips@ece.cmu.edu cc: Subject: RE: Addition of CmdSN in Data-out PDU I have two small questions that would help me understand this. How do you know that unsolicited data is expected? By nature, unsolicited data is received as a "maximum surprise" which can only be determined after unpacking and parsing at least a part of the command structure, possibly even including the SCSI command (although there are some hints contained in the command header information). How can you constrain a generic system to posting the unsolicited data in the same order that the commands were emitted? In general, I would have expected the system to be emitting command followed immediately by the corresponding unsolicited data. If that is not the case, it means that there was a delay in obtaining the unsolicited data for transfer and that the delay was sufficient to allow the insertion of commands. If the delay is that large (and probably variable), the enforcement of transfer of unsolicited data in the same order as the commands are emitted seems to me to be a significant challenge, and certainly shouldn't be required as normal behavior. While it would make things simpler for targets (already challenged by unsolicited data), it seems to me that it would make things much more complex for initiators. Bob > -----Original Message----- > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > Sent: Friday, October 12, 2001 2:51 PM > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > Matthew, > > Since the unsolicited data does not follow the > command, you need the link list. But since the > unsolicited data must be sent in the same order > as the commands, a link list is enough. > > Let us say that you have 8 commands. The ones > for which we expect unsolicted data are marked > as Cnn(ud). And I have marked the unsolicted > data PDUs as UD(nn). The (nn) with data implies > that it is implicit and not actually carried with > the PDU itself. > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > --> UD(07) C08(ud) UD(08) ---> > > After the target receives the command C01, C02, and C03 > for which it expects unsolicited data, it puts them in > a link list. It also receives C04 and C05 for which > unsolicited data is not expected and they don't go > on the list. It then receives C06 for which unsolicited > data is expected, and it is added to then end of the list. > Then an unsolicited data PDU is received. It must go > with the command at the head of the list which is C01. > Use the ITT to make sure and you can then take C01 off > the list and so on. > > Somesh > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > Sent: Friday, October 12, 2001 7:53 AM > > To: 'Binford, Charles'; ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Charles, > > > > As you have described the spec states that "that > unsolicited data MUST be > > sent in the same order as the commands". This is not the same as > > unsolicited data must follow the command associated with > it: For example: > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > x in all the > > example can be the ITT. It is not the CmdSN. > > > > This is allowed: > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > and the target will have to use the ITT to associate the > data with the > > command. > > > > Matthew > > > > > > -----Original Message----- > > From: Binford, Charles [mailto:CBinford@pirus.com] > > Sent: Friday, October 12, 2001 2:50 PM > > To: ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > I have not verify version 8 is still the same, but version 07-97 > > had a rule > > that unsolicited data MUST be sent in the same order as the > commands. > > > > Thus, there is no need for a search on the ITT. The target > just needs to > > keep of linked list of I/Os waiting on unsolicited data. > New commands are > > added to the tail, any unsolicited data *should* be associated > > with the I/O > > at the head of the list. The ITT is used as a sanity check and > > you're done. > > > > What am I missing? > > > > Charles Binford > > Pirus Networks > > 316.315.0382 x222 From owner-ips@ece.cmu.edu Mon Oct 15 08:21: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 IAA25189 for ; Mon, 15 Oct 2001 08:21:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FB4GY28271 for ips-outgoing; Mon, 15 Oct 2001 07:04:16 -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 f9FB4El28266 for ; Mon, 15 Oct 2001 07:04:14 -0400 (EDT) Received: from london ([192.168.1.99]) by mail.wrs.com (8.9.3/8.9.1) with SMTP id EAA04551; Mon, 15 Oct 2001 04:03:28 -0700 (PDT) From: "Rod Harrison" To: "Julian Satran" , Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU Date: Mon, 15 Oct 2001 12:06:09 +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 think you might have misunderstood what I meant. I was not advocating we change the spec in favour of relaxing the data ordering requirements. I was just point out there is a problem for the initiator to solve in order maintain correct ordering, and that I believe it is not a terribly difficult one. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian Satran Sent: Sunday, October 14, 2001 9:30 PM To: ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Immediate data are not mandatory (even if enabled). Having one or ten DMAs does not change the fact that they share a TCP "pipe" and a decent transmitter will ship the TCP data in order - otherwise it just throws his problems in the receiver's lap. Our additional requirement on order should make no difference. And it would be time to change the name of the thread. Julo "Rod Harrison" Snively" Sent by: cc: , owner-ips@ece.cmu. "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" edu , "'Binford, Charles'" , Subject: RE: Addition of CmdSN in Data-out PDU 13-10-01 13:12 Please respond to "Rod Harrison" Even more common would be the DMA latency. As an initiator I would send the command PDU as soon as I could if there were no immediate data, then queue the DMA for the unsolicited data. Since there could be many other DMAs queued ahead of the unsolicited data it is quite possible that other commands, both read and write, will be sent before the DMA completes. You are spot one when you say the delay in obtaining the unsolicited data may be large and variable. If there are multiple DMA engines it does become a challenge for the initiator to ensure the correct ordering of the unsolicited data. Note that since there may be multiple unsolicited data PDUs in the same burst, and those may be filled with separate DMAs the ordering problem propagates down to within individual commands. I don't believe it is a particularly difficult problem for the initiator to solve, but I do agree things would be easier for the initiator if the ordering requirement were removed. And more so if the requirement to send in dataSN order were also removed, but this is probably too much pain for the target. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of John Hufferd Sent: Saturday, October 13, 2001 1:01 AM To: Robert Snively Cc: 'somesh_gupta@silverbacksystems.com'; BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; ips@ece.cmu.edu Subject: RE: Addition of CmdSN in Data-out PDU Robert, I think that an Initiator being able to send a waiting Read command, without having to wait for many large write segments -- that are being sent (as unsolicited data) -- is very useful. And that would mean, the unsolicited data is waiting to be sent until the Read Commands are sent. This might be a very frequent case. . . . 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 10/12/2001 03:56:06 PM Sent by: owner-ips@ece.cmu.edu To: "'somesh_gupta@silverbacksystems.com'" , "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , "'Binford, Charles'" , ips@ece.cmu.edu cc: Subject: RE: Addition of CmdSN in Data-out PDU I have two small questions that would help me understand this. How do you know that unsolicited data is expected? By nature, unsolicited data is received as a "maximum surprise" which can only be determined after unpacking and parsing at least a part of the command structure, possibly even including the SCSI command (although there are some hints contained in the command header information). How can you constrain a generic system to posting the unsolicited data in the same order that the commands were emitted? In general, I would have expected the system to be emitting command followed immediately by the corresponding unsolicited data. If that is not the case, it means that there was a delay in obtaining the unsolicited data for transfer and that the delay was sufficient to allow the insertion of commands. If the delay is that large (and probably variable), the enforcement of transfer of unsolicited data in the same order as the commands are emitted seems to me to be a significant challenge, and certainly shouldn't be required as normal behavior. While it would make things simpler for targets (already challenged by unsolicited data), it seems to me that it would make things much more complex for initiators. Bob > -----Original Message----- > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > Sent: Friday, October 12, 2001 2:51 PM > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > Matthew, > > Since the unsolicited data does not follow the > command, you need the link list. But since the > unsolicited data must be sent in the same order > as the commands, a link list is enough. > > Let us say that you have 8 commands. The ones > for which we expect unsolicted data are marked > as Cnn(ud). And I have marked the unsolicted > data PDUs as UD(nn). The (nn) with data implies > that it is implicit and not actually carried with > the PDU itself. > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > --> UD(07) C08(ud) UD(08) ---> > > After the target receives the command C01, C02, and C03 > for which it expects unsolicited data, it puts them in > a link list. It also receives C04 and C05 for which > unsolicited data is not expected and they don't go > on the list. It then receives C06 for which unsolicited > data is expected, and it is added to then end of the list. > Then an unsolicited data PDU is received. It must go > with the command at the head of the list which is C01. > Use the ITT to make sure and you can then take C01 off > the list and so on. > > Somesh > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > Sent: Friday, October 12, 2001 7:53 AM > > To: 'Binford, Charles'; ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Charles, > > > > As you have described the spec states that "that > unsolicited data MUST be > > sent in the same order as the commands". This is not the same as > > unsolicited data must follow the command associated with > it: For example: > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > x in all the > > example can be the ITT. It is not the CmdSN. > > > > This is allowed: > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > and the target will have to use the ITT to associate the > data with the > > command. > > > > Matthew > > > > > > -----Original Message----- > > From: Binford, Charles [mailto:CBinford@pirus.com] > > Sent: Friday, October 12, 2001 2:50 PM > > To: ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > I have not verify version 8 is still the same, but version 07-97 > > had a rule > > that unsolicited data MUST be sent in the same order as the > commands. > > > > Thus, there is no need for a search on the ITT. The target > just needs to > > keep of linked list of I/Os waiting on unsolicited data. > New commands are > > added to the tail, any unsolicited data *should* be associated > > with the I/O > > at the head of the list. The ITT is used as a sanity check and > > you're done. > > > > What am I missing? > > > > Charles Binford > > Pirus Networks > > 316.315.0382 x222 From owner-ips@ece.cmu.edu Mon Oct 15 14:05: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 OAA08184 for ; Mon, 15 Oct 2001 14:05:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FGkKV20827 for ips-outgoing; Mon, 15 Oct 2001 12:46:20 -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 f9FGkIl20823 for ; Mon, 15 Oct 2001 12:46:19 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id D24827E9; Mon, 15 Oct 2001 09:46:17 -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 JAA07484; Mon, 15 Oct 2001 09:46:11 -0700 (PDT) Message-ID: <3BCB149A.B66963CF@cup.hp.com> Date: Mon, 15 Oct 2001 09:53:46 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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 - change - negotiation reset 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, Please see comments below. - Santosh Julian Satran wrote: > 3.10.3 Target Transfer Tag > > When the Target Transfer Tag is set to the reserved value 0xffffffff, it tells the target that this is a new request and the target should reset any internal state associated with the Initiator Task Tag. I believe the above is in violation with general protocol rules regarding uniqueness of task tags. initiator Task Tags are required to be unique for a given initiator and it should be considered a protocol error when an initiator re-uses an initiator task tag while a prior instance of the task tag is still active at the target. Such re-uses of an active task tag by an initiator are REJECTed by the target with a reason of "protocol error" or "task in progress". (It is also not clear which of the 2 reason codes is to be used in this case ?). In general, task tag resources MUST NOT be reused by initiators without first ensuring that their prior usage had been completed, either through successful completion of the prior task, or a completed error recovery of the prior task through an Abort Task or some higher recovery mechanism such as session teardown. I suggest that operational parameters be cleared by an initiator by either issuing an Abort Task for the text command, or tearing down the connection, or re-negotiating new parameters and the above special-cased rule be removed. > Long text responses are handled as in the following example: > > I->T Text SendTargets=all (F=1,TTT=0xffffffff) > T->I Text (F=0,TTT=0x12345678) > I->T Text (F=1, TTT=0x12345678) > T->I Text (F=0, TTT=0x12345678) > I->T Text (F=1, TTT=0x12345678) > ... > T->I Text (F=1, TTT=0xffffffff) Regarding the above description of long text exchange handling, is it a requirement that the initiator should send an EMPTY text command in response to a long text response ? Can it originate any keys or respond to any keys in continuing a long text exchange ? (This would occur on long text exchanges involving X-* keys, and not SendTargets). > Text response PDU > 3.11.3 Target Transfer Tag > > If the target receives a Text Request with the Target Task Tag set to the reserved value of 0xffffffff it resets its internal state associated with the given Initiator Task Tag. Please see above comments on this rule. It violates "unique task tag" protocol rules & requires targets to special case the handling of task tags. > > --------------------------------- > > 3.17 Reject > > 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| 0x3f |1| Reserved | Reason | Reserved | > +---------------+---------------+---------------+---------------+ > 4| Reserved | DataSegmentLength | > +---------------+---------------+---------------+---------------+ > 8/ Reserved / > +/ / > +---------------+---------------+---------------+---------------+ > 24| StatSN | > +---------------+---------------+---------------+---------------+ > 28| ExpCmdSN | > +---------------+---------------+---------------+---------------+ > 32| MaxCmdSN | > +---------------+---------------+---------------+---------------+ > 36| DataSN or Reserved | > +---------------+---------------+---------------+---------------+ > 40| Reserved | > +---------------+---------------+---------------+---------------+ > 44| Reserved | > +---------------+---------------+---------------+---------------+ > 48| Digest (if any) | > +---------------+---------------+---------------+---------------+ > xx/ Complete Header of Bad PDU / > +/ / > +---------------+---------------+---------------+---------------+ > yy/Vendor specific data (if any) / > / / > +---------------+---------------+---------------+---------------+ > zz > > Reject is used to indicate an iSCSI error condition (protocol, unsupported option etc.). > > 3.17.1 Reason > > The reject Reason is coded as follows: > > > +------+-----------------------------------------+------------------+ > | Code | Explanation | Can the original | > | (hex)| | PDU be re-sent? | > +------+-----------------------------------------+------------------+ > | 0x01 | Full Feature Phase Command before login | 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 | Task in progress | no | > | | | | > | 0x08 | Invalid SNACK | no | > | | | | > | 0x09 | Target Transfer Tag Reject for this | no | > | | Initiator Task Tag | | > | | | | > | 0x0a | Long Operation Reject - Can't generate | yes | > | | Target Transfer Tag - out of resources | | > | | | | > | 0x0b | Negotiation Reset | no | > +------+-----------------------------------------+------------------+ It is still not clear on when the target would need to use a "Negotiation Reset" reject reason code. Any reject from the target of a text command results in a reset of operational parameters and an explicit reason code such as "Negotiation Reset" is not required. > ---------------------------------- > 6. Operational Parameter Negotiation Outside the Login Phase > > An initiator MAY reset an operational parameter negotiation by issuing a Text request with the Target Transfer Tag set to the value 0xffffffff after receiving a response with the Target Transfer Tag set to a value other than 0xffffffff. A target may reset an operational parameter negotiation by answering a Text request with a Reject. I suggest the above rule not be allowed, since it special cases the protocol handling of "non-unique task tags". -- ################################## 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 Mon Oct 15 14:17: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 OAA08573 for ; Mon, 15 Oct 2001 14:17:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FH6Bn22344 for ips-outgoing; Mon, 15 Oct 2001 13:06:11 -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 f9FH69l22339 for ; Mon, 15 Oct 2001 13:06:09 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 3D6B0576; Mon, 15 Oct 2001 10:06:08 -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 KAA08620; Mon, 15 Oct 2001 10:06:03 -0700 (PDT) Message-ID: <3BCB1941.652A952B@cup.hp.com> Date: Mon, 15 Oct 2001 10:13:37 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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: [Fwd: iSCSI - revised 2.2.4] 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 Satran wrote: > > Santosh, > > The reason I am hesitant on accepting this change proposal as is that it > might makes the negotiation very much state dependent and different for > keys that have a default and keys that don't have one. I don't see why. An initiator that receives a login response needs to know whether to respond to a received key anyway. It does this by some mechanism like maintaining a list of keys that it sent in its login command. All that is required is that the initiator include those operational keys that it sent as defaults in this list. (it needs to do this anyway, since usage of defaults implies the initiator is offering those key values.) Also, when the target responds to a default offering, it is actually sending back the result of the negotiation. What benefit exists in having the initiator again echo this value back to the target in a redundant round-trip ? > In addition it may > change login behavior for different versions of the protocol that may have > different defaults. Again, I don't see why. The default values accepted by both sides are the defaults of the "version active" returned in the login response. > I admit that it has appeal for the login (where the > defaults are relevant) by shortening some negotiations. > > However the issues it raises are multiple. Assume that you have the > following sequence: > > I->T key1=x > T->I key1=z,key2=a > I->T key2=b > .... > > Observe that the initiator designer was very conservative and probably > intended to negotiate the keys one at a time > while the target is aggressive and wants to set everything as soon as > possible. I don't understand how the above scenario is correct. If key2 was an operational parameter, it already has a default defined for it, and the initiator cannot negotiate it one at a time, since it has already made the offer (of the default) by not sending the key explicitly. In any case, the initiator can always re-negotiate a key by re-sending the key again. I don't understand how the above example justifies the need for your current model. > > With the defaults rule the results are harder to define. > > With the rules we have now the results are hardly dependent on sequence. > > Add to this that with the new rules about PDULength exchanges are hardly > "self contained" - i.e. key=value pairs can span sequences (that was > another reasons I did not like this but framing at high speeds has > precedence!). > > However we might perhaps want to consider the following loose rule for > defaults in the context of operational parameter negotiation at login only > (leaving the negotiation rules as they are): > > If the initiator issues a login request with the F bit set to 1 is assumed > to have an imaginary content including all the operational keys that have a > default value and where not sent yet by the initiator during login and > their values set to the default value. Julian, the login rules are already complex enough. Why do we need to special case them further and increase the complexity ? I think login behaviour is quite simple to understand/follow when the initiator is considered as the originator of a key if it uses default values for that key. Thanks, Santosh > > Comments? > > Julo > > PS - and a procedural thing - nagging me repeatedly on a subject is > annoying and quoting the number of agreements before attempting different > scenarios is even more so It is unfortunate that you consider my polite requests to attempt to resolve an open issue as nagging. I don't know how much more polite I could possibly get. [and I am trying to discuss specific scenarios to understand the issues you have with this]. > > > Santosh Rao > > hp.com> cc: > Sent by: Subject: [Fwd: iSCSI - revised 2.2.4] > owner-ips@ece. > cmu.edu > > > 11-10-01 01:36 > Please respond > to Santosh Rao > > > > Julian, > > What is the resolution on this issue ? > > - Santosh > > Santosh Rao wrote: > > > > Julian, > > > > I apologize upfront for being so persistent on this. > > > > However, it would really help if you could give some clear example of a > > scenario as to why the initiator cannot be considered the originator of > > a negotiation, when it offers a key value implicitly, through the use of > > a default. > > > > Several people on this list (Paul Konning, Sanjeev, Deva, myself, and > > perhaps others, that I cannot recall at the moment) have asked that the > > spec must not differentiate login behaviour when the initiator offers a > > key explicitly vs. when it offers a key implicitly thru the use of the > > default. > > > > Please help us understand the need for iscsi to distingush the login > > behaviour in the above case. [through some tangible scenarios and > > examples]. > > > > Thanks, > > Santosh > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Julian, > > > > > > I would also request an explicit definition of offering party and > > > responding party. The current text still leaves ambiguity when target > > > sends a key in response to implicit default key of the Intiator. In > > > this case who is the offering party and who is the responding party > > > > > > Sanjeev > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, October 05, 2001 2:06 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI - revised 2.2.4 > > > > > > Here is a revised (complete) part 2.2.4 based on recent > > > agreed changes: > > > > > > 1.1.1 Text Mode Negotiation > > > > > > During login and thereafter some session or connection > > > parameters are negotiated through an exchange of textual > > > information. > > > > > > All negotiations are stateless - i.e. the result MUST be > > > based only on newly exchanged values. > > > > > > The general format of text negotiation is: > > > > > > Originator-> = > > > Responder-> =|reject|NotUnderstood > > > > > > The value can be a number, a single literal constant a > > > Boolean value (yes or no) or a list of comma separated > > > literal constant values. > > > > > > In literal list negotiation, the originator sends for each > > > key a list of options (literal constants which may include > > > "none") in its order of preference. > > > > > > The responding party answers with the first value from the > > > list it supports and is allowed to use for the specific > > > originator. > > > > > > The constant "none" MUST always be used to indicate a > > > missing function. However, none is a valid selection only if > > > it is explicitly offered. > > > > > > If a target is not supporting, or not allowed to use with a > > > specific originator, any of the offered options, it may use > > > the constant "reject". The constants "none" and "reject" > > > are reserved and must be used only as described here. Any > > > key not understood is answered with "NotUnderstood". > > > > > > For numerical and single literal negotiations, the > > > responding party MUST respond with the required key and the > > > value it selects, based on the selection rule specific to > > > the key, becomes the negotiation result. Selection of a > > > value not admissible under the selection rules is considered > > > a protocol error and handled accordingly. > > > > > > For Boolean negotiations (keys taking the values yes or no), > > > the responding party MUST respond with the required key and > > > the result of the negotiation when the received value does > > > not determine that result by itself. The last value > > > transmitted becomes the negotiation result. The rules for > > > selecting the value to respond with are expressed as Boolean > > > functions of the value received and the value that the > > > responding party would select in the absence of knowledge of > > > the received value. > > > > > > Specifically, the two cases in which responses are OPTIONAL > > > are: > > > > > > - The Boolean function is "AND" and the value "no" is > > > received. The outcome of the negotiation is "no". > > > - The Boolean function is "OR" and the value "yes" is > > > received. The outcome of the negotiation is "yes". > > > > > > Responses are REQUIRED in all other cases, and the value > > > chosen and sent by the responder becomes the outcome of the > > > negotiation. > > > > > > The value "?" with any key has the meaning of enquiry and > > > should be answered with the current value or > > > "NotUnderstood". > > > > > > 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, only the initiator can > > > initiate the negotiation start (through the first Text > > > request) and completion (by setting to 1 and keeping to 1 > > > the F bit in a Text request). > > > > > > Comments ? > > > > > > 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 Mon Oct 15 15:48: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 PAA10471 for ; Mon, 15 Oct 2001 15:48:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FIctu29693 for ips-outgoing; Mon, 15 Oct 2001 14:38:55 -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 f9FIcrl29687 for ; Mon, 15 Oct 2001 14:38:53 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id 324561F651; Mon, 15 Oct 2001 14:36:32 -0400 (EDT) Received: from xatlbh2.atl.hp.com (xatlbh2.atl.hp.com [15.45.89.187]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id D753A1FA93; Mon, 15 Oct 2001 14:32:22 -0400 (EDT) Received: by xatlbh2.atl.hp.com with Internet Mail Service (5.5.2653.19) id <4MYHQRTS>; Mon, 15 Oct 2001 14:32:22 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF1CB@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI: NIC interoperability Date: Mon, 15 Oct 2001 14:32: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 Mallikarjun is advocating including A,B,and C statements explicitly in the document. I support this. Marj > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, October 12, 2001 10:03 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: NIC interoperability > > > Mallikarjun, > > I have repeatedly stated that from a practical point of view we are > spending a lot of ink on a non-issue. > I have even insisted on mandating C in the draft. Some of the list > members/readers/authors seem to consider such a requirement > as "excessive" > - as it implies resorting to a higher authority on every > session creation - > and that might not be strictly necessary (although it will be > sufficient). > Adding a text key is neither simpler nor easier nor will it solve the > conflict problem. > And I have very little time and patience left for pages of > debate on the > merits of one or other port naming script. > > Julo > > > > > > "Mallikarjun > > C." To: ips > > > om> Subject: iSCSI: > NIC interoperability > Sent by: > > owner-ips@ece. > > cmu.edu > > > > > > 10-10-01 04:14 > > Please respond > > to cbm > > > > > > > > > After seeing some of the emails on this topic from Dave > Sheehy, David Black and Jim Hafner, I have some comments > and questions. > > It appears to me that the following three are the major > issues that one has to deal with for building a multi-NIC > iSCSI Node, where the NICs are potentially from different > vendors. > A. Each NIC MUST allow the Node name to be configurable. > B. Each NIC MUST allow the ISID range to be configurable > (if deployed in an initiator configuration). > C. In addition, if only one (initiator/target) portal group > is sought to be presented (i.e. session spanning across > any and all of these NICs is a requirement), each NIC > MUST allow itself to be managed by an externally-resident > "session manager" in some "TBD standard way". > > Admittedly, C is is the hardest and till the "TBD standard way" > is defined to interact with a session manager, it cannot be > mandated. Failure to comply with C would only create multiple > portal groups in an iSCSI implementation - each portal group > limited to NIC(s) from a given vendor. > > But, A and B above seem reasonable and in fact seem required > to be mandated - both to avoid the problems as with FC Node > Name, and also to address the concerns of not leaving target > with a deterministic way to enforce access control mechanisms > and such. > > I realize that the "no duplicate nexus" goal does not strictly > require A (hence neither B), but I recommend that A be mandated, > thus automatically making B an additional requirement for initiator > configurations. Rev08 iSCSI draft seems to refer to A and B > in section 9 (implementation notes) as "should". Was there a > concern about the appropriateness of mandating A and B in the > main modeling discussion? They appear fairly straightforward > to implement. > > If the reasoning was not to require _any_ configuration of an > iSCSI NIC, I would argue that you require some "name" to be > configurable anytime you want to build a logically monolithic > entity (as in a node) from smaller components (each of which > can act as a logically independent entity in its own right). > > Comments from NDT and/or Julian would help. > > 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 Mon Oct 15 16: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 QAA11181 for ; Mon, 15 Oct 2001 16:40:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FJMiR03098 for ips-outgoing; Mon, 15 Oct 2001 15:22:44 -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 f9FJMGl03062 for ; Mon, 15 Oct 2001 15:22:42 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id 92270744 for ; Mon, 15 Oct 2001 15:22:15 -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 MAA06946 for ; Mon, 15 Oct 2001 12:23:39 -0700 (PDT) Message-Id: <200110151923.MAA06946@core.rose.hp.com> Date: Mon, 15 Oct 2001 12:34:07 -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: [Fwd: iSCSI - revised 2.2.4] References: <3BCB1941.652A952B@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, It appears to me that there are a couple of questions to address, to arrive at a resolution to this change request - 1)Should all operational keys be sent in one text command PDU? (Can they, given that the max PDU size may be a constraint? Or, did the constraint go away with the recent set of changes that allow one key=value to span multiple PDUs?) 2)Can keys be renegotiated to different values (after they were negotiated once) in the same negotiation sequence? If I understood Santosh right, he is implicitly assuming "yes" to (1) above - so anything that the initiator does not offer tantamounts to an explicit default. If that's the case, I agree with this view. [ Julian, please comment how the new key-spanning is differentiated from the multi-command sequence in the PDU header. ] If the answer to (2) above "yes" (which Santosh thinks is the case, and suggests as the answer to Julian's scenario), I would first of all like to understand the practical usage of it. As a first reaction, it appears to me to open the door for endless exchanges. But there may be other safeguards in the draft that I haven't closely looked at. Thanks. -- 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: > > > > Santosh, > > > > The reason I am hesitant on accepting this change proposal as is that it > > might makes the negotiation very much state dependent and different for > > keys that have a default and keys that don't have one. > > I don't see why. An initiator that receives a login response needs to > know whether to respond to a received key anyway. It does this by some > mechanism like maintaining a list of keys that it sent in its login > command. All that is required is that the initiator include those > operational keys that it sent as defaults in this list. (it needs to do > this anyway, since usage of defaults implies the initiator is offering > those key values.) > > Also, when the target responds to a default offering, it is actually > sending back the result of the negotiation. What benefit exists in > having the initiator again echo this value back to the target in a > redundant round-trip ? > > > In addition it may > > change login behavior for different versions of the protocol that may have > > different defaults. > > Again, I don't see why. The default values accepted by both sides are > the defaults of the "version active" returned in the login response. > > > I admit that it has appeal for the login (where the > > defaults are relevant) by shortening some negotiations. > > > > However the issues it raises are multiple. Assume that you have the > > following sequence: > > > > I->T key1=x > > T->I key1=z,key2=a > > I->T key2=b > > .... > > > > Observe that the initiator designer was very conservative and probably > > intended to negotiate the keys one at a time > > while the target is aggressive and wants to set everything as soon as > > possible. > > I don't understand how the above scenario is correct. If key2 was an > operational parameter, it already has a default defined for it, and the > initiator cannot negotiate it one at a time, since it has already made > the offer (of the default) by not sending the key explicitly. > > In any case, the initiator can always re-negotiate a key by re-sending > the key again. I don't understand how the above example justifies the > need for your current model. > > > > > With the defaults rule the results are harder to define. > > > > With the rules we have now the results are hardly dependent on sequence. > > > > Add to this that with the new rules about PDULength exchanges are hardly > > "self contained" - i.e. key=value pairs can span sequences (that was > > another reasons I did not like this but framing at high speeds has > > precedence!). > > > > However we might perhaps want to consider the following loose rule for > > defaults in the context of operational parameter negotiation at login only > > (leaving the negotiation rules as they are): > > > > If the initiator issues a login request with the F bit set to 1 is assumed > > to have an imaginary content including all the operational keys that have a > > default value and where not sent yet by the initiator during login and > > their values set to the default value. > > Julian, the login rules are already complex enough. Why do we need to > special case them further and increase the complexity ? I think login > behaviour is quite simple to understand/follow when the initiator is > considered as the originator of a key if it uses default values for that > key. > > Thanks, > Santosh > > > > > Comments? > > > > Julo > > > > PS - and a procedural thing - nagging me repeatedly on a subject is > > annoying and quoting the number of agreements before attempting different > > scenarios is even more so > > It is unfortunate that you consider my polite requests to attempt to > resolve an open issue as nagging. I don't know how much more polite I > could possibly get. [and I am trying to discuss specific scenarios to > understand the issues you have with this]. > > > > > > > Santosh Rao > > > > hp.com> cc: > > Sent by: Subject: [Fwd: iSCSI - revised 2.2.4] > > owner-ips@ece. > > cmu.edu > > > > > > 11-10-01 01:36 > > Please respond > > to Santosh Rao > > > > > > > > Julian, > > > > What is the resolution on this issue ? > > > > - Santosh > > > > Santosh Rao wrote: > > > > > > Julian, > > > > > > I apologize upfront for being so persistent on this. > > > > > > However, it would really help if you could give some clear example of a > > > scenario as to why the initiator cannot be considered the originator of > > > a negotiation, when it offers a key value implicitly, through the use of > > > a default. > > > > > > Several people on this list (Paul Konning, Sanjeev, Deva, myself, and > > > perhaps others, that I cannot recall at the moment) have asked that the > > > spec must not differentiate login behaviour when the initiator offers a > > > key explicitly vs. when it offers a key implicitly thru the use of the > > > default. > > > > > > Please help us understand the need for iscsi to distingush the login > > > behaviour in the above case. [through some tangible scenarios and > > > examples]. > > > > > > Thanks, > > > Santosh > > > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > > > Julian, > > > > > > > > I would also request an explicit definition of offering party and > > > > responding party. The current text still leaves ambiguity when target > > > > sends a key in response to implicit default key of the Intiator. In > > > > this case who is the offering party and who is the responding party > > > > > > > > Sanjeev > > > > > > > > -----Original Message----- > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > Sent: Friday, October 05, 2001 2:06 PM > > > > To: ips@ece.cmu.edu > > > > Subject: iSCSI - revised 2.2.4 > > > > > > > > Here is a revised (complete) part 2.2.4 based on recent > > > > agreed changes: > > > > > > > > 1.1.1 Text Mode Negotiation > > > > > > > > During login and thereafter some session or connection > > > > parameters are negotiated through an exchange of textual > > > > information. > > > > > > > > All negotiations are stateless - i.e. the result MUST be > > > > based only on newly exchanged values. > > > > > > > > The general format of text negotiation is: > > > > > > > > Originator-> = > > > > Responder-> =|reject|NotUnderstood > > > > > > > > The value can be a number, a single literal constant a > > > > Boolean value (yes or no) or a list of comma separated > > > > literal constant values. > > > > > > > > In literal list negotiation, the originator sends for each > > > > key a list of options (literal constants which may include > > > > "none") in its order of preference. > > > > > > > > The responding party answers with the first value from the > > > > list it supports and is allowed to use for the specific > > > > originator. > > > > > > > > The constant "none" MUST always be used to indicate a > > > > missing function. However, none is a valid selection only if > > > > it is explicitly offered. > > > > > > > > If a target is not supporting, or not allowed to use with a > > > > specific originator, any of the offered options, it may use > > > > the constant "reject". The constants "none" and "reject" > > > > are reserved and must be used only as described here. Any > > > > key not understood is answered with "NotUnderstood". > > > > > > > > For numerical and single literal negotiations, the > > > > responding party MUST respond with the required key and the > > > > value it selects, based on the selection rule specific to > > > > the key, becomes the negotiation result. Selection of a > > > > value not admissible under the selection rules is considered > > > > a protocol error and handled accordingly. > > > > > > > > For Boolean negotiations (keys taking the values yes or no), > > > > the responding party MUST respond with the required key and > > > > the result of the negotiation when the received value does > > > > not determine that result by itself. The last value > > > > transmitted becomes the negotiation result. The rules for > > > > selecting the value to respond with are expressed as Boolean > > > > functions of the value received and the value that the > > > > responding party would select in the absence of knowledge of > > > > the received value. > > > > > > > > Specifically, the two cases in which responses are OPTIONAL > > > > are: > > > > > > > > - The Boolean function is "AND" and the value "no" is > > > > received. The outcome of the negotiation is "no". > > > > - The Boolean function is "OR" and the value "yes" is > > > > received. The outcome of the negotiation is "yes". > > > > > > > > Responses are REQUIRED in all other cases, and the value > > > > chosen and sent by the responder becomes the outcome of the > > > > negotiation. > > > > > > > > The value "?" with any key has the meaning of enquiry and > > > > should be answered with the current value or > > > > "NotUnderstood". > > > > > > > > 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, only the initiator can > > > > initiate the negotiation start (through the first Text > > > > request) and completion (by setting to 1 and keeping to 1 > > > > the F bit in a Text request). > > > > > > > > Comments ? > > > > > > > > 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 Mon Oct 15 16:45: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 QAA11305 for ; Mon, 15 Oct 2001 16:45:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FK9Lv06577 for ips-outgoing; Mon, 15 Oct 2001 16:09:21 -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 f9FK9Gl06566 for ; Mon, 15 Oct 2001 16:09:20 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel2.hp.com (Postfix) with ESMTP id 1A60F2EA for ; Mon, 15 Oct 2001 13:09:16 -0700 (PDT) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by xparelay1.corp.hp.com (Postfix) with ESMTP id DF66A1F51A for ; Mon, 15 Oct 2001 13:09:15 -0700 (PDT) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id <4S8D486B>; Mon, 15 Oct 2001 13:09:15 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF1CD@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: [Fwd: iSCSI - revised 2.2.4] Date: Mon, 15 Oct 2001 13:09:13 -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 > However we might perhaps want to consider the following loose rule for > defaults in the context of operational parameter negotiation at login only > (leaving the negotiation rules as they are): > > If the initiator issues a login request with the F bit set to 1 is assumed > to have an imaginary content including all the operational keys that have a > default value and where not sent yet by the initiator during login and > their values set to the default value. > > Comments? > Julian, Thanks for the detailed explanation of your thinking, I missed the possibility that an initiator might not choose to fit the maximum number of key/value pairs per PDU. Can the login section state that an initiator SHOULD send the max number of key/value pairs it can fit per PDU? Just to encourage efficient implementations? :-) I'm a little confused as to what you are suggesting in the above text - my thought is that a target does not know when it can assume that the initiator has "offered a default" until the initiator sets the T bit to transition to the next negotiation phase. Did you mean to say T not F bit? Thanks! Marjorie From owner-ips@ece.cmu.edu Mon Oct 15 17:49: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 RAA13026 for ; Mon, 15 Oct 2001 17:49:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FL04v10332 for ips-outgoing; Mon, 15 Oct 2001 17:00:04 -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 f9FKxtl10314; Mon, 15 Oct 2001 16:59:55 -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 NAA12466; Mon, 15 Oct 2001 13:59:38 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWV58Q9>; Mon, 15 Oct 2001 13:59:37 -0700 Message-ID: From: Robert Snively To: "'Julian Satran'" , John Hufferd Cc: "'Binford, Charles'" , ips@ece.cmu.edu, "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , owner-ips@ece.cmu.edu, Robert Snively , "'somesh_gupta@silverbacksystems.com'" Subject: RE: Addition of CmdSN in Data-out PDU Date: Mon, 15 Oct 2001 13:59:32 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Can they send enough commands to close the window just as fatally? > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, October 13, 2001 1:09 PM > To: John Hufferd > Cc: 'Binford, Charles'; ips@ece.cmu.edu; BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2); owner-ips@ece.cmu.edu; Robert Snively; > 'somesh_gupta@silverbacksystems.com' > Subject: RE: Addition of CmdSN in Data-out PDU > > > Robert, > > The reason for the rule is limiting restrictions to what is logically > mandated and leaving all the rest to the implementer. > The ordering rule is there to help avoid the trivial deadlock where > commands start asking for solicited data and the windows is closed by > unsolicited data and having to resort to dropping data to > reopen the TCP > window. > > Having data immediately follow the command is admisible but some > implementer might choose to have and launch as many commands > as possible > to get the data transfer overlap with positioning operations. > > The targets are supposed to consider out of order delivery of data a > protocol error. > > Regards, > Julo > > > > > John Hufferd/San Jose/IBM@IBMUS > Sent by: owner-ips@ece.cmu.edu > 13-10-01 02:01 > Please respond to John Hufferd > > > To: Robert Snively > cc: "'somesh_gupta@silverbacksystems.com'" > , "BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2)" , > "'Binford, Charles'" > , ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > Robert, > I think that an Initiator being able to send a waiting Read command, > without having to wait for many large write segments -- that > are being > sent > (as unsolicited data) -- is very useful. And that would mean, the > unsolicited data is waiting to be sent until the Read > Commands are sent. > This might be a very frequent case. > > . > . > . > 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 > 10/12/2001 03:56:06 > PM > > Sent by: owner-ips@ece.cmu.edu > > > To: "'somesh_gupta@silverbacksystems.com'" > , "BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2)" , "'Binford, > Charles'" , ips@ece.cmu.edu > cc: > Subject: RE: Addition of CmdSN in Data-out PDU > > > > I have two small questions that would help me understand this. > > How do you know that unsolicited data is expected? By nature, > unsolicited data is received as a "maximum surprise" which can > only be determined after unpacking and parsing at least a > part of the command structure, possibly even including the > SCSI command (although there are some hints contained in the > command header information). > > How can you constrain a generic system to posting the > unsolicited data in the same order that the commands were > emitted? In general, I would have expected the system to > be emitting command followed immediately by the corresponding > unsolicited data. If that is not the case, it means that there > was a delay in obtaining the unsolicited data for transfer and > that the delay was sufficient to allow the insertion of commands. > If the delay is that large (and probably variable), the enforcement > of transfer of unsolicited data in the same order as the > commands are emitted seems to me to be a significant challenge, > and certainly shouldn't be required as normal behavior. While it > would make things simpler for targets (already challenged by > unsolicited data), it seems to me that it would make things > much more complex for initiators. > > Bob > > > -----Original Message----- > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > > Sent: Friday, October 12, 2001 2:51 PM > > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > > ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Matthew, > > > > Since the unsolicited data does not follow the > > command, you need the link list. But since the > > unsolicited data must be sent in the same order > > as the commands, a link list is enough. > > > > Let us say that you have 8 commands. The ones > > for which we expect unsolicted data are marked > > as Cnn(ud). And I have marked the unsolicted > > data PDUs as UD(nn). The (nn) with data implies > > that it is implicit and not actually carried with > > the PDU itself. > > > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > > --> UD(07) C08(ud) UD(08) ---> > > > > After the target receives the command C01, C02, and C03 > > for which it expects unsolicited data, it puts them in > > a link list. It also receives C04 and C05 for which > > unsolicited data is not expected and they don't go > > on the list. It then receives C06 for which unsolicited > > data is expected, and it is added to then end of the list. > > Then an unsolicited data PDU is received. It must go > > with the command at the head of the list which is C01. > > Use the ITT to make sure and you can then take C01 off > > the list and so on. > > > > Somesh > > > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > > Sent: Friday, October 12, 2001 7:53 AM > > > To: 'Binford, Charles'; ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > Charles, > > > > > > As you have described the spec states that "that > > unsolicited data MUST be > > > sent in the same order as the commands". This is not the same as > > > unsolicited data must follow the command associated with > > it: For example: > > > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > > x in all the > > > example can be the ITT. It is not the CmdSN. > > > > > > This is allowed: > > > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > > > and the target will have to use the ITT to associate the > > data with the > > > command. > > > > > > Matthew > > > > > > > > > -----Original Message----- > > > From: Binford, Charles [mailto:CBinford@pirus.com] > > > Sent: Friday, October 12, 2001 2:50 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > I have not verify version 8 is still the same, but version 07-97 > > > had a rule > > > that unsolicited data MUST be sent in the same order as the > > commands. > > > > > > Thus, there is no need for a search on the ITT. The target > > just needs to > > > keep of linked list of I/Os waiting on unsolicited data. > > New commands are > > > added to the tail, any unsolicited data *should* be associated > > > with the I/O > > > at the head of the list. The ITT is used as a sanity check and > > > you're done. > > > > > > What am I missing? > > > > > > Charles Binford > > > Pirus Networks > > > 316.315.0382 x222 > > > > > > > From owner-ips@ece.cmu.edu Mon Oct 15 19:11: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 TAA15016 for ; Mon, 15 Oct 2001 19:11:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FM4WJ15198 for ips-outgoing; Mon, 15 Oct 2001 18:04:32 -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 f9FM4Nl15185 for ; Mon, 15 Oct 2001 18:04:23 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 902BD6D2 for ; Mon, 15 Oct 2001 15:04:22 -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 PAA26384; Mon, 15 Oct 2001 15:04:15 -0700 (PDT) Message-ID: <3BCB5F26.65FC659@cup.hp.com> Date: Mon, 15 Oct 2001 15:11:50 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: cbm@rose.hp.com Cc: ips Subject: Re: [Fwd: iSCSI - revised 2.2.4] References: <3BCB1941.652A952B@cup.hp.com> <200110151923.MAA06946@core.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 Mallikarjun, Thanks for attempting to drive this forward from its current deadlocked position ! My comments inline. Thanks, Santosh "Mallikarjun C." wrote: > > Julian and Santosh, > > It appears to me that there are a couple of questions > to address, to arrive at a resolution to this change > request - > > 1)Should all operational keys be sent in one > text command PDU? (Can they, given that > the max PDU size may be a constraint? Or, > did the constraint go away with the recent > set of changes that allow one key=value to > span multiple PDUs?) The constraints of max receive pdu length are known only after login negotiation of that key. Hence, there must be a definition of a minimum value for the MaxRecvPDULength and implementations MUST support a minimum buffer size of at least that value. Similar precedents exist in other protocols that negotiate a MTU. (ex : an FC frame cannot be less than 256 bytes in size.). Given that such a minimum definition is required, I would then suggest that this minimum be capable of containing all of the operational keys with some extra room. The alternative would be to require that operational parameter negotiation be split into multiple rounds with the first round only negotiating the recv pdu length. I prefer the former method due to its simplicity. > 2)Can keys be renegotiated to different values > (after they were negotiated once) in the same > negotiation sequence? There's nothing in the draft that prevents this. (I seem to remember seeing text that allowed initiators to do this, but I may be mistaken with this.) > > If I understood Santosh right, he is implicitly assuming > "yes" to (1) above - so anything that the initiator > does not offer tantamounts to an explicit default. I believe this has been the working assumption so far ! If this is not a correct assumption, I don't see how the concept of defaults can work. How does a target know whether the initiator offered the default or not ? > If > that's the case, I agree with this view. [ Julian, please > comment how the new key-spanning is differentiated from > the multi-command sequence in the PDU header. ] > > If the answer to (2) above "yes" (which Santosh thinks > is the case, and suggests as the answer to Julian's > scenario), I would first of all like to understand the > practical usage of it. I see nothing in the draft that prohibits an initiator from re-negotiating a key once it obtained the result. Something along the following lines is a possibility : i -> t : InitialR2T=yes FirstBurstSize=16K t -> i : InitialR2T=yes FirstBurstSize=512 i -> t : InitialR2T=no (initiator cannot function with a FirstBurstSize of 512 bytes, and so, decides to turn off un-solicited data.) > As a first reaction, it appears > to me to open the door for endless exchanges. An initiator decides when login operational negotiation is initiated and terminated. That said, however, if you've a buggy implementation, nothing can safeguard login from endless exchanges with the initiator never performing a stage transition to FFP. ------------------------------------------------------------------- > Santosh Rao wrote: > > > > Julian Satran wrote: > > > > > > Santosh, > > > > > > The reason I am hesitant on accepting this change proposal as is that it > > > might makes the negotiation very much state dependent and different for > > > keys that have a default and keys that don't have one. > > > > I don't see why. An initiator that receives a login response needs to > > know whether to respond to a received key anyway. It does this by some > > mechanism like maintaining a list of keys that it sent in its login > > command. All that is required is that the initiator include those > > operational keys that it sent as defaults in this list. (it needs to do > > this anyway, since usage of defaults implies the initiator is offering > > those key values.) > > > > Also, when the target responds to a default offering, it is actually > > sending back the result of the negotiation. What benefit exists in > > having the initiator again echo this value back to the target in a > > redundant round-trip ? > > > > > In addition it may > > > change login behavior for different versions of the protocol that may have > > > different defaults. > > > > Again, I don't see why. The default values accepted by both sides are > > the defaults of the "version active" returned in the login response. > > > > > I admit that it has appeal for the login (where the > > > defaults are relevant) by shortening some negotiations. > > > > > > However the issues it raises are multiple. Assume that you have the > > > following sequence: > > > > > > I->T key1=x > > > T->I key1=z,key2=a > > > I->T key2=b > > > .... > > > > > > Observe that the initiator designer was very conservative and probably > > > intended to negotiate the keys one at a time > > > while the target is aggressive and wants to set everything as soon as > > > possible. > > > > I don't understand how the above scenario is correct. If key2 was an > > operational parameter, it already has a default defined for it, and the > > initiator cannot negotiate it one at a time, since it has already made > > the offer (of the default) by not sending the key explicitly. > > > > In any case, the initiator can always re-negotiate a key by re-sending > > the key again. I don't understand how the above example justifies the > > need for your current model. > > > > > > > > With the defaults rule the results are harder to define. > > > > > > With the rules we have now the results are hardly dependent on sequence. > > > > > > Add to this that with the new rules about PDULength exchanges are hardly > > > "self contained" - i.e. key=value pairs can span sequences (that was > > > another reasons I did not like this but framing at high speeds has > > > precedence!). > > > > > > However we might perhaps want to consider the following loose rule for > > > defaults in the context of operational parameter negotiation at login only > > > (leaving the negotiation rules as they are): > > > > > > If the initiator issues a login request with the F bit set to 1 is assumed > > > to have an imaginary content including all the operational keys that have a > > > default value and where not sent yet by the initiator during login and > > > their values set to the default value. > > > > Julian, the login rules are already complex enough. Why do we need to > > special case them further and increase the complexity ? I think login > > behaviour is quite simple to understand/follow when the initiator is > > considered as the originator of a key if it uses default values for that > > key. > > > > Thanks, > > Santosh > > > > > > > > Comments? > > > > > > Julo > > > > > > PS - and a procedural thing - nagging me repeatedly on a subject is > > > annoying and quoting the number of agreements before attempting different > > > scenarios is even more so > > > > It is unfortunate that you consider my polite requests to attempt to > > resolve an open issue as nagging. I don't know how much more polite I > > could possibly get. [and I am trying to discuss specific scenarios to > > understand the issues you have with this]. > > > > > > > > > > > Santosh Rao > > > > > > hp.com> cc: > > > Sent by: Subject: [Fwd: iSCSI - revised 2.2.4] > > > owner-ips@ece. > > > cmu.edu > > > > > > > > > 11-10-01 01:36 > > > Please respond > > > to Santosh Rao > > > > > > > > > > > > Julian, > > > > > > What is the resolution on this issue ? > > > > > > - Santosh > > > > > > Santosh Rao wrote: > > > > > > > > Julian, > > > > > > > > I apologize upfront for being so persistent on this. > > > > > > > > However, it would really help if you could give some clear example of a > > > > scenario as to why the initiator cannot be considered the originator of > > > > a negotiation, when it offers a key value implicitly, through the use of > > > > a default. > > > > > > > > Several people on this list (Paul Konning, Sanjeev, Deva, myself, and > > > > perhaps others, that I cannot recall at the moment) have asked that the > > > > spec must not differentiate login behaviour when the initiator offers a > > > > key explicitly vs. when it offers a key implicitly thru the use of the > > > > default. > > > > > > > > Please help us understand the need for iscsi to distingush the login > > > > behaviour in the above case. [through some tangible scenarios and > > > > examples]. > > > > > > > > Thanks, > > > > Santosh > > > > > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > > > > > Julian, > > > > > > > > > > I would also request an explicit definition of offering party and > > > > > responding party. The current text still leaves ambiguity when target > > > > > sends a key in response to implicit default key of the Intiator. In > > > > > this case who is the offering party and who is the responding party > > > > > > > > > > Sanjeev > > > > > > > > > > -----Original Message----- > > > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > > > Sent: Friday, October 05, 2001 2:06 PM > > > > > To: ips@ece.cmu.edu > > > > > Subject: iSCSI - revised 2.2.4 > > > > > > > > > > Here is a revised (complete) part 2.2.4 based on recent > > > > > agreed changes: > > > > > > > > > > 1.1.1 Text Mode Negotiation > > > > > > > > > > During login and thereafter some session or connection > > > > > parameters are negotiated through an exchange of textual > > > > > information. > > > > > > > > > > All negotiations are stateless - i.e. the result MUST be > > > > > based only on newly exchanged values. > > > > > > > > > > The general format of text negotiation is: > > > > > > > > > > Originator-> = > > > > > Responder-> =|reject|NotUnderstood > > > > > > > > > > The value can be a number, a single literal constant a > > > > > Boolean value (yes or no) or a list of comma separated > > > > > literal constant values. > > > > > > > > > > In literal list negotiation, the originator sends for each > > > > > key a list of options (literal constants which may include > > > > > "none") in its order of preference. > > > > > > > > > > The responding party answers with the first value from the > > > > > list it supports and is allowed to use for the specific > > > > > originator. > > > > > > > > > > The constant "none" MUST always be used to indicate a > > > > > missing function. However, none is a valid selection only if > > > > > it is explicitly offered. > > > > > > > > > > If a target is not supporting, or not allowed to use with a > > > > > specific originator, any of the offered options, it may use > > > > > the constant "reject". The constants "none" and "reject" > > > > > are reserved and must be used only as described here. Any > > > > > key not understood is answered with "NotUnderstood". > > > > > > > > > > For numerical and single literal negotiations, the > > > > > responding party MUST respond with the required key and the > > > > > value it selects, based on the selection rule specific to > > > > > the key, becomes the negotiation result. Selection of a > > > > > value not admissible under the selection rules is considered > > > > > a protocol error and handled accordingly. > > > > > > > > > > For Boolean negotiations (keys taking the values yes or no), > > > > > the responding party MUST respond with the required key and > > > > > the result of the negotiation when the received value does > > > > > not determine that result by itself. The last value > > > > > transmitted becomes the negotiation result. The rules for > > > > > selecting the value to respond with are expressed as Boolean > > > > > functions of the value received and the value that the > > > > > responding party would select in the absence of knowledge of > > > > > the received value. > > > > > > > > > > Specifically, the two cases in which responses are OPTIONAL > > > > > are: > > > > > > > > > > - The Boolean function is "AND" and the value "no" is > > > > > received. The outcome of the negotiation is "no". > > > > > - The Boolean function is "OR" and the value "yes" is > > > > > received. The outcome of the negotiation is "yes". > > > > > > > > > > Responses are REQUIRED in all other cases, and the value > > > > > chosen and sent by the responder becomes the outcome of the > > > > > negotiation. > > > > > > > > > > The value "?" with any key has the meaning of enquiry and > > > > > should be answered with the current value or > > > > > "NotUnderstood". > > > > > > > > > > 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, only the initiator can > > > > > initiate the negotiation start (through the first Text > > > > > request) and completion (by setting to 1 and keeping to 1 > > > > > the F bit in a Text request). > > > > > > > > > > Comments ? > > > > > > > > > > Julo > > > > > > > > -- > > ################################## > > 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 Mon Oct 15 19: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 TAA15550 for ; Mon, 15 Oct 2001 19:51:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FMwbI19202 for ips-outgoing; Mon, 15 Oct 2001 18:58:37 -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 f9FMwZl19197 for ; Mon, 15 Oct 2001 18:58:35 -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 PAA29000; Mon, 15 Oct 2001 15:58:27 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWV6BJ9>; Mon, 15 Oct 2001 15:58:24 -0700 Message-ID: From: Robert Snively To: "'Sharma, Suman'" , ips@ece.cmu.edu Subject: RE: questions/suggestions on Date: Mon, 15 Oct 2001 15:58:20 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk > 1. section 4->4) Class 1 FC frames( and some signals) are not > transmitted > across an FCIP link. Since purpose of FCIP is to replace > end-to-end fiber. > So, how these frames will be transferred ? Class 1 is connection oriented and requires 100% guaranteed bandwidth the whole length of the link. TCP/IP cannot support that behavior reliably. This did not hurt anybody's feelings because class 1 is principally a legacy implementation. > > 2. section 5.2 , fig. 2 FCIP Link Model is little bit > confusing. Instead of > writing FCIP on one side and Link on other side, it will be > good if FCIP > Link is written both side. > The intent here is that the IP network as well as the two wires to the FC Fabric be interpreted as a single link. > 3. section 5.6.2.1 and 5.6.2.2. If someone is doing TCP > checksum validation, > is it required to do 5.6.2.2 checks ? At least test j) is not > required ? > The required checking is specified because the TCP checksum validation (which of course is assumed to be present) has proven less than perfectly reliable in some environments. The tests are required according to the explanations. Verification of length and length redundancy is required. At least some other verifications are a very good idea. > 4. Once TCP payload will have only one FC frame or it can > have multiple FC > frame ? Its not mentioned anywhere, but from the section > 5.6.2.2 and 5.6.2.3 > it seems to me that it can have multiple FC frame ? There is no relationship between a TCP payload or segment and the FC frame boundaries. That is the nice thing about TCP. It simply delivers a string of reasonably well checked bytes in the proper order and lets the upper layers choose what to do with them. As a result, a TCP payload may have a fraction of a frame, fractions of two frames, fractions of two frames and one or more whole frames, exactly one whole frame, or multiple whole frames. FCIP does not care, as long as the transmission of a TCP payload is not unduly held up waiting for enough information to make it a certain size. Realistically, I would expect that many implementations will at least start a TCP segment on an encapsulated frame boundary, but only end on a frame boundary if there was no additional information to throw into the segment, but that is NOT part of the architecture. From owner-ips@ece.cmu.edu Mon Oct 15 19:51: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 TAA15560 for ; Mon, 15 Oct 2001 19:51:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FNVIU21462 for ips-outgoing; Mon, 15 Oct 2001 19:31: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 f9FNVGl21457 for ; Mon, 15 Oct 2001 19:31:16 -0400 (EDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel11.hp.com (Postfix) with ESMTP id 74D021F665 for ; Mon, 15 Oct 2001 16:31:07 -0700 (PDT) Received: from xpabh2.corp.hp.com (xpabh2.corp.hp.com [15.58.136.192]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 56F2F1F51F for ; Mon, 15 Oct 2001 16:31:07 -0700 (PDT) Received: by xpabh2.corp.hp.com with Internet Mail Service (5.5.2653.19) id <4S8DVK65>; Mon, 15 Oct 2001 16:31:07 -0700 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF1D2@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips@ece.cmu.edu Subject: RE: iSCSI: default values Date: Mon, 15 Oct 2001 16:27: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 I agree - especially in light of the fact that (as currently specified) an initiator can "change it's mind" about when it's ready to exit the OPN phase of login (section 5 states "In a negotiation sequence, the T bit settings in one pair of login request-responses have no bearing on the T bit settings of the next pair. An initiator having T bit set to 1 in one pair and being answered with an T bit setting of 0 may issue the next request with T bit set to 0.") so the target can't even use the setting of the T bit to decide when to assume the initiator has "implied a default selection". 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: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Monday, October 15, 2001 4:03 PM > To: ips@ece.cmu.edu > Subject: iSCSI: default values > > > Default values may be difficult to define for text keys added after > the first stable version of the spec. The problem is that an > originator who does not send a text key cannot distinguish between: > > - a responder who understands the key and implements the default AND > - a responder who does not understand the key and does something > acceptable under a version of the spec prior to introduction > of the key. > > This whole notion of omitting a key being equivalent to sending > it with its default value strikes me as potentially problematic. > I would have thought that omitting a text key was equivalent to > "Don't Care" with the default values being "RECOMMENDED" rather > than "MANDATORY". This leads to the following rule, which I think > should go in regardless: > > - An implementation whose operational correctness and/or performance > depends on the value of a text key MUST explicitly negotiate > that key. > > This is somewhat like the old adage about voting - those who do not > vote should not complain about the results, and leads to more robust > negotiation exchanges because mismatched assumptions about defaults > get exposed. > > I realize this yields additional messages in some cases, but would > suggest that the additional negotiation robustness is an offsetting > benefit. > > 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 Mon Oct 15 19:57: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 TAA15732 for ; Mon, 15 Oct 2001 19:57:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FNB8M20110 for ips-outgoing; Mon, 15 Oct 2001 19:11:08 -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 f9FNB7l20106 for ; Mon, 15 Oct 2001 19:11:07 -0400 (EDT) Received: by maho3msx2.isus.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Oct 2001 19:11:02 -0400 Message-ID: <277DD60FB639D511AC0400B0D068B71ECAD8AD@CORPMX14> From: Black_David@emc.com To: ips@ece.cmu.edu Subject: iSCSI: default values Date: Mon, 15 Oct 2001 19:02: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 Default values may be difficult to define for text keys added after the first stable version of the spec. The problem is that an originator who does not send a text key cannot distinguish between: - a responder who understands the key and implements the default AND - a responder who does not understand the key and does something acceptable under a version of the spec prior to introduction of the key. This whole notion of omitting a key being equivalent to sending it with its default value strikes me as potentially problematic. I would have thought that omitting a text key was equivalent to "Don't Care" with the default values being "RECOMMENDED" rather than "MANDATORY". This leads to the following rule, which I think should go in regardless: - An implementation whose operational correctness and/or performance depends on the value of a text key MUST explicitly negotiate that key. This is somewhat like the old adage about voting - those who do not vote should not complain about the results, and leads to more robust negotiation exchanges because mismatched assumptions about defaults get exposed. I realize this yields additional messages in some cases, but would suggest that the additional negotiation robustness is an offsetting benefit. 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 Mon Oct 15 19:58: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 TAA15753 for ; Mon, 15 Oct 2001 19:58:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9FNHO920520 for ips-outgoing; Mon, 15 Oct 2001 19:17:24 -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 f9FNHMl20515 for ; Mon, 15 Oct 2001 19:17:22 -0400 (EDT) Received: from www.platys.com (208.55.89.7) by mail16.vwh1.net (RS ver 1.0.60s) with SMTP id 046207773; Mon, 15 Oct 2001 19:17:07 -0400 (EDT) From: "Deva-Adaptec" To: Cc: Subject: iSCSI:spec 8a Mode parameters sec. 2.5.3.2 required? Date: Mon, 15 Oct 2001 16:24:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C15595.D48EF030" 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.6600 X-MS-TNEF-Correlator: X-Loop-Detect: 1 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C15595.D48EF030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I am referring spec. 8a section 2.5.3.2. Are this section and the contents required as there are no longer any mode parameters defined for iSCSI ? Thanks Deva Adaptec ------=_NextPart_000_0000_01C15595.D48EF030 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ig4XAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHCgAPABAAFwAAAAEAGQEB A5AGAKQFAAAmAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAALACsAAAAAAAMANgAA AAAAHgBwAAEAAAA1AAAAaVNDU0k6c3BlYyA4YSBNb2RlIHBhcmFtZXRlcnMgc2VjLiAyLjUuMy4y IHJlcXVpcmVkPwAAAAACAXEAAQAAABYAAAABwVXQJupTleK2wcER1aHGAKDM4QU2AAACAR0MAQAA ABUAAABTTVRQOkRFVkFAUExBVFlTLkNPTQAAAAALAAEOAAAAAEAABg4AolxU0FXBAQIBCg4BAAAA GAAAAAAAAACSnK77nh/VEaE1AKDM4QU2woAAAAsAHw4BAAAAAgEJEAEAAAAhAQAAHQEAAHIBAABM WkZ1mTg54wMACgByY3BnMTI1FjIA+Atgbg4QMDMzTwH3AqQD4wIAY2gKwHPwZXQwIAcTAoMAUARV 8QIAcHJxEhEQ5whVB7KVAoB9CoF2CJB3awuA9GQ0DGBjAFALAwu2CrFBCoBJIGFtIAlwZkcEkAUQ DyAgc3AFkC6YIDhhF6AFkHRpAiCAIDIuNS4zLhjAwRFhZSAgdGgEABg3fQBwZBmRGXAFoAIwCfB0 4wQgCXBxdWkJcRbQBCCPGrEZYQrAGXBubyAJAKcPIBQBAHB5IARiIAqx/xbgETAEkAQgAQELgBvh AhChBcBpU0NTFsA/FmRlFmRUEPBuaxCwIAlEiGV2YRZkQWRhBTBfBZAf9QBBFnMUgQAkEAAAAAsA AIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUA AAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAABShQAAJ2oBAB4ACYAIIAYAAAAAAMAAAAAAAABG AAAAAFSFAAABAAAABAAAADkuMAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAA AAAAHgALgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ADIAIIAYAAAAAAMAA AAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAALAA2ACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAA AAsAEYAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwASgAggBgAAAAAAwAAAAAAAAEYAAAAA AYUAAAAAAAALABuACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAHIAIIAYAAAAAAMAAAAAA AABGAAAAABGFAAAAAAAAAwAegAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAACAfgPAQAAABAA AACSnK77nh/VEaE1AKDM4QU2AgH6DwEAAAAQAAAAkpyu+54f1RGhNQCgzOEFNgIB+w8BAAAAjgAA AAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB+b+4AQCqADfZbgAA AEM6XFdJTk5UXFByb2ZpbGVzXGRldmFcTG9jYWwgU2V0dGluZ3NcQXBwbGljYXRpb24gRGF0YVxN aWNyb3NvZnRcT3V0bG9va1xtYWlsYm94LnBzdAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAAC8A AAA8TkZCQktCREZKQ0RNR0NCS0pMQ0pJRUtORkVBQS5kZXZhQHBsYXR5cy5jb20+AAADAAYQvsNs QwMABxCFAAAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAElBTVJFRkVSUklOR1NQRUM4QVNF Q1RJT04yNTMyQVJFVEhJU1NFQ1RJT05BTkRUSEVDT05URU5UU1JFUVVJUkVEQVNUSEVSRUFSRU5P TE9OR0VSQU5ZTU9ERVBBUkFNRVRFUlMAAAAA+Ro= ------=_NextPart_000_0000_01C15595.D48EF030-- From owner-ips@ece.cmu.edu Mon Oct 15 21: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 VAA16516 for ; Mon, 15 Oct 2001 21:27:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9G0TEB25633 for ips-outgoing; Mon, 15 Oct 2001 20:29:14 -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 f9G0Sdl25599 for ; Mon, 15 Oct 2001 20:28:59 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 60BE61F693 for ; Mon, 15 Oct 2001 17:28:33 -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 RAA02050 for ; Mon, 15 Oct 2001 17:29:57 -0700 (PDT) Message-Id: <200110160029.RAA02050@core.rose.hp.com> Date: Mon, 15 Oct 2001 17:40:26 -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: re-negotiating the same key References: <3BCB1941.652A952B@cup.hp.com> <200110151923.MAA06946@core.rose.hp.com> <3BCB5F26.65FC659@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, Let me make one comment on renegotiating the same key multiple times within a negotiation sequence. It just bothers me to to architect a mechanism into the protocol that legally requires the other party to respond even on negotiated keys any number of times. Santosh outlined a possibility below, but that does not seem to create a hard requirement to me (a reordering of negotiation should do). iSCSI does not necessarily have to cater to all possibilities - in fact, ruling out some should simplify things. Could you/anyone please comment if you see a strong requirement for such a feature? If you think it's already not allowed, could we make that explicit? Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Santosh Rao wrote: > > Mallikarjun, > > Thanks for attempting to drive this forward from its current deadlocked > position ! My comments inline. > > Thanks, > Santosh > > "Mallikarjun C." wrote: > > > > Julian and Santosh, > > > > It appears to me that there are a couple of questions > > to address, to arrive at a resolution to this change > > request - > > > > 1)Should all operational keys be sent in one > > text command PDU? (Can they, given that > > the max PDU size may be a constraint? Or, > > did the constraint go away with the recent > > set of changes that allow one key=value to > > span multiple PDUs?) > > The constraints of max receive pdu length are known only after login > negotiation of that key. > > Hence, there must be a definition of a minimum value for the > MaxRecvPDULength and implementations MUST support a minimum buffer size > of at least that value. Similar precedents exist in other protocols that > negotiate a MTU. (ex : an FC frame cannot be less than 256 bytes in > size.). > > Given that such a minimum definition is required, I would then suggest > that this minimum be capable of containing all of the operational keys > with some extra room. > > The alternative would be to require that operational parameter > negotiation be split into multiple rounds with the first round only > negotiating the recv pdu length. > > I prefer the former method due to its simplicity. > > > 2)Can keys be renegotiated to different values > > (after they were negotiated once) in the same > > negotiation sequence? > > There's nothing in the draft that prevents this. (I seem to remember > seeing text that allowed initiators to do this, but I may be mistaken > with this.) > > > > > If I understood Santosh right, he is implicitly assuming > > "yes" to (1) above - so anything that the initiator > > does not offer tantamounts to an explicit default. > > I believe this has been the working assumption so far ! If this is not a > correct assumption, I don't see how the concept of defaults can work. > How does a target know whether the initiator offered the default or not > ? > > > If > > that's the case, I agree with this view. [ Julian, please > > comment how the new key-spanning is differentiated from > > the multi-command sequence in the PDU header. ] > > > > If the answer to (2) above "yes" (which Santosh thinks > > is the case, and suggests as the answer to Julian's > > scenario), I would first of all like to understand the > > practical usage of it. > > I see nothing in the draft that prohibits an initiator from > re-negotiating a key once it obtained the result. Something along the > following lines is a possibility : > > i -> t : InitialR2T=yes > FirstBurstSize=16K > > t -> i : InitialR2T=yes > FirstBurstSize=512 > > i -> t : InitialR2T=no (initiator cannot function with a FirstBurstSize > of 512 bytes, and so, decides to turn off un-solicited data.) > > > As a first reaction, it appears > > to me to open the door for endless exchanges. > > An initiator decides when login operational negotiation is initiated and > terminated. That said, however, if you've a buggy implementation, > nothing can safeguard login from endless exchanges with the initiator > never performing a stage transition to FFP. > > ------------------------------------------------------------------- > > > Santosh Rao wrote: > > > > > > Julian Satran wrote: > > > > > > > > Santosh, > > > > > > > > The reason I am hesitant on accepting this change proposal as is that it > > > > might makes the negotiation very much state dependent and different for > > > > keys that have a default and keys that don't have one. > > > > > > I don't see why. An initiator that receives a login response needs to > > > know whether to respond to a received key anyway. It does this by some > > > mechanism like maintaining a list of keys that it sent in its login > > > command. All that is required is that the initiator include those > > > operational keys that it sent as defaults in this list. (it needs to do > > > this anyway, since usage of defaults implies the initiator is offering > > > those key values.) > > > > > > Also, when the target responds to a default offering, it is actually > > > sending back the result of the negotiation. What benefit exists in > > > having the initiator again echo this value back to the target in a > > > redundant round-trip ? > > > > > > > In addition it may > > > > change login behavior for different versions of the protocol that may have > > > > different defaults. > > > > > > Again, I don't see why. The default values accepted by both sides are > > > the defaults of the "version active" returned in the login response. > > > > > > > I admit that it has appeal for the login (where the > > > > defaults are relevant) by shortening some negotiations. > > > > > > > > However the issues it raises are multiple. Assume that you have the > > > > following sequence: > > > > > > > > I->T key1=x > > > > T->I key1=z,key2=a > > > > I->T key2=b > > > > .... > > > > > > > > Observe that the initiator designer was very conservative and probably > > > > intended to negotiate the keys one at a time > > > > while the target is aggressive and wants to set everything as soon as > > > > possible. > > > > > > I don't understand how the above scenario is correct. If key2 was an > > > operational parameter, it already has a default defined for it, and the > > > initiator cannot negotiate it one at a time, since it has already made > > > the offer (of the default) by not sending the key explicitly. > > > > > > In any case, the initiator can always re-negotiate a key by re-sending > > > the key again. I don't understand how the above example justifies the > > > need for your current model. > > > > > > > > > > > With the defaults rule the results are harder to define. > > > > > > > > With the rules we have now the results are hardly dependent on sequence. > > > > > > > > Add to this that with the new rules about PDULength exchanges are hardly > > > > "self contained" - i.e. key=value pairs can span sequences (that was > > > > another reasons I did not like this but framing at high speeds has > > > > precedence!). > > > > > > > > However we might perhaps want to consider the following loose rule for > > > > defaults in the context of operational parameter negotiation at login only > > > > (leaving the negotiation rules as they are): > > > > > > > > If the initiator issues a login request with the F bit set to 1 is assumed > > > > to have an imaginary content including all the operational keys that have a > > > > default value and where not sent yet by the initiator during login and > > > > their values set to the default value. > > > > > > Julian, the login rules are already complex enough. Why do we need to > > > special case them further and increase the complexity ? I think login > > > behaviour is quite simple to understand/follow when the initiator is > > > considered as the originator of a key if it uses default values for that > > > key. > > > > > > Thanks, > > > Santosh > > > > > > > > > > > Comments? > > > > > > > > Julo > > > > > > > > PS - and a procedural thing - nagging me repeatedly on a subject is > > > > annoying and quoting the number of agreements before attempting different > > > > scenarios is even more so > > > > > > It is unfortunate that you consider my polite requests to attempt to > > > resolve an open issue as nagging. I don't know how much more polite I > > > could possibly get. [and I am trying to discuss specific scenarios to > > > understand the issues you have with this]. > > > From owner-ips@ece.cmu.edu Mon Oct 15 21:32: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 VAA16584 for ; Mon, 15 Oct 2001 21:32:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9G0q7U27143 for ips-outgoing; Mon, 15 Oct 2001 20:52: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 f9G0q5l27136 for ; Mon, 15 Oct 2001 20:52:05 -0400 (EDT) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel2.hp.com (Postfix) with ESMTP id D28594CE for ; Mon, 15 Oct 2001 20:52:04 -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 8E0521F56B for ; Mon, 15 Oct 2001 20:52:03 -0400 (EDT) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id <40NQGT57>; Mon, 15 Oct 2001 20:52:03 -0400 Message-ID: <6BD67FFB937FD411A04F00D0B74FE87805CCF1D6@xrose06.rose.hp.com> From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" To: ips Subject: RE: iSCSI: re-negotiating the same key Date: Mon, 15 Oct 2001 20:52: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 Similar to the key re-negotiation issue, let me comment on allowing the behavior that an initiator may change it's T bit setting from 1 back to 0 within a login phase. I don't see the need to specify that the initiator may decide to recind it's offering of the T bit based on a target response. The logic I've heard cited refers to "something that might be required by vendor unique keys". You can't design a protocol for all possible theoretical behavior of vendor unique keys. We must design for the behavior that is logical for the keys which are currently specified, and vendor unique keys must adhere to that behavior. What is the need *viewing the current set of keys* for an initiator to change it's T bit setting from 1 back to 0 within a login phase? Marjorie > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, October 15, 2001 5:40 PM > To: ips > Subject: Re:iSCSI: re-negotiating the same key > > > Julian, > > Let me make one comment on renegotiating the > same key multiple times within a negotiation > sequence. > > It just bothers me to to architect a mechanism into > the protocol that legally requires the other party > to respond even on negotiated keys any number of times. > Santosh outlined a possibility below, but that does > not seem to create a hard requirement to me (a > reordering of negotiation should do). iSCSI does > not necessarily have to cater to all possibilities > - in fact, ruling out some should simplify things. > > Could you/anyone please comment if you see a > strong requirement for such a feature? If you > think it's already not allowed, could we make > that explicit? > > Regards. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Santosh Rao wrote: > > > > Mallikarjun, > > > > Thanks for attempting to drive this forward from its > current deadlocked > > position ! My comments inline. > > > > Thanks, > > Santosh > > > > "Mallikarjun C." wrote: > > > > > > Julian and Santosh, > > > > > > It appears to me that there are a couple of questions > > > to address, to arrive at a resolution to this change > > > request - > > > > > > 1)Should all operational keys be sent in one > > > text command PDU? (Can they, given that > > > the max PDU size may be a constraint? Or, > > > did the constraint go away with the recent > > > set of changes that allow one key=value to > > > span multiple PDUs?) > > > > The constraints of max receive pdu length are known only after login > > negotiation of that key. > > > > Hence, there must be a definition of a minimum value for the > > MaxRecvPDULength and implementations MUST support a minimum > buffer size > > of at least that value. Similar precedents exist in other > protocols that > > negotiate a MTU. (ex : an FC frame cannot be less than 256 bytes in > > size.). > > > > Given that such a minimum definition is required, I would > then suggest > > that this minimum be capable of containing all of the > operational keys > > with some extra room. > > > > The alternative would be to require that operational parameter > > negotiation be split into multiple rounds with the first round only > > negotiating the recv pdu length. > > > > I prefer the former method due to its simplicity. > > > > > 2)Can keys be renegotiated to different values > > > (after they were negotiated once) in the same > > > negotiation sequence? > > > > There's nothing in the draft that prevents this. (I seem to remember > > seeing text that allowed initiators to do this, but I may > be mistaken > > with this.) > > > > > > > > If I understood Santosh right, he is implicitly assuming > > > "yes" to (1) above - so anything that the initiator > > > does not offer tantamounts to an explicit default. > > > > I believe this has been the working assumption so far ! If > this is not a > > correct assumption, I don't see how the concept of defaults > can work. > > How does a target know whether the initiator offered the > default or not > > ? > > > > > If > > > that's the case, I agree with this view. [ Julian, please > > > comment how the new key-spanning is differentiated from > > > the multi-command sequence in the PDU header. ] > > > > > > If the answer to (2) above "yes" (which Santosh thinks > > > is the case, and suggests as the answer to Julian's > > > scenario), I would first of all like to understand the > > > practical usage of it. > > > > I see nothing in the draft that prohibits an initiator from > > re-negotiating a key once it obtained the result. Something > along the > > following lines is a possibility : > > > > i -> t : InitialR2T=yes > > FirstBurstSize=16K > > > > t -> i : InitialR2T=yes > > FirstBurstSize=512 > > > > i -> t : InitialR2T=no (initiator cannot function > with a FirstBurstSize > > of 512 bytes, and so, decides to turn off un-solicited data.) > > > > > As a first reaction, it appears > > > to me to open the door for endless exchanges. > > > > An initiator decides when login operational negotiation is > initiated and > > terminated. That said, however, if you've a buggy implementation, > > nothing can safeguard login from endless exchanges with the > initiator > > never performing a stage transition to FFP. > > > > ------------------------------------------------------------------- > > > > > Santosh Rao wrote: > > > > > > > > Julian Satran wrote: > > > > > > > > > > Santosh, > > > > > > > > > > The reason I am hesitant on accepting this change > proposal as is that it > > > > > might makes the negotiation very much state dependent > and different for > > > > > keys that have a default and keys that don't have one. > > > > > > > > I don't see why. An initiator that receives a login > response needs to > > > > know whether to respond to a received key anyway. It > does this by some > > > > mechanism like maintaining a list of keys that it sent > in its login > > > > command. All that is required is that the initiator > include those > > > > operational keys that it sent as defaults in this list. > (it needs to do > > > > this anyway, since usage of defaults implies the > initiator is offering > > > > those key values.) > > > > > > > > Also, when the target responds to a default offering, > it is actually > > > > sending back the result of the negotiation. What > benefit exists in > > > > having the initiator again echo this value back to the > target in a > > > > redundant round-trip ? > > > > > > > > > In addition it may > > > > > change login behavior for different versions of the > protocol that may have > > > > > different defaults. > > > > > > > > Again, I don't see why. The default values accepted by > both sides are > > > > the defaults of the "version active" returned in the > login response. > > > > > > > > > I admit that it has appeal for the login (where the > > > > > defaults are relevant) by shortening some negotiations. > > > > > > > > > > However the issues it raises are multiple. Assume > that you have the > > > > > following sequence: > > > > > > > > > > I->T key1=x > > > > > T->I key1=z,key2=a > > > > > I->T key2=b > > > > > .... > > > > > > > > > > Observe that the initiator designer was very > conservative and probably > > > > > intended to negotiate the keys one at a time > > > > > while the target is aggressive and wants to set > everything as soon as > > > > > possible. > > > > > > > > I don't understand how the above scenario is correct. > If key2 was an > > > > operational parameter, it already has a default defined > for it, and the > > > > initiator cannot negotiate it one at a time, since it > has already made > > > > the offer (of the default) by not sending the key explicitly. > > > > > > > > In any case, the initiator can always re-negotiate a > key by re-sending > > > > the key again. I don't understand how the above example > justifies the > > > > need for your current model. > > > > > > > > > > > > > > With the defaults rule the results are harder to define. > > > > > > > > > > With the rules we have now the results are hardly > dependent on sequence. > > > > > > > > > > Add to this that with the new rules about PDULength > exchanges are hardly > > > > > "self contained" - i.e. key=value pairs can span > sequences (that was > > > > > another reasons I did not like this but framing at > high speeds has > > > > > precedence!). > > > > > > > > > > However we might perhaps want to consider the > following loose rule for > > > > > defaults in the context of operational parameter > negotiation at login only > > > > > (leaving the negotiation rules as they are): > > > > > > > > > > If the initiator issues a login request with the F > bit set to 1 is assumed > > > > > to have an imaginary content including all the > operational keys that have a > > > > > default value and where not sent yet by the initiator > during login and > > > > > their values set to the default value. > > > > > > > > Julian, the login rules are already complex enough. Why > do we need to > > > > special case them further and increase the complexity ? > I think login > > > > behaviour is quite simple to understand/follow when the > initiator is > > > > considered as the originator of a key if it uses > default values for that > > > > key. > > > > > > > > Thanks, > > > > Santosh > > > > > > > > > > > > > > Comments? > > > > > > > > > > Julo > > > > > > > > > > PS - and a procedural thing - nagging me repeatedly > on a subject is > > > > > annoying and quoting the number of agreements before > attempting different > > > > > scenarios is even more so > > > > > > > > It is unfortunate that you consider my polite requests > to attempt to > > > > resolve an open issue as nagging. I don't know how much > more polite I > > > > could possibly get. [and I am trying to discuss > specific scenarios to > > > > understand the issues you have with this]. > > > > > From owner-ips@ece.cmu.edu Tue Oct 16 03: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 DAA06748 for ; Tue, 16 Oct 2001 03:05:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9G62Tv16866 for ips-outgoing; Tue, 16 Oct 2001 02:02: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 f9G62Rl16861 for ; Tue, 16 Oct 2001 02:02:28 -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 IAA55382 for ; Tue, 16 Oct 2001 08:02:21 +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 f9G62Ks119854 for ; Tue, 16 Oct 2001 08:02:20 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: [Fwd: iSCSI - revised 2.2.4] X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 16 Oct 2001 09:02:17 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 16/10/2001 09:02:19, Serialize complete at 16/10/2001 09:02:20, Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 16/10/2001 09:02:20 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, I suggest you read the message completely and carefully and answer afterwards. Julo Santosh Rao Sent by: santoshr@cup.hp.com 15-10-01 19:13 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: [Fwd: iSCSI - revised 2.2.4] Julian Satran wrote: > > Santosh, > > The reason I am hesitant on accepting this change proposal as is that it > might makes the negotiation very much state dependent and different for > keys that have a default and keys that don't have one. I don't see why. An initiator that receives a login response needs to know whether to respond to a received key anyway. It does this by some mechanism like maintaining a list of keys that it sent in its login command. All that is required is that the initiator include those operational keys that it sent as defaults in this list. (it needs to do this anyway, since usage of defaults implies the initiator is offering those key values.) Also, when the target responds to a default offering, it is actually sending back the result of the negotiation. What benefit exists in having the initiator again echo this value back to the target in a redundant round-trip ? > In addition it may > change login behavior for different versions of the protocol that may have > different defaults. Again, I don't see why. The default values accepted by both sides are the defaults of the "version active" returned in the login response. > I admit that it has appeal for the login (where the > defaults are relevant) by shortening some negotiations. > > However the issues it raises are multiple. Assume that you have the > following sequence: > > I->T key1=x > T->I key1=z,key2=a > I->T key2=b > .... > > Observe that the initiator designer was very conservative and probably > intended to negotiate the keys one at a time > while the target is aggressive and wants to set everything as soon as > possible. I don't understand how the above scenario is correct. If key2 was an operational parameter, it already has a default defined for it, and the initiator cannot negotiate it one at a time, since it has already made the offer (of the default) by not sending the key explicitly. In any case, the initiator can always re-negotiate a key by re-sending the key again. I don't understand how the above example justifies the need for your current model. > > With the defaults rule the results are harder to define. > > With the rules we have now the results are hardly dependent on sequence. > > Add to this that with the new rules about PDULength exchanges are hardly > "self contained" - i.e. key=value pairs can span sequences (that was > another reasons I did not like this but framing at high speeds has > precedence!). > > However we might perhaps want to consider the following loose rule for > defaults in the context of operational parameter negotiation at login only > (leaving the negotiation rules as they are): > > If the initiator issues a login request with the F bit set to 1 is assumed > to have an imaginary content including all the operational keys that have a > default value and where not sent yet by the initiator during login and > their values set to the default value. Julian, the login rules are already complex enough. Why do we need to special case them further and increase the complexity ? I think login behaviour is quite simple to understand/follow when the initiator is considered as the originator of a key if it uses default values for that key. Thanks, Santosh > > Comments? > > Julo > > PS - and a procedural thing - nagging me repeatedly on a subject is > annoying and quoting the number of agreements before attempting different > scenarios is even more so It is unfortunate that you consider my polite requests to attempt to resolve an open issue as nagging. I don't know how much more polite I could possibly get. [and I am trying to discuss specific scenarios to understand the issues you have with this]. > > > Santosh Rao > > hp.com> cc: > Sent by: Subject: [Fwd: iSCSI - revised 2.2.4] > owner-ips@ece. > cmu.edu > > > 11-10-01 01:36 > Please respond > to Santosh Rao > > > > Julian, > > What is the resolution on this issue ? > > - Santosh > > Santosh Rao wrote: > > > > Julian, > > > > I apologize upfront for being so persistent on this. > > > > However, it would really help if you could give some clear example of a > > scenario as to why the initiator cannot be considered the originator of > > a negotiation, when it offers a key value implicitly, through the use of > > a default. > > > > Several people on this list (Paul Konning, Sanjeev, Deva, myself, and > > perhaps others, that I cannot recall at the moment) have asked that the > > spec must not differentiate login behaviour when the initiator offers a > > key explicitly vs. when it offers a key implicitly thru the use of the > > default. > > > > Please help us understand the need for iscsi to distingush the login > > behaviour in the above case. [through some tangible scenarios and > > examples]. > > > > Thanks, > > Santosh > > > > > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote: > > > > > > Julian, > > > > > > I would also request an explicit definition of offering party and > > > responding party. The current text still leaves ambiguity when target > > > sends a key in response to implicit default key of the Intiator. In > > > this case who is the offering party and who is the responding party > > > > > > Sanjeev > > > > > > -----Original Message----- > > > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > > > Sent: Friday, October 05, 2001 2:06 PM > > > To: ips@ece.cmu.edu > > > Subject: iSCSI - revised 2.2.4 > > > > > > Here is a revised (complete) part 2.2.4 based on recent > > > agreed changes: > > > > > > 1.1.1 Text Mode Negotiation > > > > > > During login and thereafter some session or connection > > > parameters are negotiated through an exchange of textual > > > information. > > > > > > All negotiations are stateless - i.e. the result MUST be > > > based only on newly exchanged values. > > > > > > The general format of text negotiation is: > > > > > > Originator-> = > > > Responder-> =|reject|NotUnderstood > > > > > > The value can be a number, a single literal constant a > > > Boolean value (yes or no) or a list of comma separated > > > literal constant values. > > > > > > In literal list negotiation, the originator sends for each > > > key a list of options (literal constants which may include > > > "none") in its order of preference. > > > > > > The responding party answers with the first value from the > > > list it supports and is allowed to use for the specific > > > originator. > > > > > > The constant "none" MUST always be used to indicate a > > > missing function. However, none is a valid selection only if > > > it is explicitly offered. > > > > > > If a target is not supporting, or not allowed to use with a > > > specific originator, any of the offered options, it may use > > > the constant "reject". The constants "none" and "reject" > > > are reserved and must be used only as described here. Any > > > key not understood is answered with "NotUnderstood". > > > > > > For numerical and single literal negotiations, the > > > responding party MUST respond with the required key and the > > > value it selects, based on the selection rule specific to > > > the key, becomes the negotiation result. Selection of a > > > value not admissible under the selection rules is considered > > > a protocol error and handled accordingly. > > > > > > For Boolean negotiations (keys taking the values yes or no), > > > the responding party MUST respond with the required key and > > > the result of the negotiation when the received value does > > > not determine that result by itself. The last value > > > transmitted becomes the negotiation result. The rules for > > > selecting the value to respond with are expressed as Boolean > > > functions of the value received and the value that the > > > responding party would select in the absence of knowledge of > > > the received value. > > > > > > Specifically, the two cases in which responses are OPTIONAL > > > are: > > > > > > - The Boolean function is "AND" and the value "no" is > > > received. The outcome of the negotiation is "no". > > > - The Boolean function is "OR" and the value "yes" is > > > received. The outcome of the negotiation is "yes". > > > > > > Responses are REQUIRED in all other cases, and the value > > > chosen and sent by the responder becomes the outcome of the > > > negotiation. > > > > > > The value "?" with any key has the meaning of enquiry and > > > should be answered with the current value or > > > "NotUnderstood". > > > > > > 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, only the initiator can > > > initiate the negotiation start (through the first Text > > > request) and completion (by setting to 1 and keeping to 1 > > > the F bit in a Text request). > > > > > > Comments ? > > > > > > 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 Tue Oct 16 08:06: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 IAA10914 for ; Tue, 16 Oct 2001 08:06:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GBNvo15698 for ips-outgoing; Tue, 16 Oct 2001 07:23:57 -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 f9GB6Jl14705 for ; Tue, 16 Oct 2001 07:06:19 -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 HAA08844; Tue, 16 Oct 2001 07:06:16 -0400 (EDT) Message-Id: <200110161106.HAA08844@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-isns-mib-00.txt Date: Tue, 16 Oct 2001 07:06:16 -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 : Definitions of Managed Objects for iSNS (Internet Storage Name Service) Author(s) : K. Gibbons, J. Tseng, C. Monia, T. McSweeney Filename : draft-ietf-ips-isns-mib-00.txt Pages : 45 Date : 15-Oct-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based monitoring and management of an internet Storage Name Service (iSNS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-isns-mib-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-ietf-ips-isns-mib-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-ietf-ips-isns-mib-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: <20011015133444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-isns-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-isns-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011015133444.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Tue Oct 16 13:24: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 NAA11600 for ; Tue, 16 Oct 2001 13:24:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GGiFT09825 for ips-outgoing; Tue, 16 Oct 2001 12:44:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9GGiCl09815 for ; Tue, 16 Oct 2001 12:44:13 -0400 (EDT) Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9GGiBk10189 for ; Tue, 16 Oct 2001 09:44:11 -0700 (PDT) Received: from DAPW2K (dhcp-161-44-68-108.cisco.com [161.44.68.108]) by sponge.cisco.com (Mirapoint) with SMTP id AAQ02841; Tue, 16 Oct 2001 11:41:25 -0500 (CDT) From: "Dave Peterson" To: "Ips@Ece. Cmu. Edu" Subject: iSCSI: MaxBurstSize clarification Date: Tue, 16 Oct 2001 11:43:57 -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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The most recent text I could find regarding MaxBurstSize: "Initiator and target negotiate maximum SCSI data payload in bytes in an Data-In or a solicited Data-Out 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)." Given the text above and a negotiated MaxBurstSize=64k, if the target receives a 256k read request the target is required to send four 64k sequences. IOW, the target is not allowed to send a 256k sequence. Correct? Dave From owner-ips@ece.cmu.edu Tue Oct 16 13:27: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 NAA11723 for ; Tue, 16 Oct 2001 13:27:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GGYxc09108 for ips-outgoing; Tue, 16 Oct 2001 12:34:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9GGYvl09103 for ; Tue, 16 Oct 2001 12:34:58 -0400 (EDT) Received: from sponge.cisco.com (sponge.cisco.com [64.101.128.87]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9GGYwg16990 for ; Tue, 16 Oct 2001 09:34:58 -0700 (PDT) Received: from DAPW2K (dhcp-161-44-68-108.cisco.com [161.44.68.108]) by sponge.cisco.com (Mirapoint) with SMTP id AAQ02714; Tue, 16 Oct 2001 11:32:12 -0500 (CDT) From: "Dave Peterson" To: "Ips@Ece. Cmu. Edu" Subject: iSCSI: DataPDUInOrder/DataSequenceInOrder and EMDP Date: Tue, 16 Oct 2001 11:34:45 -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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rev 08 no longer contains any text specifying the relationship between the DataPDUInOrder/DataSequenceInOrder text keys and the SCSI Mode Page EMDP bit. Is this intentional or a side-effect of the removal of the SCSI disconnect-reconnect text? Dave From owner-ips@ece.cmu.edu Tue Oct 16 13:46: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 NAA12382 for ; Tue, 16 Oct 2001 13:46:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GGJZr07656 for ips-outgoing; Tue, 16 Oct 2001 12:19:35 -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 f9GGJXl07652 for ; Tue, 16 Oct 2001 12:19:34 -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 JAA05033; Tue, 16 Oct 2001 09:02:55 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWV6MG6>; Tue, 16 Oct 2001 09:02:54 -0700 Message-ID: From: Robert Snively To: "'Rod Harrison'" , Julian Satran , ips@ece.cmu.edu Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU Date: Tue, 16 Oct 2001 09:02:50 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I am not quite sure what meaning "in-order" data has in a multi-connection session. Does it mean that you actually expect the data across multiple connections to arrive temporally in the same order that is specified by the command sequence numbers? Or does it mean that the data has to be arranged in some order by the target session processing? Or is it better to step aside from the in-order question for data transmission and do as Rob Harrison suggests: "As an initiator I would send the command PDU as soon as I could if there were no immediate data, then queue the DMA for the unsolicited data. Since there could be many other DMAs queued ahead of the unsolicited data it is quite possible that other commands, both read and write, will be sent before the DMA completes." This would imply no strict ordering requirement. If an ordering requirement is necessary, I submit that it is because of the problems with unsolicited data reception, not with the actual data order. Bob > -----Original Message----- > From: Rod Harrison [mailto:rod.harrison@windriver.com] > Sent: Monday, October 15, 2001 4:06 AM > To: Julian Satran; ips@ece.cmu.edu > Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU > > > Julian, > > I think you might have misunderstood what I meant. I was not > advocating we change the spec in favour of relaxing the data ordering > requirements. I was just point out there is a problem for the > initiator to solve in order maintain correct ordering, and that I > believe it is not a terribly difficult one. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Sunday, October 14, 2001 9:30 PM > To: ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > > Immediate data are not mandatory (even if enabled). Having one or ten > DMAs > does not change the fact that they share a TCP "pipe" and a decent > transmitter will ship the TCP data in order - otherwise it just throws > his > problems in the receiver's lap. Our additional requirement on order > should > make no difference. And it would be time to change the name of the > thread. > > Julo > > > > > > "Rod Harrison" > Jose/IBM@IBMUS, "Robert > river.com> Snively" > > Sent by: cc: > , > owner-ips@ece.cmu. "BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2)" > edu > , "'Binford, Charles'" > , > > Subject: RE: Addition > of CmdSN in Data-out PDU > 13-10-01 13:12 > Please respond to > "Rod Harrison" > > > > > > > Even more common would be the DMA latency. As an initiator > I > would > send the command PDU as soon as I could if there were no immediate > data, then queue the DMA for the unsolicited data. Since there could > be many other DMAs queued ahead of the unsolicited data it is quite > possible that other commands, both read and write, will be sent before > the DMA completes. > > You are spot one when you say the delay in obtaining the > unsolicited > data may be large and variable. If there are multiple DMA engines it > does become a challenge for the initiator to ensure the correct > ordering of the unsolicited data. Note that since there may be > multiple unsolicited data PDUs in the same burst, and those may be > filled with separate DMAs the ordering problem propagates down to > within individual commands. > > I don't believe it is a particularly difficult problem for > the > initiator to solve, but I do agree things would be easier for the > initiator if the ordering requirement were removed. And more so if the > requirement to send in dataSN order were also removed, but this is > probably too much pain for the target. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > John Hufferd > Sent: Saturday, October 13, 2001 1:01 AM > To: Robert Snively > Cc: 'somesh_gupta@silverbacksystems.com'; BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2); 'Binford, Charles'; ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > > Robert, > I think that an Initiator being able to send a waiting Read command, > without having to wait for many large write segments -- that are being > sent > (as unsolicited data) -- is very useful. And that would mean, the > unsolicited data is waiting to be sent until the Read Commands are > sent. > This might be a very frequent case. > > . > . > . > 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 10/12/2001 > 03:56:06 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: "'somesh_gupta@silverbacksystems.com'" > , "BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2)" , "'Binford, > Charles'" , ips@ece.cmu.edu > cc: > Subject: RE: Addition of CmdSN in Data-out PDU > > > > I have two small questions that would help me understand this. > > How do you know that unsolicited data is expected? By nature, > unsolicited data is received as a "maximum surprise" which can > only be determined after unpacking and parsing at least a > part of the command structure, possibly even including the > SCSI command (although there are some hints contained in the > command header information). > > How can you constrain a generic system to posting the > unsolicited data in the same order that the commands were > emitted? In general, I would have expected the system to > be emitting command followed immediately by the corresponding > unsolicited data. If that is not the case, it means that there > was a delay in obtaining the unsolicited data for transfer and > that the delay was sufficient to allow the insertion of commands. > If the delay is that large (and probably variable), the enforcement > of transfer of unsolicited data in the same order as the > commands are emitted seems to me to be a significant challenge, > and certainly shouldn't be required as normal behavior. While it > would make things simpler for targets (already challenged by > unsolicited data), it seems to me that it would make things > much more complex for initiators. > > Bob > > > -----Original Message----- > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > > Sent: Friday, October 12, 2001 2:51 PM > > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > > ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Matthew, > > > > Since the unsolicited data does not follow the > > command, you need the link list. But since the > > unsolicited data must be sent in the same order > > as the commands, a link list is enough. > > > > Let us say that you have 8 commands. The ones > > for which we expect unsolicted data are marked > > as Cnn(ud). And I have marked the unsolicted > > data PDUs as UD(nn). The (nn) with data implies > > that it is implicit and not actually carried with > > the PDU itself. > > > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > > --> UD(07) C08(ud) UD(08) ---> > > > > After the target receives the command C01, C02, and C03 > > for which it expects unsolicited data, it puts them in > > a link list. It also receives C04 and C05 for which > > unsolicited data is not expected and they don't go > > on the list. It then receives C06 for which unsolicited > > data is expected, and it is added to then end of the list. > > Then an unsolicited data PDU is received. It must go > > with the command at the head of the list which is C01. > > Use the ITT to make sure and you can then take C01 off > > the list and so on. > > > > Somesh > > > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > > Sent: Friday, October 12, 2001 7:53 AM > > > To: 'Binford, Charles'; ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > Charles, > > > > > > As you have described the spec states that "that > > unsolicited data MUST be > > > sent in the same order as the commands". This is not the same as > > > unsolicited data must follow the command associated with > > it: For example: > > > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > > x in all the > > > example can be the ITT. It is not the CmdSN. > > > > > > This is allowed: > > > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > > > and the target will have to use the ITT to associate the > > data with the > > > command. > > > > > > Matthew > > > > > > > > > -----Original Message----- > > > From: Binford, Charles [mailto:CBinford@pirus.com] > > > Sent: Friday, October 12, 2001 2:50 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > I have not verify version 8 is still the same, but version 07-97 > > > had a rule > > > that unsolicited data MUST be sent in the same order as the > > commands. > > > > > > Thus, there is no need for a search on the ITT. The target > > just needs to > > > keep of linked list of I/Os waiting on unsolicited data. > > New commands are > > > added to the tail, any unsolicited data *should* be associated > > > with the I/O > > > at the head of the list. The ITT is used as a sanity check and > > > you're done. > > > > > > What am I missing? > > > > > > Charles Binford > > > Pirus Networks > > > 316.315.0382 x222 > > > > > > > > From owner-ips@ece.cmu.edu Tue Oct 16 14:24: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 OAA14087 for ; Tue, 16 Oct 2001 14:24:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GH3ke11479 for ips-outgoing; Tue, 16 Oct 2001 13:03:46 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9GH3jl11475 for ; Tue, 16 Oct 2001 13:03:45 -0400 (EDT) Received: from nc8220exchange.ral.lucent.com (h135-92-100-21.lucent.com [135.92.100.21]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9GH3ch02758 for ; Tue, 16 Oct 2001 13:03:38 -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: Internet-Draft Cutoff Dates for Salt Lake City, Utah Date: Tue, 16 Oct 2001 13:03:37 -0400 Message-ID: <9410A0F67DFE7F4D998D45382364983617B1F4@nc8220exchange.ral.lucent.com> Thread-Topic: Internet-Draft Cutoff Dates for Salt Lake City, Utah Thread-Index: AcFWY2n6jcur1MxKR7WI5Mz53LjMYAAALm0Q 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 f9GH3jl11476 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, The cutoff dates for drafts to be considered at the Salt Lake City meeting have been posted. Nov 14 @ 5pm EST is the cutoff for all NEW drafts (e.g. those ending in -00) Nov 21 @ 5pm EST is the cutoff for all revision drafts. These are both Wednesdays. I am assuming the Wed dates were selected because of Thanksgiving, which falls on Nov 22. Thanks, Elizabeth -----Original Message----- From: Internet-Drafts Administrator [mailto:internet-drafts@ietf.org] Sent: Tuesday, October 16, 2001 9:43 AM To: IETF-Announce; @loki.ietf.org@horh1.emsr.lucent.com Subject: Internet-Draft Cutoff Dates for Salt Lake City, Utah NOTE: There are two (2) Internet-Draft Cutoff dates November 14th: Cutoff for Initial Submissions (new documents) All initial submissions(-00) must be submitted by Friday, November 14th, 17:00 US-EST. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, November 19th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of November 14th will NOT be accepted. November 21st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Friday, November 21st, 2001 at 17:00 US-EST. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_52.html From owner-ips@ece.cmu.edu Tue Oct 16 14:30: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 OAA14288 for ; Tue, 16 Oct 2001 14:30:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GGwVn11080 for ips-outgoing; Tue, 16 Oct 2001 12:58:31 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9GGwTl11075 for ; Tue, 16 Oct 2001 12:58:29 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id RAA68224 for ; Tue, 16 Oct 2001 17:37:59 +0100 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 f9GGrno28190 for ; Tue, 16 Oct 2001 18:53:49 +0200 Subject: iSCSI - negotiating against defaults/renegotiation the same key To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 16 Oct 2001 19:51:09 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 16/10/2001 19:53:49 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, I think that my previous proposal about negotiating against defaults is flawed. I was based on the simple-minded assumption that after the initiator has said all he had to say (as evidenced by the T=1) the target may assume that the values the target puts forward are against default. I even prepared a text in 5.3 that read: When the initiator issues a login request with the T bit set to 1 the target MUST assume that this request includes also an "imaginary content". The "imaginary content" consists of key=value pairs including all the operational keys that have a default value and where not sent yet by the initiator during the operational parameter negotiation. The values in the "imaginary content" are the key default values. This enables an initiator to avoid sending all the defaults while the target may negotiate as if they where sent. But that was wrong. Here is a simple example: A simple initiator may issue a first login entering the operational negotiation and having T=1 and nothing beyond the 2 names: I->T Iname... Tname This means only that he does not care about things like MaxBurst and is content with defaults. The target (in my proposal prompted by Santosh's request) can't do anything but lower the value while under our simple rule of self contained negotiations he could ask for a burst increase and the negotiation could have proceeded. For this (and a several other scenarios that you can easily build) I suggest we stick with our "old" rule that a negotiation must be completely "self contained". Now about the other two subjects: 1-Multiple negotiations on one key - we may choose one of the following ways out: a)say that both initiator and target MAY drop the login if that happens (and close the connection) b)say that both initiator and target MUST drop the login if that happens (and close the connection) c)say that this is legitimate (a negotiated parameter change due to a later change not know when the negotiation started) d)say that the whole sequence of Login request/responses is a a "single single virtual exchange" and the last value is the single one that counts in every direction - this one is somewhat related to the length question but does not allow branching decisions I am would favor a) 2. Text block length - we gave away (for a while) on our 4k text messages. That makes negotiation difficult and might somehow help some of the framing schemes: I think we may want to do one of the following: a) mandate that the default 8k is valid during login and change only at end of login b) get back to a separate length for text and fix it at 4 or 8k (not ideal for framing) Option a may solve the login issue but leaves us with an ugly text negotiation. Option b will require the framing folks to come up with a solution (works with markers though). I am in favor of b (a different and predefined length for text buffers) and return to the "complete" negotiation buffers that raise far less logical problems that the concatenation scheme we are (temporarily in). Julo From owner-ips@ece.cmu.edu Tue Oct 16 14: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 OAA14492 for ; Tue, 16 Oct 2001 14:35:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GHR8C13607 for ips-outgoing; Tue, 16 Oct 2001 13:27:08 -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 f9GHR3l13595 for ; Tue, 16 Oct 2001 13:27:03 -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 TAA96040 for ; Tue, 16 Oct 2001 19:26: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 f9GGrio40146 for ; Tue, 16 Oct 2001 18:53:44 +0200 Subject: RE: iSCSI: re-negotiating the same key To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Tue, 16 Oct 2001 19:04:09 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 16/10/2001 19:53:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Marjorie, If a target initiates a negotiations that may require a sequence of requests responses (like in security or even is simple operational exchanges) the initiator amy have to change back form T=1 to T=0 (in security thee are some obvious examples). Also on negotiating with defaults I'll have to get back to arguing against it as the proposal I had earlier won't work well - But I'll take it to another thread. Julo "KRUEGER,MARJOR IE To: ips (HP-Roseville,e cc: x1)" Subject: RE: iSCSI: re-negotiating the same Sent by: owner-ips@ece.c mu.edu 16-10-01 02:52 Please respond to "KRUEGER,MARJOR IE (HP-Roseville,e x1)" Similar to the key re-negotiation issue, let me comment on allowing the behavior that an initiator may change it's T bit setting from 1 back to 0 within a login phase. I don't see the need to specify that the initiator may decide to recind it's offering of the T bit based on a target response. The logic I've heard cited refers to "something that might be required by vendor unique keys". You can't design a protocol for all possible theoretical behavior of vendor unique keys. We must design for the behavior that is logical for the keys which are currently specified, and vendor unique keys must adhere to that behavior. What is the need *viewing the current set of keys* for an initiator to change it's T bit setting from 1 back to 0 within a login phase? Marjorie > -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > Sent: Monday, October 15, 2001 5:40 PM > To: ips > Subject: Re:iSCSI: re-negotiating the same key > > > Julian, > > Let me make one comment on renegotiating the > same key multiple times within a negotiation > sequence. > > It just bothers me to to architect a mechanism into > the protocol that legally requires the other party > to respond even on negotiated keys any number of times. > Santosh outlined a possibility below, but that does > not seem to create a hard requirement to me (a > reordering of negotiation should do). iSCSI does > not necessarily have to cater to all possibilities > - in fact, ruling out some should simplify things. > > Could you/anyone please comment if you see a > strong requirement for such a feature? If you > think it's already not allowed, could we make > that explicit? > > Regards. > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Santosh Rao wrote: > > > > Mallikarjun, > > > > Thanks for attempting to drive this forward from its > current deadlocked > > position ! My comments inline. > > > > Thanks, > > Santosh > > > > "Mallikarjun C." wrote: > > > > > > Julian and Santosh, > > > > > > It appears to me that there are a couple of questions > > > to address, to arrive at a resolution to this change > > > request - > > > > > > 1)Should all operational keys be sent in one > > > text command PDU? (Can they, given that > > > the max PDU size may be a constraint? Or, > > > did the constraint go away with the recent > > > set of changes that allow one key=value to > > > span multiple PDUs?) > > > > The constraints of max receive pdu length are known only after login > > negotiation of that key. > > > > Hence, there must be a definition of a minimum value for the > > MaxRecvPDULength and implementations MUST support a minimum > buffer size > > of at least that value. Similar precedents exist in other > protocols that > > negotiate a MTU. (ex : an FC frame cannot be less than 256 bytes in > > size.). > > > > Given that such a minimum definition is required, I would > then suggest > > that this minimum be capable of containing all of the > operational keys > > with some extra room. > > > > The alternative would be to require that operational parameter > > negotiation be split into multiple rounds with the first round only > > negotiating the recv pdu length. > > > > I prefer the former method due to its simplicity. > > > > > 2)Can keys be renegotiated to different values > > > (after they were negotiated once) in the same > > > negotiation sequence? > > > > There's nothing in the draft that prevents this. (I seem to remember > > seeing text that allowed initiators to do this, but I may > be mistaken > > with this.) > > > > > > > > If I understood Santosh right, he is implicitly assuming > > > "yes" to (1) above - so anything that the initiator > > > does not offer tantamounts to an explicit default. > > > > I believe this has been the working assumption so far ! If > this is not a > > correct assumption, I don't see how the concept of defaults > can work. > > How does a target know whether the initiator offered the > default or not > > ? > > > > > If > > > that's the case, I agree with this view. [ Julian, please > > > comment how the new key-spanning is differentiated from > > > the multi-command sequence in the PDU header. ] > > > > > > If the answer to (2) above "yes" (which Santosh thinks > > > is the case, and suggests as the answer to Julian's > > > scenario), I would first of all like to understand the > > > practical usage of it. > > > > I see nothing in the draft that prohibits an initiator from > > re-negotiating a key once it obtained the result. Something > along the > > following lines is a possibility : > > > > i -> t : InitialR2T=yes > > FirstBurstSize=16K > > > > t -> i : InitialR2T=yes > > FirstBurstSize=512 > > > > i -> t : InitialR2T=no (initiator cannot function > with a FirstBurstSize > > of 512 bytes, and so, decides to turn off un-solicited data.) > > > > > As a first reaction, it appears > > > to me to open the door for endless exchanges. > > > > An initiator decides when login operational negotiation is > initiated and > > terminated. That said, however, if you've a buggy implementation, > > nothing can safeguard login from endless exchanges with the > initiator > > never performing a stage transition to FFP. > > > > ------------------------------------------------------------------- > > > > > Santosh Rao wrote: > > > > > > > > Julian Satran wrote: > > > > > > > > > > Santosh, > > > > > > > > > > The reason I am hesitant on accepting this change > proposal as is that it > > > > > might makes the negotiation very much state dependent > and different for > > > > > keys that have a default and keys that don't have one. > > > > > > > > I don't see why. An initiator that receives a login > response needs to > > > > know whether to respond to a received key anyway. It > does this by some > > > > mechanism like maintaining a list of keys that it sent > in its login > > > > command. All that is required is that the initiator > include those > > > > operational keys that it sent as defaults in this list. > (it needs to do > > > > this anyway, since usage of defaults implies the > initiator is offering > > > > those key values.) > > > > > > > > Also, when the target responds to a default offering, > it is actually > > > > sending back the result of the negotiation. What > benefit exists in > > > > having the initiator again echo this value back to the > target in a > > > > redundant round-trip ? > > > > > > > > > In addition it may > > > > > change login behavior for different versions of the > protocol that may have > > > > > different defaults. > > > > > > > > Again, I don't see why. The default values accepted by > both sides are > > > > the defaults of the "version active" returned in the > login response. > > > > > > > > > I admit that it has appeal for the login (where the > > > > > defaults are relevant) by shortening some negotiations. > > > > > > > > > > However the issues it raises are multiple. Assume > that you have the > > > > > following sequence: > > > > > > > > > > I->T key1=x > > > > > T->I key1=z,key2=a > > > > > I->T key2=b > > > > > .... > > > > > > > > > > Observe that the initiator designer was very > conservative and probably > > > > > intended to negotiate the keys one at a time > > > > > while the target is aggressive and wants to set > everything as soon as > > > > > possible. > > > > > > > > I don't understand how the above scenario is correct. > If key2 was an > > > > operational parameter, it already has a default defined > for it, and the > > > > initiator cannot negotiate it one at a time, since it > has already made > > > > the offer (of the default) by not sending the key explicitly. > > > > > > > > In any case, the initiator can always re-negotiate a > key by re-sending > > > > the key again. I don't understand how the above example > justifies the > > > > need for your current model. > > > > > > > > > > > > > > With the defaults rule the results are harder to define. > > > > > > > > > > With the rules we have now the results are hardly > dependent on sequence. > > > > > > > > > > Add to this that with the new rules about PDULength > exchanges are hardly > > > > > "self contained" - i.e. key=value pairs can span > sequences (that was > > > > > another reasons I did not like this but framing at > high speeds has > > > > > precedence!). > > > > > > > > > > However we might perhaps want to consider the > following loose rule for > > > > > defaults in the context of operational parameter > negotiation at login only > > > > > (leaving the negotiation rules as they are): > > > > > > > > > > If the initiator issues a login request with the F > bit set to 1 is assumed > > > > > to have an imaginary content including all the > operational keys that have a > > > > > default value and where not sent yet by the initiator > during login and > > > > > their values set to the default value. > > > > > > > > Julian, the login rules are already complex enough. Why > do we need to > > > > special case them further and increase the complexity ? > I think login > > > > behaviour is quite simple to understand/follow when the > initiator is > > > > considered as the originator of a key if it uses > default values for that > > > > key. > > > > > > > > Thanks, > > > > Santosh > > > > > > > > > > > > > > Comments? > > > > > > > > > > Julo > > > > > > > > > > PS - and a procedural thing - nagging me repeatedly > on a subject is > > > > > annoying and quoting the number of agreements before > attempting different > > > > > scenarios is even more so > > > > > > > > It is unfortunate that you consider my polite requests > to attempt to > > > > resolve an open issue as nagging. I don't know how much > more polite I > > > > could possibly get. [and I am trying to discuss > specific scenarios to > > > > understand the issues you have with this]. > > > > > From owner-ips@ece.cmu.edu Tue Oct 16 14:56: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 OAA15409 for ; Tue, 16 Oct 2001 14:56:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GIRea18776 for ips-outgoing; Tue, 16 Oct 2001 14: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 f9GIRdl18771 for ; Tue, 16 Oct 2001 14:27:39 -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 OAA01095; Tue, 16 Oct 2001 14:24:57 -0400 (EDT) Message-ID: <3BCC794F.57A9BC79@cisco.com> Date: Tue, 16 Oct 2001 13:15: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: Santosh Rao CC: IPS Reflector Subject: Re: iscsi : HeaderDigest & DataDigest as operational keys ? References: <3BCC7ACF.84BCD3D9@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 I agree with Santosh; the keys are in with security for purely historical reasons, since there used to be a few cryptographic digest methods defined that depended on the authentication methods. Santosh Rao wrote: > > Julian, > > Can the keys HeaderDigest & DataDigest be moved to operational keys, > instead of their current location in security keys ? > > This would allow an initiator that is using header & data digests, but > no security authentication to complete all of its login key negotiation > in 1 phase, namely, the operational phase. It reduces login to a single > handshake for initiators that do not perform security authentication. > > The digest keys are meant for data integrity rather than security and I > am wondering why they need to be placed in the security keys (?). > > Thanks, > Santosh > > -- > ################################## > Santosh Rao > Software Design Engineer, > HP-UX iSCSI Driver Team, > Hewlett Packard, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################## -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Oct 16 14:56: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 OAA15426 for ; Tue, 16 Oct 2001 14:56:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GIEdb17765 for ips-outgoing; Tue, 16 Oct 2001 14:14:39 -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 f9GIEbl17760 for ; Tue, 16 Oct 2001 14:14: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 D88FE6DD for ; Tue, 16 Oct 2001 11:14: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 LAA02640 for ; Tue, 16 Oct 2001 11:14:31 -0700 (PDT) Message-ID: <3BCC7ACF.84BCD3D9@cup.hp.com> Date: Tue, 16 Oct 2001 11:22:07 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: iscsi : HeaderDigest & DataDigest as operational keys ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Julian, Can the keys HeaderDigest & DataDigest be moved to operational keys, instead of their current location in security keys ? This would allow an initiator that is using header & data digests, but no security authentication to complete all of its login key negotiation in 1 phase, namely, the operational phase. It reduces login to a single handshake for initiators that do not perform security authentication. The digest keys are meant for data integrity rather than security and I am wondering why they need to be placed in the security keys (?). 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 Tue Oct 16 15:14: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 PAA16355 for ; Tue, 16 Oct 2001 15:14:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GINVs18431 for ips-outgoing; Tue, 16 Oct 2001 14:23:31 -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 f9GINTl18423 for ; Tue, 16 Oct 2001 14:23:29 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel1.hp.com (Postfix) with ESMTP id 5E51F7AF; Tue, 16 Oct 2001 11:23: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 LAA03374; Tue, 16 Oct 2001 11:23:24 -0700 (PDT) Message-ID: <3BCC7CE5.C00E7C45@cup.hp.com> Date: Tue, 16 Oct 2001 11:31:01 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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 - negotiating against defaults/renegotiation the same key 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, Can you clarify what you mean by "self contained negotiations" ? Further comments inline. Thanks, Santosh Julian Satran wrote: > > Dear colleagues, > > I think that my previous proposal about negotiating against defaults is > flawed. > I was based on the simple-minded assumption that after the initiator has > said all he had to say (as evidenced by the T=1) the target may assume that > the values the target puts forward are against default. I even prepared a > text in > 5.3 that read: > > When the initiator issues a login request with the T bit set to 1 the > target MUST assume that this request includes also an "imaginary > content". The "imaginary content" consists of key=value pairs including > all the operational keys that have a default value and where not sent > yet by the initiator during the operational parameter negotiation. The > values in the "imaginary content" are the key default values. This > enables an initiator to avoid sending all the defaults while the target > may negotiate as if they where sent. > > But that was wrong. Here is a simple example: > > A simple initiator may issue a first login entering the operational > negotiation and having T=1 and nothing beyond the 2 names: > > I->T Iname... Tname > > This means only that he does not care about things like MaxBurst and is > content with defaults. > > The target (in my proposal prompted by Santosh's request) can't do > anything but lower the value while under our simple rule of self contained > negotiations he could ask for a burst increase and the negotiation could > have proceeded. If the initiator did'nt have any limitation on FirstBurstSize & MaxBurstSize, it should be sending 0 (no limit) and not 64K or 128K. Sending a finite value implies the initiator has a specific limit on the amount it can handle. While on this subject, I suggest that the default value of MaxBurstSize be 0, since the initiator does not usually care about or have a limit on this field. The field is more a limitation of the target's ability and using 0 allows the target to send back the maximum it can support as the result of the negotiation. -- ################################## 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 Tue Oct 16 15:43: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 PAA17584 for ; Tue, 16 Oct 2001 15:43:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GIrFq21027 for ips-outgoing; Tue, 16 Oct 2001 14:53:15 -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 f9GIrCl21018 for ; Tue, 16 Oct 2001 14:53:12 -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 LAA07211; Tue, 16 Oct 2001 11:52:58 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWV6S2V>; Tue, 16 Oct 2001 11:52:56 -0700 Message-ID: From: Robert Snively To: "'Julian Satran'" , ips@ece.cmu.edu Subject: RE: iSCSI - negotiating against defaults/renegotiation the same k ey Date: Tue, 16 Oct 2001 11:52:47 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk For two reasons, I would favor B) 1) If you consider case a, and the target may drop the login, what is the (consistent and interoperable) behavior if it chooses not to drop the login. 2) If you consider case c or d, when does the new and successful negotiation take place on one key if the first negotiation was successful and operation had started. By the way, how are dependent keys handled, where successful negotiation of one parameter leaves another parameter outside the accepted negotiation? Is there some kind of negotiation order or hierarchy? > 1-Multiple negotiations on one key - we may choose one of > the following > ways out: > > a)say that both initiator and target MAY drop the login if > that happens > (and close the connection) > b)say that both initiator and target MUST drop the login > if that happens > (and close the connection) > c)say that this is legitimate (a negotiated parameter > change due to a > later change not know when the negotiation started) > d)say that the whole sequence of Login request/responses > is a a "single > single virtual exchange" and the last value is the single one that > counts in every direction - this one is somewhat related > to the length > question but does not allow branching decisions > > I am would favor a) From owner-ips@ece.cmu.edu Tue Oct 16 16:51: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 QAA20562 for ; Tue, 16 Oct 2001 16:51:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GJtQq26211 for ips-outgoing; Tue, 16 Oct 2001 15:55:26 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d06lmsgate-3.uk.ibm.com (d06lmsgate-3.uk.ibm.com [195.212.29.3]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9GJtOl26202 for ; Tue, 16 Oct 2001 15:55:24 -0400 (EDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d06lmsgate-3.uk.ibm.com (1.0.0) with ESMTP id TAA128514 for ; Tue, 16 Oct 2001 19:15:04 +0100 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 f9GIMFo51102 for ; Tue, 16 Oct 2001 20:22:15 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: MaxBurstSize clarification X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 16 Oct 2001 21:22:13 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 16/10/2001 21:22:14, Serialize complete at 16/10/2001 21:22:14 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk That is correct. It has to set the F flag for times (and the A flag it wants acks). Regards, Julo "Dave Peterson" Sent by: owner-ips@ece.cmu.edu 16-10-01 18:43 Please respond to "Dave Peterson" To: "Ips@Ece. Cmu. Edu" cc: Subject: iSCSI: MaxBurstSize clarification The most recent text I could find regarding MaxBurstSize: "Initiator and target negotiate maximum SCSI data payload in bytes in an Data-In or a solicited Data-Out 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)." Given the text above and a negotiated MaxBurstSize=64k, if the target receives a 256k read request the target is required to send four 64k sequences. IOW, the target is not allowed to send a 256k sequence. Correct? Dave From owner-ips@ece.cmu.edu Tue Oct 16 18:19: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 SAA21995 for ; Tue, 16 Oct 2001 18:19:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9GLLZT02833 for ips-outgoing; Tue, 16 Oct 2001 17:21:35 -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 f9GLLXl02825 for ; Tue, 16 Oct 2001 17:21: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 87C266C4 for ; Tue, 16 Oct 2001 14:21: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 OAA16589 for ; Tue, 16 Oct 2001 14:21:27 -0700 (PDT) Message-ID: <3BCCA6A1.95BF671C@cup.hp.com> Date: Tue, 16 Oct 2001 14:29:05 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: ips : key response "NotUnderstood". 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 suggest that the below quoted text in the draft be re-phrased to state it in terms of "originating party" and "responding party", since the target may originate X-* keys, in which case, the below text is applicable for initiators. Could you also please clarify what is the expected behaviour when an initiator receives a vendor specific X-* key ? Is the initiator compelled to respond with "NotUnderstood" or can it just discard the key ? Thanks, Santosh 2.2.4 ----- "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". The values "none" and "reject" are reserved and must be used only as described here. Any key not understood is answered with NotUnderstood. " 3.10.4 ------ "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." -- ################################## 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 Tue Oct 16 22:47: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 WAA26469 for ; Tue, 16 Oct 2001 22:47:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9H1gfY20475 for ips-outgoing; Tue, 16 Oct 2001 21:42:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9H0ACl14526; Tue, 16 Oct 2001 20:10:12 -0400 (EDT) Received: from fmsmsxvs042.fm.intel.com (fmsmsxv042-1.fm.intel.com [132.233.48.110]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id AAA29536; Wed, 17 Oct 2001 00:10:12 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs042.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001101617101402776 ; Tue, 16 Oct 2001 17:10:14 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Oct 2001 17:11:24 -0700 Message-ID: From: "Mesnier, Michael" To: "'snia-ips@snia.org'" , "'snia-iscsi@snia.org'", "'snia-osd@snia.org'" , "'ips-source@ece.cmu.edu'" , "'ips@ece.cmu.edu'" Subject: Intel's iSCSI v6+ release Date: Tue, 16 Oct 2001 17:10:05 -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 Intel Lab's open source iSCSI is now available on SourceForge. See http://www.sourceforge.net/projects/intel-iscsi. This is a software implementation of iSCSI v6 w/ v7 opcodes, including both host and target mode linux drivers. More information can be found in the README. Best regards, -- Mike Mesnier Intel Labs michael.mesnier@intel.com From owner-ips@ece.cmu.edu Tue Oct 16 22: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 WAA26503 for ; Tue, 16 Oct 2001 22:48:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9H1sHf21172 for ips-outgoing; Tue, 16 Oct 2001 21:54:17 -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 f9H1s2l21146 for ; Tue, 16 Oct 2001 21:54:16 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel1.hp.com (Postfix) with ESMTP id 135824E4 for ; Tue, 16 Oct 2001 21:54:01 -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 SAA11876 for ; Tue, 16 Oct 2001 18:55:24 -0700 (PDT) Message-Id: <200110170155.SAA11876@core.rose.hp.com> Date: Tue, 16 Oct 2001 19:05:54 -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 - negotiating against defaults/renegotiation the same key 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 I see it, there are at least two options in negotiating for defaults - A) As David implied in an earlier message, mandate every defined key to be negotiated. That leaves target to originate only vendor-unique keys, to be responded in vendor-unique ways. B) Leave the defaults in, and rely on the T-bit to prompt target to originate non-default key values. We would then have to specify that an initiator MUST explicitly state "can accept any value" when it really is the case (to prevent the case you're concerned about). IOW, non-mention of a text key should have the exact semantics of an explicit offering of the default. I am mildly partial towards A. Regarding re-negotiating the same key, I guess I would prefer (b) - mandating a connection to be dropped. [ BTW, I am not sure (c) is correct - both parties should know when a negotiation started, to potentially discard the results of a partial negotiation on a failure. ] On the topic of differentiating text exchanges from that of others, I would vote no - so I guess I support your option (a). Please comment how it does make the negotiation more complicated. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > Dear colleagues, > > I think that my previous proposal about negotiating against defaults is > flawed. > I was based on the simple-minded assumption that after the initiator has > said all he had to say (as evidenced by the T=1) the target may assume that > the values the target puts forward are against default. I even prepared a > text in > 5.3 that read: > > When the initiator issues a login request with the T bit set to 1 the > target MUST assume that this request includes also an "imaginary > content". The "imaginary content" consists of key=value pairs including > all the operational keys that have a default value and where not sent > yet by the initiator during the operational parameter negotiation. The > values in the "imaginary content" are the key default values. This > enables an initiator to avoid sending all the defaults while the target > may negotiate as if they where sent. > > But that was wrong. Here is a simple example: > > A simple initiator may issue a first login entering the operational > negotiation and having T=1 and nothing beyond the 2 names: > > I->T Iname... Tname > > This means only that he does not care about things like MaxBurst and is > content with defaults. > > The target (in my proposal prompted by Santosh's request) can't do > anything but lower the value while under our simple rule of self contained > negotiations he could ask for a burst increase and the negotiation could > have proceeded. > > For this (and a several other scenarios that you can easily build) I > suggest we stick with our "old" rule that a negotiation must be completely > "self contained". > > Now about the other two subjects: > > 1-Multiple negotiations on one key - we may choose one of the following > ways out: > > a)say that both initiator and target MAY drop the login if that happens > (and close the connection) > b)say that both initiator and target MUST drop the login if that happens > (and close the connection) > c)say that this is legitimate (a negotiated parameter change due to a > later change not know when the negotiation started) > d)say that the whole sequence of Login request/responses is a a "single > single virtual exchange" and the last value is the single one that > counts in every direction - this one is somewhat related to the length > question but does not allow branching decisions > > I am would favor a) > > 2. Text block length - we gave away (for a while) on our 4k text messages. > That makes negotiation difficult and might somehow help some of the > framing schemes: > > I think we may want to do one of the following: > > a) mandate that the default 8k is valid during login and change only at > end of login > b) get back to a separate length for text and fix it at 4 or 8k (not > ideal for framing) > > Option a may solve the login issue but leaves us with an ugly text > negotiation. > > Option b will require the framing folks to come up with a solution (works > with markers though). > > I am in favor of b (a different and predefined length for text buffers) > and return to the "complete" negotiation buffers > that raise far less logical problems that the concatenation scheme we are > (temporarily in). > > Julo From owner-ips@ece.cmu.edu Wed Oct 17 02:18: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 CAA12125 for ; Wed, 17 Oct 2001 02:18:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9H5JmD03596 for ips-outgoing; Wed, 17 Oct 2001 01:19:48 -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 f9H5Jkl03586 for ; Wed, 17 Oct 2001 01:19:46 -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 HAA130128 for ; Wed, 17 Oct 2001 07:19: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.97.1) with ESMTP id f9H5Jds22814 for ; Wed, 17 Oct 2001 07:19:39 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - negotiating against defaults/renegotiation the same key X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 17 Oct 2001 08:19:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 17/10/2001 08:19:39, Serialize complete at 17/10/2001 08:19:39 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallilkarjun, David only suggested that whoever desires to be certain about values has to negotiate them. This a reasonably conservative option and does not exclude defaults but excludes negotiating "against defaults" that I find also excessively complicated. Also negotiation can be originated at target and initiator. I think also that A (negotiate by making the full exchange) is the preferred alternative. As for the ugly text - if we get to have a "universal" PDU length (including text) we might end up having text requests (and/or responses) that are so short that most of the key=value pairs are not finished in one exchange (and then we have empty PDU's in the opposite direction). I would rather see a 4k text block and key=value not spanning PDU's. But this has its own drawbacks (framing, not uniform etc.). Julo "Mallikarjun C." Sent by: owner-ips@ece.cmu.edu 17-10-01 04:05 Please respond to cbm To: ips cc: Subject: Re: iSCSI - negotiating against defaults/renegotiation the same key Julian, As I see it, there are at least two options in negotiating for defaults - A) As David implied in an earlier message, mandate every defined key to be negotiated. That leaves target to originate only vendor-unique keys, to be responded in vendor-unique ways. B) Leave the defaults in, and rely on the T-bit to prompt target to originate non-default key values. We would then have to specify that an initiator MUST explicitly state "can accept any value" when it really is the case (to prevent the case you're concerned about). IOW, non-mention of a text key should have the exact semantics of an explicit offering of the default. I am mildly partial towards A. Regarding re-negotiating the same key, I guess I would prefer (b) - mandating a connection to be dropped. [ BTW, I am not sure (c) is correct - both parties should know when a negotiation started, to potentially discard the results of a partial negotiation on a failure. ] On the topic of differentiating text exchanges from that of others, I would vote no - so I guess I support your option (a). Please comment how it does make the negotiation more complicated. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > Dear colleagues, > > I think that my previous proposal about negotiating against defaults is > flawed. > I was based on the simple-minded assumption that after the initiator has > said all he had to say (as evidenced by the T=1) the target may assume that > the values the target puts forward are against default. I even prepared a > text in > 5.3 that read: > > When the initiator issues a login request with the T bit set to 1 the > target MUST assume that this request includes also an "imaginary > content". The "imaginary content" consists of key=value pairs including > all the operational keys that have a default value and where not sent > yet by the initiator during the operational parameter negotiation. The > values in the "imaginary content" are the key default values. This > enables an initiator to avoid sending all the defaults while the target > may negotiate as if they where sent. > > But that was wrong. Here is a simple example: > > A simple initiator may issue a first login entering the operational > negotiation and having T=1 and nothing beyond the 2 names: > > I->T Iname... Tname > > This means only that he does not care about things like MaxBurst and is > content with defaults. > > The target (in my proposal prompted by Santosh's request) can't do > anything but lower the value while under our simple rule of self contained > negotiations he could ask for a burst increase and the negotiation could > have proceeded. > > For this (and a several other scenarios that you can easily build) I > suggest we stick with our "old" rule that a negotiation must be completely > "self contained". > > Now about the other two subjects: > > 1-Multiple negotiations on one key - we may choose one of the following > ways out: > > a)say that both initiator and target MAY drop the login if that happens > (and close the connection) > b)say that both initiator and target MUST drop the login if that happens > (and close the connection) > c)say that this is legitimate (a negotiated parameter change due to a > later change not know when the negotiation started) > d)say that the whole sequence of Login request/responses is a a "single > single virtual exchange" and the last value is the single one that > counts in every direction - this one is somewhat related to the length > question but does not allow branching decisions > > I am would favor a) > > 2. Text block length - we gave away (for a while) on our 4k text messages. > That makes negotiation difficult and might somehow help some of the > framing schemes: > > I think we may want to do one of the following: > > a) mandate that the default 8k is valid during login and change only at > end of login > b) get back to a separate length for text and fix it at 4 or 8k (not > ideal for framing) > > Option a may solve the login issue but leaves us with an ugly text > negotiation. > > Option b will require the framing folks to come up with a solution (works > with markers though). > > I am in favor of b (a different and predefined length for text buffers) > and return to the "complete" negotiation buffers > that raise far less logical problems that the concatenation scheme we are > (temporarily in). > > Julo From owner-ips@ece.cmu.edu Wed Oct 17 05:00: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 FAA16520 for ; Wed, 17 Oct 2001 05:00:23 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9H7wcN11960 for ips-outgoing; Wed, 17 Oct 2001 03:58:38 -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 f9H7wZl11949 for ; Wed, 17 Oct 2001 03:58:35 -0400 (EDT) Received: from COORS (coors.eurologic.com [192.168.7.111]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id IAA06893 for ; Wed, 17 Oct 2001 08:55:58 +0100 (BST) Message-ID: <009b01c156e1$93c6e380$6f07a8c0@COORS> From: "Ron Cohen" To: "ips" Subject: Questions Date: Wed, 17 Oct 2001 08:58:56 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01C156E9.F42F16E0" 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_0098_01C156E9.F42F16E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please excuse if the questions I ask have already been handled. I have = just come back to reading the reflector after changing jobs. 1. In section 2.2.7 it states that for a discovery session the iSCSI = Target Name can be ignored. It also states the default name "iSCSI" is = reserved and is not used as an indivdiual initiator or target name. Two = points. 1) Does this imply that the canonical name "iscsi" no longer = exists or can it still be used for a discovery session? 2) If the name = still exists, is it case sensitive and has its syntax changed from = "iscsi" to "iSCSI"? 2. As I understand it, two sessions may be established between an iSCSI = initiator and an iSCSI target by setting different values to the ISID. = If we consider that an iSCSI session is roughly an I_T Nexus, would this = constitute two nexii? How should SCSI device reservations and operating = mode parameters (Mode Sense/Mode Select) be handled in this case? To be continued... Ronald Cohen E-mail: rcohen@Eurologic.com Telephone: +44 (0) 117 930 9615 ------=_NextPart_000_0098_01C156E9.F42F16E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please excuse if the questions I ask = have already=20 been handled.  I have just come back to reading the reflector after = changing jobs.
 
1.  In section 2.2.7  it = states that for=20 a discovery session the iSCSI Target Name can be ignored.  It also = states=20 the default name "iSCSI" is reserved and is not used as an indivdiual = initiator=20 or target name.  Two points.  1) Does this imply that the = canonical=20 name "iscsi" no longer exists or can it still be used for a discovery=20 session?  2) If the name still exists, is it case sensitive and has = its=20 syntax changed from "iscsi" to "iSCSI"?
 
2.  As I understand it, two = sessions may be=20 established between an iSCSI initiator and an iSCSI target by setting = different=20 values to the ISID.  If we consider that an iSCSI session is = roughly an I_T=20 Nexus, would this constitute two nexii?  How should SCSI = device=20 reservations and operating mode parameters (Mode Sense/Mode Select) be = handled=20 in this case?
 
To be continued...
 
Ronald Cohen
E-mail:  rcohen@Eurologic.com
Telephon= e: =20 +44 (0) 117 930 9615
------=_NextPart_000_0098_01C156E9.F42F16E0-- From owner-ips@ece.cmu.edu Wed Oct 17 11:02: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 LAA26794 for ; Wed, 17 Oct 2001 11:02:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9HE2ja12668 for ips-outgoing; Wed, 17 Oct 2001 10:02:45 -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 f9HE2al12650 for ; Wed, 17 Oct 2001 10:02:37 -0400 (EDT) Received: by ATLOPS with Internet Mail Service (5.5.2448.0) id ; Wed, 17 Oct 2001 10:02:23 -0400 Message-ID: <25369470B6F0D41194820002B328BDD21A0142@ATLOPS> From: Eddy Quicksall To: Lee Xing , ips@ece.cmu.edu Subject: RE: A Question on ExpStatSN Date: Wed, 17 Oct 2001 10:02:12 -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 There is no problem with queuing because the CmdSN's don't have any order relationship to the StatSN's. I may not have understood your concern so if this doesn't answer your question, please give an example. Eddy -----Original Message----- From: Lee Xing [mailto:lxing@Crossroads.com] Sent: Monday, September 24, 2001 04:16 PM To: ips@ece.cmu.edu Subject: A Question on ExpStatSN 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 Wed Oct 17 12:06: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 MAA28544 for ; Wed, 17 Oct 2001 12:06:37 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9HF14f16932 for ips-outgoing; Wed, 17 Oct 2001 11:01:04 -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 f9HF13l16928 for ; Wed, 17 Oct 2001 11:01:03 -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 LAA09096; Wed, 17 Oct 2001 11:00:50 -0400 (EDT) Message-ID: <3BCD9AF6.D0AB75CB@cisco.com> Date: Wed, 17 Oct 2001 09:51:34 -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: Ron Cohen CC: ips Subject: Re: Questions References: <009b01c156e1$93c6e380$6f07a8c0@COORS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ron- I can reply to the first question. The canonical name "iscsi" is no longer used. Also, only lower-case characters are allowed in iSCSI names, so "iSCSI" is no longer be a valid iSCSI name. -- Mark > Ron Cohen wrote: > > Please excuse if the questions I ask have already been handled. I have just come back to reading > the reflector after changing jobs. > > 1. In section 2.2.7 it states that for a discovery session the iSCSI Target Name can be > ignored. It also states the default name "iSCSI" is reserved and is not used as an indivdiual > initiator or target name. Two points. 1) Does this imply that the canonical name "iscsi" no > longer exists or can it still be used for a discovery session? 2) If the name still exists, is it > case sensitive and has its syntax changed from "iscsi" to "iSCSI"? -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Wed Oct 17 14:07: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 OAA01992 for ; Wed, 17 Oct 2001 14:07:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9HHCQK27587 for ips-outgoing; Wed, 17 Oct 2001 13:12: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 f9HHCOl27581 for ; Wed, 17 Oct 2001 13:12:24 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id C9BCA1F723; Wed, 17 Oct 2001 10:12: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 KAA27676; Wed, 17 Oct 2001 10:12:10 -0700 (PDT) Message-ID: <3BCDBDB6.2AF45DE9@cup.hp.com> Date: Wed, 17 Oct 2001 10:19:50 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Black_David@emc.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI: default values References: <277DD60FB639D511AC0400B0D068B71ECAD8AD@CORPMX14> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Black_David@emc.com wrote: > > Default values may be difficult to define for text keys added after > the first stable version of the spec. The problem is that an > originator who does not send a text key cannot distinguish between: > > - a responder who understands the key and implements the default AND > - a responder who does not understand the key and does something > acceptable under a version of the spec prior to introduction > of the key. David, I see a minor nit in the above described scenario. During iscsi login, both sides need to agree on a common overlapping version in their respective ranges of (version_low, version_high) sent in the login pdu. Lack of a common version results in the target rejecting the login with an "unsupported version" status explanation. Once the 2 sides have agreed to a common version, both sides know all the supported operational & security keys in use. Thus, one side cannot send a "key defined in a later version of the spec" which the other side does not understand. Such an erroneous key usage, would have to be due to a buggy implementation and would cause the other side to treat it as a vendor unique key being originated to which it would respond with NotUnderstood. That said, I agree with the intent of your suggestions below. Thanks, Santosh > This whole notion of omitting a key being equivalent to sending > it with its default value strikes me as potentially problematic. > I would have thought that omitting a text key was equivalent to > "Don't Care" with the default values being "RECOMMENDED" rather > than "MANDATORY". This leads to the following rule, which I think > should go in regardless: > > - An implementation whose operational correctness and/or performance > depends on the value of a text key MUST explicitly negotiate > that key. > > This is somewhat like the old adage about voting - those who do not > vote should not complain about the results, and leads to more robust > negotiation exchanges because mismatched assumptions about defaults > get exposed. > > I realize this yields additional messages in some cases, but would > suggest that the additional negotiation robustness is an offsetting > benefit. > > 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 > --------------------------------------------------- -- ################################## 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 Wed Oct 17 16:05: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 QAA06204 for ; Wed, 17 Oct 2001 16:05:55 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9HJBp207812 for ips-outgoing; Wed, 17 Oct 2001 15:11:51 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pluto.he.net (pluto.he.net [216.218.167.2]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9HJBkl07797 for ; Wed, 17 Oct 2001 15:11:47 -0400 (EDT) Received: from linux1vmware (cpe-66-87-94-156.ca.sprintbbd.net [66.87.94.156]) by pluto.he.net (8.8.6/8.8.2) with SMTP id MAA20055; Wed, 17 Oct 2001 12:11:39 -0700 From: "shailesh Manjrekar" To: "KRUEGER,MARJORIE \(HP-Roseville,ex1\)" , "'Julian Satran'" , Subject: RE: iSCSI: NIC interoperability Date: Wed, 17 Oct 2001 12:11:28 -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 V6.00.2600.0000 Importance: Normal In-Reply-To: <6BD67FFB937FD411A04F00D0B74FE87805CCF1CB@xrose06.rose.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Folks, I would like to question the (C) requirement, in the interest of implementation simplicity. I have also seen some previous threads on whether to have a host based session manager v/s session handling at the offload engine with routing on the host (each NIC, independent portal group). The value add with session spanning across NIC's namely : - availability at the connection level and - ability to scale by bandwidth aggregation, could also be reasonably achieved by - reestablishing session on the different path ( the time taken for failover to different connection v/s establishing a new session needs to be characterized, but should not be significant if weighed against the simplicity ). - bandwidth aggregation can be achieved by multi-ported, multi-engine HBA's and also at a multi-connection level. The price to pay for session spanning across NIC's would be of having a intelligent session manager on the host managing the per session counters, parameters etc. which would result in somewhat performance hit of going between on-chip and off-chip and making the interface between the host and offload engine, less intelligent. Would there be really vendor interest of having added complexity on host side for iscsi implementations. Any directions/comments appreciated ! Regards, Shailesh. Aarohi Communications. -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of KRUEGER,MARJORIE (HP-Roseville,ex1) Sent: Monday, October 15, 2001 11:32 AM To: 'Julian Satran'; ips@ece.cmu.edu Subject: RE: iSCSI: NIC interoperability Mallikarjun is advocating including A,B,and C statements explicitly in the document. I support this. Marj > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Friday, October 12, 2001 10:03 PM > To: ips@ece.cmu.edu > Subject: Re: iSCSI: NIC interoperability > > > Mallikarjun, > > I have repeatedly stated that from a practical point of view we are > spending a lot of ink on a non-issue. > I have even insisted on mandating C in the draft. Some of the list > members/readers/authors seem to consider such a requirement > as "excessive" > - as it implies resorting to a higher authority on every > session creation - > and that might not be strictly necessary (although it will be > sufficient). > Adding a text key is neither simpler nor easier nor will it solve the > conflict problem. > And I have very little time and patience left for pages of > debate on the > merits of one or other port naming script. > > Julo > > > > > > "Mallikarjun > > C." To: ips > > > om> Subject: iSCSI: > NIC interoperability > Sent by: > > owner-ips@ece. > > cmu.edu > > > > > > 10-10-01 04:14 > > Please respond > > to cbm > > > > > > > > > After seeing some of the emails on this topic from Dave > Sheehy, David Black and Jim Hafner, I have some comments > and questions. > > It appears to me that the following three are the major > issues that one has to deal with for building a multi-NIC > iSCSI Node, where the NICs are potentially from different > vendors. > A. Each NIC MUST allow the Node name to be configurable. > B. Each NIC MUST allow the ISID range to be configurable > (if deployed in an initiator configuration). > C. In addition, if only one (initiator/target) portal group > is sought to be presented (i.e. session spanning across > any and all of these NICs is a requirement), each NIC > MUST allow itself to be managed by an externally-resident > "session manager" in some "TBD standard way". > > Admittedly, C is is the hardest and till the "TBD standard way" > is defined to interact with a session manager, it cannot be > mandated. Failure to comply with C would only create multiple > portal groups in an iSCSI implementation - each portal group > limited to NIC(s) from a given vendor. > > But, A and B above seem reasonable and in fact seem required > to be mandated - both to avoid the problems as with FC Node > Name, and also to address the concerns of not leaving target > with a deterministic way to enforce access control mechanisms > and such. > > I realize that the "no duplicate nexus" goal does not strictly > require A (hence neither B), but I recommend that A be mandated, > thus automatically making B an additional requirement for initiator > configurations. Rev08 iSCSI draft seems to refer to A and B > in section 9 (implementation notes) as "should". Was there a > concern about the appropriateness of mandating A and B in the > main modeling discussion? They appear fairly straightforward > to implement. > > If the reasoning was not to require _any_ configuration of an > iSCSI NIC, I would argue that you require some "name" to be > configurable anytime you want to build a logically monolithic > entity (as in a node) from smaller components (each of which > can act as a logically independent entity in its own right). > > Comments from NDT and/or Julian would help. > > 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 Oct 17 16:59: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 QAA07349 for ; Wed, 17 Oct 2001 16:59:53 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9HJuYd11520 for ips-outgoing; Wed, 17 Oct 2001 15:56:34 -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 f9HJuVl11509 for ; Wed, 17 Oct 2001 15:56:31 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id <4R3PXP9A>; Wed, 17 Oct 2001 14:56:26 -0500 Message-ID: <3C7122FAF06DD5118ED600500473364826312B@esply01.cnt.com> From: Michael Schoberg To: "IPS Reflector (E-mail)" Subject: iSCSI: Login authentication SRP/CHAP Date: Wed, 17 Oct 2001 14:53:09 -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 having some problems figuring out the exact implementation for the login authentication protocols being proposed. Is anyone else having similar issues answering these questions: What is the hashing algorithm that will be used for SRP authentication (SHA-1, MD5, HMAC-SHA1)? The SRP negotiation passes the following information (T->I): SRP_s = SRP salt SRP_N = (SRP n value - Large prime number. All computations are performed modulo n) SRP_g = Primitive root modulo of n By passing [N] & [g] (T->I), does this mean the initiator must verify that [N] is a prime and [g] is a primitive root modulo of [N]? What are the min/max digits for [N] and [g]? If any of these are not satisfied (N not prime, g not primitive modulo root, #digits too small or large), could it be used as an attack against the initiator or be used to derive the initiator's password? The reference to RFC 1994 does not fully describe the CHAP function for iSCSI, it describes the CHAP message protocol which isn't really used in our case. There's some parameters that need to be nailed down. What is the CHAP hash algorithm: (MD5)? What is the sequence of hashes that take place on a CHAP challenge to form the CHAP digest? The iSCSI draft allows for algorithm selection (CHAP_A=) but doesn't describe any. Are these supposed to dictate the hashing function or give a description of [what/how it] gets hashed (or both)? Will there be a mandatory set (A1..An) that compliant iSCSI implementations must provide? Is there a reference that actually shows the sequence for a CHAP digest being formed from MD5 hashes? It would help to have an appendix with real username/password examples of the result exchange? A table with a few sample sets would be useful for validating designs. From owner-ips@ece.cmu.edu Wed Oct 17 18:11: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 SAA08416 for ; Wed, 17 Oct 2001 18:11:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9HLL2w18364 for ips-outgoing; Wed, 17 Oct 2001 17:21:02 -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 f9HLL0l18359 for ; Wed, 17 Oct 2001 17:21:00 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9HLKtu24343 for ; Wed, 17 Oct 2001 14:20:55 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9HLKnB03811 for ; Wed, 17 Oct 2001 14:20:49 -0700 From: "Bill Strahm" To: "IPS Reflector \(E-mail\)" Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Wed, 17 Oct 2001 14:19: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) In-Reply-To: <3C7122FAF06DD5118ED600500473364826312B@esply01.cnt.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Just to bring up a cynical point. Why do we need SRP anyway... after all I am running over a required secure channel, so there should be no problem with just sending a user ID/Passphrase over the secure channel. This will prevent a LOT of interoperability problems, extra code required to implement additional security algorithms, etc. This makes my implementation much simpler, I can seperate login/authentication parameters (currently SRP) vs. setting up a secure channel (IPsec). If we go the Application level secure authentication method, I would rather we replace the security layer with TLS rather than IPsec, so we get authentication/security all in one place rather than scattered around lower layer protocols, application protocols... Bill Strahm +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Michael Schoberg Sent: Wednesday, October 17, 2001 12:53 PM To: IPS Reflector (E-mail) Subject: iSCSI: Login authentication SRP/CHAP I'm having some problems figuring out the exact implementation for the login authentication protocols being proposed. Is anyone else having similar issues answering these questions: What is the hashing algorithm that will be used for SRP authentication (SHA-1, MD5, HMAC-SHA1)? The SRP negotiation passes the following information (T->I): SRP_s = SRP salt SRP_N = (SRP n value - Large prime number. All computations are performed modulo n) SRP_g = Primitive root modulo of n By passing [N] & [g] (T->I), does this mean the initiator must verify that [N] is a prime and [g] is a primitive root modulo of [N]? What are the min/max digits for [N] and [g]? If any of these are not satisfied (N not prime, g not primitive modulo root, #digits too small or large), could it be used as an attack against the initiator or be used to derive the initiator's password? The reference to RFC 1994 does not fully describe the CHAP function for iSCSI, it describes the CHAP message protocol which isn't really used in our case. There's some parameters that need to be nailed down. What is the CHAP hash algorithm: (MD5)? What is the sequence of hashes that take place on a CHAP challenge to form the CHAP digest? The iSCSI draft allows for algorithm selection (CHAP_A=) but doesn't describe any. Are these supposed to dictate the hashing function or give a description of [what/how it] gets hashed (or both)? Will there be a mandatory set (A1..An) that compliant iSCSI implementations must provide? Is there a reference that actually shows the sequence for a CHAP digest being formed from MD5 hashes? It would help to have an appendix with real username/password examples of the result exchange? A table with a few sample sets would be useful for validating designs. From owner-ips@ece.cmu.edu Wed Oct 17 18:13: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 SAA08454 for ; Wed, 17 Oct 2001 18:13:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9HKxE816610 for ips-outgoing; Wed, 17 Oct 2001 16:59:14 -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 f9HKxDl16603 for ; Wed, 17 Oct 2001 16:59:13 -0400 (EDT) Received: from cisco.com (ssenum@ssenum-lnx.cisco.com [10.82.1.44]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA21782 for ; Wed, 17 Oct 2001 16:59:06 -0400 (EDT) Message-ID: <3BCDF148.925E4997@cisco.com> Date: Wed, 17 Oct 2001 15:59:52 -0500 From: Steven Senum X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en MIME-Version: 1.0 To: "IPS Reflector (E-mail)" Subject: Re: iSCSI: Login authentication SRP/CHAP References: <3C7122FAF06DD5118ED600500473364826312B@esply01.cnt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Michael, I can't answer your questions on SRP, but I probably can answer a few on CHAP. The CHAP_A key (algorithm) is specified in RFC 1994: 5 CHAP with MD5 [3] The CHAP_I (identifier), CHAP_C (challenge), CHAP_N (name) and CHAP_R (response) are also specified in RFC 1994: Identifier The Identifier field is one octet. The Identifier field MUST be changed each time a Challenge is sent. The Response Identifier MUST be copied from the Identifier field of the Challenge which caused the Response. Value (challenge and response) The Value field is one or more octets. The most significant octet is transmitted first. The Challenge Value is a variable stream of octets. The importance of the uniqueness of the Challenge Value and its relationship to the secret is described above. The Challenge Value MUST be changed each time a Challenge is sent. The length of the Challenge Value depends upon the method used to generate the octets, and is independent of the hash algorithm used. The Response Value is the one-way hash calculated over a stream of octets consisting of the Identifier, followed by (concatenated with) the "secret", followed by (concatenated with) the Challenge Value. The length of the Response Value depends upon the hash algorithm used (16 octets for MD5). Name The Name field is one or more octets representing the identification of the system transmitting the packet. There are no limitations on the content of this field. For example, it MAY contain ASCII character strings or globally unique identifiers in ASN.1 syntax. The Name should not be NUL or CR/LF terminated. The size is determined from the Length field. Basically, iSCSI just uses a different encoding, since it is sending "text" keys, instead of binary. A sample output from my (Cisco's) implementation is as follows: I-> AuthMethod=CHAP,none (CSG,NSG=0,1 T=1) T-> AuthMethod=CHAP (CSG,NSG=0,1 T=0) I-> CHAP_A=5 (CSG,NSG=0,1 T=0) T-> CHAP_A=5 (CSG,NSG=0,1 T=0) CHAP_I=70 CHAP_C=0x9593dd5e25f87b9e0fcc6891e6670461 I-> CHAP_N=u1 (CSG,NSG=0,1 T=1) CHAP_R=0x7e64294a4376affca14cdaecf3c72e21 T-> (CSG,NSG=0,1 T=1) You can also look at Cisco's Linux implementation on SourceForge: http://sourceforge.net/projects/linux-iscsi Hope this helps. Regards, Steve Senum Michael Schoberg wrote: > > I'm having some problems figuring out the exact implementation for the login > authentication protocols being proposed. Is anyone else having similar > issues answering these questions: > > What is the hashing algorithm that will be used for SRP authentication > (SHA-1, MD5, HMAC-SHA1)? > > The SRP negotiation passes the following information (T->I): > > SRP_s = SRP salt > SRP_N = (SRP n value - Large prime number. All computations are performed > modulo n) > SRP_g = Primitive root modulo of n > > By passing [N] & [g] (T->I), does this mean the initiator must verify that > [N] is a prime and [g] is a primitive root modulo of [N]? What are the > min/max digits for [N] and [g]? If any of these are not satisfied (N not > prime, g not primitive modulo root, #digits too small or large), could it be > used as an attack against the initiator or be used to derive the initiator's > password? > > The reference to RFC 1994 does not fully describe the CHAP function for > iSCSI, it describes the CHAP message protocol which isn't really used in our > case. There's some parameters that need to be nailed down. What is the > CHAP hash algorithm: (MD5)? What is the sequence of hashes that take place > on a CHAP challenge to form the CHAP digest? > > The iSCSI draft allows for algorithm selection (CHAP_A=) but > doesn't describe any. Are these supposed to dictate the hashing function or > give a description of [what/how it] gets hashed (or both)? Will there be a > mandatory set (A1..An) that compliant iSCSI implementations must provide? > Is there a reference that actually shows the sequence for a CHAP digest > being formed from MD5 hashes? > > It would help to have an appendix with real username/password examples of > the result exchange? A table with a few sample sets would be useful for > validating designs. From owner-ips@ece.cmu.edu Wed Oct 17 18:23: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 SAA08559 for ; Wed, 17 Oct 2001 18:23:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9HLkRB20423 for ips-outgoing; Wed, 17 Oct 2001 17:46:27 -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 f9HLkPl20417 for ; Wed, 17 Oct 2001 17:46:25 -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 OAA22470; Wed, 17 Oct 2001 14:44:07 -0700 (PDT) Received: from aimexc07.corp.adaptec.com (aimexc07.corp.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id OAA19868; Wed, 17 Oct 2001 14:30:12 -0700 (PDT) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Oct 2001 14:44:07 -0700 Message-ID: From: "Lee, CJ" To: "'Michael Schoberg'" Cc: "'ips@ece.cmu.edu'" Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Wed, 17 Oct 2001 14:44:06 -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 Michael, According to RFC2945, SHA1 is the hash algorithm used by SRP. For CHAP, according to 08 draft, MD5 is the required to be implemented algorithm and other algorithms can certainly be added if so desired. Unlike RFC2945, RFC1994 describes CHAP in the context of PPP LCP negotiation and one should/could not apply it directly to be used in iSCSI login authentication. Take a look at the 08 draft Appendix A, CHAP challenge, response exchanges are carried out using login commands and responses. RFC1994 merely spells out how response is calculated based on the challenge and info. associated with the authentication session (ID) and the communicating peer (secret). CJ Lee Adaptec, Inc. -----Original Message----- From: Michael Schoberg [mailto:michael_schoberg@cnt.com] Sent: Wednesday, October 17, 2001 12:53 PM To: IPS Reflector (E-mail) Subject: iSCSI: Login authentication SRP/CHAP I'm having some problems figuring out the exact implementation for the login authentication protocols being proposed. Is anyone else having similar issues answering these questions: What is the hashing algorithm that will be used for SRP authentication (SHA-1, MD5, HMAC-SHA1)? The SRP negotiation passes the following information (T->I): SRP_s = SRP salt SRP_N = (SRP n value - Large prime number. All computations are performed modulo n) SRP_g = Primitive root modulo of n By passing [N] & [g] (T->I), does this mean the initiator must verify that [N] is a prime and [g] is a primitive root modulo of [N]? What are the min/max digits for [N] and [g]? If any of these are not satisfied (N not prime, g not primitive modulo root, #digits too small or large), could it be used as an attack against the initiator or be used to derive the initiator's password? The reference to RFC 1994 does not fully describe the CHAP function for iSCSI, it describes the CHAP message protocol which isn't really used in our case. There's some parameters that need to be nailed down. What is the CHAP hash algorithm: (MD5)? What is the sequence of hashes that take place on a CHAP challenge to form the CHAP digest? The iSCSI draft allows for algorithm selection (CHAP_A=) but doesn't describe any. Are these supposed to dictate the hashing function or give a description of [what/how it] gets hashed (or both)? Will there be a mandatory set (A1..An) that compliant iSCSI implementations must provide? Is there a reference that actually shows the sequence for a CHAP digest being formed from MD5 hashes? It would help to have an appendix with real username/password examples of the result exchange? A table with a few sample sets would be useful for validating designs. From owner-ips@ece.cmu.edu Wed Oct 17 20:10: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 UAA09899 for ; Wed, 17 Oct 2001 20:10:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9HNVaX27817 for ips-outgoing; Wed, 17 Oct 2001 19:31:36 -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 f9HNVYl27813 for ; Wed, 17 Oct 2001 19:31:34 -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 QAA18231 for ; Wed, 17 Oct 2001 16:31:27 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWV7QYQ>; Wed, 17 Oct 2001 16:31:27 -0700 Message-ID: From: Robert Snively To: "'ips@ece.cmu.edu'" Subject: Question on security document Date: Wed, 17 Oct 2001 16:31:25 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk I have a recommendation to the authors of the security document: draft-ietf-ips-security-03.txt There are a number of places where sentences like: "Conformant iSCSI, FCIP and iFCP security implementations MUST support both IKE Main Mode and Aggressive Mode." are used. I propose that all those "MUSTs", "SHOULDs", and similar words in the security document be changed to lower case as explained below. According to the security document, it is informational, and never aspires to be more than an informational RFC. If I understand RFC 2026 properly, Section 4.2.2 (attached below for reference) strongly implies that these documents cannot be used for verifying compliance. However, RFC 2119 has a somewhat conflicted definition of how words like "MUST" should be interpreted. It says that they are rare and precious words that prevent very bad things from happening. It is implied that non-interoperability is one of those things and security failure is another. It also implies that they rise no higher in requirement than the document itself. I had expected that the iSCSI, FCIP, and iFCP documents were required to define their security compliance requirements. However, here we have an informational draft taking over that same job and using language that implies a compliance failure if the "MUSTs" are ignored. It is not at all clear what would happen if one of the primary documents accidentally or purposely conflicted with the "MUSTs" of the security document. I believe the best solution for this is to change all words in the security document with possible keyword meaning to lower case, using the corresponding wording in each of the primary documents to to uniquely specify by capitalization the truly important special keywords that will actually be used for conformance verification. That keeps the informational document informational, prevents irresolvable keyword conflicts between the informational document and the primary documents, and allows the primary documents to do their compliance specification without any danger of misinterpretation. By changing all words in the informational document to lower case, it will be very clear that the details contained in the primary documents supercede the text of the informational document. ---------- Reference text from RFC 2026 ------------------------- 4.2.2 Informational An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. The Informational designation is intended to provide for the timely publication of a very broad range of responsible informational documents from many sources, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see section 4.2.3). Specifications that have been prepared outside of the Internet community and are not incorporated into the Internet Standards Process by any of the provisions of section 10 may be published as Informational RFCs, with the permission of the owner and the concurrence of the RFC Editor. -------------- Reference text from RFC 2119 ------------------- In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. ...... 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. 7. Security Considerations These terms are frequently used to specify behavior with security implications. The effects on security of not implementing a MUST or SHOULD, or doing something the specification says MUST NOT or SHOULD NOT be done may be very subtle. Document authors should take the time to elaborate the security implications of not following recommendations or requirements as most implementors will not have had the benefit of the experience and discussion that produced the specification. Bob Snively e-mail: rsnively@brocade.com Brocade Communications Systems phone: 408 487 8135 1745 Technology Drive San Jose, CA 95110 From owner-ips@ece.cmu.edu Wed Oct 17 21: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 VAA11625 for ; Wed, 17 Oct 2001 21:44:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9I0oef02675 for ips-outgoing; Wed, 17 Oct 2001 20:50:40 -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 f9I0ocl02671 for ; Wed, 17 Oct 2001 20:50:38 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Oct 2001 17:50:29 -0700 Message-ID: From: Charles Monia To: "Ips (E-mail)" Subject: RE: Question on security document Date: Wed, 17 Oct 2001 17:50: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 Hi: I had assumed that one goal of the document was to set forth the language necessary for each spec to pass muster with the IESG in the realm of security. If that's correct, I'm concerned that the suggested change may compromise that intent. Charles > -----Original Message----- > From: Robert Snively [mailto:rsnively@Brocade.COM] > Sent: Wednesday, October 17, 2001 4:31 PM > To: 'ips@ece.cmu.edu' > Subject: Question on security document > > > I have a recommendation to the authors of the security > document: > > draft-ietf-ips-security-03.txt > > There are a number of places where sentences like: > > "Conformant iSCSI, FCIP and iFCP security > implementations MUST support > both IKE Main Mode and Aggressive Mode." > > are used. I propose that all those "MUSTs", "SHOULDs", and similar > words in the security document be changed to lower case as > explained below. > > According to the security document, it is informational, and never > aspires to be more than an informational RFC. If I > understand RFC 2026 properly, Section 4.2.2 (attached below > for reference) strongly implies that these documents cannot > be used for verifying compliance. However, RFC 2119 has > a somewhat conflicted definition of how words like "MUST" > should be interpreted. It says that they are rare > and precious words that prevent very bad things from happening. > It is implied that non-interoperability is one of those things and > security failure is another. It also implies that they rise > no higher in requirement than the document itself. > > I had expected that the iSCSI, FCIP, and iFCP documents > were required to define their security compliance requirements. > However, here we have an informational draft taking over that > same job and using language that implies a compliance failure > if the "MUSTs" are ignored. It is not at all clear what would > happen if one of the primary documents accidentally or purposely > conflicted with the "MUSTs" of the security document. > > I believe the best solution for this is to change all words > in the security document with possible keyword meaning > to lower case, using the > corresponding wording in each of the primary documents to > to uniquely specify by capitalization the truly important > special keywords that will actually be used for conformance > verification. That keeps the informational document > informational, prevents irresolvable keyword conflicts between > the informational document and the primary documents, and allows > the primary documents to do their compliance specification > without any danger of misinterpretation. > By changing all words in the informational document to lower > case, it will be very clear that the details contained in the > primary documents supercede the text of the informational document. > > ---------- Reference text from RFC 2026 ------------------------- > > 4.2.2 Informational > > An "Informational" specification is published for the general > information of the Internet community, and does not represent an > Internet community consensus or recommendation. The Informational > designation is intended to provide for the timely publication of a > very broad range of responsible informational documents from many > sources, subject only to editorial considerations and to > verification > that there has been adequate coordination with the > standards process > (see section 4.2.3). > > Specifications that have been prepared outside of the Internet > community and are not incorporated into the Internet Standards > Process by any of the provisions of section 10 may be published as > Informational RFCs, with the permission of the owner and the > concurrence of the RFC Editor. > > > -------------- Reference text from RFC 2119 ------------------- > > > In many standards track documents several words are used to signify > the requirements in the specification. These words are often > capitalized. This document defines these words as they should be > interpreted in IETF documents. Authors who follow these guidelines > should incorporate this phrase near the beginning of their > document: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as > described in > RFC 2119. > > Note that the force of these words is modified by the requirement > level of the document in which they are used. > > 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the > definition is an absolute requirement of the specification. > > ...... > > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > > 7. Security Considerations > > These terms are frequently used to specify behavior with security > implications. The effects on security of not implementing > a MUST or > SHOULD, or doing something the specification says MUST NOT > or SHOULD > NOT be done may be very subtle. Document authors should > take the time > to elaborate the security implications of not following > recommendations or requirements as most implementors will not have > had the benefit of the experience and discussion that produced the > specification. > > > Bob Snively e-mail: rsnively@brocade.com > Brocade Communications Systems phone: 408 487 8135 > 1745 Technology Drive > San Jose, CA 95110 > From owner-ips@ece.cmu.edu Thu Oct 18 07:32: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 HAA04465 for ; Thu, 18 Oct 2001 07:32:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IAb2B16343 for ips-outgoing; Thu, 18 Oct 2001 06:37:02 -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 f9IAb0l16338 for ; Thu, 18 Oct 2001 06:37:00 -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 MAA81956; Thu, 18 Oct 2001 12:33: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 f9IAX4d259202; Thu, 18 Oct 2001 12:33:04 +0200 Importance: Normal Subject: Re: iSCSI: Login authentication SRP/CHAP To: michael_schoberg@cnt.com, Steven Senum Cc: "IPS Reflector (E-mail)" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Thu, 18 Oct 2001 13:34:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 18/10/2001 13:33:04 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Michael,. For the SRP questions: The hash is SHA-1 for which the parameter definitions are given in RFC -2945. We'll make that more clear (will reference the SRP-SHA1 mechanism there). The issue of the allowed DH groups (N,g) is still open - would hopefully be closed by next revision and a statement for that will be added. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Steven Senum @ece.cmu.edu on 17/10/2001 22:59:52 Please respond to Steven Senum Sent by: owner-ips@ece.cmu.edu To: "IPS Reflector (E-mail)" cc: Subject: Re: iSCSI: Login authentication SRP/CHAP Hi Michael, I can't answer your questions on SRP, but I probably can answer a few on CHAP. The CHAP_A key (algorithm) is specified in RFC 1994: 5 CHAP with MD5 [3] The CHAP_I (identifier), CHAP_C (challenge), CHAP_N (name) and CHAP_R (response) are also specified in RFC 1994: Identifier The Identifier field is one octet. The Identifier field MUST be changed each time a Challenge is sent. The Response Identifier MUST be copied from the Identifier field of the Challenge which caused the Response. Value (challenge and response) The Value field is one or more octets. The most significant octet is transmitted first. The Challenge Value is a variable stream of octets. The importance of the uniqueness of the Challenge Value and its relationship to the secret is described above. The Challenge Value MUST be changed each time a Challenge is sent. The length of the Challenge Value depends upon the method used to generate the octets, and is independent of the hash algorithm used. The Response Value is the one-way hash calculated over a stream of octets consisting of the Identifier, followed by (concatenated with) the "secret", followed by (concatenated with) the Challenge Value. The length of the Response Value depends upon the hash algorithm used (16 octets for MD5). Name The Name field is one or more octets representing the identification of the system transmitting the packet. There are no limitations on the content of this field. For example, it MAY contain ASCII character strings or globally unique identifiers in ASN.1 syntax. The Name should not be NUL or CR/LF terminated. The size is determined from the Length field. Basically, iSCSI just uses a different encoding, since it is sending "text" keys, instead of binary. A sample output from my (Cisco's) implementation is as follows: I-> AuthMethod=CHAP,none (CSG,NSG=0,1 T=1) T-> AuthMethod=CHAP (CSG,NSG=0,1 T=0) I-> CHAP_A=5 (CSG,NSG=0,1 T=0) T-> CHAP_A=5 (CSG,NSG=0,1 T=0) CHAP_I=70 CHAP_C=0x9593dd5e25f87b9e0fcc6891e6670461 I-> CHAP_N=u1 (CSG,NSG=0,1 T=1) CHAP_R=0x7e64294a4376affca14cdaecf3c72e21 T-> (CSG,NSG=0,1 T=1) You can also look at Cisco's Linux implementation on SourceForge: http://sourceforge.net/projects/linux-iscsi Hope this helps. Regards, Steve Senum Michael Schoberg wrote: > > I'm having some problems figuring out the exact implementation for the login > authentication protocols being proposed. Is anyone else having similar > issues answering these questions: > > What is the hashing algorithm that will be used for SRP authentication > (SHA-1, MD5, HMAC-SHA1)? > > The SRP negotiation passes the following information (T->I): > > SRP_s = SRP salt > SRP_N = (SRP n value - Large prime number. All computations are performed > modulo n) > SRP_g = Primitive root modulo of n > > By passing [N] & [g] (T->I), does this mean the initiator must verify that > [N] is a prime and [g] is a primitive root modulo of [N]? What are the > min/max digits for [N] and [g]? If any of these are not satisfied (N not > prime, g not primitive modulo root, #digits too small or large), could it be > used as an attack against the initiator or be used to derive the initiator's > password? > > The reference to RFC 1994 does not fully describe the CHAP function for > iSCSI, it describes the CHAP message protocol which isn't really used in our > case. There's some parameters that need to be nailed down. What is the > CHAP hash algorithm: (MD5)? What is the sequence of hashes that take place > on a CHAP challenge to form the CHAP digest? > > The iSCSI draft allows for algorithm selection (CHAP_A=) but > doesn't describe any. Are these supposed to dictate the hashing function or > give a description of [what/how it] gets hashed (or both)? Will there be a > mandatory set (A1..An) that compliant iSCSI implementations must provide? > Is there a reference that actually shows the sequence for a CHAP digest > being formed from MD5 hashes? > > It would help to have an appendix with real username/password examples of > the result exchange? A table with a few sample sets would be useful for > validating designs. From owner-ips@ece.cmu.edu Thu Oct 18 11: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 LAA13393 for ; Thu, 18 Oct 2001 11:53:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IEaNx01111 for ips-outgoing; Thu, 18 Oct 2001 10:36:23 -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 f9IEaLl01106 for ; Thu, 18 Oct 2001 10:36:21 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f9IEaAM30690; Thu, 18 Oct 2001 10:36:10 -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 f9IEa9d06759; Thu, 18 Oct 2001 10:36:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15310.59658.355000.995288@gargle.gargle.HOWL> Date: Thu, 18 Oct 2001 10:36:58 -0400 From: Paul Koning To: cmonia@NishanSystems.com Cc: ips@ece.cmu.edu Subject: RE: Question on security document 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 17 October 2001) by Charles Monia: > Hi: > > I had assumed that one goal of the document was to set forth the language > necessary for each spec to pass muster with the IESG in the realm of > security. If that's correct, I'm concerned that the suggested change may > compromise that intent. > > Charles > > -----Original Message----- > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > Sent: Wednesday, October 17, 2001 4:31 PM > > To: 'ips@ece.cmu.edu' > > Subject: Question on security document > > > > > > I have a recommendation to the authors of the security > > document: > > ... The problem, as Bob is right to point out, is that informational RFCs by definition cannot establish requirements on implementations. So if you want there to be security requirements that apply to iFCP, iSCSI, and so on, they can only be stated in standards track RFCs, not informational RFCs. It may be a separate document or part of the IPS document it applies to. So one answer is for the security draft not to be informational anymore. paul From owner-ips@ece.cmu.edu Thu Oct 18 12: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 MAA14802 for ; Thu, 18 Oct 2001 12:43:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IG2PE07991 for ips-outgoing; Thu, 18 Oct 2001 12:02:25 -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 f9IG29l07976 for ; Thu, 18 Oct 2001 12:02:14 -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 SAA13982; Thu, 18 Oct 2001 18:01:46 +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 f9IG1gd165180; Thu, 18 Oct 2001 18:01:42 +0200 Importance: Normal Subject: RE: Question on security document To: Robert Snively Cc: "'Paul Koning'" , cmonia@NishanSystems.com, ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Thu, 18 Oct 2001 19:02:57 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 18/10/2001 19:01:41 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bob, The intention of the security document was tutorial, elaborated discussion, motivations and more detailed guidelines and recommendations for the security aspects. The "official" mandatory statements are only in the standard RFCs. I'm not sure about the IETF rule for informational RFC but I don't see a problem with MUST statements there as long as they are in sync with the corresponding standard RFC. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Robert Snively @ece.cmu.edu on 18/10/2001 17:35:35 Please respond to Robert Snively Sent by: owner-ips@ece.cmu.edu To: "'Paul Koning'" , cmonia@NishanSystems.com cc: ips@ece.cmu.edu Subject: RE: Question on security document Paul, I rather prefer to see the security mandates carried in the primary documents, as our IETF mentors originally proposed. That way, there is less possibility of inconsistent language that may change the primary documents. Then the security document would be a tutorial and remain informational. This will simplify the standardization process, because each of us will only have to read the security document for guidelines to our development of the security section of the primary documents. If we were to make the security document the standard, then each of us will have to read the entire document to make sure that some global restriction does not fall unintentionally on a particular protocol. If we do choose to make the security document the authoritative document (which I would vote against), then it needs a major rewrite to clarify, separate, and make more precise the requirements for each protocol. Charles, If the security document was intended as a draft of the security sections for each protocol, it needs a major rewrite to separate the particular language to be dropped into each document from the tutorial information. It then needs to formulate much more clearly and formally the language that will be dropped into the primary documents. That would be okay with me, but the draft should indicate that the language to be dropped into the primary documents is only proposed and that the actual applicable standards information is contained in the primary document. Bob > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Thursday, October 18, 2001 7:37 AM > To: cmonia@NishanSystems.com > Cc: ips@ece.cmu.edu > Subject: RE: Question on security document > > > Excerpt of message (sent 17 October 2001) by Charles Monia: > > Hi: > > > > I had assumed that one goal of the document was to set > forth the language > > necessary for each spec to pass muster with the IESG in the realm of > > security. If that's correct, I'm concerned that the > suggested change may > > compromise that intent. > > > > Charles > > > -----Original Message----- > > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > > Sent: Wednesday, October 17, 2001 4:31 PM > > > To: 'ips@ece.cmu.edu' > > > Subject: Question on security document > > > > > > > > > I have a recommendation to the authors of the security > > > document: > > > ... > > The problem, as Bob is right to point out, is that informational RFCs > by definition cannot establish requirements on implementations. So if > you want there to be security requirements that apply to iFCP, iSCSI, > and so on, they can only be stated in standards track RFCs, not > informational RFCs. It may be a separate document or part of the IPS > document it applies to. > > So one answer is for the security draft not to be informational > anymore. > > paul > > From owner-ips@ece.cmu.edu Thu Oct 18 12:48: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 MAA14929 for ; Thu, 18 Oct 2001 12:48:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IFrtE07390 for ips-outgoing; Thu, 18 Oct 2001 11:53:55 -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 f9IFrpl07375 for ; Thu, 18 Oct 2001 11:53:52 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f9IFrkM30951 for ; Thu, 18 Oct 2001 11:53:46 -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 f9IFrj802398 for ; Thu, 18 Oct 2001 11:53:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15310.64314.0.111578@gargle.gargle.HOWL> Date: Thu, 18 Oct 2001 11:54:34 -0400 From: Paul Koning To: ips@ece.cmu.edu Subject: Re: iSCSI - changes - PDULength and related 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 (((resending this, since the previous copy seems to have gone AWOL))) Excerpt of message (sent 12 October 2001) by Julian Satran: > ... > In addition text request and response key+value strings are not required to > be confined to a single PDU (as we PDULength can be a low as 64 bytes!) > > Comments? Why change the minimum value of PDULength (and the two burstsize parameters)? It used to be 512, which makes more sense, although even that is rather small. Allowing the length to be set to such tiny values (like 64) adds a lot of complexity to the implementation to no useful purpose. I'd prefer to see a minimum around 1500, but if not, at least it should not be reduced from the existing value of 512. paul > ... > 23 MaxRecvPDULength > > Use: All > Who can send: Initiator and Target > > MaxRecvPDULength=<0|number-64-to-2**24> > ... > 24 MaxBurstSize > > Use: LO > Who can send: Initiator and Target > > MaxBurstSize=<0|number-64-to-2**24> > > Default is 256 Kbytes. > > Initiator and target negotiate maximum SCSI data payload in bytes > ... > 25 FirstBurstSize > > Use: LO > Who can send: Initiator and Target > > FirstBurstSize=<0|number-64-to-2**24> From owner-ips@ece.cmu.edu Thu Oct 18 12:48: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 MAA14954 for ; Thu, 18 Oct 2001 12:48:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IFZq505843 for ips-outgoing; Thu, 18 Oct 2001 11:35: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 f9IFZnl05833 for ; Thu, 18 Oct 2001 11:35:49 -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 IAA15688; Thu, 18 Oct 2001 08:35:36 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWV7ZTN>; Thu, 18 Oct 2001 08:35:36 -0700 Message-ID: From: Robert Snively To: "'Paul Koning'" , cmonia@NishanSystems.com Cc: ips@ece.cmu.edu Subject: RE: Question on security document Date: Thu, 18 Oct 2001 08:35:35 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Paul, I rather prefer to see the security mandates carried in the primary documents, as our IETF mentors originally proposed. That way, there is less possibility of inconsistent language that may change the primary documents. Then the security document would be a tutorial and remain informational. This will simplify the standardization process, because each of us will only have to read the security document for guidelines to our development of the security section of the primary documents. If we were to make the security document the standard, then each of us will have to read the entire document to make sure that some global restriction does not fall unintentionally on a particular protocol. If we do choose to make the security document the authoritative document (which I would vote against), then it needs a major rewrite to clarify, separate, and make more precise the requirements for each protocol. Charles, If the security document was intended as a draft of the security sections for each protocol, it needs a major rewrite to separate the particular language to be dropped into each document from the tutorial information. It then needs to formulate much more clearly and formally the language that will be dropped into the primary documents. That would be okay with me, but the draft should indicate that the language to be dropped into the primary documents is only proposed and that the actual applicable standards information is contained in the primary document. Bob > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Thursday, October 18, 2001 7:37 AM > To: cmonia@NishanSystems.com > Cc: ips@ece.cmu.edu > Subject: RE: Question on security document > > > Excerpt of message (sent 17 October 2001) by Charles Monia: > > Hi: > > > > I had assumed that one goal of the document was to set > forth the language > > necessary for each spec to pass muster with the IESG in the realm of > > security. If that's correct, I'm concerned that the > suggested change may > > compromise that intent. > > > > Charles > > > -----Original Message----- > > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > > Sent: Wednesday, October 17, 2001 4:31 PM > > > To: 'ips@ece.cmu.edu' > > > Subject: Question on security document > > > > > > > > > I have a recommendation to the authors of the security > > > document: > > > ... > > The problem, as Bob is right to point out, is that informational RFCs > by definition cannot establish requirements on implementations. So if > you want there to be security requirements that apply to iFCP, iSCSI, > and so on, they can only be stated in standards track RFCs, not > informational RFCs. It may be a separate document or part of the IPS > document it applies to. > > So one answer is for the security draft not to be informational > anymore. > > paul > > From owner-ips@ece.cmu.edu Thu Oct 18 13: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 NAA16813 for ; Thu, 18 Oct 2001 13:56:44 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IGpBi11902 for ips-outgoing; Thu, 18 Oct 2001 12:51:11 -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 f9IGp9l11898 for ; Thu, 18 Oct 2001 12:51:09 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9IGp3u29556; Thu, 18 Oct 2001 09:51:03 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9IGovB20577; Thu, 18 Oct 2001 09:50:57 -0700 From: "Bill Strahm" To: "Ofer Biran" , "Robert Snively" Cc: "'Paul Koning'" , , Subject: RE: Question on security document Date: Thu, 18 Oct 2001 09:50:44 -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 V6.00.2600.0000 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here is the problem. I create an informational RFC that includes compliance statements (I want to use 3Des, AES would be nice, etc.) I create a standards track RFC and point to the informational RFC to provide security I don't think you can do this - I know that you would not be able to go up the standards track because you are required to have all of your dependacies at your level of standardization or higher (It makes no sense to have a full standard dependant on a standard that is at draft standard level) Bob is technically correct. What I hope this group does is pick up the correct verbage from the security draft and put it into the standards protocol documents, or put the security doc on the standards track Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ofer Biran Sent: Thursday, October 18, 2001 9:03 AM To: Robert Snively Cc: 'Paul Koning'; cmonia@NishanSystems.com; ips@ece.cmu.edu Subject: RE: Question on security document Bob, The intention of the security document was tutorial, elaborated discussion, motivations and more detailed guidelines and recommendations for the security aspects. The "official" mandatory statements are only in the standard RFCs. I'm not sure about the IETF rule for informational RFC but I don't see a problem with MUST statements there as long as they are in sync with the corresponding standard RFC. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Robert Snively @ece.cmu.edu on 18/10/2001 17:35:35 Please respond to Robert Snively Sent by: owner-ips@ece.cmu.edu To: "'Paul Koning'" , cmonia@NishanSystems.com cc: ips@ece.cmu.edu Subject: RE: Question on security document Paul, I rather prefer to see the security mandates carried in the primary documents, as our IETF mentors originally proposed. That way, there is less possibility of inconsistent language that may change the primary documents. Then the security document would be a tutorial and remain informational. This will simplify the standardization process, because each of us will only have to read the security document for guidelines to our development of the security section of the primary documents. If we were to make the security document the standard, then each of us will have to read the entire document to make sure that some global restriction does not fall unintentionally on a particular protocol. If we do choose to make the security document the authoritative document (which I would vote against), then it needs a major rewrite to clarify, separate, and make more precise the requirements for each protocol. Charles, If the security document was intended as a draft of the security sections for each protocol, it needs a major rewrite to separate the particular language to be dropped into each document from the tutorial information. It then needs to formulate much more clearly and formally the language that will be dropped into the primary documents. That would be okay with me, but the draft should indicate that the language to be dropped into the primary documents is only proposed and that the actual applicable standards information is contained in the primary document. Bob > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Thursday, October 18, 2001 7:37 AM > To: cmonia@NishanSystems.com > Cc: ips@ece.cmu.edu > Subject: RE: Question on security document > > > Excerpt of message (sent 17 October 2001) by Charles Monia: > > Hi: > > > > I had assumed that one goal of the document was to set > forth the language > > necessary for each spec to pass muster with the IESG in the realm of > > security. If that's correct, I'm concerned that the > suggested change may > > compromise that intent. > > > > Charles > > > -----Original Message----- > > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > > Sent: Wednesday, October 17, 2001 4:31 PM > > > To: 'ips@ece.cmu.edu' > > > Subject: Question on security document > > > > > > > > > I have a recommendation to the authors of the security > > > document: > > > ... > > The problem, as Bob is right to point out, is that informational RFCs > by definition cannot establish requirements on implementations. So if > you want there to be security requirements that apply to iFCP, iSCSI, > and so on, they can only be stated in standards track RFCs, not > informational RFCs. It may be a separate document or part of the IPS > document it applies to. > > So one answer is for the security draft not to be informational > anymore. > > paul > > From owner-ips@ece.cmu.edu Thu Oct 18 13:58: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 NAA16846 for ; Thu, 18 Oct 2001 13:58:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IHP1Q14392 for ips-outgoing; Thu, 18 Oct 2001 13:25: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 f9IHOxl14387 for ; Thu, 18 Oct 2001 13:24:59 -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 TAA24440; Thu, 18 Oct 2001 19:24: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 f9IHOgd203152; Thu, 18 Oct 2001 19:24:42 +0200 Importance: Normal Subject: RE: Question on security document To: "Bill Strahm" Cc: "Robert Snively" , "'Paul Koning'" , , X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Thu, 18 Oct 2001 20:25:59 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 18/10/2001 20:24:43 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, > you are required to have all of your dependacies > at your level of standardization or higher For iSCSI the references to the security document definitely do not create a dependency. e.g.: "Further details on typical iSCSI scenarios and the relation between the initiators, targets and the communication end points can be found in [SEC-IPS]." Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "Bill Strahm" on 18/10/2001 18:50:44 Please respond to "Bill Strahm" To: Ofer Biran/Haifa/IBM@IBMIL, "Robert Snively" cc: "'Paul Koning'" , , Subject: RE: Question on security document Here is the problem. I create an informational RFC that includes compliance statements (I want to use 3Des, AES would be nice, etc.) I create a standards track RFC and point to the informational RFC to provide security I don't think you can do this - I know that you would not be able to go up the standards track because you are required to have all of your dependacies at your level of standardization or higher (It makes no sense to have a full standard dependant on a standard that is at draft standard level) Bob is technically correct. What I hope this group does is pick up the correct verbage from the security draft and put it into the standards protocol documents, or put the security doc on the standards track Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ofer Biran Sent: Thursday, October 18, 2001 9:03 AM To: Robert Snively Cc: 'Paul Koning'; cmonia@NishanSystems.com; ips@ece.cmu.edu Subject: RE: Question on security document Bob, The intention of the security document was tutorial, elaborated discussion, motivations and more detailed guidelines and recommendations for the security aspects. The "official" mandatory statements are only in the standard RFCs. I'm not sure about the IETF rule for informational RFC but I don't see a problem with MUST statements there as long as they are in sync with the corresponding standard RFC. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Robert Snively @ece.cmu.edu on 18/10/2001 17:35:35 Please respond to Robert Snively Sent by: owner-ips@ece.cmu.edu To: "'Paul Koning'" , cmonia@NishanSystems.com cc: ips@ece.cmu.edu Subject: RE: Question on security document Paul, I rather prefer to see the security mandates carried in the primary documents, as our IETF mentors originally proposed. That way, there is less possibility of inconsistent language that may change the primary documents. Then the security document would be a tutorial and remain informational. This will simplify the standardization process, because each of us will only have to read the security document for guidelines to our development of the security section of the primary documents. If we were to make the security document the standard, then each of us will have to read the entire document to make sure that some global restriction does not fall unintentionally on a particular protocol. If we do choose to make the security document the authoritative document (which I would vote against), then it needs a major rewrite to clarify, separate, and make more precise the requirements for each protocol. Charles, If the security document was intended as a draft of the security sections for each protocol, it needs a major rewrite to separate the particular language to be dropped into each document from the tutorial information. It then needs to formulate much more clearly and formally the language that will be dropped into the primary documents. That would be okay with me, but the draft should indicate that the language to be dropped into the primary documents is only proposed and that the actual applicable standards information is contained in the primary document. Bob > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Thursday, October 18, 2001 7:37 AM > To: cmonia@NishanSystems.com > Cc: ips@ece.cmu.edu > Subject: RE: Question on security document > > > Excerpt of message (sent 17 October 2001) by Charles Monia: > > Hi: > > > > I had assumed that one goal of the document was to set > forth the language > > necessary for each spec to pass muster with the IESG in the realm of > > security. If that's correct, I'm concerned that the > suggested change may > > compromise that intent. > > > > Charles > > > -----Original Message----- > > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > > Sent: Wednesday, October 17, 2001 4:31 PM > > > To: 'ips@ece.cmu.edu' > > > Subject: Question on security document > > > > > > > > > I have a recommendation to the authors of the security > > > document: > > > ... > > The problem, as Bob is right to point out, is that informational RFCs > by definition cannot establish requirements on implementations. So if > you want there to be security requirements that apply to iFCP, iSCSI, > and so on, they can only be stated in standards track RFCs, not > informational RFCs. It may be a separate document or part of the IPS > document it applies to. > > So one answer is for the security draft not to be informational > anymore. > > paul > > From owner-ips@ece.cmu.edu Thu Oct 18 13: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 NAA16863 for ; Thu, 18 Oct 2001 13:58:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IH6H912991 for ips-outgoing; Thu, 18 Oct 2001 13:06:17 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9IH5cl12944 for ; Thu, 18 Oct 2001 13:05:42 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9IH4qS02219 for ; Thu, 18 Oct 2001 13:04:52 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Thu, 18 Oct 2001 13:05:09 -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 40YK3H8W; Thu, 18 Oct 2001 13:04:40 -0400 Received: from travos.nortelnetworks.com (cse-ns-laptop.us.nortel.com [47.16.69.109]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T54YW2NJ; Thu, 18 Oct 2001 13:04:42 -0400 Message-Id: <5.0.2.1.2.20011018124737.03ff4d20@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 18 Oct 2001 13:05:55 -0400 To: Robert Snively , "'Paul Koning'" , cmonia@NishanSystems.com From: "Franco Travostino" Subject: RE: Question on security document Cc: ips@ece.cmu.edu In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_8978695==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_8978695==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed We have routinely taken our text into the security draft, and we had it reviewed and scrubbed off there by a good group of security experts. We routinely took selected things back into the authoritative document (iFCP in our case, but it could have been any one the three protocols). The use of the very same textual conventions is key to this high-bandwidth interaction, as well as to keeping the documents in sync as we repeat the cycle over and over. The security draft also serves the purpose of keeper of the knowledge, hence it does not fit the normative text role. Rationale text and data (e.g., the speed/cycles figures) will hopefully be a good companion text to many Standard RFC's readers. As well as new RFC writers (good data outlives bad theory :-). I don't see a conflict between MUST words and Informational RFC, the latter clearly and unambiguously dominates over the former. -franco At 11:35 AM 10/18/2001, Robert Snively wrote: >Paul, > >I rather prefer to see the security mandates carried in >the primary documents, as our IETF mentors originally proposed. >That way, there is less possibility of inconsistent >language that may change the primary documents. Then the >security document would be a tutorial and remain informational. >This will simplify the standardization process, because >each of us will only have to read the security document for >guidelines to our development of the security section of the >primary documents. If we were to make the security document >the standard, then each of us will have to >read the entire document to make sure that some global >restriction does not fall unintentionally on a particular >protocol. > >If we do choose to make the security document the authoritative >document (which I would vote against), then it needs a major >rewrite to clarify, separate, and make more precise the requirements for >each protocol. > >Charles, > >If the security document was intended as a draft of the security >sections for each protocol, it needs a major rewrite to separate >the particular language to be dropped into each document from the >tutorial information. It then needs to formulate much more >clearly and formally the language that will be dropped into the >primary documents. That would be okay with me, but the draft >should indicate that the language to be dropped into the >primary documents is only proposed and that the actual applicable >standards information is contained in the primary document. > >Bob > > > -----Original Message----- > > From: Paul Koning [mailto:ni1d@arrl.net] > > Sent: Thursday, October 18, 2001 7:37 AM > > To: cmonia@NishanSystems.com > > Cc: ips@ece.cmu.edu > > Subject: RE: Question on security document > > > > > > Excerpt of message (sent 17 October 2001) by Charles Monia: > > > Hi: > > > > > > I had assumed that one goal of the document was to set > > forth the language > > > necessary for each spec to pass muster with the IESG in the realm of > > > security. If that's correct, I'm concerned that the > > suggested change may > > > compromise that intent. > > > > > > Charles > > > > -----Original Message----- > > > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > > > Sent: Wednesday, October 17, 2001 4:31 PM > > > > To: 'ips@ece.cmu.edu' > > > > Subject: Question on security document > > > > > > > > > > > > I have a recommendation to the authors of the security > > > > document: > > > > ... > > > > The problem, as Bob is right to point out, is that informational RFCs > > by definition cannot establish requirements on implementations. So if > > you want there to be security requirements that apply to iFCP, iSCSI, > > and so on, they can only be stated in standards track RFCs, not > > informational RFCs. It may be a separate document or part of the IPS > > document it applies to. > > > > So one answer is for the security draft not to be informational > > anymore. > > > > paul > > > > 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 --=====================_8978695==_.ALT Content-Type: text/html; charset="us-ascii"
We have routinely taken our text into the security draft, and we had it reviewed and scrubbed off there by a good group of security experts. We routinely took selected things back into the authoritative document (iFCP in our case, but it could have been any one the three protocols). The use of the very same textual conventions is key to this high-bandwidth interaction, as well as to keeping the documents in sync as we repeat the cycle over and over.

The security draft also serves the purpose of keeper of the knowledge, hence it does not fit the normative text  role.  Rationale text and data (e.g., the speed/cycles figures) will hopefully be a good companion text to many Standard RFC's readers. As well as new RFC writers (good data outlives bad theory :-).

I don't see a conflict between MUST words and Informational RFC, the latter clearly and unambiguously dominates over the former.

-franco

At 11:35 AM 10/18/2001, Robert Snively wrote:
Paul,

I rather prefer to see the security mandates carried in
the primary documents, as our IETF mentors originally proposed.
That way, there is less possibility of inconsistent
language that may change the primary documents.  Then the
security document would be a tutorial and remain informational.
This will simplify the standardization process, because
each of us will only have to read the security document for
guidelines to our development of the security section of the
primary documents.  If we were to make the security document
the standard, then each of us will have to
read the entire document to make sure that some global
restriction does not fall unintentionally on a particular
protocol. 

If we do choose to make the security document the authoritative
document (which I would vote against), then it needs a major
rewrite to clarify, separate, and make more precise the requirements for
each protocol.

Charles, 

If the security document was intended as a draft of the security
sections for each protocol, it needs a major rewrite to separate
the particular language to be dropped into each document from the
tutorial information.  It then needs to formulate much more
clearly and formally the language that will be dropped into the
primary documents.  That would be okay with me, but the draft
should indicate that the language to be dropped into the
primary documents is only proposed and that the actual applicable
standards information is contained in the primary document.

Bob

> -----Original Message-----
> From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: Thursday, October 18, 2001 7:37 AM
> To: cmonia@NishanSystems.com
> Cc: ips@ece.cmu.edu
> Subject: RE: Question on security document
>
>
> Excerpt of message (sent 17 October 2001) by Charles Monia:
> > Hi:
> >
> > I had assumed that one goal of the document was to set
> forth the language
> > necessary for each spec to pass muster with the IESG in the realm of
> > security.  If that's correct, I'm concerned that the
> suggested change may
> > compromise that intent.
> >
> > Charles
> > > -----Original Message-----
> > > From: Robert Snively [mailto:rsnively@Brocade.COM]
> > > Sent: Wednesday, October 17, 2001 4:31 PM
> > > To: 'ips@ece.cmu.edu'
> > > Subject: Question on security document
> > >
> > >
> > > I have a recommendation to the authors of the security
> > > document:
> > > ...
>
> The problem, as Bob is right to point out, is that informational RFCs
> by definition cannot establish requirements on implementations.  So if
> you want there to be security requirements that apply to iFCP, iSCSI,
> and so on, they can only be stated in standards track RFCs, not
> informational RFCs.  It may be a separate document or part of the IPS
> document it applies to.
>
> So one answer is for the security draft not to be informational
> anymore.
>
>       paul
>
>


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
 --=====================_8978695==_.ALT-- From owner-ips@ece.cmu.edu Thu Oct 18 15:06: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 PAA18138 for ; Thu, 18 Oct 2001 15:06:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IHWgq14987 for ips-outgoing; Thu, 18 Oct 2001 13:32:42 -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 f9IHWel14982 for ; Thu, 18 Oct 2001 13:32:40 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9IHWYu29908; Thu, 18 Oct 2001 10:32:34 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9IHWTB21810; Thu, 18 Oct 2001 10:32:29 -0700 From: "Bill Strahm" To: "Ofer Biran" Cc: "Robert Snively" , "'Paul Koning'" , , Subject: RE: Question on security document Date: Thu, 18 Oct 2001 10:32:15 -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 V6.00.2600.0000 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit In that case you can't have requirements (ie SHOULD/MUST) language in the reference document... There is a difference between typical scenarios and REQUIRED scenarios... ie if you are saying that typically you will use IPsec with 3DES/SHA1 using Aggresive mode IKE that is fine... If you want to say you MUST use IKE/IPsec then you need a standards track document saying how you will do this. Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: Ofer Biran [mailto:BIRAN@il.ibm.com] Sent: Thursday, October 18, 2001 10:26 AM To: Bill Strahm Cc: Robert Snively; 'Paul Koning'; cmonia@NishanSystems.com; ips@ece.cmu.edu Subject: RE: Question on security document Bill, > you are required to have all of your dependacies > at your level of standardization or higher For iSCSI the references to the security document definitely do not create a dependency. e.g.: "Further details on typical iSCSI scenarios and the relation between the initiators, targets and the communication end points can be found in [SEC-IPS]." Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "Bill Strahm" on 18/10/2001 18:50:44 Please respond to "Bill Strahm" To: Ofer Biran/Haifa/IBM@IBMIL, "Robert Snively" cc: "'Paul Koning'" , , Subject: RE: Question on security document Here is the problem. I create an informational RFC that includes compliance statements (I want to use 3Des, AES would be nice, etc.) I create a standards track RFC and point to the informational RFC to provide security I don't think you can do this - I know that you would not be able to go up the standards track because you are required to have all of your dependacies at your level of standardization or higher (It makes no sense to have a full standard dependant on a standard that is at draft standard level) Bob is technically correct. What I hope this group does is pick up the correct verbage from the security draft and put it into the standards protocol documents, or put the security doc on the standards track Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ofer Biran Sent: Thursday, October 18, 2001 9:03 AM To: Robert Snively Cc: 'Paul Koning'; cmonia@NishanSystems.com; ips@ece.cmu.edu Subject: RE: Question on security document Bob, The intention of the security document was tutorial, elaborated discussion, motivations and more detailed guidelines and recommendations for the security aspects. The "official" mandatory statements are only in the standard RFCs. I'm not sure about the IETF rule for informational RFC but I don't see a problem with MUST statements there as long as they are in sync with the corresponding standard RFC. Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Robert Snively @ece.cmu.edu on 18/10/2001 17:35:35 Please respond to Robert Snively Sent by: owner-ips@ece.cmu.edu To: "'Paul Koning'" , cmonia@NishanSystems.com cc: ips@ece.cmu.edu Subject: RE: Question on security document Paul, I rather prefer to see the security mandates carried in the primary documents, as our IETF mentors originally proposed. That way, there is less possibility of inconsistent language that may change the primary documents. Then the security document would be a tutorial and remain informational. This will simplify the standardization process, because each of us will only have to read the security document for guidelines to our development of the security section of the primary documents. If we were to make the security document the standard, then each of us will have to read the entire document to make sure that some global restriction does not fall unintentionally on a particular protocol. If we do choose to make the security document the authoritative document (which I would vote against), then it needs a major rewrite to clarify, separate, and make more precise the requirements for each protocol. Charles, If the security document was intended as a draft of the security sections for each protocol, it needs a major rewrite to separate the particular language to be dropped into each document from the tutorial information. It then needs to formulate much more clearly and formally the language that will be dropped into the primary documents. That would be okay with me, but the draft should indicate that the language to be dropped into the primary documents is only proposed and that the actual applicable standards information is contained in the primary document. Bob > -----Original Message----- > From: Paul Koning [mailto:ni1d@arrl.net] > Sent: Thursday, October 18, 2001 7:37 AM > To: cmonia@NishanSystems.com > Cc: ips@ece.cmu.edu > Subject: RE: Question on security document > > > Excerpt of message (sent 17 October 2001) by Charles Monia: > > Hi: > > > > I had assumed that one goal of the document was to set > forth the language > > necessary for each spec to pass muster with the IESG in the realm of > > security. If that's correct, I'm concerned that the > suggested change may > > compromise that intent. > > > > Charles > > > -----Original Message----- > > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > > Sent: Wednesday, October 17, 2001 4:31 PM > > > To: 'ips@ece.cmu.edu' > > > Subject: Question on security document > > > > > > > > > I have a recommendation to the authors of the security > > > document: > > > ... > > The problem, as Bob is right to point out, is that informational RFCs > by definition cannot establish requirements on implementations. So if > you want there to be security requirements that apply to iFCP, iSCSI, > and so on, they can only be stated in standards track RFCs, not > informational RFCs. It may be a separate document or part of the IPS > document it applies to. > > So one answer is for the security draft not to be informational > anymore. > > paul > > From owner-ips@ece.cmu.edu Thu Oct 18 17:38: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 RAA20305 for ; Thu, 18 Oct 2001 17:38:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IKdTY00524 for ips-outgoing; Thu, 18 Oct 2001 16:39:29 -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 f9IKdRl00519 for ; Thu, 18 Oct 2001 16:39:27 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id <4R3PX8Q8>; Thu, 18 Oct 2001 15:39:21 -0500 Message-ID: <3C7122FAF06DD5118ED600500473364826312C@esply01.cnt.com> From: Michael Schoberg To: "IPS Reflector (E-mail)" Subject: iSCSI: Login error checking Date: Thu, 18 Oct 2001 15:36:10 -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 trying to figure out all the options/failure possibilities for LOGIN. Has anyone worked out the details on how to the current feature set correctly? There's a lot to look out for... If anyone sees anything that's incorrect or missing, please let me know. LOGIN RECEIVED Does the draft allow for Header Digest Errors (HDE) on login requests? If so, the draft allows these to be ignored. Potentially, an invalid or improperly formatted login request could end up being registered as a HDE and ignored. Generic command errors Login arrives but doesn't have the I-BIT set. Target ignores I-BIT error or follows synchronization rules. -or- Target responds with 0200, T-BIT, and drops connection. Login series arrives. N'th login contains alternate CmdSN value from (N=0). Target responds with 0200, T-BIT, and drops connection Login for a new connection to a session. CmdSN does not match expected CmdSN value. How much tolerance is allowed for this? Worst case, what is done? Login restart received (TSID != 0, X-BIT) ExpStatSN is not recognized for the existing connection. Target responds with 0200, T-BIT, and drops connection. Login restart received (TSID != 0, X-BIT) N'th login has X-BIT set. Target responds with 0200, T-BIT, and drops connection. Login received (TSID = 0, X-BIT) Target responds with 0200, T-BIT, and drops connection. Version range not within supported range. Target responds with 0205, T-BIT, and drops connection. (ISID, TSID, CID) errors Login arrives with (TSID = 0). Post authentication yields an existing SSID. X-BIT = false Target obeys TSID rule (2.5.3) and destroys previous SSID X-BIT = true Target attempts to recover the connection/session. Login arrives with (TSID != 0) (CID != 0). SSID isn't found. Target responds with 0200, 0208, T-BIT, and drops connection. Login arrives with (TSID != 0) (CID = 0) SSID exists. X-BIT = false Target Responds with 0200, T-BIT, and drops connection -or- Target cleanup & closes previous session post-authentication. X-BIT = true Target begins session recovery, closes previous session TCP socket. Login arrives with (TSID != 0) (CID != 0). SSID & CID exist. X-BIT = false Target Responds with 0200, T-BIT, and drops connection X-BIT = true Target begins connection recovery. Login arrives (TSID = 0) (CID != 0) Target Responds with 0200, T-BIT, and drops connection Login arrives (TSID != 0) (CID != 0). Too many connections for SSID. Target responds with 0206, T-BIT, and drops connection. Login negotiation stream, (ISID/TSID/CID) are seen changing from the fixed/negotiated values. Target responds with 0200, T-BIT, and drops connection. Invalid CSG / NSG Login arrives with an unexpected CSG value. Target responds with 0200, T-BIT, and drops connection. Login contains NSG that's invalid (or undesired) Target responds with valid/desired NSG value. Parameter passed in improper state Login has parameter that is invalid for the current negotiation state. (e.g. Sending a InitiatorName after InitiatorName was negotiated. Sending InitiatorName/TargetName when (CID != 0), Sending TargetName after TargetName already negotiated Sending a LoginOperationalNegotation parameter when CSG=0, etc.) Target Responds with 0200, T-Bit, Drops connection. -or- Target Responds normally, but with Parameter=reject Parameter Unknown Login has parameter that is unknown to target. Target Responds with Parameter=NotUnderstood Parameter value is invalid Login has parameter value that is not acceptable. Target responds with Parameter= Missing parameter Target receives login (T-BIT) Not all parameters (without defaults) negotiated for current login state. Target responds with 0207, T-BIT, and drops connection. SessionType Unavailable Target receives a SessionType that is unrecognized or unavailable. Target responds with 0209, T-BIT, and drops connection. Authentication Initiator does not offer an acceptable authentication method in SecurityNegotiation stage. Target responds with 0201, T-BIT, and drops connection TargetName requested is not available on this interface. Target responds with [0101, 0102, 0203, 0204], T-BIT, and drops connection. InitiatorName not recognized Target responds with 0202, T-BIT and drops connection. Initiator sends an invalid or incomplete response to an authentication exchange. Target responds with 0201, T-BIT, and drops connection. Target Error Encountered Misc. target error encountered. Target responds with 0300, T-BIT, and drops connection. iSCSI service disabled. Target responds with 0301, T-BIT, and drops connection. iSCSI service has run out of resources Target responds with 0302, T-BIT, and drops connection. From owner-ips@ece.cmu.edu Thu Oct 18 17:38: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 RAA20318 for ; Thu, 18 Oct 2001 17:38:59 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IKnlw01315 for ips-outgoing; Thu, 18 Oct 2001 16:49:47 -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 f9IKnil01308 for ; Thu, 18 Oct 2001 16:49:44 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Oct 2001 13:49:38 -0700 Message-ID: From: Charles Monia To: ips@ece.cmu.edu Subject: RE: Question on security document Date: Thu, 18 Oct 2001 13:49: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 Hi: I'm in agreement with the idea that the authoritative requirements are those explicitly spelled out in the protocol specs and not by reference to an informational document. My expectation was that the informational security spec being developed by the design team would provide the *language* or at least a clear statement of the requirements to be incorporated directly into the protocol specifications. Charles > -----Original Message----- > From: Robert Snively [mailto:rsnively@brocade.com] > Sent: Thursday, October 18, 2001 8:36 AM > To: 'Paul Koning'; cmonia@NishanSystems.com > Cc: ips@ece.cmu.edu > Subject: RE: Question on security document > > > Paul, > > I rather prefer to see the security mandates carried in > the primary documents, as our IETF mentors originally proposed. > That way, there is less possibility of inconsistent > language that may change the primary documents. Then the > security document would be a tutorial and remain informational. > This will simplify the standardization process, because > each of us will only have to read the security document for > guidelines to our development of the security section of the > primary documents. If we were to make the security document > the standard, then each of us will have to > read the entire document to make sure that some global > restriction does not fall unintentionally on a particular > protocol. > > If we do choose to make the security document the authoritative > document (which I would vote against), then it needs a major > rewrite to clarify, separate, and make more precise the > requirements for > each protocol. > > Charles, > > If the security document was intended as a draft of the security > sections for each protocol, it needs a major rewrite to separate > the particular language to be dropped into each document from the > tutorial information. It then needs to formulate much more > clearly and formally the language that will be dropped into the > primary documents. That would be okay with me, but the draft > should indicate that the language to be dropped into the > primary documents is only proposed and that the actual applicable > standards information is contained in the primary document. > > Bob > > > -----Original Message----- > > From: Paul Koning [mailto:ni1d@arrl.net] > > Sent: Thursday, October 18, 2001 7:37 AM > > To: cmonia@NishanSystems.com > > Cc: ips@ece.cmu.edu > > Subject: RE: Question on security document > > > > > > Excerpt of message (sent 17 October 2001) by Charles Monia: > > > Hi: > > > > > > I had assumed that one goal of the document was to set > > forth the language > > > necessary for each spec to pass muster with the IESG in > the realm of > > > security. If that's correct, I'm concerned that the > > suggested change may > > > compromise that intent. > > > > > > Charles > > > > -----Original Message----- > > > > From: Robert Snively [mailto:rsnively@Brocade.COM] > > > > Sent: Wednesday, October 17, 2001 4:31 PM > > > > To: 'ips@ece.cmu.edu' > > > > Subject: Question on security document > > > > > > > > > > > > I have a recommendation to the authors of the security > > > > document: > > > > ... > > > > The problem, as Bob is right to point out, is that > informational RFCs > > by definition cannot establish requirements on > implementations. So if > > you want there to be security requirements that apply to > iFCP, iSCSI, > > and so on, they can only be stated in standards track RFCs, not > > informational RFCs. It may be a separate document or part > of the IPS > > document it applies to. > > > > So one answer is for the security draft not to be informational > > anymore. > > > > paul > > > > > From owner-ips@ece.cmu.edu Thu Oct 18 17:40: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 RAA20344 for ; Thu, 18 Oct 2001 17:40:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IKoKA01365 for ips-outgoing; Thu, 18 Oct 2001 16:50:20 -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 f9IKoIl01360 for ; Thu, 18 Oct 2001 16:50:19 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id <4R3PX8VT>; Thu, 18 Oct 2001 15:50:13 -0500 Message-ID: <3C7122FAF06DD5118ED600500473364826312D@esply01.cnt.com> From: Michael Schoberg To: "'Steven Senum'" , "IPS Reflector (E-mail)" Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Thu, 18 Oct 2001 15:47:02 -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 Steve, So a CHAP calculation is: MD5() MD5() MD5() -> 16 byte digest -or- MD5( | | ) Where "|" is a concatenation function. -> 16 byte digest Shouldn't we be using the CHAP_N field rather than CHAP_I (CHAP Identifier)? I also noticed that RFC 1994 says to use the identifier (CHAP_I) as a reference in the response. The iSCSI draft doesn't refer to the CHAP_I value in the response. Thanks. : The CHAP_I (identifier), CHAP_C (challenge), : CHAP_N (name) and CHAP_R (response) : are also specified in RFC 1994: : : Identifier : : The Identifier field is one octet. The Identifier field MUST be : changed each time a Challenge is sent. : : The Response Identifier MUST be copied from the Identifier field : of the Challenge which caused the Response. : : Value (challenge and response) : : The Value field is one or more octets. The most : significant octet : is transmitted first. : : The Challenge Value is a variable stream of octets. The : importance of the uniqueness of the Challenge Value and its : relationship to the secret is described above. The Challenge : Value MUST be changed each time a Challenge is sent. The length : of the Challenge Value depends upon the method used to generate : the octets, and is independent of the hash algorithm used. : : The Response Value is the one-way hash calculated over : a stream of : octets consisting of the Identifier, followed by (concatenated : with) the "secret", followed by (concatenated with) the : Challenge : Value. The length of the Response Value depends upon the hash : algorithm used (16 octets for MD5). : : Name : : The Name field is one or more octets representing the : identification of the system transmitting the packet. There are : no limitations on the content of this field. For : example, it MAY : contain ASCII character strings or globally unique : identifiers in : ASN.1 syntax. The Name should not be NUL or CR/LF terminated. : The size is determined from the Length field. From owner-ips@ece.cmu.edu Thu Oct 18 17:51: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 RAA20459 for ; Thu, 18 Oct 2001 17:51:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9ILPTY03900 for ips-outgoing; Thu, 18 Oct 2001 17:25:29 -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 f9ILPRl03892 for ; Thu, 18 Oct 2001 17:25:27 -0400 (EDT) Received: from cisco.com (dhcp-161-44-68-189.cisco.com [161.44.68.189]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA04243 for ; Thu, 18 Oct 2001 17:25:21 -0400 (EDT) Message-ID: <3BCF48B6.D47DCB15@cisco.com> Date: Thu, 18 Oct 2001 16:25:10 -0500 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI: Login authentication SRP/CHAP References: <3C7122FAF06DD5118ED600500473364826312D@esply01.cnt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Michael, Michael Schoberg wrote: > > Steve, > > So a CHAP calculation is: > > MD5() > MD5() > MD5() > -> 16 byte digest > -or- > > MD5( | | ) Where "|" is a concatenation > function. > -> 16 byte digest The above looks correct. > > Shouldn't we be using the CHAP_N field rather than CHAP_I (CHAP Identifier)? No, CHAP_I is correct. CHAP_N (CHAP Name) is used to determine the shared secret. > > I also noticed that RFC 1994 says to use the identifier (CHAP_I) as a > reference in the response. The iSCSI draft doesn't refer to the CHAP_I > value in the response. Ofer and I didn't put CHAP_I in the response because: 1. It would break the bi-directional CHAP option. We would have to define a different key for the response to avoid key ambiguities. 2. We don't really need it, as PPP CHAP's purpose was to match up challenges and responses on an unreliable link. However, since it is part of the hash calculation, we still need to send it with the challenge. Regards, Steve Senum > : The CHAP_I (identifier), CHAP_C (challenge), > : CHAP_N (name) and CHAP_R (response) > : are also specified in RFC 1994: > : > : Identifier > : > : The Identifier field is one octet. The Identifier field MUST be > : changed each time a Challenge is sent. > : > : The Response Identifier MUST be copied from the Identifier field > : of the Challenge which caused the Response. > : > : Value (challenge and response) > : > : The Value field is one or more octets. The most > : significant octet > : is transmitted first. > : > : The Challenge Value is a variable stream of octets. The > : importance of the uniqueness of the Challenge Value and its > : relationship to the secret is described above. The Challenge > : Value MUST be changed each time a Challenge is sent. The length > : of the Challenge Value depends upon the method used to generate > : the octets, and is independent of the hash algorithm used. > : > : The Response Value is the one-way hash calculated over > : a stream of > : octets consisting of the Identifier, followed by (concatenated > : with) the "secret", followed by (concatenated with) the > : Challenge > : Value. The length of the Response Value depends upon the hash > : algorithm used (16 octets for MD5). > : > : Name > : > : The Name field is one or more octets representing the > : identification of the system transmitting the packet. There are > : no limitations on the content of this field. For > : example, it MAY > : contain ASCII character strings or globally unique > : identifiers in > : ASN.1 syntax. The Name should not be NUL or CR/LF terminated. > : The size is determined from the Length field. From owner-ips@ece.cmu.edu Thu Oct 18 20:18: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 UAA21684 for ; Thu, 18 Oct 2001 20:18:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9IN86N10664 for ips-outgoing; Thu, 18 Oct 2001 19:08: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 f9IN83l10655 for ; Thu, 18 Oct 2001 19:08:03 -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 QAA24641; Thu, 18 Oct 2001 16:07:48 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWV8GHS>; Thu, 18 Oct 2001 16:07:47 -0700 Message-ID: From: Robert Snively To: "'Franco Travostino'" Cc: ips@ece.cmu.edu Subject: RE: Question on security document Date: Thu, 18 Oct 2001 16:07:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15829.B2CF0660" 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_01C15829.B2CF0660 Content-Type: text/plain Franco, The problem is that the format of the document does not differentiate between the tutorial information and the language that is to go into the Standard RFCs. I would expect that we should have a formal clause for each document saying something to the effect: "and because of the knowledge carried in the above tutorial, the [FCIP, iSCSI, iFCP] document should contain the following text to properly describe the expected behavior. For the actual standard requirements, see [FCIP, iSCSI, iFCP]." This clearly separates the result of the discussion (text to be shoved into a Standard RFC which has no authority in this document, but will have authority when it is shoved into the Standard RFC, perhaps with editorial or technical modifications) and the tutorial discussion itself (which explains without any capitalized requirements why it is nice to do each of the things proposed in the text to be included in the Standard RFC). Bob -----Original Message----- From: Franco Travostino [mailto:travos@nortelnetworks.com] Sent: Thursday, October 18, 2001 10:06 AM To: Robert Snively; 'Paul Koning'; cmonia@NishanSystems.com Cc: ips@ece.cmu.edu Subject: RE: Question on security document We have routinely taken our text into the security draft, and we had it reviewed and scrubbed off there by a good group of security experts. We routinely took selected things back into the authoritative document (iFCP in our case, but it could have been any one the three protocols). The use of the very same textual conventions is key to this high-bandwidth interaction, as well as to keeping the documents in sync as we repeat the cycle over and over. The security draft also serves the purpose of keeper of the knowledge, hence it does not fit the normative text role. Rationale text and data (e.g., the speed/cycles figures) will hopefully be a good companion text to many Standard RFC's readers. As well as new RFC writers (good data outlives bad theory :-). I don't see a conflict between MUST words and Informational RFC, the latter clearly and unambiguously dominates over the former. -franco At 11:35 AM 10/18/2001, Robert Snively wrote: Paul, I rather prefer to see the security mandates carried in the primary documents, as our IETF mentors originally proposed. That way, there is less possibility of inconsistent language that may change the primary documents. Then the security document would be a tutorial and remain informational. This will simplify the standardization process, because each of us will only have to read the security document for guidelines to our development of the security section of the primary documents. If we were to make the security document the standard, then each of us will have to read the entire document to make sure that some global restriction does not fall unintentionally on a particular protocol. If we do choose to make the security document the authoritative document (which I would vote against), then it needs a major rewrite to clarify, separate, and make more precise the requirements for each protocol. Charles, If the security document was intended as a draft of the security sections for each protocol, it needs a major rewrite to separate the particular language to be dropped into each document from the tutorial information. It then needs to formulate much more clearly and formally the language that will be dropped into the primary documents. That would be okay with me, but the draft should indicate that the language to be dropped into the primary documents is only proposed and that the actual applicable standards information is contained in the primary document. Bob > -----Original Message----- > From: Paul Koning [ mailto:ni1d@arrl.net ] > Sent: Thursday, October 18, 2001 7:37 AM > To: cmonia@NishanSystems.com > Cc: ips@ece.cmu.edu > Subject: RE: Question on security document > > > Excerpt of message (sent 17 October 2001) by Charles Monia: > > Hi: > > > > I had assumed that one goal of the document was to set > forth the language > > necessary for each spec to pass muster with the IESG in the realm of > > security. If that's correct, I'm concerned that the > suggested change may > > compromise that intent. > > > > Charles > > > -----Original Message----- > > > From: Robert Snively [ mailto:rsnively@Brocade.COM ] > > > Sent: Wednesday, October 17, 2001 4:31 PM > > > To: 'ips@ece.cmu.edu' > > > Subject: Question on security document > > > > > > > > > I have a recommendation to the authors of the security > > > document: > > > ... > > The problem, as Bob is right to point out, is that informational RFCs > by definition cannot establish requirements on implementations. So if > you want there to be security requirements that apply to iFCP, iSCSI, > and so on, they can only be stated in standards track RFCs, not > informational RFCs. It may be a separate document or part of the IPS > document it applies to. > > So one answer is for the security draft not to be informational > anymore. > > paul > > 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_01C15829.B2CF0660 Content-Type: text/html

Franco,
 
The problem is that the format of the document does not differentiate between
the tutorial information and the language that is to go into the Standard RFCs.
 
I would expect that we should have a formal clause for each document saying
something to the effect:
 
"and because of the knowledge carried in the above tutorial, the [FCIP, iSCSI, iFCP]
document should contain the following text to properly describe the expected
behavior.  For the actual standard requirements, see [FCIP, iSCSI, iFCP]."
 
This clearly separates the result of the discussion (text to be shoved into a
Standard RFC which has no authority in this document, but will have authority when it is
shoved into the Standard RFC, perhaps with editorial or technical modifications)
and the tutorial discussion itself (which explains
without any capitalized requirements why it is nice to do each of the things
proposed in the text to be included in the Standard RFC).
 
Bob
-----Original Message-----
From: Franco Travostino [mailto:travos@nortelnetworks.com]
Sent: Thursday, October 18, 2001 10:06 AM
To: Robert Snively; 'Paul Koning'; cmonia@NishanSystems.com
Cc: ips@ece.cmu.edu
Subject: RE: Question on security document


We have routinely taken our text into the security draft, and we had it reviewed and scrubbed off there by a good group of security experts. We routinely took selected things back into the authoritative document (iFCP in our case, but it could have been any one the three protocols). The use of the very same textual conventions is key to this high-bandwidth interaction, as well as to keeping the documents in sync as we repeat the cycle over and over.

The security draft also serves the purpose of keeper of the knowledge, hence it does not fit the normative text  role.  Rationale text and data (e.g., the speed/cycles figures) will hopefully be a good companion text to many Standard RFC's readers. As well as new RFC writers (good data outlives bad theory :-).

I don't see a conflict between MUST words and Informational RFC, the latter clearly and unambiguously dominates over the former.

-franco

At 11:35 AM 10/18/2001, Robert Snively wrote:
Paul,

I rather prefer to see the security mandates carried in
the primary documents, as our IETF mentors originally proposed.
That way, there is less possibility of inconsistent
language that may change the primary documents.  Then the
security document would be a tutorial and remain informational.
This will simplify the standardization process, because
each of us will only have to read the security document for
guidelines to our development of the security section of the
primary documents.  If we were to make the security document
the standard, then each of us will have to
read the entire document to make sure that some global
restriction does not fall unintentionally on a particular
protocol. 

If we do choose to make the security document the authoritative
document (which I would vote against), then it needs a major
rewrite to clarify, separate, and make more precise the requirements for
each protocol.

Charles, 

If the security document was intended as a draft of the security
sections for each protocol, it needs a major rewrite to separate
the particular language to be dropped into each document from the
tutorial information.  It then needs to formulate much more
clearly and formally the language that will be dropped into the
primary documents.  That would be okay with me, but the draft
should indicate that the language to be dropped into the
primary documents is only proposed and that the actual applicable
standards information is contained in the primary document.

Bob

> -----Original Message-----
> From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: Thursday, October 18, 2001 7:37 AM
> To: cmonia@NishanSystems.com
> Cc: ips@ece.cmu.edu
> Subject: RE: Question on security document
>
>
> Excerpt of message (sent 17 October 2001) by Charles Monia:
> > Hi:
> >
> > I had assumed that one goal of the document was to set
> forth the language
> > necessary for each spec to pass muster with the IESG in the realm of
> > security.  If that's correct, I'm concerned that the
> suggested change may
> > compromise that intent.
> >
> > Charles
> > > -----Original Message-----
> > > From: Robert Snively [mailto:rsnively@Brocade.COM]
> > > Sent: Wednesday, October 17, 2001 4:31 PM
> > > To: 'ips@ece.cmu.edu'
> > > Subject: Question on security document
> > >
> > >
> > > I have a recommendation to the authors of the security
> > > document:
> > > ...
>
> The problem, as Bob is right to point out, is that informational RFCs
> by definition cannot establish requirements on implementations.  So if
> you want there to be security requirements that apply to iFCP, iSCSI,
> and so on, they can only be stated in standards track RFCs, not
> informational RFCs.  It may be a separate document or part of the IPS
> document it applies to.
>
> So one answer is for the security draft not to be informational
> anymore.
>
>       paul
>
>


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_01C15829.B2CF0660-- From owner-ips@ece.cmu.edu Thu Oct 18 21:06: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 VAA22115 for ; Thu, 18 Oct 2001 21:06:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9J0Ll614996 for ips-outgoing; Thu, 18 Oct 2001 20:21:47 -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 f9J0Lkl14991 for ; Thu, 18 Oct 2001 20:21:46 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Oct 2001 17:21:40 -0700 Message-ID: From: Charles Monia To: ips@ece.cmu.edu Subject: RE: Question on security document Date: Thu, 18 Oct 2001 17:21:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15834.049853C0" 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_01C15834.049853C0 Content-Type: text/plain; charset="iso-8859-1" Hi Folks: I hope we do not delay closure on the technical content in order to correct what seem to be editorial issues. Charles -----Original Message----- From: Robert Snively [mailto:rsnively@Brocade.COM] Sent: Thursday, October 18, 2001 4:08 PM To: 'Franco Travostino' Cc: ips@ece.cmu.edu Subject: RE: Question on security document Franco, The problem is that the format of the document does not differentiate between the tutorial information and the language that is to go into the Standard RFCs. I would expect that we should have a formal clause for each document saying something to the effect: "and because of the knowledge carried in the above tutorial, the [FCIP, iSCSI, iFCP] document should contain the following text to properly describe the expected behavior. For the actual standard requirements, see [FCIP, iSCSI, iFCP]." This clearly separates the result of the discussion (text to be shoved into a Standard RFC which has no authority in this document, but will have authority when it is shoved into the Standard RFC, perhaps with editorial or technical modifications) and the tutorial discussion itself (which explains without any capitalized requirements why it is nice to do each of the things proposed in the text to be included in the Standard RFC). Bob -----Original Message----- From: Franco Travostino [mailto:travos@nortelnetworks.com] Sent: Thursday, October 18, 2001 10:06 AM To: Robert Snively; 'Paul Koning'; cmonia@NishanSystems.com Cc: ips@ece.cmu.edu Subject: RE: Question on security document We have routinely taken our text into the security draft, and we had it reviewed and scrubbed off there by a good group of security experts. We routinely took selected things back into the authoritative document (iFCP in our case, but it could have been any one the three protocols). The use of the very same textual conventions is key to this high-bandwidth interaction, as well as to keeping the documents in sync as we repeat the cycle over and over. The security draft also serves the purpose of keeper of the knowledge, hence it does not fit the normative text role. Rationale text and data (e.g., the speed/cycles figures) will hopefully be a good companion text to many Standard RFC's readers. As well as new RFC writers (good data outlives bad theory :-). I don't see a conflict between MUST words and Informational RFC, the latter clearly and unambiguously dominates over the former. -franco At 11:35 AM 10/18/2001, Robert Snively wrote: Paul, I rather prefer to see the security mandates carried in the primary documents, as our IETF mentors originally proposed. That way, there is less possibility of inconsistent language that may change the primary documents. Then the security document would be a tutorial and remain informational. This will simplify the standardization process, because each of us will only have to read the security document for guidelines to our development of the security section of the primary documents. If we were to make the security document the standard, then each of us will have to read the entire document to make sure that some global restriction does not fall unintentionally on a particular protocol. If we do choose to make the security document the authoritative document (which I would vote against), then it needs a major rewrite to clarify, separate, and make more precise the requirements for each protocol. Charles, If the security document was intended as a draft of the security sections for each protocol, it needs a major rewrite to separate the particular language to be dropped into each document from the tutorial information. It then needs to formulate much more clearly and formally the language that will be dropped into the primary documents. That would be okay with me, but the draft should indicate that the language to be dropped into the primary documents is only proposed and that the actual applicable standards information is contained in the primary document. Bob > -----Original Message----- > From: Paul Koning [ mailto:ni1d@arrl.net ] > Sent: Thursday, October 18, 2001 7:37 AM > To: cmonia@NishanSystems.com > Cc: ips@ece.cmu.edu > Subject: RE: Question on security document > > > Excerpt of message (sent 17 October 2001) by Charles Monia: > > Hi: > > > > I had assumed that one goal of the document was to set > forth the language > > necessary for each spec to pass muster with the IESG in the realm of > > security. If that's correct, I'm concerned that the > suggested change may > > compromise that intent. > > > > Charles > > > -----Original Message----- > > > From: Robert Snively [ mailto:rsnively@Brocade.COM ] > > > Sent: Wednesday, October 17, 2001 4:31 PM > > > To: 'ips@ece.cmu.edu' > > > Subject: Question on security document > > > > > > > > > I have a recommendation to the authors of the security > > > document: > > > ... > > The problem, as Bob is right to point out, is that informational RFCs > by definition cannot establish requirements on implementations. So if > you want there to be security requirements that apply to iFCP, iSCSI, > and so on, they can only be stated in standards track RFCs, not > informational RFCs. It may be a separate document or part of the IPS > document it applies to. > > So one answer is for the security draft not to be informational > anymore. > > paul > > 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_01C15834.049853C0 Content-Type: text/html; charset="iso-8859-1"
Hi Folks:
 
I hope we do not delay closure on the technical content in order to correct what seem to be editorial issues.
 
Charles 
-----Original Message-----
From: Robert Snively [mailto:rsnively@Brocade.COM]
Sent: Thursday, October 18, 2001 4:08 PM
To: 'Franco Travostino'
Cc: ips@ece.cmu.edu
Subject: RE: Question on security document

Franco,
 
The problem is that the format of the document does not differentiate between
the tutorial information and the language that is to go into the Standard RFCs.
 
I would expect that we should have a formal clause for each document saying
something to the effect:
 
"and because of the knowledge carried in the above tutorial, the [FCIP, iSCSI, iFCP]
document should contain the following text to properly describe the expected
behavior.  For the actual standard requirements, see [FCIP, iSCSI, iFCP]."
 
This clearly separates the result of the discussion (text to be shoved into a
Standard RFC which has no authority in this document, but will have authority when it is
shoved into the Standard RFC, perhaps with editorial or technical modifications)
and the tutorial discussion itself (which explains
without any capitalized requirements why it is nice to do each of the things
proposed in the text to be included in the Standard RFC).
 
Bob
-----Original Message-----
From: Franco Travostino [mailto:travos@nortelnetworks.com]
Sent: Thursday, October 18, 2001 10:06 AM
To: Robert Snively; 'Paul Koning'; cmonia@NishanSystems.com
Cc: ips@ece.cmu.edu
Subject: RE: Question on security document


We have routinely taken our text into the security draft, and we had it reviewed and scrubbed off there by a good group of security experts. We routinely took selected things back into the authoritative document (iFCP in our case, but it could have been any one the three protocols). The use of the very same textual conventions is key to this high-bandwidth interaction, as well as to keeping the documents in sync as we repeat the cycle over and over.

The security draft also serves the purpose of keeper of the knowledge, hence it does not fit the normative text  role.  Rationale text and data (e.g., the speed/cycles figures) will hopefully be a good companion text to many Standard RFC's readers. As well as new RFC writers (good data outlives bad theory :-).

I don't see a conflict between MUST words and Informational RFC, the latter clearly and unambiguously dominates over the former.

-franco

At 11:35 AM 10/18/2001, Robert Snively wrote:
Paul,

I rather prefer to see the security mandates carried in
the primary documents, as our IETF mentors originally proposed.
That way, there is less possibility of inconsistent
language that may change the primary documents.  Then the
security document would be a tutorial and remain informational.
This will simplify the standardization process, because
each of us will only have to read the security document for
guidelines to our development of the security section of the
primary documents.  If we were to make the security document
the standard, then each of us will have to
read the entire document to make sure that some global
restriction does not fall unintentionally on a particular
protocol. 

If we do choose to make the security document the authoritative
document (which I would vote against), then it needs a major
rewrite to clarify, separate, and make more precise the requirements for
each protocol.

Charles, 

If the security document was intended as a draft of the security
sections for each protocol, it needs a major rewrite to separate
the particular language to be dropped into each document from the
tutorial information.  It then needs to formulate much more
clearly and formally the language that will be dropped into the
primary documents.  That would be okay with me, but the draft
should indicate that the language to be dropped into the
primary documents is only proposed and that the actual applicable
standards information is contained in the primary document.

Bob

> -----Original Message-----
> From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: Thursday, October 18, 2001 7:37 AM
> To: cmonia@NishanSystems.com
> Cc: ips@ece.cmu.edu
> Subject: RE: Question on security document
>
>
> Excerpt of message (sent 17 October 2001) by Charles Monia:
> > Hi:
> >
> > I had assumed that one goal of the document was to set
> forth the language
> > necessary for each spec to pass muster with the IESG in the realm of
> > security.  If that's correct, I'm concerned that the
> suggested change may
> > compromise that intent.
> >
> > Charles
> > > -----Original Message-----
> > > From: Robert Snively [mailto:rsnively@Brocade.COM]
> > > Sent: Wednesday, October 17, 2001 4:31 PM
> > > To: 'ips@ece.cmu.edu'
> > > Subject: Question on security document
> > >
> > >
> > > I have a recommendation to the authors of the security
> > > document:
> > > ...
>
> The problem, as Bob is right to point out, is that informational RFCs
> by definition cannot establish requirements on implementations.  So if
> you want there to be security requirements that apply to iFCP, iSCSI,
> and so on, they can only be stated in standards track RFCs, not
> informational RFCs.  It may be a separate document or part of the IPS
> document it applies to.
>
> So one answer is for the security draft not to be informational
> anymore.
>
>       paul
>
>


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_01C15834.049853C0-- From owner-ips@ece.cmu.edu Fri Oct 19 01:03: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 BAA26474 for ; Fri, 19 Oct 2001 01:03:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9J3m4427186 for ips-outgoing; Thu, 18 Oct 2001 23:48:04 -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 f9J3m3l27182 for ; Thu, 18 Oct 2001 23:48:03 -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 f9J3lu815517 for ; Thu, 18 Oct 2001 23:47:56 -0400 (EDT) Subject: IPS-ALL: RE: Question on security document MIME-Version: 1.0 Date: Thu, 18 Oct 2001 23:47:55 -0400 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15850.D61D187F" Message-ID: <9410A0F67DFE7F4D998D4538236498360408BF@nc8220exchange.ral.lucent.com> Disposition-Notification-To: "Elizabeth Rodriguez" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message Thread-Topic: Question on security document Thread-Index: AcFYNuie9xmqZbt7RBih1WKM/3IGZgAFz3hg From: "Elizabeth Rodriguez" To: "Charles Monia" , Cc: "Allison Mankin (E-mail)" , "Scott Bradner (E-mail)" , "David Black (E-mail)" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C15850.D61D187F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, =20 What Bob Snively and Bill Strahm have stated on this email thread is true -- the current tone of the security document is prescriptive -- making statements about conformance and direction for the iSCSI, FCIP and iFCP documents. Per RFC 2026, an informational draft is for general information only, and does not represent group consensus or recommendation. So, this does not quite fit what the direction of this document is presently. =20 =20 As pointed out by Bob, the current language in the security draft may cause confusion later, since if a draft (iSCSI, FCIP or iFCP) chooses to not follow a directive of the security RFC, that would be proper, in that the security RFC was informational only and cannot make requirements of the standards track documents. =20 The question remains on how to resolve the issue. There have been several recommendations on this thread, most of which are possible directions that we can take. I am unclear of what is the appropriate direction, and have asked the ADs for guidance on this issue. They have agreed that this is an important issue, and hope to respond quickly. =20 Thanks, =20 Elizabeth Rodriguez -----Original Message----- From: Charles Monia [mailto:cmonia@NishanSystems.com] Sent: Thursday, October 18, 2001 7:22 PM To: ips@ece.cmu.edu Subject: RE: Question on security document Hi Folks: =20 I hope we do not delay closure on the technical content in order to correct what seem to be editorial issues. =20 Charles=20 -----Original Message----- From: Robert Snively [mailto:rsnively@Brocade.COM] Sent: Thursday, October 18, 2001 4:08 PM To: 'Franco Travostino' Cc: ips@ece.cmu.edu Subject: RE: Question on security document Franco, =20 The problem is that the format of the document does not differentiate between the tutorial information and the language that is to go into the Standard RFCs. =20 I would expect that we should have a formal clause for each document saying something to the effect: =20 "and because of the knowledge carried in the above tutorial, the [FCIP, iSCSI, iFCP] document should contain the following text to properly describe the expected behavior. For the actual standard requirements, see [FCIP, iSCSI, iFCP]." =20 This clearly separates the result of the discussion (text to be shoved into a Standard RFC which has no authority in this document, but will have authority when it is=20 shoved into the Standard RFC, perhaps with editorial or technical modifications)=20 and the tutorial discussion itself (which explains without any capitalized requirements why it is nice to do each of the things proposed in the text to be included in the Standard RFC). =20 Bob -----Original Message----- From: Franco Travostino [mailto:travos@nortelnetworks.com] Sent: Thursday, October 18, 2001 10:06 AM To: Robert Snively; 'Paul Koning'; cmonia@NishanSystems.com Cc: ips@ece.cmu.edu Subject: RE: Question on security document We have routinely taken our text into the security draft, and we had it reviewed and scrubbed off there by a good group of security experts. We routinely took selected things back into the authoritative document (iFCP in our case, but it could have been any one the three protocols). The use of the very same textual conventions is key to this high-bandwidth interaction, as well as to keeping the documents in sync as we repeat the cycle over and over. The security draft also serves the purpose of keeper of the knowledge, hence it does not fit the normative text role. Rationale text and data (e.g., the speed/cycles figures) will hopefully be a good companion text to many Standard RFC's readers. As well as new RFC writers (good data outlives bad theory :-). I don't see a conflict between MUST words and Informational RFC, the latter clearly and unambiguously dominates over the former. -franco At 11:35 AM 10/18/2001, Robert Snively wrote: Paul, I rather prefer to see the security mandates carried in the primary documents, as our IETF mentors originally proposed. That way, there is less possibility of inconsistent language that may change the primary documents. Then the security document would be a tutorial and remain informational. This will simplify the standardization process, because=20 each of us will only have to read the security document for guidelines to our development of the security section of the primary documents. If we were to make the security document the standard, then each of us will have to read the entire document to make sure that some global restriction does not fall unintentionally on a particular protocol. =20 If we do choose to make the security document the authoritative document (which I would vote against), then it needs a major=20 rewrite to clarify, separate, and make more precise the requirements for each protocol. Charles, =20 If the security document was intended as a draft of the security sections for each protocol, it needs a major rewrite to separate the particular language to be dropped into each document from the tutorial information. It then needs to formulate much more clearly and formally the language that will be dropped into the primary documents. That would be okay with me, but the draft should indicate that the language to be dropped into the primary documents is only proposed and that the actual applicable standards information is contained in the primary document. Bob > -----Original Message----- > From: Paul Koning [ mailto:ni1d@arrl.net] > Sent: Thursday, October 18, 2001 7:37 AM > To: cmonia@NishanSystems.com > Cc: ips@ece.cmu.edu > Subject: RE: Question on security document >=20 >=20 > Excerpt of message (sent 17 October 2001) by Charles Monia: > > Hi: > >=20 > > I had assumed that one goal of the document was to set=20 > forth the language > > necessary for each spec to pass muster with the IESG in the realm of > > security. If that's correct, I'm concerned that the=20 > suggested change may > > compromise that intent. > >=20 > > Charles > > > -----Original Message----- > > > From: Robert Snively [ mailto:rsnively@Brocade.COM] > > > Sent: Wednesday, October 17, 2001 4:31 PM > > > To: 'ips@ece.cmu.edu' > > > Subject: Question on security document > > >=20 > > >=20 > > > I have a recommendation to the authors of the security=20 > > > document: > > > ... >=20 > The problem, as Bob is right to point out, is that informational RFCs > by definition cannot establish requirements on implementations. So if > you want there to be security requirements that apply to iFCP, iSCSI, > and so on, they can only be stated in standards track RFCs, not > informational RFCs. It may be a separate document or part of the IPS > document it applies to. >=20 > So one answer is for the security draft not to be informational > anymore. >=20 > paul >=20 >=20 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_01C15850.D61D187F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=20 all,
 
What=20 Bob Snively and Bill Strahm have stated on this email thread is true -- = the=20 current tone of the security document is prescriptive -- making = statements about=20 conformance and direction for the iSCSI, FCIP and iFCP documents.  = Per RFC=20 2026, an informational draft is for general information only, and = does not=20 represent group consensus or recommendation.  So, this does not = quite fit=20 what the direction of this document is presently.  =
 
As=20 pointed out by Bob, the current language in the security draft may cause = confusion later, since if a draft (iSCSI, FCIP or iFCP) chooses to not = follow a=20 directive of the security RFC, that would be proper, in that the = security RFC=20 was informational only and cannot make requirements of the standards = track=20 documents.
 
The=20 question remains on how to resolve the issue.  There have been = several=20 recommendations on this thread, most of which are possible directions = that we=20 can take.
I am=20 unclear of what is the appropriate direction, and have asked the ADs=20 for guidance on this issue.
They=20 have agreed that this is an important issue, and hope to respond=20 quickly.
 
Thanks,
 
Elizabeth Rodriguez
-----Original Message-----
From: Charles Monia=20 [mailto:cmonia@NishanSystems.com]
Sent: Thursday, October = 18, 2001=20 7:22 PM
To: ips@ece.cmu.edu
Subject: RE: Question = on=20 security document

Hi=20 Folks:
 
I=20 hope we do not delay closure on the technical content in order to = correct what=20 seem to be editorial issues.
 
Charles 
-----Original Message-----
From: Robert Snively=20 [mailto:rsnively@Brocade.COM]
Sent: Thursday, October 18, = 2001=20 4:08 PM
To: 'Franco Travostino'
Cc:=20 ips@ece.cmu.edu
Subject: RE: Question on security=20 document

Franco,
 
The problem is that the format of the = document does=20 not differentiate between
the tutorial information and the language = that is=20 to go into the Standard RFCs.
 
I=20 would expect that we should have a formal clause for each document=20 saying
something to the = effect:
 
"and because of the knowledge carried in = the above=20 tutorial, the [FCIP, iSCSI, iFCP]
document should contain the following = text to=20 properly describe the expected
behavior.  For the actual standard=20 requirements, see [FCIP, iSCSI, iFCP]."
 
This clearly separates the result of the = discussion=20 (text to be shoved into a
Standard RFC which has no authority in = this=20 document, but will have authority when it is
shoved into the Standard RFC, perhaps = with=20 editorial or technical modifications)
and the tutorial discussion itself (which = explains
without any capitalized requirements why = it is nice=20 to do each of the things
proposed in the text to be included in = the Standard=20 RFC).
 
Bob
-----Original Message-----
From: Franco = Travostino=20 [mailto:travos@nortelnetworks.com]
Sent: Thursday, = October 18,=20 2001 10:06 AM
To: Robert Snively; 'Paul Koning';=20 cmonia@NishanSystems.com
Cc: = ips@ece.cmu.edu
Subject:=20 RE: Question on security document


We=20 have routinely taken our text into the security draft, and we had = it=20 reviewed and scrubbed off there by a good group of security = experts. We=20 routinely took selected things back into the authoritative = document (iFCP=20 in our case, but it could have been any one the three protocols). = The use=20 of the very same textual conventions is key to this high-bandwidth = interaction, as well as to keeping the documents in sync as we = repeat the=20 cycle over and over.

The security draft also serves the = purpose of=20 keeper of the knowledge, hence it does not fit the normative = text =20 role.  Rationale text and data (e.g., the speed/cycles = figures) will=20 hopefully be a good companion text to many Standard RFC's readers. = As well=20 as new RFC writers (good data outlives bad theory :-).

I = don't see=20 a conflict between MUST words and Informational RFC, the latter = clearly=20 and unambiguously dominates over the = former.

-franco

At=20 11:35 AM 10/18/2001, Robert Snively wrote:
Paul,

I rather = prefer to=20 see the security mandates carried in
the primary documents, = as our=20 IETF mentors originally proposed.
That way, there is less = possibility=20 of inconsistent
language that may change the primary = documents. =20 Then the
security document would be a tutorial and remain=20 informational.
This will simplify the standardization = process,=20 because
each of us will only have to read the security = document=20 for
guidelines to our development of the security section of=20 the
primary documents.  If we were to make the security=20 document
the standard, then each of us will have to
read = the=20 entire document to make sure that some global
restriction = does not=20 fall unintentionally on a particular
protocol.  =

If we do=20 choose to make the security document the = authoritative
document=20 (which I would vote against), then it needs a major
rewrite = to=20 clarify, separate, and make more precise the requirements = for
each=20 protocol.

Charles, 

If the security document = was=20 intended as a draft of the security
sections for each = protocol, it=20 needs a major rewrite to separate
the particular language to = be=20 dropped into each document from the
tutorial = information.  It=20 then needs to formulate much more
clearly and formally the = language=20 that will be dropped into the
primary documents.  That = would be=20 okay with me, but the draft
should indicate that the language = to be=20 dropped into the
primary documents is only proposed and that = the=20 actual applicable
standards information is contained in the = primary=20 document.

Bob

> -----Original = Message-----
>=20 From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: = Thursday,=20 October 18, 2001 7:37 AM
> To: = cmonia@NishanSystems.com
>=20 Cc: ips@ece.cmu.edu
> Subject: RE: Question on security=20 document
>
>
> Excerpt of message (sent 17 = October=20 2001) by Charles Monia:
> > Hi:
> >
> = > I=20 had assumed that one goal of the document was to set
> = forth the=20 language
> > necessary for each spec to pass muster = with the=20 IESG in the realm of
> > security.  If that's = correct, I'm=20 concerned that the
> suggested change may
> > = compromise=20 that intent.
> >
> > Charles
> > = >=20 -----Original Message-----
> > > From: Robert = Snively [mailto:rsnively@Brocade.COM]
> > = >=20 Sent: Wednesday, October 17, 2001 4:31 PM
> > > To:=20 'ips@ece.cmu.edu'
> > > Subject: Question on = security=20 document
> > >
> > >
> > > = I have=20 a recommendation to the authors of the security
> > = >=20 document:
> > > ...
>
> The problem, as = Bob is=20 right to point out, is that informational RFCs
> by = definition=20 cannot establish requirements on implementations.  So = if
>=20 you want there to be security requirements that apply to iFCP,=20 iSCSI,
> and so on, they can only be stated in standards = track=20 RFCs, not
> informational RFCs.  It may be a separate = document or part of the IPS
> document it applies = to.
>=20
> So one answer is for the security draft not to be=20 informational
> anymore.
>
>=20       paul
> =
>=20


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

------_=_NextPart_001_01C15850.D61D187F-- From owner-ips@ece.cmu.edu Fri Oct 19 05:53: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 FAA13194 for ; Fri, 19 Oct 2001 05:53:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9J8sro12713 for ips-outgoing; Fri, 19 Oct 2001 04:54: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 f9J8spl12708 for ; Fri, 19 Oct 2001 04:54: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 EAA54380; Fri, 19 Oct 2001 04:52: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 f9J8snh100632; Fri, 19 Oct 2001 02:54:50 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Login authentication SRP/CHAP To: "Bill Strahm" Cc: "IPS Reflector \(E-mail\)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 19 Oct 2001 01:53:34 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/19/2001 02:54:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, IPSec is optional to use! So you can not assume that you have a Secure connection. And even if you use IPSec, you can not be sure that Privacy (encryption) is being used. So for these reasons alone you need to have an iSCSI method of Authentication. Next, the lower levels only know that the link is OK to be use for something. It does not know that it is iSCSI that is using the link, and if it did it does not have access to the iSCSI ACLs. Nor does iSCSI know what is handled at the lower levels so it must do its own ACL processing. Even if the link is secure (perhaps even encrypted) and iSCSI Authentication finds out that you are user "Bill", that does not say that you have the right to get at All resources. "Bill" will be authorized to operate from certain iSCSI Initiator Nodes, and those nodes will only be permitted to see certain approprate LUs. These are all iSCSI functions NOT TCP or IPSec. Your suggestion to use TLS, was fully discussed in Irvine, and that issue is now behind us. . . . 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 "Bill Strahm" @ece.cmu.edu on 10/17/2001 02:19:38 PM Sent by: owner-ips@ece.cmu.edu To: "IPS Reflector \(E-mail\)" cc: Subject: RE: iSCSI: Login authentication SRP/CHAP Just to bring up a cynical point. Why do we need SRP anyway... after all I am running over a required secure channel, so there should be no problem with just sending a user ID/Passphrase over the secure channel. This will prevent a LOT of interoperability problems, extra code required to implement additional security algorithms, etc. This makes my implementation much simpler, I can seperate login/authentication parameters (currently SRP) vs. setting up a secure channel (IPsec). If we go the Application level secure authentication method, I would rather we replace the security layer with TLS rather than IPsec, so we get authentication/security all in one place rather than scattered around lower layer protocols, application protocols... Bill Strahm +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Michael Schoberg Sent: Wednesday, October 17, 2001 12:53 PM To: IPS Reflector (E-mail) Subject: iSCSI: Login authentication SRP/CHAP I'm having some problems figuring out the exact implementation for the login authentication protocols being proposed. Is anyone else having similar issues answering these questions: What is the hashing algorithm that will be used for SRP authentication (SHA-1, MD5, HMAC-SHA1)? The SRP negotiation passes the following information (T->I): SRP_s = SRP salt SRP_N = (SRP n value - Large prime number. All computations are performed modulo n) SRP_g = Primitive root modulo of n By passing [N] & [g] (T->I), does this mean the initiator must verify that [N] is a prime and [g] is a primitive root modulo of [N]? What are the min/max digits for [N] and [g]? If any of these are not satisfied (N not prime, g not primitive modulo root, #digits too small or large), could it be used as an attack against the initiator or be used to derive the initiator's password? The reference to RFC 1994 does not fully describe the CHAP function for iSCSI, it describes the CHAP message protocol which isn't really used in our case. There's some parameters that need to be nailed down. What is the CHAP hash algorithm: (MD5)? What is the sequence of hashes that take place on a CHAP challenge to form the CHAP digest? The iSCSI draft allows for algorithm selection (CHAP_A=) but doesn't describe any. Are these supposed to dictate the hashing function or give a description of [what/how it] gets hashed (or both)? Will there be a mandatory set (A1..An) that compliant iSCSI implementations must provide? Is there a reference that actually shows the sequence for a CHAP digest being formed from MD5 hashes? It would help to have an appendix with real username/password examples of the result exchange? A table with a few sample sets would be useful for validating designs. From owner-ips@ece.cmu.edu Fri Oct 19 12:34: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 MAA23276 for ; Fri, 19 Oct 2001 12:34:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JFk3I17894 for ips-outgoing; Fri, 19 Oct 2001 11:46: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 f9JFk1l17888 for ; Fri, 19 Oct 2001 11:46: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 LAA28300; Fri, 19 Oct 2001 11:43:31 -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 f9JFjdY221284; Fri, 19 Oct 2001 09:45:39 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: Login authentication SRP/CHAP To: "Bill Strahm" Cc: "IPS Reflector \(E-mail\)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Fri, 19 Oct 2001 08:44:42 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/19/2001 09:45:38 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Bill, This was all discussed in Irvine, we need to move on to things which will help us close the Spec. . . . 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 "Bill Strahm" on 10/19/2001 08:35:59 AM To: John Hufferd/San Jose/IBM@IBMUS cc: "IPS Reflector \(E-mail\)" Subject: RE: iSCSI: Login authentication SRP/CHAP But it is Required to implement, so the link has as much security as the administrator requires for the situation. So if IPsec is not being used it is because a) the administrator doesn't care about wire security b) the administrator doesn't have anything that needs to be protected c) the administrator doesn't have the resources to protect it. So for those reasons I don't buy the argument in your first paragraph... The rest is just strict ACL... For you do not need SRP to provide identity information, I could just as easily send username="Bill" password="foo" over the wire and it will provide the same functionality (all SRP does is prevent you from having to send Bill and foo over the wire directly at the cost of a lot of mathematics. And with a link that is administratively configured to be adequately secure, I don't see the problem with it. I do not understand why you are requiring IPsec/IKE, but refusing to consider a much simpler to configure/support TLS. It sounds like many of the problems that you are having that are requiring you to go with a protocol that has unknown IP rights, and licensing behind it could be easily solved by changing the security from IPsec to TLS, but that is my opinion. I think the problem is that people are trying to solve way too many problems, assume that IPsec has adiquate link security and go from there. If IPsec is not capable of securing the link, then remove the solution and replace it with a technology that can secure the link... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, October 19, 2001 1:54 AM To: Bill Strahm Cc: IPS Reflector (E-mail) Subject: RE: iSCSI: Login authentication SRP/CHAP Bill, IPSec is optional to use! So you can not assume that you have a Secure connection. And even if you use IPSec, you can not be sure that Privacy (encryption) is being used. So for these reasons alone you need to have an iSCSI method of Authentication. Next, the lower levels only know that the link is OK to be use for something. It does not know that it is iSCSI that is using the link, and if it did it does not have access to the iSCSI ACLs. Nor does iSCSI know what is handled at the lower levels so it must do its own ACL processing. Even if the link is secure (perhaps even encrypted) and iSCSI Authentication finds out that you are user "Bill", that does not say that you have the right to get at All resources. "Bill" will be authorized to operate from certain iSCSI Initiator Nodes, and those nodes will only be permitted to see certain approprate LUs. These are all iSCSI functions NOT TCP or IPSec. Your suggestion to use TLS, was fully discussed in Irvine, and that issue is now behind us. . . . 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 "Bill Strahm" @ece.cmu.edu on 10/17/2001 02:19:38 PM Sent by: owner-ips@ece.cmu.edu To: "IPS Reflector \(E-mail\)" cc: Subject: RE: iSCSI: Login authentication SRP/CHAP Just to bring up a cynical point. Why do we need SRP anyway... after all I am running over a required secure channel, so there should be no problem with just sending a user ID/Passphrase over the secure channel. This will prevent a LOT of interoperability problems, extra code required to implement additional security algorithms, etc. This makes my implementation much simpler, I can seperate login/authentication parameters (currently SRP) vs. setting up a secure channel (IPsec). If we go the Application level secure authentication method, I would rather we replace the security layer with TLS rather than IPsec, so we get authentication/security all in one place rather than scattered around lower layer protocols, application protocols... Bill Strahm +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Michael Schoberg Sent: Wednesday, October 17, 2001 12:53 PM To: IPS Reflector (E-mail) Subject: iSCSI: Login authentication SRP/CHAP I'm having some problems figuring out the exact implementation for the login authentication protocols being proposed. Is anyone else having similar issues answering these questions: What is the hashing algorithm that will be used for SRP authentication (SHA-1, MD5, HMAC-SHA1)? The SRP negotiation passes the following information (T->I): SRP_s = SRP salt SRP_N = (SRP n value - Large prime number. All computations are performed modulo n) SRP_g = Primitive root modulo of n By passing [N] & [g] (T->I), does this mean the initiator must verify that [N] is a prime and [g] is a primitive root modulo of [N]? What are the min/max digits for [N] and [g]? If any of these are not satisfied (N not prime, g not primitive modulo root, #digits too small or large), could it be used as an attack against the initiator or be used to derive the initiator's password? The reference to RFC 1994 does not fully describe the CHAP function for iSCSI, it describes the CHAP message protocol which isn't really used in our case. There's some parameters that need to be nailed down. What is the CHAP hash algorithm: (MD5)? What is the sequence of hashes that take place on a CHAP challenge to form the CHAP digest? The iSCSI draft allows for algorithm selection (CHAP_A=) but doesn't describe any. Are these supposed to dictate the hashing function or give a description of [what/how it] gets hashed (or both)? Will there be a mandatory set (A1..An) that compliant iSCSI implementations must provide? Is there a reference that actually shows the sequence for a CHAP digest being formed from MD5 hashes? It would help to have an appendix with real username/password examples of the result exchange? A table with a few sample sets would be useful for validating designs. From owner-ips@ece.cmu.edu Fri Oct 19 12:37: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 MAA23426 for ; Fri, 19 Oct 2001 12:37:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JFaS417229 for ips-outgoing; Fri, 19 Oct 2001 11:36:28 -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 f9JFaQl17221 for ; Fri, 19 Oct 2001 11:36:26 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9JFaJu03442; Fri, 19 Oct 2001 08:36:20 -0700 Received: from strahmw2k (ras-pc-7-1.sanera.net [172.16.7.1]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9JFaDB11934; Fri, 19 Oct 2001 08:36:14 -0700 From: "Bill Strahm" To: "John Hufferd" Cc: "IPS Reflector \(E-mail\)" Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Fri, 19 Oct 2001 08:35:59 -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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit But it is Required to implement, so the link has as much security as the administrator requires for the situation. So if IPsec is not being used it is because a) the administrator doesn't care about wire security b) the administrator doesn't have anything that needs to be protected c) the administrator doesn't have the resources to protect it. So for those reasons I don't buy the argument in your first paragraph... The rest is just strict ACL... For you do not need SRP to provide identity information, I could just as easily send username="Bill" password="foo" over the wire and it will provide the same functionality (all SRP does is prevent you from having to send Bill and foo over the wire directly at the cost of a lot of mathematics. And with a link that is administratively configured to be adequately secure, I don't see the problem with it. I do not understand why you are requiring IPsec/IKE, but refusing to consider a much simpler to configure/support TLS. It sounds like many of the problems that you are having that are requiring you to go with a protocol that has unknown IP rights, and licensing behind it could be easily solved by changing the security from IPsec to TLS, but that is my opinion. I think the problem is that people are trying to solve way too many problems, assume that IPsec has adiquate link security and go from there. If IPsec is not capable of securing the link, then remove the solution and replace it with a technology that can secure the link... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, October 19, 2001 1:54 AM To: Bill Strahm Cc: IPS Reflector (E-mail) Subject: RE: iSCSI: Login authentication SRP/CHAP Bill, IPSec is optional to use! So you can not assume that you have a Secure connection. And even if you use IPSec, you can not be sure that Privacy (encryption) is being used. So for these reasons alone you need to have an iSCSI method of Authentication. Next, the lower levels only know that the link is OK to be use for something. It does not know that it is iSCSI that is using the link, and if it did it does not have access to the iSCSI ACLs. Nor does iSCSI know what is handled at the lower levels so it must do its own ACL processing. Even if the link is secure (perhaps even encrypted) and iSCSI Authentication finds out that you are user "Bill", that does not say that you have the right to get at All resources. "Bill" will be authorized to operate from certain iSCSI Initiator Nodes, and those nodes will only be permitted to see certain approprate LUs. These are all iSCSI functions NOT TCP or IPSec. Your suggestion to use TLS, was fully discussed in Irvine, and that issue is now behind us. . . . 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 "Bill Strahm" @ece.cmu.edu on 10/17/2001 02:19:38 PM Sent by: owner-ips@ece.cmu.edu To: "IPS Reflector \(E-mail\)" cc: Subject: RE: iSCSI: Login authentication SRP/CHAP Just to bring up a cynical point. Why do we need SRP anyway... after all I am running over a required secure channel, so there should be no problem with just sending a user ID/Passphrase over the secure channel. This will prevent a LOT of interoperability problems, extra code required to implement additional security algorithms, etc. This makes my implementation much simpler, I can seperate login/authentication parameters (currently SRP) vs. setting up a secure channel (IPsec). If we go the Application level secure authentication method, I would rather we replace the security layer with TLS rather than IPsec, so we get authentication/security all in one place rather than scattered around lower layer protocols, application protocols... Bill Strahm +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Michael Schoberg Sent: Wednesday, October 17, 2001 12:53 PM To: IPS Reflector (E-mail) Subject: iSCSI: Login authentication SRP/CHAP I'm having some problems figuring out the exact implementation for the login authentication protocols being proposed. Is anyone else having similar issues answering these questions: What is the hashing algorithm that will be used for SRP authentication (SHA-1, MD5, HMAC-SHA1)? The SRP negotiation passes the following information (T->I): SRP_s = SRP salt SRP_N = (SRP n value - Large prime number. All computations are performed modulo n) SRP_g = Primitive root modulo of n By passing [N] & [g] (T->I), does this mean the initiator must verify that [N] is a prime and [g] is a primitive root modulo of [N]? What are the min/max digits for [N] and [g]? If any of these are not satisfied (N not prime, g not primitive modulo root, #digits too small or large), could it be used as an attack against the initiator or be used to derive the initiator's password? The reference to RFC 1994 does not fully describe the CHAP function for iSCSI, it describes the CHAP message protocol which isn't really used in our case. There's some parameters that need to be nailed down. What is the CHAP hash algorithm: (MD5)? What is the sequence of hashes that take place on a CHAP challenge to form the CHAP digest? The iSCSI draft allows for algorithm selection (CHAP_A=) but doesn't describe any. Are these supposed to dictate the hashing function or give a description of [what/how it] gets hashed (or both)? Will there be a mandatory set (A1..An) that compliant iSCSI implementations must provide? Is there a reference that actually shows the sequence for a CHAP digest being formed from MD5 hashes? It would help to have an appendix with real username/password examples of the result exchange? A table with a few sample sets would be useful for validating designs. From owner-ips@ece.cmu.edu Fri Oct 19 12:38: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 MAA23485 for ; Fri, 19 Oct 2001 12:38:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JFuqx18840 for ips-outgoing; Fri, 19 Oct 2001 11:56:52 -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 f9JFupl18836 for ; Fri, 19 Oct 2001 11:56:51 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Oct 2001 08:56:44 -0700 Message-ID: From: Charles Monia To: "Ips (E-mail)" Subject: iFCP revision 6 Date: Fri, 19 Oct 2001 08:56: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 Colleagues: iFCP revision 6 is available for review at: ftp://ftp.t11.org/t11/docs/01-495v2.pdf -- PDF with markups visible ftp://ftp.t11.org/t11/docs/01-495v2.txt -- Text version We anticipate at least one more revision to reflect the findings of the security design team. Aside from that, the technical content is complete. With that in mind, we encourage a review by the IPS community with the understanding that further changes in the security section are expected. Charles Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 From owner-ips@ece.cmu.edu Fri Oct 19 12:42: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 MAA23650 for ; Fri, 19 Oct 2001 12:42:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JFbKo17293 for ips-outgoing; Fri, 19 Oct 2001 11:37:20 -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 f9JFbIl17289 for ; Fri, 19 Oct 2001 11:37:18 -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 IAA22278; Fri, 19 Oct 2001 08:37:09 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWV8PA3>; Fri, 19 Oct 2001 08:37:08 -0700 Message-ID: From: Robert Snively To: "'Charles Monia'" , ips@ece.cmu.edu Subject: RE: Question on security document Date: Fri, 19 Oct 2001 08:37:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C158B3.E87ED120" 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_01C158B3.E87ED120 Content-Type: text/plain; charset="iso-8859-1" Folks, I agree that this is in many respects an editorial issue, but it is one with profound capability for creating severe technical discrepancies which will delay the creation of interoperable implementations. We must not only resolve the technical content (which we are near to doing), but document it in such a manner that people will build it only one way, the way we want. Bob -----Original Message----- From: Charles Monia [mailto:cmonia@NishanSystems.com] Sent: Thursday, October 18, 2001 5:22 PM Hi Folks: I hope we do not delay closure on the technical content in order to correct what seem to be editorial issues. Charles -----Original Message----- From: Robert Snively [mailto:rsnively@Brocade.COM] Sent: Thursday, October 18, 2001 4:08 PM Franco, The problem is that the format of the document does not differentiate between the tutorial information and the language that is to go into the Standard RFCs. I would expect that we should have a formal clause for each document saying something to the effect: "and because of the knowledge carried in the above tutorial, the [FCIP, iSCSI, iFCP] document should contain the following text to properly describe the expected behavior. For the actual standard requirements, see [FCIP, iSCSI, iFCP]." This clearly separates the result of the discussion (text to be shoved into a Standard RFC which has no authority in this document, but will have authority when it is shoved into the Standard RFC, perhaps with editorial or technical modifications) and the tutorial discussion itself (which explains without any capitalized requirements why it is nice to do each of the things proposed in the text to be included in the Standard RFC). Bob -----Original Message----- From: Franco Travostino [mailto:travos@nortelnetworks.com] Sent: Thursday, October 18, 2001 10:06 AM We have routinely taken our text into the security draft, and we had it reviewed and scrubbed off there by a good group of security experts. We routinely took selected things back into the authoritative document (iFCP in our case, but it could have been any one the three protocols). The use of the very same textual conventions is key to this high-bandwidth interaction, as well as to keeping the documents in sync as we repeat the cycle over and over. The security draft also serves the purpose of keeper of the knowledge, hence it does not fit the normative text role. Rationale text and data (e.g., the speed/cycles figures) will hopefully be a good companion text to many Standard RFC's readers. As well as new RFC writers (good data outlives bad theory :-). I don't see a conflict between MUST words and Informational RFC, the latter clearly and unambiguously dominates over the former. -franco At 11:35 AM 10/18/2001, Robert Snively wrote: Paul, I rather prefer to see the security mandates carried in the primary documents, as our IETF mentors originally proposed. That way, there is less possibility of inconsistent language that may change the primary documents. Then the security document would be a tutorial and remain informational. This will simplify the standardization process, because each of us will only have to read the security document for guidelines to our development of the security section of the primary documents. If we were to make the security document the standard, then each of us will have to read the entire document to make sure that some global restriction does not fall unintentionally on a particular protocol. If we do choose to make the security document the authoritative document (which I would vote against), then it needs a major rewrite to clarify, separate, and make more precise the requirements for each protocol. Charles, If the security document was intended as a draft of the security sections for each protocol, it needs a major rewrite to separate the particular language to be dropped into each document from the tutorial information. It then needs to formulate much more clearly and formally the language that will be dropped into the primary documents. That would be okay with me, but the draft should indicate that the language to be dropped into the primary documents is only proposed and that the actual applicable standards information is contained in the primary document. Bob > -----Original Message----- > From: Paul Koning [ mailto:ni1d@arrl.net ] > Sent: Thursday, October 18, 2001 7:37 AM > > Excerpt of message (sent 17 October 2001) by Charles Monia: > > Hi: > > > > I had assumed that one goal of the document was to set > forth the language > > necessary for each spec to pass muster with the IESG in the realm of > > security. If that's correct, I'm concerned that the > suggested change may > > compromise that intent. > > > > Charles > > > -----Original Message----- > > > From: Robert Snively [ mailto:rsnively@Brocade.COM ] > > > Sent: Wednesday, October 17, 2001 4:31 PM > > > To: 'ips@ece.cmu.edu' > > > Subject: Question on security document > > > > > > > > > I have a recommendation to the authors of the security > > > document: > > > ... > > The problem, as Bob is right to point out, is that informational RFCs > by definition cannot establish requirements on implementations. So if > you want there to be security requirements that apply to iFCP, iSCSI, > and so on, they can only be stated in standards track RFCs, not > informational RFCs. It may be a separate document or part of the IPS > document it applies to. > > So one answer is for the security draft not to be informational > anymore. > > paul ------_=_NextPart_001_01C158B3.E87ED120 Content-Type: text/html; charset="iso-8859-1"
Folks,
 
I agree that this is in many respects an editorial issue, but it is one with profound capability
for creating severe technical discrepancies which will delay the creation of interoperable
implementations.  We must not only resolve the technical content (which we are near
to doing), but document it in such a manner that people will build it only one way,
the way we want.
 
Bob 
 
 -----Original Message-----
From: Charles Monia [mailto:cmonia@NishanSystems.com]
Sent: Thursday, October 18, 2001 5:22 PM
Hi Folks:
 
I hope we do not delay closure on the technical content in order to correct what seem to be editorial issues.
 
Charles 
-----Original Message-----
From: Robert Snively [mailto:rsnively@Brocade.COM]
Sent: Thursday, October 18, 2001 4:08 PM
Franco,
 
The problem is that the format of the document does not differentiate between
the tutorial information and the language that is to go into the Standard RFCs.
 
I would expect that we should have a formal clause for each document saying
something to the effect:
 
"and because of the knowledge carried in the above tutorial, the [FCIP, iSCSI, iFCP]
document should contain the following text to properly describe the expected
behavior.  For the actual standard requirements, see [FCIP, iSCSI, iFCP]."
 
This clearly separates the result of the discussion (text to be shoved into a
Standard RFC which has no authority in this document, but will have authority when it is
shoved into the Standard RFC, perhaps with editorial or technical modifications)
and the tutorial discussion itself (which explains
without any capitalized requirements why it is nice to do each of the things
proposed in the text to be included in the Standard RFC).
 
Bob
-----Original Message-----
From: Franco Travostino [mailto:travos@nortelnetworks.com]
Sent: Thursday, October 18, 2001 10:06 AM

We have routinely taken our text into the security draft, and we had it reviewed and scrubbed off there by a good group of security experts. We routinely took selected things back into the authoritative document (iFCP in our case, but it could have been any one the three protocols). The use of the very same textual conventions is key to this high-bandwidth interaction, as well as to keeping the documents in sync as we repeat the cycle over and over.

The security draft also serves the purpose of keeper of the knowledge, hence it does not fit the normative text  role.  Rationale text and data (e.g., the speed/cycles figures) will hopefully be a good companion text to many Standard RFC's readers. As well as new RFC writers (good data outlives bad theory :-).

I don't see a conflict between MUST words and Informational RFC, the latter clearly and unambiguously dominates over the former.

-franco

At 11:35 AM 10/18/2001, Robert Snively wrote:
Paul,

I rather prefer to see the security mandates carried in
the primary documents, as our IETF mentors originally proposed.
That way, there is less possibility of inconsistent
language that may change the primary documents.  Then the
security document would be a tutorial and remain informational.
This will simplify the standardization process, because
each of us will only have to read the security document for
guidelines to our development of the security section of the
primary documents.  If we were to make the security document
the standard, then each of us will have to
read the entire document to make sure that some global
restriction does not fall unintentionally on a particular
protocol. 

If we do choose to make the security document the authoritative
document (which I would vote against), then it needs a major
rewrite to clarify, separate, and make more precise the requirements for
each protocol.

Charles, 

If the security document was intended as a draft of the security
sections for each protocol, it needs a major rewrite to separate
the particular language to be dropped into each document from the
tutorial information.  It then needs to formulate much more
clearly and formally the language that will be dropped into the
primary documents.  That would be okay with me, but the draft
should indicate that the language to be dropped into the
primary documents is only proposed and that the actual applicable
standards information is contained in the primary document.

Bob

> -----Original Message-----
> From: Paul Koning [mailto:ni1d@arrl.net]
> Sent: Thursday, October 18, 2001 7:37 AM
>
> Excerpt of message (sent 17 October 2001) by Charles Monia:
> > Hi:
> >
> > I had assumed that one goal of the document was to set
> forth the language
> > necessary for each spec to pass muster with the IESG in the realm of
> > security.  If that's correct, I'm concerned that the
> suggested change may
> > compromise that intent.
> >
> > Charles
> > > -----Original Message-----
> > > From: Robert Snively [mailto:rsnively@Brocade.COM]
> > > Sent: Wednesday, October 17, 2001 4:31 PM
> > > To: 'ips@ece.cmu.edu'
> > > Subject: Question on security document
> > >
> > >
> > > I have a recommendation to the authors of the security
> > > document:
> > > ...
>
> The problem, as Bob is right to point out, is that informational RFCs
> by definition cannot establish requirements on implementations.  So if
> you want there to be security requirements that apply to iFCP, iSCSI,
> and so on, they can only be stated in standards track RFCs, not
> informational RFCs.  It may be a separate document or part of the IPS
> document it applies to.
>
> So one answer is for the security draft not to be informational
> anymore.
>
>       paul
------_=_NextPart_001_01C158B3.E87ED120-- From owner-ips@ece.cmu.edu Fri Oct 19 12:44: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 MAA23708 for ; Fri, 19 Oct 2001 12:44:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JG37D19248 for ips-outgoing; Fri, 19 Oct 2001 12:03:07 -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 f9JG35l19243 for ; Fri, 19 Oct 2001 12:03:05 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9JG30u03589; Fri, 19 Oct 2001 09:03:00 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9JG2sB12348; Fri, 19 Oct 2001 09:02:54 -0700 From: "Bill Strahm" To: "John Hufferd" Cc: "IPS Reflector \(E-mail\)" Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Fri, 19 Oct 2001 09:02:39 -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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok, We have MUST implement IPsec We have MUST implement SRP why don't we remove SRP as a MUST implement and go with CHAP, or another authentication protocol that doesn't have the IP problems that SRP has. I still haven't gotten a clean licensing statement from Stanford that I am comfortable with, and there was quite a bit of Zero Sum Proof of knowledge exchanges going on in Orange County about other IP involved with SRP. Again, SRP isn't needed, we have a secure link underneath the application, it will cost implementors an unknown amount of money to licence it, and it may infringe on other unknown patents... This isn't a good thing to base a standard on. Now I am not saying that you MUST NOT implement SRP, just move the requirement from MUST implement and I am happy. Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, October 19, 2001 8:45 AM To: Bill Strahm Cc: IPS Reflector (E-mail) Subject: RE: iSCSI: Login authentication SRP/CHAP Bill, This was all discussed in Irvine, we need to move on to things which will help us close the Spec. . . . 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 "Bill Strahm" on 10/19/2001 08:35:59 AM To: John Hufferd/San Jose/IBM@IBMUS cc: "IPS Reflector \(E-mail\)" Subject: RE: iSCSI: Login authentication SRP/CHAP But it is Required to implement, so the link has as much security as the administrator requires for the situation. So if IPsec is not being used it is because a) the administrator doesn't care about wire security b) the administrator doesn't have anything that needs to be protected c) the administrator doesn't have the resources to protect it. So for those reasons I don't buy the argument in your first paragraph... The rest is just strict ACL... For you do not need SRP to provide identity information, I could just as easily send username="Bill" password="foo" over the wire and it will provide the same functionality (all SRP does is prevent you from having to send Bill and foo over the wire directly at the cost of a lot of mathematics. And with a link that is administratively configured to be adequately secure, I don't see the problem with it. I do not understand why you are requiring IPsec/IKE, but refusing to consider a much simpler to configure/support TLS. It sounds like many of the problems that you are having that are requiring you to go with a protocol that has unknown IP rights, and licensing behind it could be easily solved by changing the security from IPsec to TLS, but that is my opinion. I think the problem is that people are trying to solve way too many problems, assume that IPsec has adiquate link security and go from there. If IPsec is not capable of securing the link, then remove the solution and replace it with a technology that can secure the link... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: John Hufferd [mailto:hufferd@us.ibm.com] Sent: Friday, October 19, 2001 1:54 AM To: Bill Strahm Cc: IPS Reflector (E-mail) Subject: RE: iSCSI: Login authentication SRP/CHAP Bill, IPSec is optional to use! So you can not assume that you have a Secure connection. And even if you use IPSec, you can not be sure that Privacy (encryption) is being used. So for these reasons alone you need to have an iSCSI method of Authentication. Next, the lower levels only know that the link is OK to be use for something. It does not know that it is iSCSI that is using the link, and if it did it does not have access to the iSCSI ACLs. Nor does iSCSI know what is handled at the lower levels so it must do its own ACL processing. Even if the link is secure (perhaps even encrypted) and iSCSI Authentication finds out that you are user "Bill", that does not say that you have the right to get at All resources. "Bill" will be authorized to operate from certain iSCSI Initiator Nodes, and those nodes will only be permitted to see certain approprate LUs. These are all iSCSI functions NOT TCP or IPSec. Your suggestion to use TLS, was fully discussed in Irvine, and that issue is now behind us. . . . 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 "Bill Strahm" @ece.cmu.edu on 10/17/2001 02:19:38 PM Sent by: owner-ips@ece.cmu.edu To: "IPS Reflector \(E-mail\)" cc: Subject: RE: iSCSI: Login authentication SRP/CHAP Just to bring up a cynical point. Why do we need SRP anyway... after all I am running over a required secure channel, so there should be no problem with just sending a user ID/Passphrase over the secure channel. This will prevent a LOT of interoperability problems, extra code required to implement additional security algorithms, etc. This makes my implementation much simpler, I can seperate login/authentication parameters (currently SRP) vs. setting up a secure channel (IPsec). If we go the Application level secure authentication method, I would rather we replace the security layer with TLS rather than IPsec, so we get authentication/security all in one place rather than scattered around lower layer protocols, application protocols... Bill Strahm +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Michael Schoberg Sent: Wednesday, October 17, 2001 12:53 PM To: IPS Reflector (E-mail) Subject: iSCSI: Login authentication SRP/CHAP I'm having some problems figuring out the exact implementation for the login authentication protocols being proposed. Is anyone else having similar issues answering these questions: What is the hashing algorithm that will be used for SRP authentication (SHA-1, MD5, HMAC-SHA1)? The SRP negotiation passes the following information (T->I): SRP_s = SRP salt SRP_N = (SRP n value - Large prime number. All computations are performed modulo n) SRP_g = Primitive root modulo of n By passing [N] & [g] (T->I), does this mean the initiator must verify that [N] is a prime and [g] is a primitive root modulo of [N]? What are the min/max digits for [N] and [g]? If any of these are not satisfied (N not prime, g not primitive modulo root, #digits too small or large), could it be used as an attack against the initiator or be used to derive the initiator's password? The reference to RFC 1994 does not fully describe the CHAP function for iSCSI, it describes the CHAP message protocol which isn't really used in our case. There's some parameters that need to be nailed down. What is the CHAP hash algorithm: (MD5)? What is the sequence of hashes that take place on a CHAP challenge to form the CHAP digest? The iSCSI draft allows for algorithm selection (CHAP_A=) but doesn't describe any. Are these supposed to dictate the hashing function or give a description of [what/how it] gets hashed (or both)? Will there be a mandatory set (A1..An) that compliant iSCSI implementations must provide? Is there a reference that actually shows the sequence for a CHAP digest being formed from MD5 hashes? It would help to have an appendix with real username/password examples of the result exchange? A table with a few sample sets would be useful for validating designs. From owner-ips@ece.cmu.edu Fri Oct 19 13:24: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 NAA25136 for ; Fri, 19 Oct 2001 13:24:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JGgmp22066 for ips-outgoing; Fri, 19 Oct 2001 12:42: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] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9JGgkl22061 for ; Fri, 19 Oct 2001 12:42:46 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9JGgeu03862; Fri, 19 Oct 2001 09:42:40 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9JGgZB13358; Fri, 19 Oct 2001 09:42:35 -0700 From: "Bill Strahm" To: Cc: "John Hufferd" , "IPS Reflector \(E-mail\)" Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Fri, 19 Oct 2001 09:42:17 -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: <3BD0534B.3A3A371F@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit So what you are arguing is that you expect a large number of implementations to opt for #3... In that case we do not have a secure link. You have two choices, either remove option #3 because they are not iSCSI devices therefore do not need to be considered, or change your security requirement to use IPsec to a SHOULD... I honestly think the later is the better choice because right now there are VERY few solutions that can handle IPsec at the speeds we are talking about (there are a few IPsec accellerators that you hinted at in existance today however)... Now if I have a situation where I do not have a required secure link under the protocol, then I think we MUST have a secure login... But I don't think we need both (I think both requirements should be SHOULD requirements to solve a problem) Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: mbakke@cisco.com [mailto:mbakke@cisco.com] Sent: Friday, October 19, 2001 9:23 AM To: Bill Strahm Cc: John Hufferd; IPS Reflector (E-mail) Subject: Re: iSCSI: Login authentication SRP/CHAP Bill- We have talked about this very subject extensively in other face-to-face meetings. Here's a summary. Basically, the "mandatory to implement" for a secure link (either IPsec or SSL) is an IETF requirement, and not necessarily a product requirement. Therefore, we will see three kinds of products: 1. Products that implement IPsec in hardware. These will provide good performance and security in the same package, but will add hardware cost (not list price) at a few hundred dollars per port. This, plus development cost, plus the fact that not everyone requires this kind of security, will make this cost-prohibitive for many products. As IPsec chips are developed, this could be integrated at a somewhat lower cost, but again, we're talking a fairly long time before these things are realized in products. 2. Products that implement IPsec in software. This may be acceptable for some initiators that do not require much bandwidth, but will almost never be acceptable to meet a target's bandwidth requirements. Some vendors may be tempted to put in a "toy implementation" of IPsec in software just to claim RFC compliance, but performance will be so poor that nobody will actually want to use it. 3. Products that just leave out IPsec entirely. This is what today's iSCSI products already do, and this is cheaper than putting IPsec in hardware, and more honest (at least in high bandwidth products) than putting it in software. The marketing guys can deal with the "compliant-except-for-IPsec" problem. After all, very few file server or other data storage products support this kind of security; the demand for IPsec may be a specialty market, or an optional, added-cost item for some products. It doesn't matter whether IPsec or SSL is used for the secure link; either one requires roughly the same hardware cost and/or software performance cost for the above solutions. We have to deal with #3. -- Mark Bill Strahm wrote: > > But it is Required to implement, so the link has as much security as the > administrator requires for the situation. So if IPsec is not being used it > is because a) the administrator doesn't care about wire security b) the > administrator doesn't have anything that needs to be protected c) the > administrator doesn't have the resources to protect it. So for those > reasons I don't buy the argument in your first paragraph... > > The rest is just strict ACL... For you do not need SRP to provide identity > information, I could just as easily send username="Bill" password="foo" over > the wire and it will provide the same functionality (all SRP does is prevent > you from having to send Bill and foo over the wire directly at the cost of a > lot of mathematics. And with a link that is administratively configured to > be adequately secure, I don't see the problem with it. > > I do not understand why you are requiring IPsec/IKE, but refusing to > consider a much simpler to configure/support TLS. It sounds like many of > the problems that you are having that are requiring you to go with a > protocol that has unknown IP rights, and licensing behind it could be easily > solved by changing the security from IPsec to TLS, but that is my opinion. > > I think the problem is that people are trying to solve way too many > problems, assume that IPsec has adiquate link security and go from there. > If IPsec is not capable of securing the link, then remove the solution and > replace it with a technology that can secure the link... > > Bill > +========+=========+=========+=========+=========+=========+=========+ > Bill Strahm Software Development is a race between Programmers > Member of the trying to build bigger and better idiot proof software > Technical Staff and the Universe trying to produce bigger and better > bill@sanera.net idiots. > (503) 601-0263 So far the Universe is winning --- Rich Cook > > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, October 19, 2001 1:54 AM > To: Bill Strahm > Cc: IPS Reflector (E-mail) > Subject: RE: iSCSI: Login authentication SRP/CHAP > > Bill, > IPSec is optional to use! So you can not assume that you have a Secure > connection. And even if you use IPSec, you can not be sure that Privacy > (encryption) is being used. So for these reasons alone you need to have an > iSCSI method of Authentication. > > Next, the lower levels only know that the link is OK to be use for > something. It does not know that it is iSCSI that is using the link, and > if it did it does not have access to the iSCSI ACLs. Nor does iSCSI know > what is handled at the lower levels so it must do its own ACL processing. > > Even if the link is secure (perhaps even encrypted) and iSCSI > Authentication finds out that you are user "Bill", that does not say that > you have the right to get at All resources. "Bill" will be authorized to > operate from certain iSCSI Initiator Nodes, and those nodes will only be > permitted to see certain approprate LUs. These are all iSCSI functions NOT > TCP or IPSec. > > Your suggestion to use TLS, was fully discussed in Irvine, and that issue > is now behind us. > > . > . > . > 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 > > "Bill Strahm" @ece.cmu.edu on 10/17/2001 02:19:38 PM > > Sent by: owner-ips@ece.cmu.edu > > To: "IPS Reflector \(E-mail\)" > cc: > Subject: RE: iSCSI: Login authentication SRP/CHAP > > Just to bring up a cynical point. Why do we need SRP anyway... after all I > am running over a required secure channel, so there should be no problem > with just sending a user ID/Passphrase over the secure channel. This will > prevent a LOT of interoperability problems, extra code required to > implement > additional security algorithms, etc. > > This makes my implementation much simpler, I can seperate > login/authentication parameters (currently SRP) vs. setting up a secure > channel (IPsec). If we go the Application level secure authentication > method, I would rather we replace the security layer with TLS rather than > IPsec, so we get authentication/security all in one place rather than > scattered around lower layer protocols, application protocols... > > Bill Strahm > +========+=========+=========+=========+=========+=========+=========+ > Bill Strahm Software Development is a race between Programmers > Member of the trying to build bigger and better idiot proof software > Technical Staff and the Universe trying to produce bigger and better > bill@sanera.net idiots. > (503) 601-0263 So far the Universe is winning --- Rich Cook > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Michael Schoberg > Sent: Wednesday, October 17, 2001 12:53 PM > To: IPS Reflector (E-mail) > Subject: iSCSI: Login authentication SRP/CHAP > > I'm having some problems figuring out the exact implementation for the > login > authentication protocols being proposed. Is anyone else having similar > issues answering these questions: > > What is the hashing algorithm that will be used for SRP authentication > (SHA-1, MD5, HMAC-SHA1)? > > The SRP negotiation passes the following information (T->I): > > SRP_s = SRP salt > SRP_N = (SRP n value - Large prime number. All computations are performed > modulo n) > SRP_g = Primitive root modulo of n > > By passing [N] & [g] (T->I), does this mean the initiator must verify that > [N] is a prime and [g] is a primitive root modulo of [N]? What are the > min/max digits for [N] and [g]? If any of these are not satisfied (N not > prime, g not primitive modulo root, #digits too small or large), could it > be > used as an attack against the initiator or be used to derive the > initiator's > password? > > The reference to RFC 1994 does not fully describe the CHAP function for > iSCSI, it describes the CHAP message protocol which isn't really used in > our > case. There's some parameters that need to be nailed down. What is the > CHAP hash algorithm: (MD5)? What is the sequence of hashes that take place > on a CHAP challenge to form the CHAP digest? > > The iSCSI draft allows for algorithm selection (CHAP_A=) but > doesn't describe any. Are these supposed to dictate the hashing function > or > give a description of [what/how it] gets hashed (or both)? Will there be a > mandatory set (A1..An) that compliant iSCSI implementations must provide? > Is there a reference that actually shows the sequence for a CHAP digest > being formed from MD5 hashes? > > It would help to have an appendix with real username/password examples of > the result exchange? A table with a few sample sets would be useful for > validating designs. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Oct 19 13:26: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 NAA25180 for ; Fri, 19 Oct 2001 13:26:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JGWB721275 for ips-outgoing; Fri, 19 Oct 2001 12:32:11 -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 f9JGW9l21271 for ; Fri, 19 Oct 2001 12:32:09 -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 MAA03652; Fri, 19 Oct 2001 12:31:56 -0400 (EDT) Message-ID: <3BD0534B.3A3A371F@cisco.com> Date: Fri, 19 Oct 2001 11:22:35 -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: Bill Strahm CC: John Hufferd , "IPS Reflector (E-mail)" Subject: Re: iSCSI: Login authentication SRP/CHAP 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- We have talked about this very subject extensively in other face-to-face meetings. Here's a summary. Basically, the "mandatory to implement" for a secure link (either IPsec or SSL) is an IETF requirement, and not necessarily a product requirement. Therefore, we will see three kinds of products: 1. Products that implement IPsec in hardware. These will provide good performance and security in the same package, but will add hardware cost (not list price) at a few hundred dollars per port. This, plus development cost, plus the fact that not everyone requires this kind of security, will make this cost-prohibitive for many products. As IPsec chips are developed, this could be integrated at a somewhat lower cost, but again, we're talking a fairly long time before these things are realized in products. 2. Products that implement IPsec in software. This may be acceptable for some initiators that do not require much bandwidth, but will almost never be acceptable to meet a target's bandwidth requirements. Some vendors may be tempted to put in a "toy implementation" of IPsec in software just to claim RFC compliance, but performance will be so poor that nobody will actually want to use it. 3. Products that just leave out IPsec entirely. This is what today's iSCSI products already do, and this is cheaper than putting IPsec in hardware, and more honest (at least in high bandwidth products) than putting it in software. The marketing guys can deal with the "compliant-except-for-IPsec" problem. After all, very few file server or other data storage products support this kind of security; the demand for IPsec may be a specialty market, or an optional, added-cost item for some products. It doesn't matter whether IPsec or SSL is used for the secure link; either one requires roughly the same hardware cost and/or software performance cost for the above solutions. We have to deal with #3. -- Mark Bill Strahm wrote: > > But it is Required to implement, so the link has as much security as the > administrator requires for the situation. So if IPsec is not being used it > is because a) the administrator doesn't care about wire security b) the > administrator doesn't have anything that needs to be protected c) the > administrator doesn't have the resources to protect it. So for those > reasons I don't buy the argument in your first paragraph... > > The rest is just strict ACL... For you do not need SRP to provide identity > information, I could just as easily send username="Bill" password="foo" over > the wire and it will provide the same functionality (all SRP does is prevent > you from having to send Bill and foo over the wire directly at the cost of a > lot of mathematics. And with a link that is administratively configured to > be adequately secure, I don't see the problem with it. > > I do not understand why you are requiring IPsec/IKE, but refusing to > consider a much simpler to configure/support TLS. It sounds like many of > the problems that you are having that are requiring you to go with a > protocol that has unknown IP rights, and licensing behind it could be easily > solved by changing the security from IPsec to TLS, but that is my opinion. > > I think the problem is that people are trying to solve way too many > problems, assume that IPsec has adiquate link security and go from there. > If IPsec is not capable of securing the link, then remove the solution and > replace it with a technology that can secure the link... > > Bill > +========+=========+=========+=========+=========+=========+=========+ > Bill Strahm Software Development is a race between Programmers > Member of the trying to build bigger and better idiot proof software > Technical Staff and the Universe trying to produce bigger and better > bill@sanera.net idiots. > (503) 601-0263 So far the Universe is winning --- Rich Cook > > -----Original Message----- > From: John Hufferd [mailto:hufferd@us.ibm.com] > Sent: Friday, October 19, 2001 1:54 AM > To: Bill Strahm > Cc: IPS Reflector (E-mail) > Subject: RE: iSCSI: Login authentication SRP/CHAP > > Bill, > IPSec is optional to use! So you can not assume that you have a Secure > connection. And even if you use IPSec, you can not be sure that Privacy > (encryption) is being used. So for these reasons alone you need to have an > iSCSI method of Authentication. > > Next, the lower levels only know that the link is OK to be use for > something. It does not know that it is iSCSI that is using the link, and > if it did it does not have access to the iSCSI ACLs. Nor does iSCSI know > what is handled at the lower levels so it must do its own ACL processing. > > Even if the link is secure (perhaps even encrypted) and iSCSI > Authentication finds out that you are user "Bill", that does not say that > you have the right to get at All resources. "Bill" will be authorized to > operate from certain iSCSI Initiator Nodes, and those nodes will only be > permitted to see certain approprate LUs. These are all iSCSI functions NOT > TCP or IPSec. > > Your suggestion to use TLS, was fully discussed in Irvine, and that issue > is now behind us. > > . > . > . > 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 > > "Bill Strahm" @ece.cmu.edu on 10/17/2001 02:19:38 PM > > Sent by: owner-ips@ece.cmu.edu > > To: "IPS Reflector \(E-mail\)" > cc: > Subject: RE: iSCSI: Login authentication SRP/CHAP > > Just to bring up a cynical point. Why do we need SRP anyway... after all I > am running over a required secure channel, so there should be no problem > with just sending a user ID/Passphrase over the secure channel. This will > prevent a LOT of interoperability problems, extra code required to > implement > additional security algorithms, etc. > > This makes my implementation much simpler, I can seperate > login/authentication parameters (currently SRP) vs. setting up a secure > channel (IPsec). If we go the Application level secure authentication > method, I would rather we replace the security layer with TLS rather than > IPsec, so we get authentication/security all in one place rather than > scattered around lower layer protocols, application protocols... > > Bill Strahm > +========+=========+=========+=========+=========+=========+=========+ > Bill Strahm Software Development is a race between Programmers > Member of the trying to build bigger and better idiot proof software > Technical Staff and the Universe trying to produce bigger and better > bill@sanera.net idiots. > (503) 601-0263 So far the Universe is winning --- Rich Cook > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Michael Schoberg > Sent: Wednesday, October 17, 2001 12:53 PM > To: IPS Reflector (E-mail) > Subject: iSCSI: Login authentication SRP/CHAP > > I'm having some problems figuring out the exact implementation for the > login > authentication protocols being proposed. Is anyone else having similar > issues answering these questions: > > What is the hashing algorithm that will be used for SRP authentication > (SHA-1, MD5, HMAC-SHA1)? > > The SRP negotiation passes the following information (T->I): > > SRP_s = SRP salt > SRP_N = (SRP n value - Large prime number. All computations are performed > modulo n) > SRP_g = Primitive root modulo of n > > By passing [N] & [g] (T->I), does this mean the initiator must verify that > [N] is a prime and [g] is a primitive root modulo of [N]? What are the > min/max digits for [N] and [g]? If any of these are not satisfied (N not > prime, g not primitive modulo root, #digits too small or large), could it > be > used as an attack against the initiator or be used to derive the > initiator's > password? > > The reference to RFC 1994 does not fully describe the CHAP function for > iSCSI, it describes the CHAP message protocol which isn't really used in > our > case. There's some parameters that need to be nailed down. What is the > CHAP hash algorithm: (MD5)? What is the sequence of hashes that take place > on a CHAP challenge to form the CHAP digest? > > The iSCSI draft allows for algorithm selection (CHAP_A=) but > doesn't describe any. Are these supposed to dictate the hashing function > or > give a description of [what/how it] gets hashed (or both)? Will there be a > mandatory set (A1..An) that compliant iSCSI implementations must provide? > Is there a reference that actually shows the sequence for a CHAP digest > being formed from MD5 hashes? > > It would help to have an appendix with real username/password examples of > the result exchange? A table with a few sample sets would be useful for > validating designs. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Fri Oct 19 14:25: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 OAA27017 for ; Fri, 19 Oct 2001 14:25:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JHn3D27011 for ips-outgoing; Fri, 19 Oct 2001 13:49:03 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9JHn0l27004 for ; Fri, 19 Oct 2001 13:49:00 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9JHmJS11468 for ; Fri, 19 Oct 2001 13:48:19 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 19 Oct 2001 13:48:29 -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 VFL30JM6; Fri, 19 Oct 2001 13:48:03 -0400 Received: from travos.nortelnetworks.com (cse-ns-laptop.us.nortel.com [47.16.69.109]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T54YWJ91; Fri, 19 Oct 2001 13:48:03 -0400 Message-Id: <5.0.2.1.2.20011019134507.02df1660@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 19 Oct 2001 13:49:24 -0400 To: "IPS Reflector (E-mail)" From: "Franco Travostino" Subject: iFCP: minutes iFCP authors' confcall this Fri October 19th 9:00am PST Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_13253817==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_13253817==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Attendees: Kevin Gibbons, Nishan Systems Charles Monia, Nishan Systems Inder Monga, Nortel Networks Franco Travostino, Nortel Networks Wayland Jeong,. Troika Networks a) Comments on iFCP, -06. CM described the delta between -05 and -06. The section on AES (with proper I-D references) will be removed should AES hit any roadblock in its way to RFC (to be verified at the upcoming Salt Lake City meeting, IPsec WG meeting). CM mentioned that the mechanisms for comparing WWNs (e.g., tie breaking) are currently under-specified and should rather reference an RFC. All participants agreed that it will be good to receive substantial review feedback based on -06 from the community. b) iFCP Security Update FT described changes that occurred in the iFCP security words while they were "massaged" within the security informational draft. Changes are as follows: 1) "Conformant iFCP implementations MUST support ESP in tunnel mode and MAY support ESP in transport mode" (the MAY was a SHOULD in former iFCP text). 2) "Manual keying MUST NOT be used". (missing in former iFCP text) 3) Signature key authentication MAY be implemented (it was a SHOULD in former iFCP text) 4) Aggressive mode SHOULD be used when pre-shared keys are used for authentication ((it was a MUST in former iFCP text) 5) ID Payload MUST carry a single IP address and a single non-zero port number (there wasn't a port number in former iFCP text). Changes 2-4 will be immediately retrofitted to the (authoritative) iFCP specification text. There was consensus to wait for 1) and 5), with the action item (IM the owner) to verify whether commercial, off the shelf IKE implementations support this ID payload format. CM queried about signature key authentication, which is still left as a TBS in the iFCP spec. FT recalled that the authors of the security informational draft are also waiting for new text on this topic. FT owns the action item of checking with that crowd at their next confcall (Tue 23th). c) iFCP MIB update KG briefed the iFCP co-authors on the status of the iFCP MIB draft. The next revision of the draft will take the official IETF name and will restart with -00. As such, it must be turned in by the IETF 52 deadline set for rookie drafts. Since Irvine, Keith McCloghrie has been very helpful. The MIB draft is known to compile without errors. The new draft will correctly cite rfc2837 for any Fibre Channel definition. In the new draft, there will also be a compliance section, and the gateway denominations will be removed from tables. -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 --=====================_13253817==_.ALT Content-Type: text/html; charset="us-ascii"
Attendees:

Kevin Gibbons, Nishan Systems
Charles Monia, Nishan Systems
Inder Monga, Nortel Networks
Franco Travostino, Nortel Networks
Wayland Jeong,. Troika Networks

a) Comments on iFCP, -06.

CM described the delta between -05 and -06. The section on AES (with proper I-D references) will be removed should AES hit any roadblock in its way to RFC (to be verified at the upcoming Salt Lake City meeting, IPsec WG meeting). CM mentioned that the mechanisms for comparing WWNs (e.g., tie breaking) are currently under-specified and should rather reference an RFC. All participants agreed that it will be good to receive substantial review feedback based on -06 from the community.

b) iFCP Security Update

FT described changes that occurred in the iFCP security words while they were "massaged" within the security informational draft. Changes are as follows:
1) "Conformant iFCP implementations MUST support ESP in tunnel mode and MAY support ESP in transport mode" (the MAY was a SHOULD in former iFCP text).
2) "Manual keying MUST NOT be used". (missing in former iFCP text)
3) Signature key authentication MAY be implemented (it was a SHOULD in former iFCP text)
4) Aggressive mode SHOULD be used when pre-shared keys are used for authentication ((it was a MUST in former iFCP text)
5) ID Payload MUST carry a single IP address and a single non-zero port number (there wasn't a port number in former iFCP text).
Changes 2-4 will be immediately retrofitted to the (authoritative) iFCP specification text. There was consensus to wait for 1) and 5), with the action item (IM the owner) to verify whether commercial, off the shelf IKE implementations support this ID payload format.

CM queried about signature key authentication, which is still left as a TBS in the iFCP spec. FT recalled that the authors of the security informational draft are also waiting for new text on this topic. FT owns the action item of checking with that crowd at their next confcall (Tue 23th).

c) iFCP MIB update

KG briefed the iFCP co-authors on the status of the iFCP MIB draft. The next revision of the draft will take the official IETF name and will restart with -00. As such, it must be turned in by the IETF 52 deadline set for rookie drafts. Since Irvine, Keith McCloghrie <kzm@cisco.com> has been very helpful. The MIB draft is known to compile without errors. The new draft will correctly cite rfc2837 for any Fibre Channel definition. In the new draft, there will also be a compliance section, and the gateway denominations will be removed from tables.

-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
 --=====================_13253817==_.ALT-- From owner-ips@ece.cmu.edu Fri Oct 19 14:30: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 OAA27202 for ; Fri, 19 Oct 2001 14:30:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JHR0F25337 for ips-outgoing; Fri, 19 Oct 2001 13:27:00 -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 f9JHQwl25331 for ; Fri, 19 Oct 2001 13:26:58 -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 NAA03868; Fri, 19 Oct 2001 13:26:45 -0400 (EDT) Message-ID: <3BD06024.F596303A@cisco.com> Date: Fri, 19 Oct 2001 12:17: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: Bill Strahm CC: John Hufferd , "IPS Reflector (E-mail)" Subject: Re: iSCSI: Login authentication SRP/CHAP 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: > > So what you are arguing is that you expect a large number of implementations > to opt for #3... In that case we do not have a secure link. You have two > choices, either remove option #3 because they are not iSCSI devices > therefore do not need to be considered, or change your security requirement > to use IPsec to a SHOULD... I like the SHOULD. The problem is that the IETF will not let us go through last call with the SHOULD; they want a MUST implement. So the best we can do as implementors is provide the full solution (at a premium price) where needed, and claim a minor deviance from the specification where it's not required. BTW, I prefer CHAP as well; even if it's not as secure, it's the only thing compatible with existing RADIUS infrastructure. Perhaps we could say: - IPsec is a MUST implement - CHAP is a MUST implement and anyone wanting a non-IPsec implementation can put in SRP if they think that they need a more secure method than CHAP. -- Mark > I honestly think the later is the better choice because right now there are > VERY few solutions that can handle IPsec at the speeds we are talking about > (there are a few IPsec accellerators that you hinted at in existance today > however)... Now if I have a situation where I do not have a required secure > link under the protocol, then I think we MUST have a secure login... But I > don't think we need both (I think both requirements should be SHOULD > requirements to solve a problem) > > Bill > +========+=========+=========+=========+=========+=========+=========+ > Bill Strahm Software Development is a race between Programmers > Member of the trying to build bigger and better idiot proof software > Technical Staff and the Universe trying to produce bigger and better > bill@sanera.net idiots. > (503) 601-0263 So far the Universe is winning --- Rich Cook > > -----Original Message----- > From: mbakke@cisco.com [mailto:mbakke@cisco.com] > Sent: Friday, October 19, 2001 9:23 AM > To: Bill Strahm > Cc: John Hufferd; IPS Reflector (E-mail) > Subject: Re: iSCSI: Login authentication SRP/CHAP > > Bill- > > We have talked about this very subject extensively in other > face-to-face meetings. Here's a summary. Basically, the > "mandatory to implement" for a secure link (either IPsec or > SSL) is an IETF requirement, and not necessarily a product > requirement. Therefore, we will see three kinds of products: > > 1. Products that implement IPsec in hardware. These will > provide good performance and security in the same package, > but will add hardware cost (not list price) at a few > hundred dollars per port. This, plus development cost, > plus the fact that not everyone requires this kind of > security, will make this cost-prohibitive for many products. > > As IPsec chips are developed, this could be integrated at > a somewhat lower cost, but again, we're talking a fairly > long time before these things are realized in products. > > 2. Products that implement IPsec in software. This may be > acceptable for some initiators that do not require much > bandwidth, but will almost never be acceptable to meet > a target's bandwidth requirements. Some vendors may be > tempted to put in a "toy implementation" of IPsec in > software just to claim RFC compliance, but performance > will be so poor that nobody will actually want to use it. > > 3. Products that just leave out IPsec entirely. This is what > today's iSCSI products already do, and this is cheaper than > putting IPsec in hardware, and more honest (at least in > high bandwidth products) than putting it in software. The > marketing guys can deal with the "compliant-except-for-IPsec" > problem. After all, very few file server or other data > storage products support this kind of security; the demand > for IPsec may be a specialty market, or an optional, added-cost > item for some products. > > It doesn't matter whether IPsec or SSL is used for the > secure link; either one requires roughly the same hardware > cost and/or software performance cost for the above solutions. > > We have to deal with #3. > > -- > Mark > > Bill Strahm wrote: > > > > But it is Required to implement, so the link has as much security as the > > administrator requires for the situation. So if IPsec is not being used > it > > is because a) the administrator doesn't care about wire security b) the > > administrator doesn't have anything that needs to be protected c) the > > administrator doesn't have the resources to protect it. So for those > > reasons I don't buy the argument in your first paragraph... > > > > The rest is just strict ACL... For you do not need SRP to provide identity > > information, I could just as easily send username="Bill" password="foo" > over > > the wire and it will provide the same functionality (all SRP does is > prevent > > you from having to send Bill and foo over the wire directly at the cost of > a > > lot of mathematics. And with a link that is administratively configured > to > > be adequately secure, I don't see the problem with it. > > > > I do not understand why you are requiring IPsec/IKE, but refusing to > > consider a much simpler to configure/support TLS. It sounds like many of > > the problems that you are having that are requiring you to go with a > > protocol that has unknown IP rights, and licensing behind it could be > easily > > solved by changing the security from IPsec to TLS, but that is my opinion. > > > > I think the problem is that people are trying to solve way too many > > problems, assume that IPsec has adiquate link security and go from there. > > If IPsec is not capable of securing the link, then remove the solution and > > replace it with a technology that can secure the link... > > > > Bill > > +========+=========+=========+=========+=========+=========+=========+ > > Bill Strahm Software Development is a race between Programmers > > Member of the trying to build bigger and better idiot proof software > > Technical Staff and the Universe trying to produce bigger and better > > bill@sanera.net idiots. > > (503) 601-0263 So far the Universe is winning --- Rich Cook > > > > -----Original Message----- > > From: John Hufferd [mailto:hufferd@us.ibm.com] > > Sent: Friday, October 19, 2001 1:54 AM > > To: Bill Strahm > > Cc: IPS Reflector (E-mail) > > Subject: RE: iSCSI: Login authentication SRP/CHAP > > > > Bill, > > IPSec is optional to use! So you can not assume that you have a Secure > > connection. And even if you use IPSec, you can not be sure that Privacy > > (encryption) is being used. So for these reasons alone you need to have > an > > iSCSI method of Authentication. > > > > Next, the lower levels only know that the link is OK to be use for > > something. It does not know that it is iSCSI that is using the link, and > > if it did it does not have access to the iSCSI ACLs. Nor does iSCSI know > > what is handled at the lower levels so it must do its own ACL processing. > > > > Even if the link is secure (perhaps even encrypted) and iSCSI > > Authentication finds out that you are user "Bill", that does not say that > > you have the right to get at All resources. "Bill" will be authorized to > > operate from certain iSCSI Initiator Nodes, and those nodes will only be > > permitted to see certain approprate LUs. These are all iSCSI functions > NOT > > TCP or IPSec. > > > > Your suggestion to use TLS, was fully discussed in Irvine, and that issue > > is now behind us. > > > > . > > . > > . > > 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 > > > > "Bill Strahm" @ece.cmu.edu on 10/17/2001 02:19:38 PM > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: "IPS Reflector \(E-mail\)" > > cc: > > Subject: RE: iSCSI: Login authentication SRP/CHAP > > > > Just to bring up a cynical point. Why do we need SRP anyway... after all > I > > am running over a required secure channel, so there should be no problem > > with just sending a user ID/Passphrase over the secure channel. This will > > prevent a LOT of interoperability problems, extra code required to > > implement > > additional security algorithms, etc. > > > > This makes my implementation much simpler, I can seperate > > login/authentication parameters (currently SRP) vs. setting up a secure > > channel (IPsec). If we go the Application level secure authentication > > method, I would rather we replace the security layer with TLS rather than > > IPsec, so we get authentication/security all in one place rather than > > scattered around lower layer protocols, application protocols... > > > > Bill Strahm > > +========+=========+=========+=========+=========+=========+=========+ > > Bill Strahm Software Development is a race between Programmers > > Member of the trying to build bigger and better idiot proof software > > Technical Staff and the Universe trying to produce bigger and better > > bill@sanera.net idiots. > > (503) 601-0263 So far the Universe is winning --- Rich Cook > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Michael Schoberg > > Sent: Wednesday, October 17, 2001 12:53 PM > > To: IPS Reflector (E-mail) > > Subject: iSCSI: Login authentication SRP/CHAP > > > > I'm having some problems figuring out the exact implementation for the > > login > > authentication protocols being proposed. Is anyone else having similar > > issues answering these questions: > > > > What is the hashing algorithm that will be used for SRP authentication > > (SHA-1, MD5, HMAC-SHA1)? > > > > The SRP negotiation passes the following information (T->I): > > > > SRP_s = SRP salt > > SRP_N = (SRP n value - Large prime number. All computations are performed > > modulo n) > > SRP_g = Primitive root modulo of n > > > > By passing [N] & [g] (T->I), does this mean the initiator must verify that > > [N] is a prime and [g] is a primitive root modulo of [N]? What are the > > min/max digits for [N] and [g]? If any of these are not satisfied (N not > > prime, g not primitive modulo root, #digits too small or large), could it > > be > > used as an attack against the initiator or be used to derive the > > initiator's > > password? > > > > The reference to RFC 1994 does not fully describe the CHAP function for > > iSCSI, it describes the CHAP message protocol which isn't really used in > > our > > case. There's some parameters that need to be nailed down. What is the > > CHAP hash algorithm: (MD5)? What is the sequence of hashes that take > place > > on a CHAP challenge to form the CHAP digest? > > > > The iSCSI draft allows for algorithm selection (CHAP_A=) but > > doesn't describe any. Are these supposed to dictate the hashing function > > or > > give a description of [what/how it] gets hashed (or both)? Will there be > a > > mandatory set (A1..An) that compliant iSCSI implementations must provide? > > Is there a reference that actually shows the sequence for a CHAP digest > > being formed from MD5 hashes? > > > > It would help to have an appendix with real username/password examples of > > the result exchange? A table with a few sample sets would be useful for > > validating designs. > > -- > 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 Oct 19 18:02: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 SAA02728 for ; Fri, 19 Oct 2001 18:02:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JL7B112609 for ips-outgoing; Fri, 19 Oct 2001 17:07:11 -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 f9JL7Al12605 for ; Fri, 19 Oct 2001 17:07:10 -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 f9JL73h24646 for ; Fri, 19 Oct 2001 17:07:03 -0400 (EDT) Subject: IPS-All: Review requested of iFCP revision 6 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 19 Oct 2001 17:06:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message Message-ID: <9410A0F67DFE7F4D998D4538236498360408C1@nc8220exchange.ral.lucent.com> Thread-Topic: iFCP revision 6 Thread-Index: AcFYuIJXjkrX4yzuSI6qVfek6/yDyAAKEzfA From: "Elizabeth Rodriguez" To: "Charles Monia" , "Ips (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f9JL7Al12606 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, The authors of the iFCP document have indicated that the iFCP draft is almost complete, with only the security section pending. While the last call process cannot begin until the security issues being discussed in the security draft have been resolved, the iFCP authors are requesting that the IPS WG review the draft and provide any comments to the draft (except security related issues) at this time. This will hopefully make the last call process go smoother. The chairs would like to request feedback from the IPS WG on this draft. Comments and feedback by November 2 would be appreciated. Thanks, Elizabeth & David -----Original Message----- From: Charles Monia [mailto:cmonia@NishanSystems.com] Sent: Friday, October 19, 2001 10:57 AM To: Ips (E-mail) Subject: iFCP revision 6 Colleagues: iFCP revision 6 is available for review at: ftp://ftp.t11.org/t11/docs/01-495v2.pdf -- PDF with markups visible ftp://ftp.t11.org/t11/docs/01-495v2.txt -- Text version We anticipate at least one more revision to reflect the findings of the security design team. Aside from that, the technical content is complete. With that in mind, we encourage a review by the IPS community with the understanding that further changes in the security section are expected. Charles Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 From owner-ips@ece.cmu.edu Fri Oct 19 18:56: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 SAA04261 for ; Fri, 19 Oct 2001 18:56:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JMCqh16938 for ips-outgoing; Fri, 19 Oct 2001 18:12:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mail.tropicnetworks.com (m99-50.on.tac.net [209.202.99.50] (may be forged)) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9JLc1l14744 for ; Fri, 19 Oct 2001 17:38:01 -0400 (EDT) Received: from pcckelly ([10.1.5.74]) by mail.tropicnetworks.com (Netscape Messaging Server 3.6) with SMTP id AAA61AB for ; Fri, 19 Oct 2001 17:37:58 -0400 From: "Colin Kelly" To: Subject: FC encapsulation Date: Fri, 19 Oct 2001 17:35:00 -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 have a question regarding the proposed ieft draft (draft-ietf-ips-fcencapsulation-03), regarding FC encapsulation, as a basis for FCIP, IFCP, and mFCP (plus, I assume, any potential future higher level encapsulations, such as the martini draft, or other "virtual wire" encapsulations). The FCIP draft states that "FC Primitive Signals, Primitive Sequences, and Class 1 Frames are not transmitted across an FCIP link because they cannot be encoded using FC Frame Encapsulation". I understand this restriction for primitive signals/sequences, as they are never framed/transmitted, but do not understand the reason for the class 1 frame restriction. The proposed FC frame encapsulation is consistent with this restriction, in that in section 5.3, the FC SOF translation table (table 1) does not contain SOFc1, SOFi1, or SOFn1 entries. Other that this, the draft does not mention which FC classes are or are not supported, or why. Is there a fundamental reason why the FC encapsulation draft does not include class 1? The fibre channel standards (as far as I can tell) do not exclude the possibility of allowing class 1 connections through a fabric, so regardless of the intent of the FCIP, IFCP, and mFCP encapsulations, I do not see why this draft should exclude class 1. If there is not underlying reason, then Table 1 within the draft should be expanded to include class 1, and possibly class 4 and 6. I realize that this may be "academic", in that perhaps most FC equipment in the field may not use class 1 anyway... Thankyou, Colin Kelly Tropic Networks Ottawa, Ontario From owner-ips@ece.cmu.edu Fri Oct 19 20:01: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 UAA06584 for ; Fri, 19 Oct 2001 20:01:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9JN7Ki20323 for ips-outgoing; Fri, 19 Oct 2001 19:07:20 -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 f9JN7Il20317 for ; Fri, 19 Oct 2001 19:07:18 -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 QAA06556; Fri, 19 Oct 2001 16:06:57 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWV88Y4>; Fri, 19 Oct 2001 16:06:57 -0700 Message-ID: From: Robert Snively To: "'Colin Kelly'" , ips@ece.cmu.edu Subject: RE: FC encapsulation Date: Fri, 19 Oct 2001 16:06:56 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk > > Is there a fundamental reason why the FC encapsulation draft > does not include class 1? The Fibre Channel standards (as far > as I can tell) do not exclude the possibility of allowing > class 1 connections through a fabric, so regardless of the intent > of the FCIP, IFCP, and mFCP encapsulations, I do not see why > this draft should exclude class 1. Yes, there really is a fundamental problem. Class 1 switch behavior makes a full bandwidth lossless circuit connection between one Fibre Channel node and another. If you push exactly 1 Gbit into it, it SHALL push exactly 1 Gbit out, totally in order and without loss and with low latency. It will also change from one circuit connection to another rather dynamically under Fibre Channel protocol control, with extremely low connection latencies. TCP/IP simply does not provide those capabilities, so we never even considered including it. Class 6 is a clone of Class 1 in those respects. Class 4 has the same general properties, but with clocked fractional bandwidth, so it has the same problems. This did not upset most Fibre Channel implementers because all the key applications that could truly exploit those additional capabilities provided by TCP/IP were all implemented in Class 2 and in Class 3. The few highly specialized legacy applications that used Class 1 were perfectly happy with no IP connectivity. Hope that is some help, Bob Snively e-mail: rsnively@brocade.com Brocade Communications Systems phone: 408 487 8135 1745 Technology Drive San Jose, CA 95110 From owner-ips@ece.cmu.edu Sat Oct 20 22:38: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 WAA22958 for ; Sat, 20 Oct 2001 22:38:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9L1gPc20366 for ips-outgoing; Sat, 20 Oct 2001 21:42:25 -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 f9L1gMl20360 for ; Sat, 20 Oct 2001 21:42:23 -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 DAA105790 for ; Sun, 21 Oct 2001 03:42: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 f9L1g9m191696 for ; Sun, 21 Oct 2001 03:42:10 +0200 Subject: Re: iSCSI - changes - PDULength and related To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 21 Oct 2001 01:02:04 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/10/2001 04:42:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Some framing mechanisms (defined by other standards) work well with PDU length not exceeding path MTU. This may be suboptimal (and I assume will be seldomness in use) but may help get things going. Julo ----- Forwarded by Julian Satran/Haifa/IBM on 20-10-01 23:58 ----- Paul Koning cc: ips@ece.cmu.edu Subject: Re: iSCSI - changes - PDULength 15-10-01 17:04 and related Please respond to Paul Koning Excerpt of message (sent 12 October 2001) by Julian Satran: > ... > In addition text request and response key+value strings are not required to > be confined to a single PDU (as we PDULength can be a low as 64 bytes!) > > Comments? Why change the minimum value of PDULength (and the two burstsize parameters)? It used to be 512, which makes more sense, although even that is rather small. Allowing the length to be set to such tiny values (like 64) adds a lot of complexity to the implementation to no useful purpose. I'd prefer to see a minimum around 1500, but if not, at least it should not be reduced from the existing value of 512. paul > ... > 23 MaxRecvPDULength > > Use: All > Who can send: Initiator and Target > > MaxRecvPDULength=<0|number-64-to-2**24> > ... > 24 MaxBurstSize > > Use: LO > Who can send: Initiator and Target > > MaxBurstSize=<0|number-64-to-2**24> > > Default is 256 Kbytes. > > Initiator and target negotiate maximum SCSI data payload in bytes > ... > 25 FirstBurstSize > > Use: LO > Who can send: Initiator and Target > > FirstBurstSize=<0|number-64-to-2**24> ----- Forwarded by Julian Satran/Haifa/IBM on 20-10-01 23:58 ----- Paul Koning cc: Sent by: Subject: Re: iSCSI - changes - PDULength owner-ips@ece. and related cmu.edu 18-10-01 17:54 Please respond to Paul Koning (((resending this, since the previous copy seems to have gone AWOL))) Excerpt of message (sent 12 October 2001) by Julian Satran: > ... > In addition text request and response key+value strings are not required to > be confined to a single PDU (as we PDULength can be a low as 64 bytes!) > > Comments? Why change the minimum value of PDULength (and the two burstsize parameters)? It used to be 512, which makes more sense, although even that is rather small. Allowing the length to be set to such tiny values (like 64) adds a lot of complexity to the implementation to no useful purpose. I'd prefer to see a minimum around 1500, but if not, at least it should not be reduced from the existing value of 512. paul > ... > 23 MaxRecvPDULength > > Use: All > Who can send: Initiator and Target > > MaxRecvPDULength=<0|number-64-to-2**24> > ... > 24 MaxBurstSize > > Use: LO > Who can send: Initiator and Target > > MaxBurstSize=<0|number-64-to-2**24> > > Default is 256 Kbytes. > > Initiator and target negotiate maximum SCSI data payload in bytes > ... > 25 FirstBurstSize > > Use: LO > Who can send: Initiator and Target > > FirstBurstSize=<0|number-64-to-2**24> From owner-ips@ece.cmu.edu Sat Oct 20 22:41: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 WAA22986 for ; Sat, 20 Oct 2001 22:41:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9L1gfn20390 for ips-outgoing; Sat, 20 Oct 2001 21:42: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 f9L1gdl20384 for ; Sat, 20 Oct 2001 21:42:39 -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 DAA80392 for ; Sun, 21 Oct 2001 03:42: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.97.1) with ESMTP id f9L1gSm118966 for ; Sun, 21 Oct 2001 03:42:28 +0200 Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 21 Oct 2001 01:18:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/10/2001 04:42:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, The ordering rule is for a connection (not for a session). It's sole purpose is to minimize the chance for a deadlock. Regards, Julo Robert Snively , Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu 16-10-01 18:02 cc: Please respond Subject: RE: iSCSI: Addition of CmdSN in to Robert Data-out PDU Snively I am not quite sure what meaning "in-order" data has in a multi-connection session. Does it mean that you actually expect the data across multiple connections to arrive temporally in the same order that is specified by the command sequence numbers? Or does it mean that the data has to be arranged in some order by the target session processing? Or is it better to step aside from the in-order question for data transmission and do as Rob Harrison suggests: "As an initiator I would send the command PDU as soon as I could if there were no immediate data, then queue the DMA for the unsolicited data. Since there could be many other DMAs queued ahead of the unsolicited data it is quite possible that other commands, both read and write, will be sent before the DMA completes." This would imply no strict ordering requirement. If an ordering requirement is necessary, I submit that it is because of the problems with unsolicited data reception, not with the actual data order. Bob > -----Original Message----- > From: Rod Harrison [mailto:rod.harrison@windriver.com] > Sent: Monday, October 15, 2001 4:06 AM > To: Julian Satran; ips@ece.cmu.edu > Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU > > > Julian, > > I think you might have misunderstood what I meant. I was not > advocating we change the spec in favour of relaxing the data ordering > requirements. I was just point out there is a problem for the > initiator to solve in order maintain correct ordering, and that I > believe it is not a terribly difficult one. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Julian Satran > Sent: Sunday, October 14, 2001 9:30 PM > To: ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > > Immediate data are not mandatory (even if enabled). Having one or ten > DMAs > does not change the fact that they share a TCP "pipe" and a decent > transmitter will ship the TCP data in order - otherwise it just throws > his > problems in the receiver's lap. Our additional requirement on order > should > make no difference. And it would be time to change the name of the > thread. > > Julo > > > > > > "Rod Harrison" > Jose/IBM@IBMUS, "Robert > river.com> Snively" > > Sent by: cc: > , > owner-ips@ece.cmu. "BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2)" > edu > , "'Binford, Charles'" > , > > Subject: RE: Addition > of CmdSN in Data-out PDU > 13-10-01 13:12 > Please respond to > "Rod Harrison" > > > > > > > Even more common would be the DMA latency. As an initiator > I > would > send the command PDU as soon as I could if there were no immediate > data, then queue the DMA for the unsolicited data. Since there could > be many other DMAs queued ahead of the unsolicited data it is quite > possible that other commands, both read and write, will be sent before > the DMA completes. > > You are spot one when you say the delay in obtaining the > unsolicited > data may be large and variable. If there are multiple DMA engines it > does become a challenge for the initiator to ensure the correct > ordering of the unsolicited data. Note that since there may be > multiple unsolicited data PDUs in the same burst, and those may be > filled with separate DMAs the ordering problem propagates down to > within individual commands. > > I don't believe it is a particularly difficult problem for > the > initiator to solve, but I do agree things would be easier for the > initiator if the ordering requirement were removed. And more so if the > requirement to send in dataSN order were also removed, but this is > probably too much pain for the target. > > - Rod > > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > John Hufferd > Sent: Saturday, October 13, 2001 1:01 AM > To: Robert Snively > Cc: 'somesh_gupta@silverbacksystems.com'; BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2); 'Binford, Charles'; ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > > Robert, > I think that an Initiator being able to send a waiting Read command, > without having to wait for many large write segments -- that are being > sent > (as unsolicited data) -- is very useful. And that would mean, the > unsolicited data is waiting to be sent until the Read Commands are > sent. > This might be a very frequent case. > > . > . > . > 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 10/12/2001 > 03:56:06 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: "'somesh_gupta@silverbacksystems.com'" > , "BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2)" , "'Binford, > Charles'" , ips@ece.cmu.edu > cc: > Subject: RE: Addition of CmdSN in Data-out PDU > > > > I have two small questions that would help me understand this. > > How do you know that unsolicited data is expected? By nature, > unsolicited data is received as a "maximum surprise" which can > only be determined after unpacking and parsing at least a > part of the command structure, possibly even including the > SCSI command (although there are some hints contained in the > command header information). > > How can you constrain a generic system to posting the > unsolicited data in the same order that the commands were > emitted? In general, I would have expected the system to > be emitting command followed immediately by the corresponding > unsolicited data. If that is not the case, it means that there > was a delay in obtaining the unsolicited data for transfer and > that the delay was sufficient to allow the insertion of commands. > If the delay is that large (and probably variable), the enforcement > of transfer of unsolicited data in the same order as the > commands are emitted seems to me to be a significant challenge, > and certainly shouldn't be required as normal behavior. While it > would make things simpler for targets (already challenged by > unsolicited data), it seems to me that it would make things > much more complex for initiators. > > Bob > > > -----Original Message----- > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > > Sent: Friday, October 12, 2001 2:51 PM > > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > > ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Matthew, > > > > Since the unsolicited data does not follow the > > command, you need the link list. But since the > > unsolicited data must be sent in the same order > > as the commands, a link list is enough. > > > > Let us say that you have 8 commands. The ones > > for which we expect unsolicted data are marked > > as Cnn(ud). And I have marked the unsolicted > > data PDUs as UD(nn). The (nn) with data implies > > that it is implicit and not actually carried with > > the PDU itself. > > > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > > --> UD(07) C08(ud) UD(08) ---> > > > > After the target receives the command C01, C02, and C03 > > for which it expects unsolicited data, it puts them in > > a link list. It also receives C04 and C05 for which > > unsolicited data is not expected and they don't go > > on the list. It then receives C06 for which unsolicited > > data is expected, and it is added to then end of the list. > > Then an unsolicited data PDU is received. It must go > > with the command at the head of the list which is C01. > > Use the ITT to make sure and you can then take C01 off > > the list and so on. > > > > Somesh > > > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > > Sent: Friday, October 12, 2001 7:53 AM > > > To: 'Binford, Charles'; ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > Charles, > > > > > > As you have described the spec states that "that > > unsolicited data MUST be > > > sent in the same order as the commands". This is not the same as > > > unsolicited data must follow the command associated with > > it: For example: > > > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > > x in all the > > > example can be the ITT. It is not the CmdSN. > > > > > > This is allowed: > > > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > > > and the target will have to use the ITT to associate the > > data with the > > > command. > > > > > > Matthew > > > > > > > > > -----Original Message----- > > > From: Binford, Charles [mailto:CBinford@pirus.com] > > > Sent: Friday, October 12, 2001 2:50 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > I have not verify version 8 is still the same, but version 07-97 > > > had a rule > > > that unsolicited data MUST be sent in the same order as the > > commands. > > > > > > Thus, there is no need for a search on the ITT. The target > > just needs to > > > keep of linked list of I/Os waiting on unsolicited data. > > New commands are > > > added to the tail, any unsolicited data *should* be associated > > > with the I/O > > > at the head of the list. The ITT is used as a sanity check and > > > you're done. > > > > > > What am I missing? > > > > > > Charles Binford > > > Pirus Networks > > > 316.315.0382 x222 > > > > > > > > From owner-ips@ece.cmu.edu Sat Oct 20 22:42: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 WAA22998 for ; Sat, 20 Oct 2001 22:42:05 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9L1gte20401 for ips-outgoing; Sat, 20 Oct 2001 21:42:55 -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 f9L1grl20397 for ; Sat, 20 Oct 2001 21:42:53 -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 DAA120320 for ; Sun, 21 Oct 2001 03:42: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 f9L1gam174960 for ; Sun, 21 Oct 2001 03:42:36 +0200 Subject: RE: iSCSI: ISID issue summary To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Sun, 21 Oct 2001 01:21:18 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/10/2001 04:42:35 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk There is going to be a "conservative reuse" rule. Stay tuned. Julo "Rod Harrison" cc: Subject: RE: iSCSI: ISID issue summary 15-10-01 13:10 Please respond to "Rod Harrison" Julian, I don't understand what you are considering "excessive and restrictive." I'm requesting that we don't do something that would prevent designing an iSCSI HBA to work with existing SCSI HBA drivers, for example requiring that the host side driver be involved in every session set-up. I have no issue with the host being required to provide some coordinating entity if multiple sessions are being spanned over multiple iSCSI HBAs, either from the same or different vendors. I would just like us not to place this restriction on simpler deployments like one iSCSI HBA, or more than one with no session spanning. In the latter cases I believe David's ISID range idea would be sufficient. Does this explain my position better, or is there something you still object to? - Rod -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Sunday, October 14, 2001 9:21 PM To: Rod Harrison Subject: RE: iSCSI: ISID issue summary I think that this would be both excessive and unwarranted. And there is no reason to associate it with the wire protocol. And I don't think that David Black had this type of excessive restriction in mind in the "conservative reuse" rule. Julo "Rod Harrison" , river.com> , Sent by: cc: owner-ips@ece.cmu. Subject: RE: iSCSI: ISID issue summary edu 13-10-01 13:25 Please respond to "Rod Harrison" I am in favour of the 'statically configure the ISIDs along with the iSCSI name and write the "conservative reuse" rule into the iSCSI protocol specification' approach. One thing I would like to see happen here is to allow iSCSI HBAs to be used with existing SCSI drivers. Many vendors have well tested drivers in the field, and it is currently a relatively easy job to make an iSCSI HBA look like an existing SCSI HBA. Doing so is a time to market win and should also slightly ease customers new technology fears. There is a clear advantage to being able to tell customers that they can fit an iSCSI HBA into systems alongside their existing SCSI HBAs and have them "just work" after some initial configuration. Setting ISID ranges can easily be done as part of this initial configuration, as can setting the iSCSI name, IP address, DHCP use, or whatever else an iSCSI HBA needs to know. I'm not against having to have some coordinating entity on the host as long as that is optional, and preferably only needed for more complex installations. - Rod -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Black_David@emc.com Sent: Saturday, October 13, 2001 2:49 AM To: Robert.Elliott@compaq.com; ips@ece.cmu.edu Subject: RE: iSCSI: ISID issue summary Rob, > As Nick noted, the problem is where do you store these ISIDs? > For that matter, where do you store the iSCSI name? [..snip..] > With iSCSI you have no guarantee of hardware. Software-based implementations will have access to a file or registry or something like that. Boot involves BIOS nonsense and pain of varying forms and has access to BIOS parameter store (may be battery-backed RAM rather than flash) if needed. Booting over a software implementation can be very difficult - in essence, the iSCSI software gets added to the main system BIOS (not something to be done lightly, especially as there are existing protocols that can retrieve a boot image over IP). > For the SCSI RDMA Protocol for InfiniBand, we chose: > initiator port name = 64-bit worldwide identifier from > the InfiniBand channel adapter plus > 64 extra bits > All software using the same InfiniBand channel adapter have to > coordinate usage of the extra bits, but single-OS single-driver > systems can just fill them with zeros. But SRP only needs to coordinate within "the same InfiniBand channel adapter". iSCSI currently requires the ISID to be coordinated across adapters/network interfaces. That's an important difference. > Persistent reservations, access controls, extended copy, > third-party XOR commands, and the supporting alias commands > are all potential users of port names today. Protocol bridges > and management tools may also benefit from using names > rather than addresses. I'll take that as a strong hint from the T10 direction that this set of issues cannot be deferred (matching Jim's comments). > Are the iSCSI name and ISID used as part of authentication? > How does a device driver prove it has the right to use > a certain iSCSI name/ISID? How does it prevent some other > software from using its own iSCSI name/ISID? Only the iSCSI name is used, and iSCSI inband authentication (which requires state on the target) is used to deal with both of the latter questions. > If we didn't have ISIDs we'd still have the same debate about > managing the iSCSI names. Two software implementations > on the same machine could choose the same iSCSI name and > conflict - the same problems result. Actually, the iSCSI name has to be statically configured - it's somewhat akin to an IP address in that using the same one twice on two different independent systems will have unintended (and potentially unpleasant) results. Picking the name dynamically is not anticipated because that name is expected to show up in the configuration of LUN masking/ mapping access controls on the Targets. > Jim's partitioning lets the OS pick an iSCSI name (unique > from any other OS on the fabric, with any luck) and requires > the OS coordinate ISIDs for any iSCSI drivers sharing > that iSCSI name. A dedicated iSCSI HBA could also hand > out ISIDs for drivers using it. With the exception of having "the OS pick an iSCSI name", that's correct. The problem is one system with two HBAs that don't know about each other. Also, unlike InfiniBand, one can expect an iSCSI HBA to have a dedicated driver. > This should limit the > scope of conflicts to one system rather than the whole > fabric. It'd be helpful to have standards for the OS > or HBAs to solve this, but that seems outside the scope > of the iSCSI protocol spec. A solution that works here is to statically configure the ISIDs along with the iSCSI name and write the "conservative reuse" rule into the iSCSI protocol specification. Thanks, --David > -----Original Message----- > From: Elliott, Robert [mailto:Robert.Elliott@compaq.com] > Sent: Wednesday, October 10, 2001 8:19 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: ISID issue summary > > > David Black wrote: > > > SCSI architecture (SAM2) is based on an intuition that SCSI > > ports are fixed (e.g., physical) things that have names. So > > far, the existence of the names has been an intellectual > > curiosity as they haven't mattered to any visible SCSI > > functionality. > > Not quite true. The Fibre Channel port's Worldwide_Name - > what SAM-2 now calls the initiator port name - is used > today for persistent reservations. SPC-2 has this wording: > > For those SCSI protocols for which the initiator port's > world wide identification is available to the device > server the initiator port's world wide identification > shall be used to determine if the initiator identifier > has changed. > > FCP-2 indicates that the Worldwide_Name of the Fibre Channel > port serves as the "initiator port's world wide > identification." (that phrase will change to "initiator > port name" as Jim's (accepted) T10 name proposal is > digested.) > > > Single port Initiators predominate in > > both Parallel SCSI and Fibre Channel (e.g., a dual ported > > Fibre Channel HBA is usually treated as two SCSI Initiators, > > not a single dual-ported one). > > According to the SAM-2 multiport model, you can upgrade that > "usually" to "always." The key to the multiport model is: > > Initiator = initator port > Target = target port > > In FCP-2, initiator ports equal Fibre Channel ports. There's > no way to treat two physical ports as the same initiator > without violating the standards. > > The multiport model defines "initiator device" as the object > that contains multiple initiator ports. The initiator device > has neither an address nor a name in any existing protocol. > There are no commands that rely on it. Jim wanted to start > using that concept for iSCSI access controls. > > > Jim tells us that T10 is about to define persistent reserve > > functionality that depends on the identity of the SCSI Initiator > > Port - in particular that under some circumstances, persistent > > reservations will be associated with the Initiator Port independent > > of the Target Port. Persistent reservations are currently bound > > to the Initiator Port and Target Port (as well as the LU they > > affect). For the rest of this message, I'm going to assume > > Again, the reason for this is the multiport model that says > initiator = initiator port and target = target port. > > > that we want to support this functionality. Assuming this and > > that I got the description in this paragraph right ... > > > > ... I need to take a slight detour into pragmatics. Those > > who configure storage networks rapidly discover the value > > of consistency and matching configurations. Multi-path I/O > > configurations tend to want to see access to the same set of LUs > > consistently across a set of interfaces (i.e., Ports). Between > > suitable configuration and the aggressive setup of connections > > to all possible targets, all the required connections come into > > existence as part of the boot process. Applying > > this experience to the new persistent reservation functionality, > > one would expect persistent reservations that are bound only to > > an Initiator Port to be independent of the Target Port, in that > > the reservation should span connections to all of the relevant > > Target Ports and those connections should come into existence > > as part of the boot process. > > That's the goal of one of the T10 proposals. If initiators > are identified only by their port addresses, it's not safe. > The two target ports could be on different fabrics, where > initiators are different but happen to have the same > addresses. On a fabric where the initiator port has a name > that is known to be worldwide unique, this becomes a > non-issue if the initiator port name is used instead of the > initiator port address. > > > Turning to iSCSI, the situation gets complicated by the > > interaction of two factors: > > - Parallel sessions are permitted down to the interface > > level (e.g., more than one iSCSI session may exist > > that uses IP addresses A and B to connect iSCSI Initiator > > I to iSCSI Target T). > > - SCSI disallows parallel nexii (i.e., more than one session > > between the same two SCSI Ports). > > If SCSI Ports are mapped to hardware entities such as network > > interfaces in iSCSI, the opportunity for parallel sessions > > between the same pair of network interfaces vanishes. In order > > to avoid that outcome, iSCSI Initiator Ports have to be > > mapped to software entities. To date, the ISID has been > > used to identify those software entities, and the only rule > > on their allocation is: > > > > ISID RULE: Between a given iSCSI Initiator and iSCSI > > Target Portal Group (SCSI target port), then can be only > > one session with a given ISID (identifying a SCSI > > initiator port). See 3.12.8. > > There's a bit more than that. The "iSCSI Name" has to > be included with the ISID to identify the initiator port. > Jim wanted the iSCSI name to be the "initiator device name." > > > In order to get the expected outcome of the new functionality > > being defined by T10, the same ISID has to be used to establish > > all the connections that the persistent reservation is supposed > > to span. Unfortunately, that's above and beyond what iSCSI > > requires - the relevant text about doing this in -08 is: > > > > The "ISID rule" does not preclude > > the use of the same ISID from the same iSCSI Initiator with > > different Target Portal Groups on the same iSCSI target or > > on other iSCSI targets > > > > "does not preclude" is rather weak language for something that's > > essential to making a piece of SCSI functionality work. If an > > iSCSI implementation uses a different ISID for every session > > (which is also not precluded by the current text), then persistent > > reservations will never span Targets or Target Ports for that > > implementation despite T10's best efforts and intentions. IMHO, > > allowing that outcome is *wrong* (and this is the source of the > > difference of opinion between Jim and myself). > > > > The correction to this involves what Jim has called "conservative > > reuse" of ISIDs. This is something like for each ISID that an > > implementation uses, a connection with that ISID is made to > > every possible Target Portal Group of every possible Target. I > > suspect a longer explanation than this will be needed, including > > a discussion of the desirability of avoiding a situation in which > > the same ISID is used by two iSCSI implementations that are part > > of the same Initiator and set up sessions concurrently. > > > > IMHO, if we want to support persistent reservations at this stage > > that span target ports, we need to replace the "does not preclude" > > language with a REQUIREMENT for conservative reuse to avoid a > > situation in which SCSI functionality that works consistently with > > other transports works inconsistently with iSCSI (i.e., doesn't > > work with iSCSI implementations that don't do conservative reuse). > > As Nick noted, the problem is where do you store these ISIDs? > For that matter, where do you store the iSCSI name? With > Fibre Channel, the Worldwide_name is in a ROM associated with > the port. With iSCSI you have no guarantee of hardware. You > can usually find an Ethernet MAC address and could base a > name off of that. However, there's no guarantees. > > For the SCSI RDMA Protocol for InfiniBand, we chose: > initiator port name = 64-bit worldwide identifier from > the InfiniBand channel adapter plus > 64 extra bits > All software using the same InfiniBand channel adapter have to > coordinate usage of the extra bits, but single-OS single-driver > systems can just fill them with zeros. > > > Stepping back from the assumption that support for port-spanning > > persistent reservations is required, I observe that the conservative > > reuse rule impacts all implementations, even those that will never > > use such persistent reservations because ISID is a mandatory part > > of the iSCSI protocol. > > Persistent reservations, access controls, extended copy, > third-party XOR commands, and the supporting alias commands > are all potential users of port names today. Protocol bridges > and management tools may also benefit from using names > rather than addresses. > > > If a text key were used instead, only those > > Initiators that want to support this functionality on which T10 > > is "crossing a few t's and dotting a few i's" are affected (the > > text key is optional). The text key would be subject to a > > conservative reuse rule similar to the one that would be needed > > for ISIDs, and once T10 finishes the i's and t's, we can precisely > > reference the SCSI features (persistent reservation expansion) > > that require use of this text key. > > > > In addition, text keys have much better alternatives for dealing > > with conflicts than ISIDs - if a text key conflicts, it is possible > > to continue the negotiation with a different text key, whereas > > ISID conflict is fatal to one of the two sessions involved. > > As Jim has previously observed, changing the text key (e.g., > > generate a large random number in response to a conflict), > > results in a situation that can be dealt with by software that > > uses persistent reservations, although this departure from > > conservative reuse should only occur as a consequence of some > > sort of configuration mistake or bug. At the tail end of this > > reasoning chain is the observation that use of this text key > > leaves the ISID without value/purpose, and hence would call > > for its removal (or perhaps designation as a reserved field). > > This just seems to make the names more vague and volatile. > > Are the iSCSI name and ISID used as part of authentication? > How does a device driver prove it has the right to use > a certain iSCSI name/ISID? How does it prevent some other > software from using its own iSCSI name/ISID? > > > Putting on my WG chair hat for a moment, I can accept either > > alternative outlined above: > > - Add conservative reuse to the ISID rule. > > - Use a text key for iSCSI port identification. > > But I'm not comfortable with the current situation in which iSCSI > > implementations are permitted to break T10-defined SCSI features > > that will work as expected in other SCSI transports. > > > > I hope this now makes sense to more people than just Jim and I, > > and I apologize for the length of this message, as this is a > > somewhat subtle issue. > > > > Comments? > > If we didn't have ISIDs we'd still have the same debate about > managing the iSCSI names. Two software implementations > on the same machine could choose the same iSCSI name and > conflict - the same problems result. > > Jim's partitioning lets the OS pick an iSCSI name (unique > from any other OS on the fabric, with any luck) and requires > the OS coordinate ISIDs for any iSCSI drivers sharing > that iSCSI name. A dedicated iSCSI HBA could also hand > out ISIDs for drivers using it. This should limit the > scope of conflicts to one system rather than the whole > fabric. It'd be helpful to have standards for the OS > or HBAs to solve this, but that seems outside the scope > of the iSCSI protocol spec. > > > --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 > > --------------------------------------------------- > > > --- > Rob Elliott, Compaq Server Storage > Robert.Elliott@compaq.com > From owner-ips@ece.cmu.edu Sat Oct 20 23:41: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 XAA23622 for ; Sat, 20 Oct 2001 23:41:28 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9L36EE24725 for ips-outgoing; Sat, 20 Oct 2001 23:06: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 f9L36Bl24720 for ; Sat, 20 Oct 2001 23:06:12 -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 FAA127950 for ; Sun, 21 Oct 2001 05:06:04 +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 f9L365r128084 for ; Sun, 21 Oct 2001 05:06:05 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI:spec 8a Mode parameters sec. 2.5.3.2 required? X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sun, 21 Oct 2001 06:06:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/10/2001 06:06:05, Serialize complete at 21/10/2001 06:06:05 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk We have to say explicitly that there are no iSCSI specific mode pages. Julo "Deva-Adaptec" Sent by: owner-ips@ece.cmu.edu 16-10-01 01:24 Please respond to "Deva-Adaptec" To: cc: Subject: iSCSI:spec 8a Mode parameters sec. 2.5.3.2 required? I am referring spec. 8a section 2.5.3.2. Are this section and the contents required as there are no longer any mode parameters defined for iSCSI ? Thanks Deva Adaptec #### winmail.dat has been removed from this note on October 21 2001 by Julian Satran From owner-ips@ece.cmu.edu Sat Oct 20 23:56: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 XAA23773 for ; Sat, 20 Oct 2001 23:56:00 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9L2u8R24213 for ips-outgoing; Sat, 20 Oct 2001 22:56: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 f9L2u5l24209 for ; Sat, 20 Oct 2001 22:56: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 EAA75100 for ; Sun, 21 Oct 2001 04:55: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 f9L2ttm110660 for ; Sun, 21 Oct 2001 04:55:55 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: Addition of CmdSN in Data-out PDU X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sun, 21 Oct 2001 05:55:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 21/10/2001 05:55:55, Serialize complete at 21/10/2001 05:55:55 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Robert, Closing the window is a common event on TCP connection. The deadlock can occur only if a command sends its data while the target requests data for an earlier command. Julo Robert Snively Sent by: owner-ips@ece.cmu.edu 15-10-01 22:59 Please respond to Robert Snively To: Julian Satran/Haifa/IBM@IBMIL, John Hufferd/San Jose/IBM@IBMUS cc: "'Binford, Charles'" , ips@ece.cmu.edu, "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" , owner-ips@ece.cmu.edu, Robert Snively , "'somesh_gupta@silverbacksystems.com'" Subject: RE: Addition of CmdSN in Data-out PDU Can they send enough commands to close the window just as fatally? > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, October 13, 2001 1:09 PM > To: John Hufferd > Cc: 'Binford, Charles'; ips@ece.cmu.edu; BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2); owner-ips@ece.cmu.edu; Robert Snively; > 'somesh_gupta@silverbacksystems.com' > Subject: RE: Addition of CmdSN in Data-out PDU > > > Robert, > > The reason for the rule is limiting restrictions to what is logically > mandated and leaving all the rest to the implementer. > The ordering rule is there to help avoid the trivial deadlock where > commands start asking for solicited data and the windows is closed by > unsolicited data and having to resort to dropping data to > reopen the TCP > window. > > Having data immediately follow the command is admisible but some > implementer might choose to have and launch as many commands > as possible > to get the data transfer overlap with positioning operations. > > The targets are supposed to consider out of order delivery of data a > protocol error. > > Regards, > Julo > > > > > John Hufferd/San Jose/IBM@IBMUS > Sent by: owner-ips@ece.cmu.edu > 13-10-01 02:01 > Please respond to John Hufferd > > > To: Robert Snively > cc: "'somesh_gupta@silverbacksystems.com'" > , "BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2)" , > "'Binford, Charles'" > , ips@ece.cmu.edu > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > Robert, > I think that an Initiator being able to send a waiting Read command, > without having to wait for many large write segments -- that > are being > sent > (as unsolicited data) -- is very useful. And that would mean, the > unsolicited data is waiting to be sent until the Read > Commands are sent. > This might be a very frequent case. > > . > . > . > 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 > 10/12/2001 03:56:06 > PM > > Sent by: owner-ips@ece.cmu.edu > > > To: "'somesh_gupta@silverbacksystems.com'" > , "BURBRIDGE,MATTHEW > (HP-UnitedKingdom,ex2)" , "'Binford, > Charles'" , ips@ece.cmu.edu > cc: > Subject: RE: Addition of CmdSN in Data-out PDU > > > > I have two small questions that would help me understand this. > > How do you know that unsolicited data is expected? By nature, > unsolicited data is received as a "maximum surprise" which can > only be determined after unpacking and parsing at least a > part of the command structure, possibly even including the > SCSI command (although there are some hints contained in the > command header information). > > How can you constrain a generic system to posting the > unsolicited data in the same order that the commands were > emitted? In general, I would have expected the system to > be emitting command followed immediately by the corresponding > unsolicited data. If that is not the case, it means that there > was a delay in obtaining the unsolicited data for transfer and > that the delay was sufficient to allow the insertion of commands. > If the delay is that large (and probably variable), the enforcement > of transfer of unsolicited data in the same order as the > commands are emitted seems to me to be a significant challenge, > and certainly shouldn't be required as normal behavior. While it > would make things simpler for targets (already challenged by > unsolicited data), it seems to me that it would make things > much more complex for initiators. > > Bob > > > -----Original Message----- > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > > Sent: Friday, October 12, 2001 2:51 PM > > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > > ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > Matthew, > > > > Since the unsolicited data does not follow the > > command, you need the link list. But since the > > unsolicited data must be sent in the same order > > as the commands, a link list is enough. > > > > Let us say that you have 8 commands. The ones > > for which we expect unsolicted data are marked > > as Cnn(ud). And I have marked the unsolicted > > data PDUs as UD(nn). The (nn) with data implies > > that it is implicit and not actually carried with > > the PDU itself. > > > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > > --> UD(07) C08(ud) UD(08) ---> > > > > After the target receives the command C01, C02, and C03 > > for which it expects unsolicited data, it puts them in > > a link list. It also receives C04 and C05 for which > > unsolicited data is not expected and they don't go > > on the list. It then receives C06 for which unsolicited > > data is expected, and it is added to then end of the list. > > Then an unsolicited data PDU is received. It must go > > with the command at the head of the list which is C01. > > Use the ITT to make sure and you can then take C01 off > > the list and so on. > > > > Somesh > > > > > > > -----Original Message----- > > > From: owner-ips@ece.cmu.edu > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > > Sent: Friday, October 12, 2001 7:53 AM > > > To: 'Binford, Charles'; ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > Charles, > > > > > > As you have described the spec states that "that > > unsolicited data MUST be > > > sent in the same order as the commands". This is not the same as > > > unsolicited data must follow the command associated with > > it: For example: > > > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > > x in all the > > > example can be the ITT. It is not the CmdSN. > > > > > > This is allowed: > > > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > > > and the target will have to use the ITT to associate the > > data with the > > > command. > > > > > > Matthew > > > > > > > > > -----Original Message----- > > > From: Binford, Charles [mailto:CBinford@pirus.com] > > > Sent: Friday, October 12, 2001 2:50 PM > > > To: ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > I have not verify version 8 is still the same, but version 07-97 > > > had a rule > > > that unsolicited data MUST be sent in the same order as the > > commands. > > > > > > Thus, there is no need for a search on the ITT. The target > > just needs to > > > keep of linked list of I/Os waiting on unsolicited data. > > New commands are > > > added to the tail, any unsolicited data *should* be associated > > > with the I/O > > > at the head of the list. The ITT is used as a sanity check and > > > you're done. > > > > > > What am I missing? > > > > > > Charles Binford > > > Pirus Networks > > > 316.315.0382 x222 > > > > > > > From owner-ips@ece.cmu.edu Sun Oct 21 07:34: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 HAA12045 for ; Sun, 21 Oct 2001 07:34:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9LANPi26868 for ips-outgoing; Sun, 21 Oct 2001 06:23:25 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9LANLl26862 for ; Sun, 21 Oct 2001 06:23:21 -0400 (EDT) Received: from ordern.demon.co.uk ([158.152.10.215]) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 15vFl5-00075e-0K; Sun, 21 Oct 2001 10:23:07 +0000 Received: from localhost(rook.ordern.com[192.168.1.1]) (94267 bytes) by ordern.demon.co.uk via smtpd with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Sun, 21 Oct 2001 11:23:06 +0100 (BST) (Smail-3.2.0.108 1999-Sep-19 #7 built 2000-Feb-18) Date: Sun, 21 Oct 2001 11:23:05 +0100 (BST) Message-Id: <20011021.112305.635728618.markb@ordern.com> To: ethereal-dev@ethereal.com Cc: ips@ece.cmu.edu Subject: Improved iSCSI dissector From: Mark Burton X-Mailer: Mew version 2.0 on XEmacs 21.4.4 (Artificial Intelligence) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Oct_21_11:23:05_2001_533)--" Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk ----Next_Part(Sun_Oct_21_11:23:05_2001_533)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit [IPS people please note that this code is currently only tested against the CVS version of ethereal - I don't know if it will work with the latest release] Folks, The enclosed code contains the following improvements: 1 - Compatible with 08 version of the protocol 2 - Handles both header and data digests 3 - Supports desegmentation 4 - Dissects multiple PDUs per packet 5 - Stronger heuristics to avoid dissecting non-iSCSI packets 6 - General rationalisation and de-crufting! The old code that attempted to automatically detect the presence of a header digest has been removed. You now have to specify in the iSCSI preferences whether digests are enabled and if they are, whether they are CRC32 or not. If not CRC32, you also need to specify the size of the digests (in bytes). Another new option specifies the iSCSI port number. This is used in the heuristics to filter out packets with silly port numbers, set to 0 to disable the port filter. One problem that I haven't been able to track down is that if desegmentation is enabled and you turn digests on or off ethereal throws a SEGV. Feedback to markb@ordern.com please. Cheers, Mark ----Next_Part(Sun_Oct_21_11:23:05_2001_533)-- Content-Type: Text/Plain; charset=us-ascii Content-Disposition: inline; filename="packet-iscsi.c" Content-Transfer-Encoding: base64 LyogcGFja2V0LWlzY3NpLmMNCiAqIFJvdXRpbmVzIGZvciBpU0NTSSBkaXNzZWN0aW9uDQog KiBDb3B5cmlnaHQgMjAwMSwgRXVyb2xvZ2ljIGFuZCBNYXJrIEJ1cnRvbiA8bWFya2JAb3Jk ZXJuLmNvbT4NCiAqDQogKiBDb25mb3JtcyB0byB0aGUgcHJvdG9jb2wgZGVzY3JpYmVkIGlu OiBkcmFmdC1pZXRmLWlwcy1pc2NzaS0wOC50eHQNCiAqDQogKiAkSWQ6IHBhY2tldC1pc2Nz aS5jLHYgMS4xMiAyMDAxLzEwLzIwIDE4OjMwOjUwIGd1eSBFeHAgJA0KICoNCiAqIEV0aGVy ZWFsIC0gTmV0d29yayB0cmFmZmljIGFuYWx5emVyDQogKiBCeSBHZXJhbGQgQ29tYnMgPGdl cmFsZEBldGhlcmVhbC5jb20+DQogKiBDb3B5cmlnaHQgMTk5OCBHZXJhbGQgQ29tYnMNCiAq DQogKiBUaGlzIHByb2dyYW0gaXMgZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1 dGUgaXQgYW5kL29yDQogKiBtb2RpZnkgaXQgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUg R2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KICogYXMgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNv ZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDINCiAqIG9mIHRoZSBMaWNlbnNl LCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9uLg0KICogDQogKiBUaGlz IHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUgdGhhdCBpdCB3aWxsIGJlIHVz ZWZ1bCwNCiAqIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRoZSBp bXBsaWVkIHdhcnJhbnR5IG9mDQogKiBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1Ig QSBQQVJUSUNVTEFSIFBVUlBPU0UuICBTZWUgdGhlDQogKiBHTlUgR2VuZXJhbCBQdWJsaWMg TGljZW5zZSBmb3IgbW9yZSBkZXRhaWxzLg0KICogDQogKiBZb3Ugc2hvdWxkIGhhdmUgcmVj ZWl2ZWQgYSBjb3B5IG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KICogYWxv bmcgd2l0aCB0aGlzIHByb2dyYW07IGlmIG5vdCwgd3JpdGUgdG8gdGhlIEZyZWUgU29mdHdh cmUNCiAqIEZvdW5kYXRpb24sIEluYy4sIDU5IFRlbXBsZSBQbGFjZSAtIFN1aXRlIDMzMCwg Qm9zdG9uLCBNQSAwMjExMS0xMzA3LCBVU0EuDQogKi8NCg0KI2lmZGVmIEhBVkVfQ09ORklH X0gNCiMgaW5jbHVkZSAiY29uZmlnLmgiDQojZW5kaWYNCg0KI2luY2x1ZGUgPHN0ZGlvLmg+ DQojaW5jbHVkZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8c3RyaW5nLmg+DQoNCiNpZmRlZiBI QVZFX1NZU19UWVBFU19IDQojIGluY2x1ZGUgPHN5cy90eXBlcy5oPg0KI2VuZGlmDQoNCiNp ZmRlZiBIQVZFX05FVElORVRfSU5fSA0KIyBpbmNsdWRlIDxuZXRpbmV0L2luLmg+DQojZW5k aWYNCg0KI2luY2x1ZGUgPGdsaWIuaD4NCg0KI2lmZGVmIE5FRURfU05QUklOVEZfSA0KIyBp bmNsdWRlICJzbnByaW50Zi5oIg0KI2VuZGlmDQoNCiNpbmNsdWRlICJwYWNrZXQuaCINCiNp bmNsdWRlICJwcmVmcy5oIg0KDQpzdGF0aWMgdWludCBpc2NzaV9kZXNlZ21lbnQgPSBUUlVF Ow0KDQpzdGF0aWMgaW50IGVuYWJsZV9ib2dvc2l0eV9maWx0ZXIgPSBUUlVFOw0Kc3RhdGlj IGd1aW50MzIgYm9ndXNfcGR1X2RhdGFfbGVuZ3RoX3RocmVzaG9sZCA9IDI1NiAqIDEwMjQ7 DQoNCnN0YXRpYyBpbnQgZW5hYmxlRGF0YURpZ2VzdHMgPSBGQUxTRTsNCnN0YXRpYyBpbnQg ZW5hYmxlSGVhZGVyRGlnZXN0cyA9IEZBTFNFOw0KDQpzdGF0aWMgaW50IGRhdGFEaWdlc3RJ c0NSQzMyID0gVFJVRTsNCnN0YXRpYyBpbnQgaGVhZGVyRGlnZXN0SXNDUkMzMiA9IFRSVUU7 DQoNCnN0YXRpYyBpbnQgZGF0YURpZ2VzdFNpemUgPSA0Ow0Kc3RhdGljIGludCBoZWFkZXJE aWdlc3RTaXplID0gNDsNCg0Kc3RhdGljIHVpbnQgaXNjc2lfcG9ydCA9IDUwMDM7DQoNCi8q IEluaXRpYWxpemUgdGhlIHByb3RvY29sIGFuZCByZWdpc3RlcmVkIGZpZWxkcyAqLw0Kc3Rh dGljIGludCBwcm90b19pc2NzaSA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9BSFMgPSAt MTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfUGFkZGluZyA9IC0xOw0Kc3RhdGljIGludCBoZl9p c2NzaV9waW5nX2RhdGEgPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfaW1tZWRpYXRlX2Rh dGEgPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfc2Vuc2VfZGF0YSA9IC0xOw0Kc3RhdGlj IGludCBoZl9pc2NzaV93cml0ZV9kYXRhID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX3Jl YWRfZGF0YSA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9lcnJvcl9wZHVfZGF0YSA9IC0x Ow0Kc3RhdGljIGludCBoZl9pc2NzaV9PcGNvZGUgPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNj c2lfRmxhZ3MgPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfSGVhZGVyRGlnZXN0ID0gLTE7 DQpzdGF0aWMgaW50IGhmX2lzY3NpX0hlYWRlckRpZ2VzdDMyID0gLTE7DQpzdGF0aWMgaW50 IGhmX2lzY3NpX0RhdGFEaWdlc3QgPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfRGF0YURp Z2VzdDMyID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1ggPSAtMTsNCnN0YXRpYyBpbnQg aGZfaXNjc2lfSSA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9TQ1NJQ29tbWFuZF9GID0g LTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1NDU0lDb21tYW5kX1IgPSAtMTsNCnN0YXRpYyBp bnQgaGZfaXNjc2lfU0NTSUNvbW1hbmRfVyA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9T Q1NJQ29tbWFuZF9BdHRyID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1NDU0lDb21tYW5k X0NSTiA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9TQ1NJQ29tbWFuZF9BZGRDREIgPSAt MTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfRGF0YVNlZ21lbnRMZW5ndGggPSAtMTsNCnN0YXRp YyBpbnQgaGZfaXNjc2lfVG90YWxBSFNMZW5ndGggPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNj c2lfTFVOID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX0luaXRpYXRvclRhc2tUYWcgPSAt MTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfRXhwZWN0ZWREYXRhVHJhbnNmZXJMZW5ndGggPSAt MTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfQ21kU04gPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNj c2lfRXhwU3RhdFNOID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1NDU0lDb21tYW5kX0NE QiA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9TQ1NJQ29tbWFuZF9DREIwID0gLTE7DQpz dGF0aWMgaW50IGhmX2lzY3NpX1N0YXRTTiA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9F eHBDbWRTTiA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9NYXhDbWRTTiA9IC0xOw0Kc3Rh dGljIGludCBoZl9pc2NzaV9TQ1NJUmVzcG9uc2VfbyA9IC0xOw0Kc3RhdGljIGludCBoZl9p c2NzaV9TQ1NJUmVzcG9uc2VfdSA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9TQ1NJUmVz cG9uc2VfTyA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9TQ1NJUmVzcG9uc2VfVSA9IC0x Ow0Kc3RhdGljIGludCBoZl9pc2NzaV9TQ1NJUmVzcG9uc2VfQmlkaVJlYWRSZXNpZHVhbENv dW50ID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1NDU0lSZXNwb25zZV9SZXNpZHVhbENv dW50ID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1NDU0lSZXNwb25zZV9SZXNwb25zZSA9 IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9TQ1NJUmVzcG9uc2VfU3RhdHVzID0gLTE7DQpz dGF0aWMgaW50IGhmX2lzY3NpX1NDU0lEYXRhX0YgPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNj c2lfU0NTSURhdGFfUyA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9TQ1NJRGF0YV9PID0g LTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1NDU0lEYXRhX1UgPSAtMTsNCnN0YXRpYyBpbnQg aGZfaXNjc2lfVGFyZ2V0VHJhbnNmZXJUYWcgPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lf RGF0YVNOID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX0J1ZmZlck9mZnNldCA9IC0xOw0K c3RhdGljIGludCBoZl9pc2NzaV9TQ1NJRGF0YV9SZXNpZHVhbENvdW50ID0gLTE7DQpzdGF0 aWMgaW50IGhmX2lzY3NpX1ZlcnNpb25NaW4gPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lf VmVyc2lvbk1heCA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9WZXJzaW9uQWN0aXZlID0g LTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX0NJRCA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2Nz aV9JU0lEID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1RTSUQgPSAtMTsNCnN0YXRpYyBp bnQgaGZfaXNjc2lfSW5pdFN0YXRTTiA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9Jbml0 Q21kU04gPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfTG9naW5fVCA9IC0xOw0Kc3RhdGlj IGludCBoZl9pc2NzaV9Mb2dpbl9DU0cgPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfTG9n aW5fTlNHID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX0xvZ2luX1N0YWdlID0gLTE7DQpz dGF0aWMgaW50IGhmX2lzY3NpX0xvZ2luX1N0YXR1cyA9IC0xOw0Kc3RhdGljIGludCBoZl9p c2NzaV9LZXlWYWx1ZSA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9UZXh0X0YgPSAtMTsN CnN0YXRpYyBpbnQgaGZfaXNjc2lfRXhwRGF0YVNOID0gLTE7DQpzdGF0aWMgaW50IGhmX2lz Y3NpX1IyVFNOID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1NDU0lUYXNrX1JlZmVyZW5j ZWRUYXNrVGFnID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1JlZkNtZFNOID0gLTE7DQpz dGF0aWMgaW50IGhmX2lzY3NpX1NDU0lUYXNrX0Z1bmN0aW9uID0gLTE7DQpzdGF0aWMgaW50 IGhmX2lzY3NpX1NDU0lUYXNrX1Jlc3BvbnNlID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3Np X0xvZ291dF9SZWFzb24gPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfTG9nb3V0X1Jlc3Bv bnNlID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1RpbWUyV2FpdCA9IC0xOw0Kc3RhdGlj IGludCBoZl9pc2NzaV9UaW1lMlJldGFpbiA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9E ZXNpcmVkRGF0YUxlbmd0aCA9IC0xOw0Kc3RhdGljIGludCBoZl9pc2NzaV9Bc3luY0V2ZW50 ID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX0V2ZW50VmVuZG9yQ29kZSA9IC0xOw0Kc3Rh dGljIGludCBoZl9pc2NzaV9QYXJhbWV0ZXIxID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3Np X1BhcmFtZXRlcjIgPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfUGFyYW1ldGVyMyA9IC0x Ow0Kc3RhdGljIGludCBoZl9pc2NzaV9SZWplY3RfUmVhc29uID0gLTE7DQpzdGF0aWMgaW50 IGhmX2lzY3NpX3NuYWNrX3R5cGUgPSAtMTsNCnN0YXRpYyBpbnQgaGZfaXNjc2lfQmVnUnVu ID0gLTE7DQpzdGF0aWMgaW50IGhmX2lzY3NpX1J1bkxlbmd0aCA9IC0xOw0KDQovKiBJbml0 aWFsaXplIHRoZSBzdWJ0cmVlIHBvaW50ZXJzICovDQpzdGF0aWMgZ2ludCBldHRfaXNjc2lf S2V5VmFsdWVzID0gLTE7DQpzdGF0aWMgZ2ludCBldHRfaXNjc2lfQ0RCID0gLTE7DQpzdGF0 aWMgZ2ludCBldHRfaXNjc2lfRmxhZ3MgPSAtMTsNCg0KI2RlZmluZSBYX0JJVCAweDgwDQoj ZGVmaW5lIElfQklUIDB4NDANCg0KI2RlZmluZSBUQVJHRVRfT1BDT0RFX0JJVCAweDIwDQoN CiNkZWZpbmUgSVNDU0lfT1BDT0RFX05PUF9PVVQgICAgICAgICAgICAgICAgICAgICAgMHgw MA0KI2RlZmluZSBJU0NTSV9PUENPREVfU0NTSV9DT01NQU5EICAgICAgICAgICAgICAgICAw eDAxDQojZGVmaW5lIElTQ1NJX09QQ09ERV9TQ1NJX1RBU0tfTUFOQUdFTUVOVF9DT01NQU5E IDB4MDINCiNkZWZpbmUgSVNDU0lfT1BDT0RFX0xPR0lOX0NPTU1BTkQgICAgICAgICAgICAg ICAgMHgwMw0KI2RlZmluZSBJU0NTSV9PUENPREVfVEVYVF9DT01NQU5EICAgICAgICAgICAg ICAgICAweDA0DQojZGVmaW5lIElTQ1NJX09QQ09ERV9TQ1NJX0RBVEFfT1VUICAgICAgICAg ICAgICAgIDB4MDUNCiNkZWZpbmUgSVNDU0lfT1BDT0RFX0xPR09VVF9DT01NQU5EICAgICAg ICAgICAgICAgMHgwNg0KI2RlZmluZSBJU0NTSV9PUENPREVfU05BQ0tfUkVRVUVTVCAgICAg ICAgICAgICAgICAweDEwDQoNCiNkZWZpbmUgSVNDU0lfT1BDT0RFX05PUF9JTiAgICAgICAg ICAgICAgICAgICAgICAgICgweDIwIHwgWF9CSVQgfCBJX0JJVCkNCiNkZWZpbmUgSVNDU0lf T1BDT0RFX1NDU0lfUkVTUE9OU0UgICAgICAgICAgICAgICAgICgweDIxIHwgWF9CSVQgfCBJ X0JJVCkNCiNkZWZpbmUgSVNDU0lfT1BDT0RFX1NDU0lfVEFTS19NQU5BR0VNRU5UX1JFU1BP TlNFICgweDIyIHwgWF9CSVQgfCBJX0JJVCkNCiNkZWZpbmUgSVNDU0lfT1BDT0RFX0xPR0lO X1JFU1BPTlNFICAgICAgICAgICAgICAgICgweDIzIHwgWF9CSVQgfCBJX0JJVCkNCiNkZWZp bmUgSVNDU0lfT1BDT0RFX1RFWFRfUkVTUE9OU0UgICAgICAgICAgICAgICAgICgweDI0IHwg WF9CSVQgfCBJX0JJVCkNCiNkZWZpbmUgSVNDU0lfT1BDT0RFX1NDU0lfREFUQV9JTiAgICAg ICAgICAgICAgICAgICgweDI1IHwgWF9CSVQgfCBJX0JJVCkNCiNkZWZpbmUgSVNDU0lfT1BD T0RFX0xPR09VVF9SRVNQT05TRSAgICAgICAgICAgICAgICgweDI2IHwgWF9CSVQgfCBJX0JJ VCkNCiNkZWZpbmUgSVNDU0lfT1BDT0RFX1IyVCAgICAgICAgICAgICAgICAgICAgICAgICAg ICgweDMxIHwgWF9CSVQgfCBJX0JJVCkNCiNkZWZpbmUgSVNDU0lfT1BDT0RFX0FTWU5DX01F U1NBR0UgICAgICAgICAgICAgICAgICgweDMyIHwgWF9CSVQgfCBJX0JJVCkNCiNkZWZpbmUg SVNDU0lfT1BDT0RFX1JFSkVDVCAgICAgICAgICAgICAgICAgICAgICAgICgweDNmIHwgWF9C SVQgfCBJX0JJVCkNCg0KI2RlZmluZSBDU0dfTUFTSyAweDBjDQoNCnN0YXRpYyBjb25zdCB2 YWx1ZV9zdHJpbmcgaXNjc2lfb3Bjb2Rlc1tdID0gew0KICB7IElTQ1NJX09QQ09ERV9OT1Bf T1VULCAgICAgICAgICAgICAgICAgICAgICAiTk9QIE91dCIgfSwNCiAgeyBJU0NTSV9PUENP REVfU0NTSV9DT01NQU5ELCAgICAgICAgICAgICAgICAgIlNDU0kgQ29tbWFuZCIgfSwNCiAg eyBJU0NTSV9PUENPREVfU0NTSV9UQVNLX01BTkFHRU1FTlRfQ09NTUFORCwgIlNDU0kgVGFz ayBNYW5hZ2VtZW50IENvbW1hbmQiIH0sDQogIHsgSVNDU0lfT1BDT0RFX0xPR0lOX0NPTU1B TkQsICAgICAgICAgICAgICAgICJMb2dpbiBDb21tYW5kIiB9LA0KICB7IElTQ1NJX09QQ09E RV9URVhUX0NPTU1BTkQsICAgICAgICAgICAgICAgICAiVGV4dCBDb21tYW5kIiB9LA0KICB7 IElTQ1NJX09QQ09ERV9TQ1NJX0RBVEFfT1VULCAgICAgICAgICAgICAgICAiU0NTSSBXcml0 ZSBEYXRhIiB9LA0KICB7IElTQ1NJX09QQ09ERV9MT0dPVVRfQ09NTUFORCwgICAgICAgICAg ICAgICAiTG9nb3V0IENvbW1hbmQiIH0sDQogIHsgSVNDU0lfT1BDT0RFX1NOQUNLX1JFUVVF U1QsICAgICAgICAgICAgICAgICJTTkFDSyBSZXF1ZXN0IiB9LA0KDQogIHsgSVNDU0lfT1BD T0RFX05PUF9JTiwgICAgICAgICAgICAgICAgICAgICAgICAiTk9QIEluIiB9LA0KICB7IElT Q1NJX09QQ09ERV9TQ1NJX1JFU1BPTlNFLCAgICAgICAgICAgICAgICAgIlNDU0kgQ29tbWFu ZCBSZXNwb25zZSIgfSwNCiAgeyBJU0NTSV9PUENPREVfU0NTSV9UQVNLX01BTkFHRU1FTlRf UkVTUE9OU0UsICJTQ1NJIFRhc2sgTWFuYWdlbWVudCBSZXNwb25zZSIgfSwNCiAgeyBJU0NT SV9PUENPREVfTE9HSU5fUkVTUE9OU0UsICAgICAgICAgICAgICAgICJMb2dpbiBSZXNwb25z ZSIgfSwNCiAgeyBJU0NTSV9PUENPREVfVEVYVF9SRVNQT05TRSwgICAgICAgICAgICAgICAg ICJUZXh0IFJlc3BvbnNlIiB9LA0KICB7IElTQ1NJX09QQ09ERV9TQ1NJX0RBVEFfSU4sICAg ICAgICAgICAgICAgICAgIlNDU0kgUmVhZCBEYXRhIiB9LA0KICB7IElTQ1NJX09QQ09ERV9M T0dPVVRfUkVTUE9OU0UsICAgICAgICAgICAgICAgIkxvZ291dCBSZXNwb25zZSIgfSwNCiAg eyBJU0NTSV9PUENPREVfUjJULCAgICAgICAgICAgICAgICAgICAgICAgICAgICJSZWFkeSBU byBUcmFuc2ZlciIgfSwNCiAgeyBJU0NTSV9PUENPREVfQVNZTkNfTUVTU0FHRSwgICAgICAg ICAgICAgICAgICJBc3luY2hyb25vdXMgTWVzc2FnZSIgfSwNCiAgeyBJU0NTSV9PUENPREVf UkVKRUNULCAgICAgICAgICAgICAgICAgICAgICAgICJSZWplY3QifSwNCiAgezAsIE5VTEx9 LA0KfTsNCg0Kc3RhdGljIGNvbnN0IHRydWVfZmFsc2Vfc3RyaW5nIGlzY3NpX21lYW5pbmdf WCA9IHsNCiAgICAiUmV0cnkiLA0KICAgICJOb3QgcmV0cnkiDQp9Ow0KDQpzdGF0aWMgY29u c3QgdHJ1ZV9mYWxzZV9zdHJpbmcgaXNjc2lfbWVhbmluZ19JID0gew0KICAgICJJbW1lZGlh dGUgZGVsaXZlcnkiLA0KICAgICJRdWV1ZWQgZGVsaXZlcnkiDQp9Ow0KDQpzdGF0aWMgY29u c3QgdHJ1ZV9mYWxzZV9zdHJpbmcgaXNjc2lfbWVhbmluZ19GID0gew0KICAgICJGaW5hbCBQ RFUgaW4gc2VxdWVuY2UiLA0KICAgICJOb3QgZmluYWwgUERVIGluIHNlcXVlbmNlIg0KfTsN Cg0Kc3RhdGljIGNvbnN0IHRydWVfZmFsc2Vfc3RyaW5nIGlzY3NpX21lYW5pbmdfVCA9IHsN CiAgICAiVHJhbnNpdCB0byBuZXh0IGxvZ2luIHN0YWdlIiwNCiAgICAiU3RheSBpbiBjdXJy ZW50IGxvZ2luIHN0YWdlIg0KfTsNCg0Kc3RhdGljIGNvbnN0IHRydWVfZmFsc2Vfc3RyaW5n IGlzY3NpX21lYW5pbmdfUyA9IHsNCiAgICAiUmVzcG9uc2UgY29udGFpbnMgU0NTSSBzdGF0 dXMiLA0KICAgICJSZXNwb25zZSBkb2VzIG5vdCBjb250YWluIFNDU0kgc3RhdHVzIg0KfTsN Cg0Kc3RhdGljIGNvbnN0IHRydWVfZmFsc2Vfc3RyaW5nIGlzY3NpX21lYW5pbmdfUiA9IHsN CiAgICAiRGF0YSB3aWxsIGJlIHJlYWQgZnJvbSB0YXJnZXQiLA0KICAgICJObyBkYXRhIHdp bGwgYmUgcmVhZCBmcm9tIHRhcmdldCINCn07DQoNCnN0YXRpYyBjb25zdCB0cnVlX2ZhbHNl X3N0cmluZyBpc2NzaV9tZWFuaW5nX1cgPSB7DQogICAgIkRhdGEgd2lsbCBiZSB3cml0dGVu IHRvIHRhcmdldCIsDQogICAgIk5vIGRhdGEgd2lsbCBiZSB3cml0dGVuIHRvIHRhcmdldCIN Cn07DQoNCnN0YXRpYyBjb25zdCB0cnVlX2ZhbHNlX3N0cmluZyBpc2NzaV9tZWFuaW5nX28g PSB7DQogICAgIlJlYWQgcGFydCBvZiBiaS1kaXJlY3Rpb25hbCBjb21tYW5kIG92ZXJmbG93 ZWQiLA0KICAgICJObyBvdmVyZmxvdyBvZiByZWFkIHBhcnQgb2YgYmktZGlyZWN0aW9uYWwg Y29tbWFuZCIsDQp9Ow0KDQpzdGF0aWMgY29uc3QgdHJ1ZV9mYWxzZV9zdHJpbmcgaXNjc2lf bWVhbmluZ191ID0gew0KICAgICJSZWFkIHBhcnQgb2YgYmktZGlyZWN0aW9uYWwgY29tbWFu ZCB1bmRlcmZsb3dlZCIsDQogICAgIk5vIHVuZGVyZmxvdyBvZiByZWFkIHBhcnQgb2YgYmkt ZGlyZWN0aW9uYWwgY29tbWFuZCIsDQp9Ow0KDQpzdGF0aWMgY29uc3QgdHJ1ZV9mYWxzZV9z dHJpbmcgaXNjc2lfbWVhbmluZ19PID0gew0KICAgICJSZXNpZHVhbCBvdmVyZmxvdyBvY2N1 cnJlZCIsDQogICAgIk5vIHJlc2lkdWFsIG92ZXJmbG93IG9jY3VycmVkIiwNCn07DQoNCnN0 YXRpYyBjb25zdCB0cnVlX2ZhbHNlX3N0cmluZyBpc2NzaV9tZWFuaW5nX1UgPSB7DQogICAg IlJlc2lkdWFsIHVuZGVyZmxvdyBvY2N1cnJlZCIsDQogICAgIk5vIHJlc2lkdWFsIHVuZGVy ZmxvdyBvY2N1cnJlZCIsDQp9Ow0KDQpzdGF0aWMgY29uc3QgdmFsdWVfc3RyaW5nIGlzY3Np X3Njc2lfcmVzcG9uc2VzW10gPSB7DQogICAgeyAwLCAiQ29tbWFuZCBjb21wbGV0ZWQgYXQg dGFyZ2V0IiB9LA0KICAgIHsgMSwgIlJlc3BvbnNlIGRvZXMgbm90IGNvbnRhaW4gU0NTSSBz dGF0dXMifSwNCiAgICB7IDAsIE5VTEwgfQ0KfTsNCg0Kc3RhdGljIGNvbnN0IHZhbHVlX3N0 cmluZyBpc2NzaV9zY3NpY29tbWFuZF90YXNrYXR0cnNbXSA9IHsNCiAgICB7MCwgIlVudGFn Z2VkIn0sDQogICAgezEsICJTaW1wbGUifSwNCiAgICB7MiwgIk9yZGVyZWQifSwNCiAgICB7 MywgIkhlYWQgb2YgUXVldWUifSwNCiAgICB7NCwgIkFDQSJ9LA0KICAgIHswLCBOVUxMfSwN Cn07DQoNCnN0YXRpYyBjb25zdCB2YWx1ZV9zdHJpbmcgaXNjc2lfc2NzaV9jZGIwW10gPSB7 DQogICAgezB4MDAsICJURVNUX1VOSVRfUkVBRFkifSwNCiAgICB7MHgwMSwgIlJFWkVST19V TklUIn0sDQogICAgezB4MDMsICJSRVFVRVNUX1NFTlNFIn0sDQogICAgezB4MDQsICJGT1JN QVRfVU5JVCJ9LA0KICAgIHsweDA1LCAiUkVBRF9CTE9DS19MSU1JVFMifSwNCiAgICB7MHgw NywgIlJFQVNTSUdOX0JMT0NLUyJ9LA0KICAgIHsweDA4LCAiUkVBRF82In0sDQogICAgezB4 MGEsICJXUklURV82In0sDQogICAgezB4MGIsICJTRUVLXzYifSwNCiAgICB7MHgwZiwgIlJF QURfUkVWRVJTRSJ9LA0KICAgIHsweDEwLCAiV1JJVEVfRklMRU1BUktTIn0sDQogICAgezB4 MTEsICJTUEFDRSJ9LA0KICAgIHsweDEyLCAiSU5RVUlSWSJ9LA0KICAgIHsweDE0LCAiUkVD T1ZFUl9CVUZGRVJFRF9EQVRBIn0sDQogICAgezB4MTUsICJNT0RFX1NFTEVDVCJ9LA0KICAg IHsweDE2LCAiUkVTRVJWRSJ9LA0KICAgIHsweDE3LCAiUkVMRUFTRSJ9LA0KICAgIHsweDE4 LCAiQ09QWSJ9LA0KICAgIHsweDE5LCAiRVJBU0UifSwNCiAgICB7MHgxYSwgIk1PREVfU0VO U0UifSwNCiAgICB7MHgxYiwgIlNUQVJUX1NUT1AifSwNCiAgICB7MHgxYywgIlJFQ0VJVkVf RElBR05PU1RJQyJ9LA0KICAgIHsweDFkLCAiU0VORF9ESUFHTk9TVElDIn0sDQogICAgezB4 MWUsICJBTExPV19NRURJVU1fUkVNT1ZBTCJ9LA0KICAgIHsweDI0LCAiU0VUX1dJTkRPVyJ9 LA0KICAgIHsweDI1LCAiUkVBRF9DQVBBQ0lUWSJ9LA0KICAgIHsweDI4LCAiUkVBRF8xMCJ9 LA0KICAgIHsweDJhLCAiV1JJVEVfMTAifSwNCiAgICB7MHgyYiwgIlNFRUtfMTAifSwNCiAg ICB7MHgyZSwgIldSSVRFX1ZFUklGWSJ9LA0KICAgIHsweDJmLCAiVkVSSUZZIn0sDQogICAg ezB4MzAsICJTRUFSQ0hfSElHSCJ9LA0KICAgIHsweDMxLCAiU0VBUkNIX0VRVUFMIn0sDQog ICAgezB4MzIsICJTRUFSQ0hfTE9XIn0sDQogICAgezB4MzMsICJTRVRfTElNSVRTIn0sDQog ICAgezB4MzQsICJQUkVfRkVUQ0gifSwNCiAgICB7MHgzNCwgIlJFQURfUE9TSVRJT04ifSwN CiAgICB7MHgzNSwgIlNZTkNIUk9OSVpFX0NBQ0hFIn0sDQogICAgezB4MzYsICJMT0NLX1VO TE9DS19DQUNIRSJ9LA0KICAgIHsweDM3LCAiUkVBRF9ERUZFQ1RfREFUQSJ9LA0KICAgIHsw eDM4LCAiTUVESVVNX1NDQU4ifSwNCiAgICB7MHgzOSwgIkNPTVBBUkUifSwNCiAgICB7MHgz YSwgIkNPUFlfVkVSSUZZIn0sDQogICAgezB4M2IsICJXUklURV9CVUZGRVIifSwNCiAgICB7 MHgzYywgIlJFQURfQlVGRkVSIn0sDQogICAgezB4M2QsICJVUERBVEVfQkxPQ0sifSwNCiAg ICB7MHgzZSwgIlJFQURfTE9ORyJ9LA0KICAgIHsweDNmLCAiV1JJVEVfTE9ORyJ9LA0KICAg IHsweDQwLCAiQ0hBTkdFX0RFRklOSVRJT04ifSwNCiAgICB7MHg0MSwgIldSSVRFX1NBTUUi fSwNCiAgICB7MHg0MywgIlJFQURfVE9DIn0sDQogICAgezB4NGMsICJMT0dfU0VMRUNUIn0s DQogICAgezB4NGQsICJMT0dfU0VOU0UifSwNCiAgICB7MHg1NSwgIk1PREVfU0VMRUNUXzEw In0sDQogICAgezB4NWEsICJNT0RFX1NFTlNFXzEwIn0sDQogICAgezB4YTUsICJNT1ZFX01F RElVTSJ9LA0KICAgIHsweGE4LCAiUkVBRF8xMiJ9LA0KICAgIHsweGFhLCAiV1JJVEVfMTIi fSwNCiAgICB7MHhhZSwgIldSSVRFX1ZFUklGWV8xMiJ9LA0KICAgIHsweGIwLCAiU0VBUkNI X0hJR0hfMTIifSwNCiAgICB7MHhiMSwgIlNFQVJDSF9FUVVBTF8xMiJ9LA0KICAgIHsweGIy LCAiU0VBUkNIX0xPV18xMiJ9LA0KICAgIHsweGI4LCAiUkVBRF9FTEVNRU5UX1NUQVRVUyJ9 LA0KICAgIHsweGI2LCAiU0VORF9WT0xVTUVfVEFHIn0sDQogICAgezB4ZWEsICJXUklURV9M T05HXzIifSwNCiAgICB7MCwgTlVMTH0sDQp9Ow0KDQpzdGF0aWMgY29uc3QgdmFsdWVfc3Ry aW5nIGlzY3NpX3Njc2lfc3RhdHVzZXNbXSA9IHsNCiAgICB7MHgwMCwgIkdvb2QifSwNCiAg ICB7MHgwMSwgIkNoZWNrIGNvbmRpdGlvbiJ9LA0KICAgIHsweDAyLCAiQ29uZGl0aW9uIGdv b2QifSwNCiAgICB7MHgwNCwgIkJ1c3kifSwNCiAgICB7MHgwOCwgIkludGVybWVkaWF0ZSBn b29kIn0sDQogICAgezB4MGEsICJJbnRlcm1lZGlhdGUgYyBnb29kIn0sDQogICAgezB4MGMs ICJSZXNlcnZhdGlvbiBjb25mbGljdCJ9LA0KICAgIHsweDExLCAiQ29tbWFuZCB0ZXJtaW5h dGVkIn0sDQogICAgezB4MTQsICJRdWV1ZSBmdWxsIn0sDQogICAgezAsIE5VTEx9LA0KfTsN Cg0Kc3RhdGljIGNvbnN0IHZhbHVlX3N0cmluZyBpc2NzaV90YXNrX3Jlc3BvbnNlc1tdID0g ew0KICAgIHswLCAiRnVuY3Rpb24gY29tcGxldGUifSwNCiAgICB7MSwgIlRhc2sgbm90IGlu IHRhc2sgc2V0In0sDQogICAgezIsICJMVU4gZG9lcyBub3QgZXhpc3QifSwNCiAgICB7MjU1 LCAiRnVuY3Rpb24gcmVqZWN0ZWQifSwNCiAgICB7MCwgTlVMTH0sDQp9Ow0KDQpzdGF0aWMg Y29uc3QgdmFsdWVfc3RyaW5nIGlzY3NpX3Rhc2tfZnVuY3Rpb25zW10gPSB7DQogICAgezEs ICJBYm9ydCBUYXNrIn0sDQogICAgezIsICJBYm9ydCBUYXNrIFNldCJ9LA0KICAgIHszLCAi Q2xlYXIgQUNBIn0sDQogICAgezQsICJDbGVhciBUYXNrIFNldCJ9LA0KICAgIHs1LCAiTG9n aWNhbCBVbml0IFJlc2V0In0sDQogICAgezYsICJUYXJnZXQgV2FybSBSZXNldCJ9LA0KICAg IHs3LCAiVGFyZ2V0IENvbGQgUmVzZXQifSwNCiAgICB7MCwgTlVMTH0sDQp9Ow0KDQpzdGF0 aWMgY29uc3QgdmFsdWVfc3RyaW5nIGlzY3NpX2xvZ2luX3N0YXR1c1tdID0gew0KICAgIHsw eDAwMDAsICJTdWNjZXNzIn0sDQogICAgezB4MDEwMSwgIlRhcmdldCBtb3ZlZCB0ZW1wb3Jh cmlseSJ9LA0KICAgIHsweDAxMDIsICJUYXJnZXQgbW92ZWQgcGVybWFuZW50bHkifSwNCiAg ICB7MHgwMjAwLCAiSW5pdGlhdG9yIGVycm9yIChtaXNjZWxsYW5lb3VzIGVycm9yKSJ9LA0K ICAgIHsweDAyMDEsICJBdGhlbnRpY2F0aW9uIGZhaWxlZCJ9LA0KICAgIHsweDAyMDIsICJB dXRob3Jpc2F0aW9uIGZhaWx1cmUifSwNCiAgICB7MHgwMjAzLCAiVGFyZ2V0IG5vdCBmb3Vu ZCJ9LA0KICAgIHsweDAyMDQsICJUYXJnZXQgcmVtb3ZlZCJ9LA0KICAgIHsweDAyMDUsICJV bnN1cHBvcnRlZCB2ZXJzaW9uIn0sDQogICAgezB4MDIwNiwgIlRvbyBtYW55IGNvbm5lY3Rp b25zIn0sDQogICAgezB4MDIwNywgIk1pc3NpbmcgcGFyYW1ldGVyIn0sDQogICAgezB4MDIw OCwgIkNhbid0IGluY2x1ZGUgaW4gc2Vzc2lvbiJ9LA0KICAgIHsweDAyMDksICJTZXNzaW9u IHR5cGUgbm90IHN1cHBvcnRlZCJ9LA0KICAgIHsweDAzMDAsICJUYXJnZXQgZXJyb3IgKG1p c2NlbGxhbmVvdXMgZXJyb3IpIn0sDQogICAgezB4MDMwMSwgIlNlcnZpY2UgdW5hdmFpbGFi bGUifSwNCiAgICB7MHgwMzAyLCAiT3V0IG9mIHJlc291cmNlcyJ9LA0KICAgIHswLCBOVUxM fSwNCn07DQoNCnN0YXRpYyBjb25zdCB2YWx1ZV9zdHJpbmcgaXNjc2lfbG9naW5fc3RhZ2Vb XSA9IHsNCiAgICB7MCwgIlNlY3VyaXR5IG5lZ290aWF0aW9uIn0sDQogICAgezEsICJPcGVy YXRpb25hbCBuZWdvdGlhdGlvbiJ9LA0KICAgIHszLCAiRnVsbCBmZWF0dXJlIHBoYXNlIn0s DQogICAgezAsIE5VTEx9LA0KfTsNCg0Kc3RhdGljIGNvbnN0IHZhbHVlX3N0cmluZyBpc2Nz aV9sb2dvdXRfcmVhc29uc1tdID0gew0KICAgIHswLCAiQ2xvc2Ugc2Vzc2lvbiJ9LA0KICAg IHsxLCAiQ2xvc2UgY29ubmVjdGlvbiJ9LA0KICAgIHsyLCAiUmVtb3ZlIGNvbm5lY3Rpb24g Zm9yIHJlY292ZXJ5In0sDQogICAgezAsIE5VTEx9LA0KfTsNCg0Kc3RhdGljIGNvbnN0IHZh bHVlX3N0cmluZyBpc2NzaV9sb2dvdXRfcmVzcG9uc2VbXSA9IHsNCiAgICB7MCwgIkNvbm5l Y3Rpb24gY2xvc2VkIHN1Y2Nlc3NmdWxseSJ9LA0KICAgIHsxLCAiQ0lEIG5vdCBmb3VuZCJ9 LA0KICAgIHsyLCAiQ29ubmVjdGlvbiByZWNvdmVyeSBub3Qgc3VwcG9ydGVkIn0sDQogICAg ezMsICJDbGVhbnVwIGZhaWxlZCBmb3IgdmFyaW91cyByZWFzb25zIn0sDQogICAgezAsIE5V TEx9LA0KfTsNCg0Kc3RhdGljIGNvbnN0IHZhbHVlX3N0cmluZyBpc2NzaV9hc3luY2V2ZW50 c1tdID0gew0KICAgIHswLCAiQSBTQ1NJIGFzeW5jaHJvbm91cyBldmVudCBpcyByZXBvcnRl ZCBpbiB0aGUgc2Vuc2UgZGF0YSJ9LA0KICAgIHsxLCAiVGFyZ2V0IHJlcXVlc3RzIGxvZ291 dCJ9LA0KICAgIHsyLCAiVGFyZ2V0IHdpbGwvaGFzIGRyb3BwZWQgY29ubmVjdGlvbiJ9LA0K ICAgIHszLCAiVGFyZ2V0IHdpbGwvaGFzIGRyb3BwZWQgYWxsIGNvbm5lY3Rpb25zIn0sDQog ICAgezAsIE5VTEx9LA0KfTsNCg0Kc3RhdGljIGNvbnN0IHZhbHVlX3N0cmluZyBpc2NzaV9z bmFja190eXBlc1tdID0gew0KICAgIHswLCAiRGF0YS9SMlQifSwNCiAgICB7MSwgIlN0YXR1 cyJ9LA0KICAgIHswLCBOVUxMfQ0KfTsNCg0Kc3RhdGljIGNvbnN0IHZhbHVlX3N0cmluZyBp c2NzaV9yZWplY3RfcmVhc29uc1tdID0gew0KICAgIHsweDAxLCAiRnVsbCBmZWF0dXJlIHBo YXNlIGNvbW1hbmQgYmVmb3JlIGxvZ2luIn0sDQogICAgezB4MDIsICJEYXRhIChwYXlsb2Fk KSBkaWdlc3QgZXJyb3IifSwNCiAgICB7MHgwMywgIkRhdGEgU05BQ0sgcmVqZWN0In0sDQog ICAgezB4MDQsICJQcm90b2NvbCBlcnJvciJ9LA0KICAgIHsweDA1LCAiQ29tbWFuZCBub3Qg c3VwcG9ydGVkIGluIHRoaXMgc2Vzc2lvbiB0eXBlIn0sDQogICAgezB4MDYsICJJbW1lZGlh dGUgY29tbWFuZCByZWplY3QgKHRvbyBtYW55IGltbWVkaWF0ZSBjb21tYW5kcykifSwNCiAg ICB7MHgwNywgIlRhc2sgaW4gcHJvZ3Jlc3MifSwNCiAgICB7MHgwOCwgIkludmFsaWQgU05B Q0sifSwNCiAgICB7MHgwOSwgIkJvb2ttYXJrIHJlamVjdCAobm8gYm9va21hcmsgZm9yIHRo aXMgaW5pdGlhdG9yIHRhc2sgdGFnKSJ9LA0KICAgIHsweDBhLCAiQm9va21hcmsgcmVqZWN0 IChjYW4ndCBnZW5lcmF0ZSBib29rbWFyayAtIG91dCBvZiByZXNvdXJjZXMpIn0sDQogICAg ezB4MGIsICJOZWdvdGlhdGlvbiByZXNldCJ9LA0KICAgIHswLCBOVUxMfSwNCn07DQoNCi8q KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKi8NCi8qICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgKi8NCi8qIENSQyBMT09LVVAgVEFCTEUgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8NCi8qID09PT09PT09 PT09PT09PT0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ki8NCi8qIFRoZSBmb2xsb3dpbmcgQ1JDIGxvb2t1cCB0YWJsZSB3YXMgZ2VuZXJhdGVkIGF1 dG9tYWdpY2FsbHkgICAgKi8NCi8qIGJ5IHRoZSBSb2Nrc29mdF50bSBNb2RlbCBDUkMgQWxn b3JpdGhtIFRhYmxlIEdlbmVyYXRpb24gICAgICAgKi8NCi8qIFByb2dyYW0gVjEuMCB1c2lu ZyB0aGUgZm9sbG93aW5nIG1vZGVsIHBhcmFtZXRlcnM6ICAgICAgICAgICAgKi8NCi8qICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKi8NCi8qICAgIFdpZHRoICAgOiA0IGJ5dGVzLiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKi8NCi8qICAgIFBvbHkgICAgOiAweDFFREM2RjQxTCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8NCi8qICAgIFJldmVyc2Ug OiBUUlVFLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8N Ci8qICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKi8NCi8qIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoZSBSb2Nrc29m dF50bSBNb2RlbCBDUkMgQWxnb3JpdGhtLCAgKi8NCi8qIHNlZSB0aGUgZG9jdW1lbnQgdGl0 bGVkICJBIFBhaW5sZXNzIEd1aWRlIHRvIENSQyBFcnJvciAgICAgICAgKi8NCi8qIERldGVj dGlvbiBBbGdvcml0aG1zIiBieSBSb3NzIFdpbGxpYW1zICAgICAgICAgICAgICAgICAgICAg ICAgKi8NCi8qIChyb3NzQGd1ZXN0LmFkZWxhaWRlLmVkdS5hdS4pLiBUaGlzIGRvY3VtZW50 IGlzIGxpa2VseSB0byBiZSAgKi8NCi8qIGluIHRoZSBGVFAgYXJjaGl2ZSAiZnRwLmFkZWxh aWRlLmVkdS5hdS9wdWIvcm9ja3NvZnQiLiAgICAgICAgKi8NCi8qICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8NCi8q KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKi8NCg0Kc3RhdGljIGd1aW50MzIgY3JjMzJUYWJsZVsyNTZdID0gew0KICAg IDB4MDAwMDAwMDBMLCAweEYyNkI4MzAzTCwgMHhFMTNCNzBGN0wsIDB4MTM1MEYzRjRMLA0K ICAgIDB4Qzc5QTk3MUZMLCAweDM1RjExNDFDTCwgMHgyNkExRTdFOEwsIDB4RDRDQTY0RUJM LA0KICAgIDB4OEFEOTU4Q0ZMLCAweDc4QjJEQkNDTCwgMHg2QkUyMjgzOEwsIDB4OTk4OUFC M0JMLA0KICAgIDB4NEQ0M0NGRDBMLCAweEJGMjg0Q0QzTCwgMHhBQzc4QkYyN0wsIDB4NUUx MzNDMjRMLA0KICAgIDB4MTA1RUM3NkZMLCAweEUyMzU0NDZDTCwgMHhGMTY1Qjc5OEwsIDB4 MDMwRTM0OUJMLA0KICAgIDB4RDdDNDUwNzBMLCAweDI1QUZEMzczTCwgMHgzNkZGMjA4N0ws IDB4QzQ5NEEzODRMLA0KICAgIDB4OUE4NzlGQTBMLCAweDY4RUMxQ0EzTCwgMHg3QkJDRUY1 N0wsIDB4ODlENzZDNTRMLA0KICAgIDB4NUQxRDA4QkZMLCAweEFGNzY4QkJDTCwgMHhCQzI2 Nzg0OEwsIDB4NEU0REZCNEJMLA0KICAgIDB4MjBCRDhFREVMLCAweEQyRDYwRERETCwgMHhD MTg2RkUyOUwsIDB4MzNFRDdEMkFMLA0KICAgIDB4RTcyNzE5QzFMLCAweDE1NEM5QUMyTCwg MHgwNjFDNjkzNkwsIDB4RjQ3N0VBMzVMLA0KICAgIDB4QUE2NEQ2MTFMLCAweDU4MEY1NTEy TCwgMHg0QjVGQTZFNkwsIDB4QjkzNDI1RTVMLA0KICAgIDB4NkRGRTQxMEVMLCAweDlGOTVD MjBETCwgMHg4Q0M1MzFGOUwsIDB4N0VBRUIyRkFMLA0KICAgIDB4MzBFMzQ5QjFMLCAweEMy ODhDQUIyTCwgMHhEMUQ4Mzk0NkwsIDB4MjNCM0JBNDVMLA0KICAgIDB4Rjc3OURFQUVMLCAw eDA1MTI1REFETCwgMHgxNjQyQUU1OUwsIDB4RTQyOTJENUFMLA0KICAgIDB4QkEzQTExN0VM LCAweDQ4NTE5MjdETCwgMHg1QjAxNjE4OUwsIDB4QTk2QUUyOEFMLA0KICAgIDB4N0RBMDg2 NjFMLCAweDhGQ0IwNTYyTCwgMHg5QzlCRjY5NkwsIDB4NkVGMDc1OTVMLA0KICAgIDB4NDE3 QjFEQkNMLCAweEIzMTA5RUJGTCwgMHhBMDQwNkQ0QkwsIDB4NTIyQkVFNDhMLA0KICAgIDB4 ODZFMThBQTNMLCAweDc0OEEwOUEwTCwgMHg2N0RBRkE1NEwsIDB4OTVCMTc5NTdMLA0KICAg IDB4Q0JBMjQ1NzNMLCAweDM5QzlDNjcwTCwgMHgyQTk5MzU4NEwsIDB4RDhGMkI2ODdMLA0K ICAgIDB4MEMzOEQyNkNMLCAweEZFNTM1MTZGTCwgMHhFRDAzQTI5QkwsIDB4MUY2ODIxOThM LA0KICAgIDB4NTEyNURBRDNMLCAweEEzNEU1OUQwTCwgMHhCMDFFQUEyNEwsIDB4NDI3NTI5 MjdMLA0KICAgIDB4OTZCRjREQ0NMLCAweDY0RDRDRUNGTCwgMHg3Nzg0M0QzQkwsIDB4ODVF RkJFMzhMLA0KICAgIDB4REJGQzgyMUNMLCAweDI5OTcwMTFGTCwgMHgzQUM3RjJFQkwsIDB4 QzhBQzcxRThMLA0KICAgIDB4MUM2NjE1MDNMLCAweEVFMEQ5NjAwTCwgMHhGRDVENjVGNEws IDB4MEYzNkU2RjdMLA0KICAgIDB4NjFDNjkzNjJMLCAweDkzQUQxMDYxTCwgMHg4MEZERTM5 NUwsIDB4NzI5NjYwOTZMLA0KICAgIDB4QTY1QzA0N0RMLCAweDU0Mzc4NzdFTCwgMHg0NzY3 NzQ4QUwsIDB4QjUwQ0Y3ODlMLA0KICAgIDB4RUIxRkNCQURMLCAweDE5NzQ0OEFFTCwgMHgw QTI0QkI1QUwsIDB4Rjg0RjM4NTlMLA0KICAgIDB4MkM4NTVDQjJMLCAweERFRUVERkIxTCwg MHhDREJFMkM0NUwsIDB4M0ZENUFGNDZMLA0KICAgIDB4NzE5ODU0MERMLCAweDgzRjNENzBF TCwgMHg5MEEzMjRGQUwsIDB4NjJDOEE3RjlMLA0KICAgIDB4QjYwMkMzMTJMLCAweDQ0Njk0 MDExTCwgMHg1NzM5QjNFNUwsIDB4QTU1MjMwRTZMLA0KICAgIDB4RkI0MTBDQzJMLCAweDA5 MkE4RkMxTCwgMHgxQTdBN0MzNUwsIDB4RTgxMUZGMzZMLA0KICAgIDB4M0NEQjlCRERMLCAw eENFQjAxOERFTCwgMHhEREUwRUIyQUwsIDB4MkY4QjY4MjlMLA0KICAgIDB4ODJGNjNCNzhM LCAweDcwOURCODdCTCwgMHg2M0NENEI4RkwsIDB4OTFBNkM4OENMLA0KICAgIDB4NDU2Q0FD NjdMLCAweEI3MDcyRjY0TCwgMHhBNDU3REM5MEwsIDB4NTYzQzVGOTNMLA0KICAgIDB4MDgy RjYzQjdMLCAweEZBNDRFMEI0TCwgMHhFOTE0MTM0MEwsIDB4MUI3RjkwNDNMLA0KICAgIDB4 Q0ZCNUY0QThMLCAweDNEREU3N0FCTCwgMHgyRThFODQ1RkwsIDB4RENFNTA3NUNMLA0KICAg IDB4OTJBOEZDMTdMLCAweDYwQzM3RjE0TCwgMHg3MzkzOENFMEwsIDB4ODFGODBGRTNMLA0K ICAgIDB4NTUzMjZCMDhMLCAweEE3NTlFODBCTCwgMHhCNDA5MUJGRkwsIDB4NDY2Mjk4RkNM LA0KICAgIDB4MTg3MUE0RDhMLCAweEVBMUEyN0RCTCwgMHhGOTRBRDQyRkwsIDB4MEIyMTU3 MkNMLA0KICAgIDB4REZFQjMzQzdMLCAweDJEODBCMEM0TCwgMHgzRUQwNDMzMEwsIDB4Q0NC QkMwMzNMLA0KICAgIDB4QTI0QkI1QTZMLCAweDUwMjAzNkE1TCwgMHg0MzcwQzU1MUwsIDB4 QjExQjQ2NTJMLA0KICAgIDB4NjVEMTIyQjlMLCAweDk3QkFBMUJBTCwgMHg4NEVBNTI0RUws IDB4NzY4MUQxNERMLA0KICAgIDB4Mjg5MkVENjlMLCAweERBRjk2RTZBTCwgMHhDOUE5OUQ5 RUwsIDB4M0JDMjFFOURMLA0KICAgIDB4RUYwODdBNzZMLCAweDFENjNGOTc1TCwgMHgwRTMz MEE4MUwsIDB4RkM1ODg5ODJMLA0KICAgIDB4QjIxNTcyQzlMLCAweDQwN0VGMUNBTCwgMHg1 MzJFMDIzRUwsIDB4QTE0NTgxM0RMLA0KICAgIDB4NzU4RkU1RDZMLCAweDg3RTQ2NkQ1TCwg MHg5NEI0OTUyMUwsIDB4NjZERjE2MjJMLA0KICAgIDB4MzhDQzJBMDZMLCAweENBQTdBOTA1 TCwgMHhEOUY3NUFGMUwsIDB4MkI5Q0Q5RjJMLA0KICAgIDB4RkY1NkJEMTlMLCAweDBEM0Qz RTFBTCwgMHgxRTZEQ0RFRUwsIDB4RUMwNjRFRURMLA0KICAgIDB4QzM4RDI2QzRMLCAweDMx RTZBNUM3TCwgMHgyMkI2NTYzM0wsIDB4RDBEREQ1MzBMLA0KICAgIDB4MDQxN0IxREJMLCAw eEY2N0MzMkQ4TCwgMHhFNTJDQzEyQ0wsIDB4MTc0NzQyMkZMLA0KICAgIDB4NDk1NDdFMEJM LCAweEJCM0ZGRDA4TCwgMHhBODZGMEVGQ0wsIDB4NUEwNDhERkZMLA0KICAgIDB4OEVDRUU5 MTRMLCAweDdDQTU2QTE3TCwgMHg2RkY1OTlFM0wsIDB4OUQ5RTFBRTBMLA0KICAgIDB4RDNE M0UxQUJMLCAweDIxQjg2MkE4TCwgMHgzMkU4OTE1Q0wsIDB4QzA4MzEyNUZMLA0KICAgIDB4 MTQ0OTc2QjRMLCAweEU2MjJGNUI3TCwgMHhGNTcyMDY0M0wsIDB4MDcxOTg1NDBMLA0KICAg IDB4NTkwQUI5NjRMLCAweEFCNjEzQTY3TCwgMHhCODMxQzk5M0wsIDB4NEE1QTRBOTBMLA0K ICAgIDB4OUU5MDJFN0JMLCAweDZDRkJBRDc4TCwgMHg3RkFCNUU4Q0wsIDB4OERDMEREOEZM LA0KICAgIDB4RTMzMEE4MUFMLCAweDExNUIyQjE5TCwgMHgwMjBCRDhFREwsIDB4RjA2MDVC RUVMLA0KICAgIDB4MjRBQTNGMDVMLCAweEQ2QzFCQzA2TCwgMHhDNTkxNEZGMkwsIDB4MzdG QUNDRjFMLA0KICAgIDB4NjlFOUYwRDVMLCAweDlCODI3M0Q2TCwgMHg4OEQyODAyMkwsIDB4 N0FCOTAzMjFMLA0KICAgIDB4QUU3MzY3Q0FMLCAweDVDMThFNEM5TCwgMHg0RjQ4MTczREws IDB4QkQyMzk0M0VMLA0KICAgIDB4RjM2RTZGNzVMLCAweDAxMDVFQzc2TCwgMHgxMjU1MUY4 MkwsIDB4RTAzRTlDODFMLA0KICAgIDB4MzRGNEY4NkFMLCAweEM2OUY3QjY5TCwgMHhENUNG ODg5REwsIDB4MjdBNDBCOUVMLA0KICAgIDB4NzlCNzM3QkFMLCAweDhCRENCNEI5TCwgMHg5 ODhDNDc0REwsIDB4NkFFN0M0NEVMLA0KICAgIDB4QkUyREEwQTVMLCAweDRDNDYyM0E2TCwg MHg1RjE2RDA1MkwsIDB4QUQ3RDUzNTFMDQp9Ow0KDQojZGVmaW5lIENSQzMyQ19QUkVMT0FE IDB4ZmZmZmZmZmYNCg0Kc3RhdGljIGd1aW50MzINCmNhbGN1bGF0ZUNSQzMyKGNvbnN0IHZv aWQgKmJ1ZiwgaW50IGxlbiwgZ3VpbnQzMiBjcmMpIHsNCiAgICBndWludDggKnAgPSAoZ3Vp bnQ4ICopYnVmOw0KICAgIHdoaWxlKGxlbi0tID4gMCkNCiAgICAgICAgY3JjID0gY3JjMzJU YWJsZVsoY3JjIF4gKnArKykgJiAweGZmXSBeIChjcmMgPj4gOCk7DQogICAgcmV0dXJuIGNy YzsNCn0NCg0Kc3RhdGljIGludA0KaXNjc2lfbWluKGludCBhLCBpbnQgYikgew0KICAgIHJl dHVybiAoYSA8IGIpPyBhIDogYjsNCn0NCg0Kc3RhdGljIGdpbnQNCmFkZFRleHRLZXlzKHBy b3RvX3RyZWUgKnR0LCB0dmJ1ZmZfdCAqdHZiLCBnaW50IG9mZnNldCwgZ3VpbnQzMiB0ZXh0 X2xlbikgew0KICAgIGNvbnN0IGdpbnQgbGltaXQgPSBvZmZzZXQgKyB0ZXh0X2xlbjsNCiAg ICB3aGlsZShvZmZzZXQgPCBsaW1pdCkgew0KCWdpbnQgbGVuID0gdHZiX3N0cm5sZW4odHZi LCBvZmZzZXQsIGxpbWl0IC0gb2Zmc2V0KTsNCglpZihsZW4gPT0gLTEpDQoJICAgIGxlbiA9 IGxpbWl0IC0gb2Zmc2V0Ow0KCWVsc2UNCgkgICAgbGVuID0gbGVuICsgMTsNCglwcm90b190 cmVlX2FkZF9pdGVtKHR0LCBoZl9pc2NzaV9LZXlWYWx1ZSwgdHZiLCBvZmZzZXQsIGxlbiwg RkFMU0UpOw0KCW9mZnNldCArPSBsZW47DQogICAgfQ0KICAgIHJldHVybiBvZmZzZXQ7DQp9 DQoNCnN0YXRpYyBnaW50DQpoYW5kbGVIZWFkZXJEaWdlc3QocHJvdG9faXRlbSAqdGksIHR2 YnVmZl90ICp0dmIsIGd1aW50IG9mZnNldCwgaW50IGhlYWRlckxlbikgew0KICAgIGludCBh dmFpbGFibGVfYnl0ZXMgPSB0dmJfbGVuZ3RoX3JlbWFpbmluZyh0dmIsIG9mZnNldCk7DQog ICAgaWYoZW5hYmxlSGVhZGVyRGlnZXN0cykgew0KCWlmKGhlYWRlckRpZ2VzdElzQ1JDMzIp IHsNCgkgICAgaWYoYXZhaWxhYmxlX2J5dGVzID49IChoZWFkZXJMZW4gKyA0KSkgew0KCQln dWludDMyIGNyYyA9IH5jYWxjdWxhdGVDUkMzMih0dmJfZ2V0X3B0cih0dmIsIG9mZnNldCwg aGVhZGVyTGVuKSwgaGVhZGVyTGVuLCBDUkMzMkNfUFJFTE9BRCk7DQoJCWd1aW50MzIgc2Vu dCA9IHR2Yl9nZXRfbnRvaGwodHZiLCBvZmZzZXQgKyBoZWFkZXJMZW4pOw0KCQlpZihjcmMg PT0gc2VudCkgew0KCQkgICAgcHJvdG9fdHJlZV9hZGRfdWludF9mb3JtYXQodGksIGhmX2lz Y3NpX0hlYWRlckRpZ2VzdDMyLCB0dmIsIG9mZnNldCArIGhlYWRlckxlbiwgNCwgc2VudCwg IkhlYWRlckRpZ2VzdDogMHglMDh4IChHb29kIENSQzMyKSIsIHNlbnQpOw0KCQl9DQoJCWVs c2Ugew0KCQkgICAgcHJvdG9fdHJlZV9hZGRfdWludF9mb3JtYXQodGksIGhmX2lzY3NpX0hl YWRlckRpZ2VzdDMyLCB0dmIsIG9mZnNldCArIGhlYWRlckxlbiwgNCwgc2VudCwgIkhlYWRl ckRpZ2VzdDogMHglMDh4IChCYWQgQ1JDMzIpIiwgc2VudCk7DQoJCX0NCgkgICAgfQ0KCSAg ICByZXR1cm4gb2Zmc2V0ICsgaGVhZGVyTGVuICsgNDsNCgl9DQoJaWYoYXZhaWxhYmxlX2J5 dGVzID49IChoZWFkZXJMZW4gKyBoZWFkZXJEaWdlc3RTaXplKSkgew0KCSAgICBwcm90b190 cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9IZWFkZXJEaWdlc3QsIHR2Yiwgb2Zmc2V0ICsg aGVhZGVyTGVuLCBoZWFkZXJEaWdlc3RTaXplLCBGQUxTRSk7DQoJfQ0KCXJldHVybiBvZmZz ZXQgKyBoZWFkZXJMZW4gKyBoZWFkZXJEaWdlc3RTaXplOw0KICAgIH0NCiAgICByZXR1cm4g b2Zmc2V0ICsgaGVhZGVyTGVuOw0KfQ0KDQpzdGF0aWMgZ2ludA0KaGFuZGxlRGF0YURpZ2Vz dChwcm90b19pdGVtICp0aSwgdHZidWZmX3QgKnR2YiwgZ3VpbnQgb2Zmc2V0LCBpbnQgZGF0 YUxlbikgew0KICAgIGludCBhdmFpbGFibGVfYnl0ZXMgPSB0dmJfbGVuZ3RoX3JlbWFpbmlu Zyh0dmIsIG9mZnNldCk7DQogICAgaWYoZW5hYmxlRGF0YURpZ2VzdHMpIHsNCglpZihkYXRh RGlnZXN0SXNDUkMzMikgew0KCSAgICBpZihhdmFpbGFibGVfYnl0ZXMgPj0gKGRhdGFMZW4g KyA0KSkgew0KCQlndWludDMyIGNyYyA9IH5jYWxjdWxhdGVDUkMzMih0dmJfZ2V0X3B0cih0 dmIsIG9mZnNldCwgZGF0YUxlbiksIGRhdGFMZW4sIENSQzMyQ19QUkVMT0FEKTsNCgkJZ3Vp bnQzMiBzZW50ID0gdHZiX2dldF9udG9obCh0dmIsIG9mZnNldCArIGRhdGFMZW4pOw0KCQlp ZihjcmMgPT0gc2VudCkgew0KCQkgICAgcHJvdG9fdHJlZV9hZGRfdWludF9mb3JtYXQodGks IGhmX2lzY3NpX0RhdGFEaWdlc3QzMiwgdHZiLCBvZmZzZXQgKyBkYXRhTGVuLCA0LCBzZW50 LCAiRGF0YURpZ2VzdDogMHglMDh4IChHb29kIENSQzMyKSIsIHNlbnQpOw0KCQl9DQoJCWVs c2Ugew0KCQkgICAgcHJvdG9fdHJlZV9hZGRfdWludF9mb3JtYXQodGksIGhmX2lzY3NpX0Rh dGFEaWdlc3QzMiwgdHZiLCBvZmZzZXQgKyBkYXRhTGVuLCA0LCBzZW50LCAiRGF0YURpZ2Vz dDogMHglMDh4IChCYWQgQ1JDMzIpIiwgc2VudCk7DQoJCX0NCgkgICAgfQ0KCSAgICByZXR1 cm4gb2Zmc2V0ICsgZGF0YUxlbiArIDQ7DQoJfQ0KCWlmKGF2YWlsYWJsZV9ieXRlcyA+PSAo ZGF0YUxlbiArIGRhdGFEaWdlc3RTaXplKSkgew0KCSAgICBwcm90b190cmVlX2FkZF9pdGVt KHRpLCBoZl9pc2NzaV9EYXRhRGlnZXN0LCB0dmIsIG9mZnNldCArIGRhdGFMZW4sIGRhdGFE aWdlc3RTaXplLCBGQUxTRSk7DQoJfQ0KCXJldHVybiBvZmZzZXQgKyBkYXRhTGVuICsgZGF0 YURpZ2VzdFNpemU7DQogICAgfQ0KICAgIHJldHVybiBvZmZzZXQgKyBkYXRhTGVuOw0KfQ0K DQpzdGF0aWMgaW50DQpoYW5kbGVEYXRhU2VnbWVudChwcm90b19pdGVtICp0aSwgdHZidWZm X3QgKnR2YiwgZ3VpbnQgb2Zmc2V0LCBndWludCBkYXRhU2VnbWVudExlbiwgZ3VpbnQgZW5k T2Zmc2V0LCBpbnQgaGZfaWQpIHsNCiAgICBpZihlbmRPZmZzZXQgPiBvZmZzZXQpIHsNCglp bnQgZGF0YU9mZnNldCA9IG9mZnNldDsNCglpbnQgZGF0YUxlbiA9IGlzY3NpX21pbihkYXRh U2VnbWVudExlbiwgZW5kT2Zmc2V0IC0gb2Zmc2V0KTsNCglpZihkYXRhTGVuID4gMCkgew0K CSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pZCwgdHZiLCBvZmZzZXQsIGRhdGFM ZW4sIEZBTFNFKTsNCgkgICAgb2Zmc2V0ICs9IGRhdGFMZW47DQoJfQ0KCWlmKG9mZnNldCA8 IGVuZE9mZnNldCAmJiAob2Zmc2V0ICYgMykgIT0gMCkgew0KCSAgICBpbnQgcGFkZGluZyA9 IDQgLSAob2Zmc2V0ICYgMyk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lz Y3NpX1BhZGRpbmcsIHR2Yiwgb2Zmc2V0LCBwYWRkaW5nLCBGQUxTRSk7DQoJICAgIG9mZnNl dCArPSBwYWRkaW5nOw0KCX0NCglpZihkYXRhU2VnbWVudExlbiA+IDAgJiYgb2Zmc2V0IDwg ZW5kT2Zmc2V0KQ0KCSAgICBvZmZzZXQgPSBoYW5kbGVEYXRhRGlnZXN0KHRpLCB0dmIsIGRh dGFPZmZzZXQsIG9mZnNldCAtIGRhdGFPZmZzZXQpOw0KICAgIH0NCg0KICAgIHJldHVybiBv ZmZzZXQ7DQp9DQoNCnN0YXRpYyBpbnQNCmhhbmRsZURhdGFTZWdtZW50QXNUZXh0S2V5cyhw cm90b19pdGVtICp0aSwgdHZidWZmX3QgKnR2YiwgZ3VpbnQgb2Zmc2V0LCBndWludCBkYXRh U2VnbWVudExlbiwgZ3VpbnQgZW5kT2Zmc2V0LCBpbnQgZGlnZXN0c0FjdGl2ZSkgew0KICAg IGlmKGVuZE9mZnNldCA+IG9mZnNldCkgew0KCWludCBkYXRhT2Zmc2V0ID0gb2Zmc2V0Ow0K CWludCB0ZXh0TGVuID0gaXNjc2lfbWluKGRhdGFTZWdtZW50TGVuLCBlbmRPZmZzZXQgLSBv ZmZzZXQpOw0KCWlmKHRleHRMZW4gPiAwKSB7DQoJICAgIHByb3RvX2l0ZW0gKnRmID0gcHJv dG9fdHJlZV9hZGRfdGV4dCh0aSwgdHZiLCBvZmZzZXQsIHRleHRMZW4sICJLZXkvVmFsdWUg UGFpcnMiKTsNCgkgICAgcHJvdG9fdHJlZSAqdHQgPSBwcm90b19pdGVtX2FkZF9zdWJ0cmVl KHRmLCBldHRfaXNjc2lfS2V5VmFsdWVzKTsNCgkgICAgb2Zmc2V0ID0gYWRkVGV4dEtleXMo dHQsIHR2Yiwgb2Zmc2V0LCB0ZXh0TGVuKTsNCgl9DQoJaWYob2Zmc2V0IDwgZW5kT2Zmc2V0 ICYmIChvZmZzZXQgJiAzKSAhPSAwKSB7DQoJICAgIGludCBwYWRkaW5nID0gNCAtIChvZmZz ZXQgJiAzKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfUGFkZGlu ZywgdHZiLCBvZmZzZXQsIHBhZGRpbmcsIEZBTFNFKTsNCgkgICAgb2Zmc2V0ICs9IHBhZGRp bmc7DQoJfQ0KCWlmKGRpZ2VzdHNBY3RpdmUgJiYgZGF0YVNlZ21lbnRMZW4gPiAwICYmIG9m ZnNldCA8IGVuZE9mZnNldCkNCgkgICAgb2Zmc2V0ID0gaGFuZGxlRGF0YURpZ2VzdCh0aSwg dHZiLCBkYXRhT2Zmc2V0LCBvZmZzZXQgLSBkYXRhT2Zmc2V0KTsNCiAgICB9DQogICAgcmV0 dXJuIG9mZnNldDsNCn0NCg0KLyogQ29kZSB0byBhY3R1YWxseSBkaXNzZWN0IHRoZSBwYWNr ZXRzICovDQpzdGF0aWMgdm9pZA0KZGlzc2VjdF9pc2NzaV9wZHUodHZidWZmX3QgKnR2Yiwg cGFja2V0X2luZm8gKnBpbmZvLCBwcm90b190cmVlICp0cmVlLCBndWludCBvZmZzZXQsIGd1 aW50OCBvcGNvZGUsIGNvbnN0IGNoYXIgKm9wY29kZV9zdHIsIGd1aW50MzIgZGF0YV9zZWdt ZW50X2xlbikgew0KICAgIGd1aW50IG9yaWdpbmFsX29mZnNldCA9IG9mZnNldDsNCiAgICBw cm90b19pdGVtICp0aTsNCiAgICBjaGFyICpzY3NpX2NvbW1hbmRfbmFtZSA9IE5VTEw7DQog ICAgZ3VpbnQgY2RiX29mZnNldCA9IG9mZnNldCArIDMyOyAvKiBvZmZzZXQgb2YgQ0RCIGZy b20gc3RhcnQgb2YgUERVICovDQogICAgZ3VpbnQgZW5kX29mZnNldCA9IG9mZnNldCArIHR2 Yl9sZW5ndGhfcmVtYWluaW5nKHR2Yiwgb2Zmc2V0KTsNCg0KICAgIC8qIE1ha2UgZW50cmll cyBpbiBQcm90b2NvbCBjb2x1bW4gYW5kIEluZm8gY29sdW1uIG9uIHN1bW1hcnkgZGlzcGxh eSAqLw0KICAgIGlmIChjaGVja19jb2wocGluZm8tPmZkLCBDT0xfUFJPVE9DT0wpKQ0KCWNv bF9zZXRfc3RyKHBpbmZvLT5mZCwgQ09MX1BST1RPQ09MLCAiaVNDU0kiKTsNCg0KICAgIGlm IChjaGVja19jb2wocGluZm8tPmZkLCBDT0xfSU5GTykpIHsNCg0KCWNvbF9hZGRfc3RyKHBp bmZvLT5mZCwgQ09MX0lORk8sIChjaGFyICopb3Bjb2RlX3N0cik7DQoNCglpZigob3Bjb2Rl ICYgfihYX0JJVCB8IElfQklUKSkgPT0gSVNDU0lfT1BDT0RFX1NDU0lfQ09NTUFORCkgew0K CSAgICAvKiBTQ1NJIENvbW1hbmQgKi8NCgkgICAgZ3VpbnQ4IGNkYjAgPSB0dmJfZ2V0X2d1 aW50OCh0dmIsIGNkYl9vZmZzZXQpOw0KCSAgICBzY3NpX2NvbW1hbmRfbmFtZSA9IG1hdGNo X3N0cnZhbChjZGIwLCBpc2NzaV9zY3NpX2NkYjApOw0KCSAgICBpZihjZGIwID09IDB4MDgg fHwgY2RiMCA9PSAweDBhKSB7DQoJCS8qIFJFQURfNiBhbmQgV1JJVEVfNiAqLw0KCQlndWlu dCBsYmEgPSB0dmJfZ2V0X250b2hsKHR2YiwgY2RiX29mZnNldCkgJiAweDFmZmZmZjsNCgkJ Z3VpbnQgbGVuID0gdHZiX2dldF9ndWludDgodHZiLCBjZGJfb2Zmc2V0ICsgNCk7DQoJCWNv bF9hcHBlbmRfZnN0cihwaW5mby0+ZmQsIENPTF9JTkZPLCAiICglcyBMQkEgMHglMDZ4IGxl biAweCUwMngpIiwgc2NzaV9jb21tYW5kX25hbWUsIGxiYSwgbGVuKTsNCgkgICAgfQ0KCSAg ICBlbHNlIGlmKGNkYjAgPT0gMHgyOCB8fCBjZGIwID09IDB4MmEpIHsNCgkJLyogUkVBRF8x MCBhbmQgV1JJVEVfMTAgKi8NCgkJZ3VpbnQgbGJhID0gdHZiX2dldF9udG9obCh0dmIsIGNk Yl9vZmZzZXQgKyAyKTsNCgkJZ3VpbnQgbGVuID0gdHZiX2dldF9udG9ocyh0dmIsIGNkYl9v ZmZzZXQgKyA3KTsNCgkJY29sX2FwcGVuZF9mc3RyKHBpbmZvLT5mZCwgQ09MX0lORk8sICIg KCVzIExCQSAweCUwOHggbGVuIDB4JTA0eCkiLCBzY3NpX2NvbW1hbmRfbmFtZSwgbGJhLCBs ZW4pOw0KCSAgICB9DQoJICAgIGVsc2UgaWYoc2NzaV9jb21tYW5kX25hbWUgIT0gTlVMTCkN CgkJY29sX2FwcGVuZF9mc3RyKHBpbmZvLT5mZCwgQ09MX0lORk8sICIgKCVzKSIsIHNjc2lf Y29tbWFuZF9uYW1lKTsNCgl9DQoJZWxzZSBpZihvcGNvZGUgPT0gSVNDU0lfT1BDT0RFX1ND U0lfUkVTUE9OU0UpIHsNCgkgICAgLyogU0NTSSBDb21tYW5kIFJlc3BvbnNlICovDQoJICAg IGNvbnN0IGNoYXIgKmJsdXJiID0gTlVMTDsNCgkgICAgLyogbG9vayBhdCByZXNwb25zZSBi eXRlICovDQoJICAgIGlmKHR2Yl9nZXRfZ3VpbnQ4KHR2Yiwgb2Zmc2V0ICsgMikgPT0gMCkg ew0KCQkvKiBjb21tYW5kIGNvbXBsZXRlZCBhdCB0YXJnZXQgKi8NCgkJYmx1cmIgPSBtYXRj aF9zdHJ2YWwodHZiX2dldF9ndWludDgodHZiLCBvZmZzZXQgKyAzKSA+PiAxLCBpc2NzaV9z Y3NpX3N0YXR1c2VzKTsNCgkgICAgfQ0KCSAgICBlbHNlDQoJCWJsdXJiID0gIlRhcmdldCBG YWlsdXJlIjsNCgkgICAgaWYoYmx1cmIgIT0gTlVMTCkNCgkJY29sX2FwcGVuZF9mc3RyKHBp bmZvLT5mZCwgQ09MX0lORk8sICIgKCVzKSIsIGJsdXJiKTsNCgl9DQogICAgfQ0KDQogICAg LyogSW4gdGhlIGludGVyZXN0IG9mIHNwZWVkLCBpZiAidHJlZSIgaXMgTlVMTCwgZG9uJ3Qg ZG8gYW55DQogICAgICAgd29yayBub3QgbmVjZXNzYXJ5IHRvIGdlbmVyYXRlIHByb3RvY29s IHRyZWUgaXRlbXMuICovDQogICAgaWYgKHRyZWUpIHsNCg0KCS8qIGNyZWF0ZSBkaXNwbGF5 IHN1YnRyZWUgZm9yIHRoZSBwcm90b2NvbCAqLw0KCXRpID0gcHJvdG9fdHJlZV9hZGRfcHJv dG9jb2xfZm9ybWF0KHRyZWUsIHByb3RvX2lzY3NpLCB0dmIsDQoJCQkJCSAgICBvZmZzZXQs IDAsICJpU0NTSSAoJXMpIiwNCgkJCQkJICAgIChjaGFyICopb3Bjb2RlX3N0cik7DQoNCglw cm90b190cmVlX2FkZF91aW50KHRpLCBoZl9pc2NzaV9PcGNvZGUsIHR2YiwNCgkJCSAgICBv ZmZzZXQgKyAwLCAxLCBvcGNvZGUpOw0KCWlmKChvcGNvZGUgJiBUQVJHRVRfT1BDT0RFX0JJ VCkgPT0gMCkgew0KCSAgICAvKiBpbml0aWF0b3IgLT4gdGFyZ2V0ICovDQoJICAgIGdpbnQg YiA9IHR2Yl9nZXRfZ3VpbnQ4KHR2Yiwgb2Zmc2V0ICsgMCk7DQoJICAgIGlmKG9wY29kZSAh PSBJU0NTSV9PUENPREVfU0NTSV9EQVRBX09VVCAmJg0KCSAgICAgICBvcGNvZGUgIT0gSVND U0lfT1BDT0RFX0xPR09VVF9DT01NQU5EICYmDQoJICAgICAgIG9wY29kZSAhPSBJU0NTSV9P UENPREVfU05BQ0tfUkVRVUVTVCkNCgkJcHJvdG9fdHJlZV9hZGRfYm9vbGVhbih0aSwgaGZf aXNjc2lfWCwgdHZiLCBvZmZzZXQgKyAwLCAxLCBiKTsNCgkgICAgaWYob3Bjb2RlICE9IElT Q1NJX09QQ09ERV9TQ1NJX0RBVEFfT1VUKQ0KCQlwcm90b190cmVlX2FkZF9ib29sZWFuKHRp LCBoZl9pc2NzaV9JLCB0dmIsIG9mZnNldCArIDAsIDEsIGIpOw0KCX0NCg0KCWlmKG9wY29k ZSA9PSBJU0NTSV9PUENPREVfTk9QX09VVCkgew0KCSAgICAvKiBOT1AgT3V0ICovDQoJICAg IHByb3RvX3RyZWVfYWRkX3VpbnQodGksIGhmX2lzY3NpX0RhdGFTZWdtZW50TGVuZ3RoLCB0 dmIsIG9mZnNldCArIDUsIDMsIGRhdGFfc2VnbWVudF9sZW4pOw0KCSAgICBwcm90b190cmVl X2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9MVU4sIHR2Yiwgb2Zmc2V0ICsgOCwgOCwgRkFMU0Up Ow0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9Jbml0aWF0b3JUYXNr VGFnLCB0dmIsIG9mZnNldCArIDE2LCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRk X2l0ZW0odGksIGhmX2lzY3NpX1RhcmdldFRyYW5zZmVyVGFnLCB0dmIsIG9mZnNldCArIDIw LCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0Nt ZFNOLCB0dmIsIG9mZnNldCArIDI0LCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRk X2l0ZW0odGksIGhmX2lzY3NpX0V4cFN0YXRTTiwgdHZiLCBvZmZzZXQgKyAyOCwgNCwgRkFM U0UpOw0KCSAgICBvZmZzZXQgPSBoYW5kbGVIZWFkZXJEaWdlc3QodGksIHR2Yiwgb2Zmc2V0 LCA0OCk7DQoJICAgIG9mZnNldCA9IGhhbmRsZURhdGFTZWdtZW50KHRpLCB0dmIsIG9mZnNl dCwgZGF0YV9zZWdtZW50X2xlbiwgZW5kX29mZnNldCwgaGZfaXNjc2lfcGluZ19kYXRhKTsN Cgl9DQoJZWxzZSBpZihvcGNvZGUgPT0gSVNDU0lfT1BDT0RFX05PUF9JTikgew0KCSAgICAv KiBOT1AgSW4gKi8NCgkgICAgcHJvdG9fdHJlZV9hZGRfdWludCh0aSwgaGZfaXNjc2lfRGF0 YVNlZ21lbnRMZW5ndGgsIHR2Yiwgb2Zmc2V0ICsgNSwgMywgZGF0YV9zZWdtZW50X2xlbik7 DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0xVTiwgdHZiLCBvZmZz ZXQgKyA4LCA4LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lz Y3NpX0luaXRpYXRvclRhc2tUYWcsIHR2Yiwgb2Zmc2V0ICsgMTYsIDQsIEZBTFNFKTsNCgkg ICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfVGFyZ2V0VHJhbnNmZXJUYWcs IHR2Yiwgb2Zmc2V0ICsgMjAsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRl bSh0aSwgaGZfaXNjc2lfU3RhdFNOLCB0dmIsIG9mZnNldCArIDI0LCA0LCBGQUxTRSk7DQoJ ICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0V4cENtZFNOLCB0dmIsIG9m ZnNldCArIDI4LCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhm X2lzY3NpX01heENtZFNOLCB0dmIsIG9mZnNldCArIDMyLCA0LCBGQUxTRSk7DQoJICAgIG9m ZnNldCA9IGhhbmRsZUhlYWRlckRpZ2VzdCh0aSwgdHZiLCBvZmZzZXQsIDQ4KTsNCgkgICAg b2Zmc2V0ID0gaGFuZGxlRGF0YVNlZ21lbnQodGksIHR2Yiwgb2Zmc2V0LCBkYXRhX3NlZ21l bnRfbGVuLCBlbmRfb2Zmc2V0LCBoZl9pc2NzaV9waW5nX2RhdGEpOw0KCX0NCgllbHNlIGlm KG9wY29kZSA9PSBJU0NTSV9PUENPREVfU0NTSV9DT01NQU5EKSB7DQoJICAgIC8qIFNDU0kg Q29tbWFuZCAqLw0KCSAgICBndWludDMyIGFoc0xlbiA9IHR2Yl9nZXRfZ3VpbnQ4KHR2Yiwg b2Zmc2V0ICsgNCkgKiA0Ow0KCSAgICB7DQoJCWdpbnQgYiA9IHR2Yl9nZXRfZ3VpbnQ4KHR2 Yiwgb2Zmc2V0ICsgMSk7DQoJCXByb3RvX2l0ZW0gKnRmID0gcHJvdG9fdHJlZV9hZGRfdWlu dCh0aSwgaGZfaXNjc2lfRmxhZ3MsIHR2Yiwgb2Zmc2V0ICsgMSwgMSwgYik7DQoJCXByb3Rv X3RyZWUgKnR0ID0gcHJvdG9faXRlbV9hZGRfc3VidHJlZSh0ZiwgZXR0X2lzY3NpX0ZsYWdz KTsNCgkJDQoJCXByb3RvX3RyZWVfYWRkX2Jvb2xlYW4odHQsIGhmX2lzY3NpX1NDU0lDb21t YW5kX0YsIHR2Yiwgb2Zmc2V0ICsgMSwgMSwgYik7DQoJCXByb3RvX3RyZWVfYWRkX2Jvb2xl YW4odHQsIGhmX2lzY3NpX1NDU0lDb21tYW5kX1IsIHR2Yiwgb2Zmc2V0ICsgMSwgMSwgYik7 DQoJCXByb3RvX3RyZWVfYWRkX2Jvb2xlYW4odHQsIGhmX2lzY3NpX1NDU0lDb21tYW5kX1cs IHR2Yiwgb2Zmc2V0ICsgMSwgMSwgYik7DQoJCXByb3RvX3RyZWVfYWRkX3VpbnQodHQsIGhm X2lzY3NpX1NDU0lDb21tYW5kX0F0dHIsIHR2Yiwgb2Zmc2V0ICsgMSwgMSwgYik7DQoJICAg IH0NCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfU0NTSUNvbW1hbmRf Q1JOLCB0dmIsIG9mZnNldCArIDMsIDEsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRf aXRlbSh0aSwgaGZfaXNjc2lfVG90YWxBSFNMZW5ndGgsIHR2Yiwgb2Zmc2V0ICsgNCwgMSwg RkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF91aW50KHRpLCBoZl9pc2NzaV9EYXRhU2Vn bWVudExlbmd0aCwgdHZiLCBvZmZzZXQgKyA1LCAzLCBkYXRhX3NlZ21lbnRfbGVuKTsNCgkg ICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfTFVOLCB0dmIsIG9mZnNldCAr IDgsIDgsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lf SW5pdGlhdG9yVGFza1RhZywgdHZiLCBvZmZzZXQgKyAxNiwgNCwgRkFMU0UpOw0KCSAgICBw cm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9FeHBlY3RlZERhdGFUcmFuc2Zlckxl bmd0aCwgdHZiLCBvZmZzZXQgKyAyMCwgNCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2Fk ZF9pdGVtKHRpLCBoZl9pc2NzaV9DbWRTTiwgdHZiLCBvZmZzZXQgKyAyNCwgNCwgRkFMU0Up Ow0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9FeHBTdGF0U04sIHR2 Yiwgb2Zmc2V0ICsgMjgsIDQsIEZBTFNFKTsNCgkgICAgew0KCQkvKiBkaXNzZWN0IGEgbGl0 dGxlIG9mIHRoZSBDREIgZm9yIHRoZSBtb3N0IGNvbW1vbg0KCQkgKiBjb21tYW5kcyAqLw0K CQlndWludDggY2RiMCA9IHR2Yl9nZXRfZ3VpbnQ4KHR2YiwgY2RiX29mZnNldCk7DQoJCWdp bnQgY2RiX2xlbiA9IDE2Ow0KCQlwcm90b19pdGVtICp0ZjsNCgkJLyogRklYTUUgLSBleHRl bmRlZCBDREIgKi8NCgkJaWYoc2NzaV9jb21tYW5kX25hbWUgPT0gTlVMTCkNCgkJICAgIHNj c2lfY29tbWFuZF9uYW1lID0gbWF0Y2hfc3RydmFsKGNkYjAsIGlzY3NpX3Njc2lfY2RiMCk7 DQoJCWlmKGNkYjAgPT0gMHgwOCB8fCBjZGIwID09IDB4MGEpIHsNCgkJICAgIC8qIFJFQURf NiBhbmQgV1JJVEVfNiAqLw0KCQkgICAgZ3VpbnQgbGJhID0gdHZiX2dldF9udG9obCh0dmIs IGNkYl9vZmZzZXQpICYgMHgxZmZmZmY7DQoJCSAgICBndWludCBsZW4gPSB0dmJfZ2V0X2d1 aW50OCh0dmIsIGNkYl9vZmZzZXQgKyA0KTsNCgkJICAgIHRmID0gcHJvdG9fdHJlZV9hZGRf dWludF9mb3JtYXQodGksIGhmX2lzY3NpX1NDU0lDb21tYW5kX0NEQjAsIHR2YiwgY2RiX29m ZnNldCwgY2RiX2xlbiwgY2RiMCwgIkNEQjogJXMgTEJBIDB4JTA2eCBsZW4gMHglMDJ4Iiwg c2NzaV9jb21tYW5kX25hbWUsIGxiYSwgbGVuKTsNCgkJfQ0KCQllbHNlIGlmKGNkYjAgPT0g MHgyOCB8fCBjZGIwID09IDB4MmEpIHsNCgkJICAgIC8qIFJFQURfMTAgYW5kIFdSSVRFXzEw ICovDQoJCSAgICBndWludCBsYmEgPSB0dmJfZ2V0X250b2hsKHR2YiwgY2RiX29mZnNldCAr IDIpOw0KCQkgICAgZ3VpbnQgbGVuID0gdHZiX2dldF9udG9ocyh0dmIsIGNkYl9vZmZzZXQg KyA3KTsNCgkJICAgIHRmID0gcHJvdG9fdHJlZV9hZGRfdWludF9mb3JtYXQodGksIGhmX2lz Y3NpX1NDU0lDb21tYW5kX0NEQjAsIHR2YiwgY2RiX29mZnNldCwgY2RiX2xlbiwgY2RiMCwg IkNEQjogJXMgTEJBIDB4JTA4eCBsZW4gMHglMDR4Iiwgc2NzaV9jb21tYW5kX25hbWUsIGxi YSwgbGVuKTsNCgkJfQ0KCQllbHNlDQoJCSAgICB0ZiA9IHByb3RvX3RyZWVfYWRkX3VpbnQo dGksIGhmX2lzY3NpX1NDU0lDb21tYW5kX0NEQjAsIHR2YiwgY2RiX29mZnNldCwgY2RiX2xl biwgY2RiMCk7DQoJCXsNCgkJICAgIHByb3RvX3RyZWUgKnR0ID0gcHJvdG9faXRlbV9hZGRf c3VidHJlZSh0ZiwgZXR0X2lzY3NpX0NEQik7DQoJCSAgICBwcm90b190cmVlX2FkZF9pdGVt KHR0LCBoZl9pc2NzaV9TQ1NJQ29tbWFuZF9DREIsIHR2YiwgY2RiX29mZnNldCwgY2RiX2xl biwgRkFMU0UpOw0KCQl9DQoJCWlmKGFoc0xlbiA+IDApIHsNCgkJICAgIC8qIEZJWE1FIC0g ZGlzc3NlY3QgQUhTPyAqLw0KCQkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNj c2lfQUhTLCB0dmIsIG9mZnNldCArIDQ4LCBhaHNMZW4sIEZBTFNFKTsNCgkJfQ0KCQlvZmZz ZXQgPSBoYW5kbGVIZWFkZXJEaWdlc3QodGksIHR2Yiwgb2Zmc2V0LCA0OCArIGFoc0xlbik7 DQoJICAgIH0NCgkgICAgb2Zmc2V0ID0gaGFuZGxlRGF0YVNlZ21lbnQodGksIHR2Yiwgb2Zm c2V0LCBkYXRhX3NlZ21lbnRfbGVuLCBlbmRfb2Zmc2V0LCBoZl9pc2NzaV9pbW1lZGlhdGVf ZGF0YSk7DQoJfQ0KCWVsc2UgaWYob3Bjb2RlID09IElTQ1NJX09QQ09ERV9TQ1NJX1JFU1BP TlNFKSB7DQoJICAgIC8qIFNDU0kgUmVzcG9uc2UgKi8NCgkgICAgew0KCQlnaW50IGIgPSB0 dmJfZ2V0X2d1aW50OCh0dmIsIG9mZnNldCArIDEpOw0KCQlwcm90b19pdGVtICp0ZiA9IHBy b3RvX3RyZWVfYWRkX3VpbnQodGksIGhmX2lzY3NpX0ZsYWdzLCB0dmIsIG9mZnNldCArIDEs IDEsIGIpOw0KCQlwcm90b190cmVlICp0dCA9IHByb3RvX2l0ZW1fYWRkX3N1YnRyZWUodGYs IGV0dF9pc2NzaV9GbGFncyk7DQoJCQ0KCQlwcm90b190cmVlX2FkZF9ib29sZWFuKHR0LCBo Zl9pc2NzaV9TQ1NJUmVzcG9uc2VfbywgdHZiLCBvZmZzZXQgKyAxLCAxLCBiKTsNCgkJcHJv dG9fdHJlZV9hZGRfYm9vbGVhbih0dCwgaGZfaXNjc2lfU0NTSVJlc3BvbnNlX3UsIHR2Yiwg b2Zmc2V0ICsgMSwgMSwgYik7DQoJCXByb3RvX3RyZWVfYWRkX2Jvb2xlYW4odHQsIGhmX2lz Y3NpX1NDU0lSZXNwb25zZV9PLCB0dmIsIG9mZnNldCArIDEsIDEsIGIpOw0KCQlwcm90b190 cmVlX2FkZF9ib29sZWFuKHR0LCBoZl9pc2NzaV9TQ1NJUmVzcG9uc2VfVSwgdHZiLCBvZmZz ZXQgKyAxLCAxLCBiKTsNCgkgICAgfQ0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBo Zl9pc2NzaV9TQ1NJUmVzcG9uc2VfUmVzcG9uc2UsIHR2Yiwgb2Zmc2V0ICsgMiwgMSwgRkFM U0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9TQ1NJUmVzcG9u c2VfU3RhdHVzLCB0dmIsIG9mZnNldCArIDMsIDEsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJl ZV9hZGRfdWludCh0aSwgaGZfaXNjc2lfRGF0YVNlZ21lbnRMZW5ndGgsIHR2Yiwgb2Zmc2V0 ICsgNSwgMywgZGF0YV9zZWdtZW50X2xlbik7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0o dGksIGhmX2lzY3NpX0luaXRpYXRvclRhc2tUYWcsIHR2Yiwgb2Zmc2V0ICsgMTYsIDQsIEZB TFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfU0NTSVJlc3Bv bnNlX1Jlc2lkdWFsQ291bnQsIHR2Yiwgb2Zmc2V0ICsgMjAsIDQsIEZBTFNFKTsNCgkgICAg cHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfU3RhdFNOLCB0dmIsIG9mZnNldCAr IDI0LCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3Np X0V4cENtZFNOLCB0dmIsIG9mZnNldCArIDI4LCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3Ry ZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX01heENtZFNOLCB0dmIsIG9mZnNldCArIDMyLCA0 LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0V4cERh dGFTTiwgdHZiLCBvZmZzZXQgKyAzNiwgNCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2Fk ZF9pdGVtKHRpLCBoZl9pc2NzaV9TQ1NJUmVzcG9uc2VfQmlkaVJlYWRSZXNpZHVhbENvdW50 LCB0dmIsIG9mZnNldCArIDQ0LCA0LCBGQUxTRSk7DQoJICAgIG9mZnNldCA9IGhhbmRsZUhl YWRlckRpZ2VzdCh0aSwgdHZiLCBvZmZzZXQsIDQ4KTsNCgkgICAgb2Zmc2V0ID0gaGFuZGxl RGF0YVNlZ21lbnQodGksIHR2Yiwgb2Zmc2V0LCBkYXRhX3NlZ21lbnRfbGVuLCBlbmRfb2Zm c2V0LCBoZl9pc2NzaV9zZW5zZV9kYXRhKTsNCgl9DQoJZWxzZSBpZihvcGNvZGUgPT0gSVND U0lfT1BDT0RFX1NDU0lfVEFTS19NQU5BR0VNRU5UX0NPTU1BTkQpIHsNCgkgICAgLyogU0NT SSBUYXNrIENvbW1hbmQgKi8NCiAJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lz Y3NpX1NDU0lUYXNrX0Z1bmN0aW9uLCB0dmIsIG9mZnNldCArIDEsIDEsIEZBTFNFKTsNCgkg ICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfTFVOLCB0dmIsIG9mZnNldCAr IDgsIDgsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lf SW5pdGlhdG9yVGFza1RhZywgdHZiLCBvZmZzZXQgKyAxNiwgNCwgRkFMU0UpOw0KCSAgICBw cm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9TQ1NJVGFza19SZWZlcmVuY2VkVGFz a1RhZywgdHZiLCBvZmZzZXQgKyAyMCwgNCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2Fk ZF9pdGVtKHRpLCBoZl9pc2NzaV9DbWRTTiwgdHZiLCBvZmZzZXQgKyAyNCwgNCwgRkFMU0Up Ow0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9FeHBTdGF0U04sIHR2 Yiwgb2Zmc2V0ICsgMjgsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0 aSwgaGZfaXNjc2lfUmVmQ21kU04sIHR2Yiwgb2Zmc2V0ICsgMzIsIDQsIEZBTFNFKTsNCgkg ICAgb2Zmc2V0ID0gaGFuZGxlSGVhZGVyRGlnZXN0KHRpLCB0dmIsIG9mZnNldCwgNDgpOw0K CX0NCgllbHNlIGlmKG9wY29kZSA9PSBJU0NTSV9PUENPREVfU0NTSV9UQVNLX01BTkFHRU1F TlRfUkVTUE9OU0UpIHsNCgkgICAgLyogU0NTSSBUYXNrIFJlc3BvbnNlICovDQoJICAgIHBy b3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX1NDU0lUYXNrX1Jlc3BvbnNlLCB0dmIs IG9mZnNldCArIDIsIDEsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwg aGZfaXNjc2lfSW5pdGlhdG9yVGFza1RhZywgdHZiLCBvZmZzZXQgKyAxNiwgNCwgRkFMU0Up Ow0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9TQ1NJVGFza19SZWZl cmVuY2VkVGFza1RhZywgdHZiLCBvZmZzZXQgKyAyMCwgNCwgRkFMU0UpOw0KCSAgICBwcm90 b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9TdGF0U04sIHR2Yiwgb2Zmc2V0ICsgMjQs IDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfRXhw Q21kU04sIHR2Yiwgb2Zmc2V0ICsgMjgsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9h ZGRfaXRlbSh0aSwgaGZfaXNjc2lfTWF4Q21kU04sIHR2Yiwgb2Zmc2V0ICsgMzIsIDQsIEZB TFNFKTsNCgkgICAgb2Zmc2V0ID0gaGFuZGxlSGVhZGVyRGlnZXN0KHRpLCB0dmIsIG9mZnNl dCwgNDgpOw0KCX0NCgllbHNlIGlmKG9wY29kZSA9PSBJU0NTSV9PUENPREVfTE9HSU5fQ09N TUFORCkgew0KCSAgICAvKiBMb2dpbiBDb21tYW5kICovDQoJICAgIGludCBkaWdlc3RzQWN0 aXZlID0gMTsNCgkgICAgew0KCQlnaW50IGIgPSB0dmJfZ2V0X2d1aW50OCh0dmIsIG9mZnNl dCArIDEpOw0KCQlpZigoYiAmIENTR19NQVNLKSA9PSAwKSB7DQoJCSAgICAvKiBjdXJyZW50 IHN0YWdlIGlzIFNlY3VyaXR5TmVnb3RpYXRpb24sIGRpZ2VzdHMNCgkJICAgICAqIGFyZSBu b3QgeWV0IHR1cm5lZCBvbiAqLw0KCQkgICAgZGlnZXN0c0FjdGl2ZSA9IDA7DQoJCX0NCiNp ZiAwDQoJCXByb3RvX2l0ZW0gKnRmID0gcHJvdG9fdHJlZV9hZGRfdWludCh0aSwgaGZfaXNj c2lfRmxhZ3MsIHR2Yiwgb2Zmc2V0ICsgMSwgMSwgYik7DQoJCXByb3RvX3RyZWUgKnR0ID0g cHJvdG9faXRlbV9hZGRfc3VidHJlZSh0ZiwgZXR0X2lzY3NpX0ZsYWdzKTsNCiNlbmRpZg0K CQkNCgkJcHJvdG9fdHJlZV9hZGRfYm9vbGVhbih0aSwgaGZfaXNjc2lfTG9naW5fVCwgdHZi LCBvZmZzZXQgKyAxLCAxLCBiKTsNCgkJcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNj c2lfTG9naW5fQ1NHLCB0dmIsIG9mZnNldCArIDEsIDEsIEZBTFNFKTsNCgkJcHJvdG9fdHJl ZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfTG9naW5fTlNHLCB0dmIsIG9mZnNldCArIDEsIDEs IEZBTFNFKTsNCgkgICAgfQ0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2Nz aV9WZXJzaW9uTWF4LCB0dmIsIG9mZnNldCArIDIsIDEsIEZBTFNFKTsNCgkgICAgcHJvdG9f dHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfVmVyc2lvbk1pbiwgdHZiLCBvZmZzZXQgKyAz LCAxLCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX3VpbnQodGksIGhmX2lzY3NpX0Rh dGFTZWdtZW50TGVuZ3RoLCB0dmIsIG9mZnNldCArIDUsIDMsIGRhdGFfc2VnbWVudF9sZW4p Ow0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9DSUQsIHR2Yiwgb2Zm c2V0ICsgOCwgMiwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9p c2NzaV9JU0lELCB0dmIsIG9mZnNldCArIDEyLCAyLCBGQUxTRSk7DQoJICAgIHByb3RvX3Ry ZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX1RTSUQsIHR2Yiwgb2Zmc2V0ICsgMTQsIDIsIEZB TFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfSW5pdGlhdG9y VGFza1RhZywgdHZiLCBvZmZzZXQgKyAxNiwgNCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVl X2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9DbWRTTiwgdHZiLCBvZmZzZXQgKyAyNCwgNCwgRkFM U0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9FeHBTdGF0U04s IHR2Yiwgb2Zmc2V0ICsgMjgsIDQsIEZBTFNFKTsNCgkgICAgaWYoZGlnZXN0c0FjdGl2ZSkN CgkJb2Zmc2V0ID0gaGFuZGxlSGVhZGVyRGlnZXN0KHRpLCB0dmIsIG9mZnNldCwgNDgpOw0K CSAgICBlbHNlDQoJCW9mZnNldCArPSA0ODsNCgkgICAgb2Zmc2V0ID0gaGFuZGxlRGF0YVNl Z21lbnRBc1RleHRLZXlzKHRpLCB0dmIsIG9mZnNldCwgZGF0YV9zZWdtZW50X2xlbiwgZW5k X29mZnNldCwgZGlnZXN0c0FjdGl2ZSk7DQoJfQ0KCWVsc2UgaWYob3Bjb2RlID09IElTQ1NJ X09QQ09ERV9MT0dJTl9SRVNQT05TRSkgew0KCSAgICAvKiBMb2dpbiBSZXNwb25zZSAqLw0K CSAgICBpbnQgZGlnZXN0c0FjdGl2ZSA9IDE7DQoJICAgIHsNCgkJZ2ludCBiID0gdHZiX2dl dF9ndWludDgodHZiLCBvZmZzZXQgKyAxKTsNCgkJaWYoKGIgJiBDU0dfTUFTSykgPT0gMCkg ew0KCQkgICAgLyogY3VycmVudCBzdGFnZSBpcyBTZWN1cml0eU5lZ290aWF0aW9uLCBkaWdl c3RzDQoJCSAgICAgKiBhcmUgbm90IHlldCB0dXJuZWQgb24gKi8NCgkJICAgIGRpZ2VzdHNB Y3RpdmUgPSAwOw0KCQl9DQojaWYgMA0KCQlwcm90b19pdGVtICp0ZiA9IHByb3RvX3RyZWVf YWRkX3VpbnQodGksIGhmX2lzY3NpX0ZsYWdzLCB0dmIsIG9mZnNldCArIDEsIDEsIGIpOw0K CQlwcm90b190cmVlICp0dCA9IHByb3RvX2l0ZW1fYWRkX3N1YnRyZWUodGYsIGV0dF9pc2Nz aV9GbGFncyk7DQojZW5kaWYNCgkJDQoJCXByb3RvX3RyZWVfYWRkX2Jvb2xlYW4odGksIGhm X2lzY3NpX0xvZ2luX1QsIHR2Yiwgb2Zmc2V0ICsgMSwgMSwgYik7DQoJCXByb3RvX3RyZWVf YWRkX2l0ZW0odGksIGhmX2lzY3NpX0xvZ2luX0NTRywgdHZiLCBvZmZzZXQgKyAxLCAxLCBG QUxTRSk7DQoJCXByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0xvZ2luX05TRywg dHZiLCBvZmZzZXQgKyAxLCAxLCBGQUxTRSk7DQoJICAgIH0NCg0KCSAgICBwcm90b190cmVl X2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9WZXJzaW9uTWF4LCB0dmIsIG9mZnNldCArIDIsIDEs IEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfVmVyc2lv bkFjdGl2ZSwgdHZiLCBvZmZzZXQgKyAzLCAxLCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVf YWRkX3VpbnQodGksIGhmX2lzY3NpX0RhdGFTZWdtZW50TGVuZ3RoLCB0dmIsIG9mZnNldCAr IDUsIDMsIGRhdGFfc2VnbWVudF9sZW4pOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRp LCBoZl9pc2NzaV9JU0lELCB0dmIsIG9mZnNldCArIDEyLCAyLCBGQUxTRSk7DQoJICAgIHBy b3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX1RTSUQsIHR2Yiwgb2Zmc2V0ICsgMTQs IDIsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfSW5p dGlhdG9yVGFza1RhZywgdHZiLCBvZmZzZXQgKyAxNiwgNCwgRkFMU0UpOw0KCSAgICBwcm90 b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9TdGF0U04sIHR2Yiwgb2Zmc2V0ICsgMjQs IDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfRXhw Q21kU04sIHR2Yiwgb2Zmc2V0ICsgMjgsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9h ZGRfaXRlbSh0aSwgaGZfaXNjc2lfTWF4Q21kU04sIHR2Yiwgb2Zmc2V0ICsgMzIsIDQsIEZB TFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfTG9naW5fU3Rh dHVzLCB0dmIsIG9mZnNldCArIDM2LCAyLCBGQUxTRSk7DQoJICAgIGlmKGRpZ2VzdHNBY3Rp dmUpDQoJCW9mZnNldCA9IGhhbmRsZUhlYWRlckRpZ2VzdCh0aSwgdHZiLCBvZmZzZXQsIDQ4 KTsNCgkgICAgZWxzZQ0KCQlvZmZzZXQgKz0gNDg7DQoJICAgIG9mZnNldCA9IGhhbmRsZURh dGFTZWdtZW50QXNUZXh0S2V5cyh0aSwgdHZiLCBvZmZzZXQsIGRhdGFfc2VnbWVudF9sZW4s IGVuZF9vZmZzZXQsIGRpZ2VzdHNBY3RpdmUpOw0KCX0NCgllbHNlIGlmKG9wY29kZSA9PSBJ U0NTSV9PUENPREVfVEVYVF9DT01NQU5EKSB7DQoJICAgIC8qIFRleHQgQ29tbWFuZCAqLw0K CSAgICB7DQoJCWdpbnQgYiA9IHR2Yl9nZXRfZ3VpbnQ4KHR2Yiwgb2Zmc2V0ICsgMSk7DQoJ CXByb3RvX2l0ZW0gKnRmID0gcHJvdG9fdHJlZV9hZGRfdWludCh0aSwgaGZfaXNjc2lfRmxh Z3MsIHR2Yiwgb2Zmc2V0ICsgMSwgMSwgYik7DQoJCXByb3RvX3RyZWUgKnR0ID0gcHJvdG9f aXRlbV9hZGRfc3VidHJlZSh0ZiwgZXR0X2lzY3NpX0ZsYWdzKTsNCgkJDQoJCXByb3RvX3Ry ZWVfYWRkX2Jvb2xlYW4odHQsIGhmX2lzY3NpX1RleHRfRiwgdHZiLCBvZmZzZXQgKyAxLCAx LCBiKTsNCgkJcHJvdG9fdHJlZV9hZGRfdWludCh0aSwgaGZfaXNjc2lfRGF0YVNlZ21lbnRM ZW5ndGgsIHR2Yiwgb2Zmc2V0ICsgNSwgMywgZGF0YV9zZWdtZW50X2xlbik7DQoJICAgIH0N CgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfSW5pdGlhdG9yVGFza1Rh ZywgdHZiLCBvZmZzZXQgKyAxNiwgNCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9p dGVtKHRpLCBoZl9pc2NzaV9UYXJnZXRUcmFuc2ZlclRhZywgdHZiLCBvZmZzZXQgKyAyMCwg NCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9DbWRT TiwgdHZiLCBvZmZzZXQgKyAyNCwgNCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9p dGVtKHRpLCBoZl9pc2NzaV9FeHBTdGF0U04sIHR2Yiwgb2Zmc2V0ICsgMjgsIDQsIEZBTFNF KTsNCgkgICAgb2Zmc2V0ID0gaGFuZGxlSGVhZGVyRGlnZXN0KHRpLCB0dmIsIG9mZnNldCwg NDgpOw0KCSAgICBvZmZzZXQgPSBoYW5kbGVEYXRhU2VnbWVudEFzVGV4dEtleXModGksIHR2 Yiwgb2Zmc2V0LCBkYXRhX3NlZ21lbnRfbGVuLCBlbmRfb2Zmc2V0LCBUUlVFKTsNCgl9DQoJ ZWxzZSBpZihvcGNvZGUgPT0gSVNDU0lfT1BDT0RFX1RFWFRfUkVTUE9OU0UpIHsNCgkgICAg LyogVGV4dCBSZXNwb25zZSAqLw0KCSAgICB7DQoJCWdpbnQgYiA9IHR2Yl9nZXRfZ3VpbnQ4 KHR2Yiwgb2Zmc2V0ICsgMSk7DQoJCXByb3RvX2l0ZW0gKnRmID0gcHJvdG9fdHJlZV9hZGRf dWludCh0aSwgaGZfaXNjc2lfRmxhZ3MsIHR2Yiwgb2Zmc2V0ICsgMSwgMSwgYik7DQoJCXBy b3RvX3RyZWUgKnR0ID0gcHJvdG9faXRlbV9hZGRfc3VidHJlZSh0ZiwgZXR0X2lzY3NpX0Zs YWdzKTsNCgkJDQoJCXByb3RvX3RyZWVfYWRkX2Jvb2xlYW4odHQsIGhmX2lzY3NpX1RleHRf RiwgdHZiLCBvZmZzZXQgKyAxLCAxLCBiKTsNCgkJcHJvdG9fdHJlZV9hZGRfdWludCh0aSwg aGZfaXNjc2lfRGF0YVNlZ21lbnRMZW5ndGgsIHR2Yiwgb2Zmc2V0ICsgNSwgMywgZGF0YV9z ZWdtZW50X2xlbik7DQoJICAgIH0NCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZf aXNjc2lfSW5pdGlhdG9yVGFza1RhZywgdHZiLCBvZmZzZXQgKyAxNiwgNCwgRkFMU0UpOw0K CSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9UYXJnZXRUcmFuc2ZlclRh ZywgdHZiLCBvZmZzZXQgKyAyMCwgNCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9p dGVtKHRpLCBoZl9pc2NzaV9TdGF0U04sIHR2Yiwgb2Zmc2V0ICsgMjQsIDQsIEZBTFNFKTsN CgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfRXhwQ21kU04sIHR2Yiwg b2Zmc2V0ICsgMjgsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwg aGZfaXNjc2lfTWF4Q21kU04sIHR2Yiwgb2Zmc2V0ICsgMzIsIDQsIEZBTFNFKTsNCgkgICAg b2Zmc2V0ID0gaGFuZGxlSGVhZGVyRGlnZXN0KHRpLCB0dmIsIG9mZnNldCwgNDgpOw0KCSAg ICBvZmZzZXQgPSBoYW5kbGVEYXRhU2VnbWVudEFzVGV4dEtleXModGksIHR2Yiwgb2Zmc2V0 LCBkYXRhX3NlZ21lbnRfbGVuLCBlbmRfb2Zmc2V0LCBUUlVFKTsNCgl9DQoJZWxzZSBpZihv cGNvZGUgPT0gSVNDU0lfT1BDT0RFX1NDU0lfREFUQV9PVVQpIHsNCgkgICAgLyogU0NTSSBE YXRhIE91dCAod3JpdGUpICovDQoJICAgIHsNCgkJZ2ludCBiID0gdHZiX2dldF9ndWludDgo dHZiLCBvZmZzZXQgKyAxKTsNCgkJcHJvdG9faXRlbSAqdGYgPSBwcm90b190cmVlX2FkZF91 aW50KHRpLCBoZl9pc2NzaV9GbGFncywgdHZiLCBvZmZzZXQgKyAxLCAxLCBiKTsNCgkJcHJv dG9fdHJlZSAqdHQgPSBwcm90b19pdGVtX2FkZF9zdWJ0cmVlKHRmLCBldHRfaXNjc2lfRmxh Z3MpOw0KDQoJCXByb3RvX3RyZWVfYWRkX2Jvb2xlYW4odHQsIGhmX2lzY3NpX1NDU0lEYXRh X0YsIHR2Yiwgb2Zmc2V0ICsgMSwgMSwgYik7DQoJICAgIH0NCgkgICAgcHJvdG9fdHJlZV9h ZGRfdWludCh0aSwgaGZfaXNjc2lfRGF0YVNlZ21lbnRMZW5ndGgsIHR2Yiwgb2Zmc2V0ICsg NSwgMywgZGF0YV9zZWdtZW50X2xlbik7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGks IGhmX2lzY3NpX0xVTiwgdHZiLCBvZmZzZXQgKyA4LCA4LCBGQUxTRSk7DQoJICAgIHByb3Rv X3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0luaXRpYXRvclRhc2tUYWcsIHR2Yiwgb2Zm c2V0ICsgMTYsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZf aXNjc2lfVGFyZ2V0VHJhbnNmZXJUYWcsIHR2Yiwgb2Zmc2V0ICsgMjAsIDQsIEZBTFNFKTsN CgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfRXhwU3RhdFNOLCB0dmIs IG9mZnNldCArIDI4LCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGks IGhmX2lzY3NpX0RhdGFTTiwgdHZiLCBvZmZzZXQgKyAzNiwgNCwgRkFMU0UpOw0KCSAgICBw cm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9CdWZmZXJPZmZzZXQsIHR2Yiwgb2Zm c2V0ICsgNDAsIDQsIEZBTFNFKTsNCgkgICAgb2Zmc2V0ID0gaGFuZGxlSGVhZGVyRGlnZXN0 KHRpLCB0dmIsIG9mZnNldCwgNDgpOw0KCSAgICBvZmZzZXQgPSBoYW5kbGVEYXRhU2VnbWVu dCh0aSwgdHZiLCBvZmZzZXQsIGRhdGFfc2VnbWVudF9sZW4sIGVuZF9vZmZzZXQsIGhmX2lz Y3NpX3dyaXRlX2RhdGEpOw0KCX0NCgllbHNlIGlmKG9wY29kZSA9PSBJU0NTSV9PUENPREVf U0NTSV9EQVRBX0lOKSB7DQoJICAgIC8qIFNDU0kgRGF0YSBJbiAocmVhZCkgKi8NCgkgICAg ew0KCQlnaW50IGIgPSB0dmJfZ2V0X2d1aW50OCh0dmIsIG9mZnNldCArIDEpOw0KCQlwcm90 b19pdGVtICp0ZiA9IHByb3RvX3RyZWVfYWRkX3VpbnQodGksIGhmX2lzY3NpX0ZsYWdzLCB0 dmIsIG9mZnNldCArIDEsIDEsIGIpOw0KCQlwcm90b190cmVlICp0dCA9IHByb3RvX2l0ZW1f YWRkX3N1YnRyZWUodGYsIGV0dF9pc2NzaV9GbGFncyk7DQoNCgkJcHJvdG9fdHJlZV9hZGRf Ym9vbGVhbih0dCwgaGZfaXNjc2lfU0NTSURhdGFfRiwgdHZiLCBvZmZzZXQgKyAxLCAxLCBi KTsNCgkJcHJvdG9fdHJlZV9hZGRfYm9vbGVhbih0dCwgaGZfaXNjc2lfU0NTSURhdGFfTywg dHZiLCBvZmZzZXQgKyAxLCAxLCBiKTsNCgkJcHJvdG9fdHJlZV9hZGRfYm9vbGVhbih0dCwg aGZfaXNjc2lfU0NTSURhdGFfVSwgdHZiLCBvZmZzZXQgKyAxLCAxLCBiKTsNCgkJcHJvdG9f dHJlZV9hZGRfYm9vbGVhbih0dCwgaGZfaXNjc2lfU0NTSURhdGFfUywgdHZiLCBvZmZzZXQg KyAxLCAxLCBiKTsNCgkgICAgfQ0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9p c2NzaV9TQ1NJUmVzcG9uc2VfU3RhdHVzLCB0dmIsIG9mZnNldCArIDMsIDEsIEZBTFNFKTsN CgkgICAgcHJvdG9fdHJlZV9hZGRfdWludCh0aSwgaGZfaXNjc2lfRGF0YVNlZ21lbnRMZW5n dGgsIHR2Yiwgb2Zmc2V0ICsgNSwgMywgZGF0YV9zZWdtZW50X2xlbik7DQoJICAgIHByb3Rv X3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0luaXRpYXRvclRhc2tUYWcsIHR2Yiwgb2Zm c2V0ICsgMTYsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZf aXNjc2lfU0NTSURhdGFfUmVzaWR1YWxDb3VudCwgdHZiLCBvZmZzZXQgKyAyMCwgNCwgRkFM U0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9TdGF0U04sIHR2 Yiwgb2Zmc2V0ICsgMjQsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0 aSwgaGZfaXNjc2lfRXhwQ21kU04sIHR2Yiwgb2Zmc2V0ICsgMjgsIDQsIEZBTFNFKTsNCgkg ICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfTWF4Q21kU04sIHR2Yiwgb2Zm c2V0ICsgMzIsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZf aXNjc2lfRGF0YVNOLCB0dmIsIG9mZnNldCArIDM2LCA0LCBGQUxTRSk7DQoJICAgIHByb3Rv X3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0J1ZmZlck9mZnNldCwgdHZiLCBvZmZzZXQg KyA0MCwgNCwgRkFMU0UpOw0KCSAgICBvZmZzZXQgPSBoYW5kbGVIZWFkZXJEaWdlc3QodGks IHR2Yiwgb2Zmc2V0LCA0OCk7DQoJICAgIG9mZnNldCA9IGhhbmRsZURhdGFTZWdtZW50KHRp LCB0dmIsIG9mZnNldCwgZGF0YV9zZWdtZW50X2xlbiwgZW5kX29mZnNldCwgaGZfaXNjc2lf cmVhZF9kYXRhKTsNCgl9DQoJZWxzZSBpZihvcGNvZGUgPT0gSVNDU0lfT1BDT0RFX0xPR09V VF9DT01NQU5EKSB7DQoJICAgIC8qIExvZ291dCBDb21tYW5kICovDQoJICAgIHByb3RvX3Ry ZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0NJRCwgdHZiLCBvZmZzZXQgKyA4LCAyLCBGQUxT RSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0xvZ291dF9SZWFz b24sIHR2Yiwgb2Zmc2V0ICsgMTEsIDEsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRf aXRlbSh0aSwgaGZfaXNjc2lfSW5pdGlhdG9yVGFza1RhZywgdHZiLCBvZmZzZXQgKyAxNiwg NCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9FeHBT dGF0U04sIHR2Yiwgb2Zmc2V0ICsgMjgsIDQsIEZBTFNFKTsNCgkgICAgb2Zmc2V0ID0gaGFu ZGxlSGVhZGVyRGlnZXN0KHRpLCB0dmIsIG9mZnNldCwgNDgpOw0KCX0NCgllbHNlIGlmKG9w Y29kZSA9PSBJU0NTSV9PUENPREVfTE9HT1VUX1JFU1BPTlNFKSB7DQoJICAgIC8qIExvZ291 dCBSZXNwb25zZSAqLw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9M b2dvdXRfUmVzcG9uc2UsIHR2Yiwgb2Zmc2V0ICsgMiwgMSwgRkFMU0UpOw0KCSAgICBwcm90 b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9Jbml0aWF0b3JUYXNrVGFnLCB0dmIsIG9m ZnNldCArIDE2LCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhm X2lzY3NpX0V4cENtZFNOLCB0dmIsIG9mZnNldCArIDI4LCA0LCBGQUxTRSk7DQoJICAgIHBy b3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX01heENtZFNOLCB0dmIsIG9mZnNldCAr IDMyLCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3Np X1RpbWUyV2FpdCwgdHZiLCBvZmZzZXQgKyA0MCwgMiwgRkFMU0UpOw0KCSAgICBwcm90b190 cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9UaW1lMlJldGFpbiwgdHZiLCBvZmZzZXQgKyA0 MiwgMiwgRkFMU0UpOw0KCSAgICBvZmZzZXQgPSBoYW5kbGVIZWFkZXJEaWdlc3QodGksIHR2 Yiwgb2Zmc2V0LCA0OCk7DQoJfQ0KCWVsc2UgaWYob3Bjb2RlID09IElTQ1NJX09QQ09ERV9T TkFDS19SRVFVRVNUKSB7DQoJICAgIC8qIFNOQUNLIFJlcXVlc3QgKi8NCgkgICAgew0KCQln aW50IGIgPSB0dmJfZ2V0X2d1aW50OCh0dmIsIG9mZnNldCArIDEpOw0KI2lmIDANCgkJcHJv dG9faXRlbSAqdGYgPSBwcm90b190cmVlX2FkZF91aW50KHRpLCBoZl9pc2NzaV9GbGFncywg dHZiLCBvZmZzZXQgKyAxLCAxLCBiKTsNCgkJcHJvdG9fdHJlZSAqdHQgPSBwcm90b19pdGVt X2FkZF9zdWJ0cmVlKHRmLCBldHRfaXNjc2lfRmxhZ3MpOw0KI2VuZGlmDQoNCgkJcHJvdG9f dHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfc25hY2tfdHlwZSwgdHZiLCBvZmZzZXQgKyAx LCAxLCBiKTsNCgkgICAgfQ0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2Nz aV9Jbml0aWF0b3JUYXNrVGFnLCB0dmIsIG9mZnNldCArIDE2LCA0LCBGQUxTRSk7DQoJICAg IHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0JlZ1J1biwgdHZiLCBvZmZzZXQg KyAyMCwgNCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2Nz aV9SdW5MZW5ndGgsIHR2Yiwgb2Zmc2V0ICsgMjQsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9f dHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfRXhwU3RhdFNOLCB0dmIsIG9mZnNldCArIDI4 LCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0V4 cERhdGFTTiwgdHZiLCBvZmZzZXQgKyAzNiwgNCwgRkFMU0UpOw0KCSAgICBvZmZzZXQgPSBo YW5kbGVIZWFkZXJEaWdlc3QodGksIHR2Yiwgb2Zmc2V0LCA0OCk7DQoJfQ0KCWVsc2UgaWYo b3Bjb2RlID09IElTQ1NJX09QQ09ERV9SMlQpIHsNCgkgICAgLyogUjJUICovDQoJICAgIHBy b3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0luaXRpYXRvclRhc2tUYWcsIHR2Yiwg b2Zmc2V0ICsgMTYsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwg aGZfaXNjc2lfVGFyZ2V0VHJhbnNmZXJUYWcsIHR2Yiwgb2Zmc2V0ICsgMjAsIDQsIEZBTFNF KTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfU3RhdFNOLCB0dmIs IG9mZnNldCArIDI0LCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGks IGhmX2lzY3NpX0V4cENtZFNOLCB0dmIsIG9mZnNldCArIDI4LCA0LCBGQUxTRSk7DQoJICAg IHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX01heENtZFNOLCB0dmIsIG9mZnNl dCArIDMyLCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lz Y3NpX1IyVFNOLCB0dmIsIG9mZnNldCArIDM2LCA0LCBGQUxTRSk7DQoJICAgIHByb3RvX3Ry ZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX0J1ZmZlck9mZnNldCwgdHZiLCBvZmZzZXQgKyA0 MCwgNCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9E ZXNpcmVkRGF0YUxlbmd0aCwgdHZiLCBvZmZzZXQgKyA0NCwgNCwgRkFMU0UpOw0KCSAgICBv ZmZzZXQgPSBoYW5kbGVIZWFkZXJEaWdlc3QodGksIHR2Yiwgb2Zmc2V0LCA0OCk7DQoJfQ0K CWVsc2UgaWYob3Bjb2RlID09IElTQ1NJX09QQ09ERV9BU1lOQ19NRVNTQUdFKSB7DQoJICAg IC8qIEFzeW5jaHJvbm91cyBNZXNzYWdlICovDQoJICAgIHByb3RvX3RyZWVfYWRkX3VpbnQo dGksIGhmX2lzY3NpX0RhdGFTZWdtZW50TGVuZ3RoLCB0dmIsIG9mZnNldCArIDUsIDMsIGRh dGFfc2VnbWVudF9sZW4pOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2Nz aV9MVU4sIHR2Yiwgb2Zmc2V0ICsgOCwgOCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2Fk ZF9pdGVtKHRpLCBoZl9pc2NzaV9TdGF0U04sIHR2Yiwgb2Zmc2V0ICsgMjQsIDQsIEZBTFNF KTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfRXhwQ21kU04sIHR2 Yiwgb2Zmc2V0ICsgMjgsIDQsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0 aSwgaGZfaXNjc2lfTWF4Q21kU04sIHR2Yiwgb2Zmc2V0ICsgMzIsIDQsIEZBTFNFKTsNCgkg ICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfQXN5bmNFdmVudCwgdHZiLCBv ZmZzZXQgKyAzNiwgMSwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBo Zl9pc2NzaV9FdmVudFZlbmRvckNvZGUsIHR2Yiwgb2Zmc2V0ICsgMzcsIDEsIEZBTFNFKTsN CgkgICAgcHJvdG9fdHJlZV9hZGRfaXRlbSh0aSwgaGZfaXNjc2lfUGFyYW1ldGVyMSwgdHZi LCBvZmZzZXQgKyAzOCwgMiwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRp LCBoZl9pc2NzaV9QYXJhbWV0ZXIyLCB0dmIsIG9mZnNldCArIDQwLCAyLCBGQUxTRSk7DQoJ ICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX1BhcmFtZXRlcjMsIHR2Yiwg b2Zmc2V0ICsgNDIsIDIsIEZBTFNFKTsNCgkgICAgb2Zmc2V0ID0gaGFuZGxlSGVhZGVyRGln ZXN0KHRpLCB0dmIsIG9mZnNldCwgNDgpOw0KCX0NCgllbHNlIGlmKG9wY29kZSA9PSBJU0NT SV9PUENPREVfUkVKRUNUKSB7DQoJICAgIC8qIFJlamVjdCAqLw0KCSAgICBwcm90b190cmVl X2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9SZWplY3RfUmVhc29uLCB0dmIsIG9mZnNldCArIDIs IDEsIEZBTFNFKTsNCgkgICAgcHJvdG9fdHJlZV9hZGRfdWludCh0aSwgaGZfaXNjc2lfRGF0 YVNlZ21lbnRMZW5ndGgsIHR2Yiwgb2Zmc2V0ICsgNSwgMywgZGF0YV9zZWdtZW50X2xlbik7 DQoJICAgIHByb3RvX3RyZWVfYWRkX2l0ZW0odGksIGhmX2lzY3NpX1N0YXRTTiwgdHZiLCBv ZmZzZXQgKyAyNCwgNCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBo Zl9pc2NzaV9FeHBDbWRTTiwgdHZiLCBvZmZzZXQgKyAyOCwgNCwgRkFMU0UpOw0KCSAgICBw cm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2NzaV9NYXhDbWRTTiwgdHZiLCBvZmZzZXQg KyAzMiwgNCwgRkFMU0UpOw0KCSAgICBwcm90b190cmVlX2FkZF9pdGVtKHRpLCBoZl9pc2Nz aV9EYXRhU04sIHR2Yiwgb2Zmc2V0ICsgMzYsIDQsIEZBTFNFKTsNCgkgICAgb2Zmc2V0ID0g aGFuZGxlSGVhZGVyRGlnZXN0KHRpLCB0dmIsIG9mZnNldCwgNDgpOw0KCSAgICBvZmZzZXQg PSBoYW5kbGVEYXRhU2VnbWVudCh0aSwgdHZiLCBvZmZzZXQsIGRhdGFfc2VnbWVudF9sZW4s IGVuZF9vZmZzZXQsIGhmX2lzY3NpX2Vycm9yX3BkdV9kYXRhKTsNCgl9DQoNCglwcm90b19p dGVtX3NldF9sZW4odGksIG9mZnNldCAtIG9yaWdpbmFsX29mZnNldCk7DQogICAgfQ0KfQ0K DQpzdGF0aWMgZ2Jvb2xlYW4NCmRpc3NlY3RfaXNjc2kodHZidWZmX3QgKnR2YiwgcGFja2V0 X2luZm8gKnBpbmZvLCBwcm90b190cmVlICp0cmVlKSB7DQogICAgLyogU2V0IHVwIHN0cnVj dHVyZXMgbmVlZGVkIHRvIGFkZCB0aGUgcHJvdG9jb2wgc3VidHJlZSBhbmQgbWFuYWdlIGl0 ICovDQogICAgZ3VpbnQgaVNDU0lQZHVzRGlzc2VjdGVkID0gMDsNCiAgICBndWludCBvZmZz ZXQgPSAwOw0KICAgIGd1aW50MzIgYXZhaWxhYmxlX2J5dGVzID0gdHZiX2xlbmd0aF9yZW1h aW5pbmcodHZiLCBvZmZzZXQpOw0KDQogICAgaWYgKCFwcm90b19pc19wcm90b2NvbF9lbmFi bGVkKHByb3RvX2lzY3NpKSkNCglyZXR1cm4gRkFMU0U7CS8qIGlTQ1NJIGhhcyBiZWVuIGRp c2FibGVkICovDQoNCiAgICAvKiBxdWljayBjaGVjayB0byBzZWUgaWYgdGhlIHBhY2tldCBp cyBsb25nIGVub3VnaCB0byBjb250YWluIHRoZQ0KICAgICAqIG1pbmltdW0gYW1vdW50IG9m IGluZm9ybWF0aW9uIHdlIG5lZWQgKi8NCiAgICBpZiAoYXZhaWxhYmxlX2J5dGVzIDwgNDgg JiYgKCFpc2NzaV9kZXNlZ21lbnQgfHwgYXZhaWxhYmxlX2J5dGVzIDwgOCkpIHsNCgkvKiBu bywgc28gZ2l2ZSB1cCAqLw0KCXJldHVybiBGQUxTRTsNCiAgICB9DQoNCiAgICAvKiBwcm9j ZXNzIG11bHRpcGxlIGlTQ1NJIFBEVXMgcGVyIHBhY2tldCAqLw0KICAgIHdoaWxlKGF2YWls YWJsZV9ieXRlcyA+PSA0OCB8fCAoaXNjc2lfZGVzZWdtZW50ICYmIGF2YWlsYWJsZV9ieXRl cyA+PSA4KSkgew0KCWNvbnN0IGNoYXIgKm9wY29kZV9zdHIgPSBOVUxMOw0KCWd1aW50MzIg ZGF0YV9zZWdtZW50X2xlbjsNCglndWludDggb3Bjb2RlID0gdHZiX2dldF9ndWludDgodHZi LCBvZmZzZXQgKyAwKTsNCglndWludDggc2Vjb25kUGR1Qnl0ZSA9IHR2Yl9nZXRfZ3VpbnQ4 KHR2Yiwgb2Zmc2V0ICsgMSk7DQoJaW50IGJhZFBkdSA9IEZBTFNFOw0KDQoJaWYoKG9wY29k ZSAmIFRBUkdFVF9PUENPREVfQklUKSA9PSAwKSB7DQoJICAgIC8qIGluaXRpYXRvciAtPiB0 YXJnZXQgKi8NCgkgICAgLyogbWFzayBvdXQgWCBhbmQgSSBiaXRzICovDQoJICAgIG9wY29k ZSAmPSB+KFhfQklUIHwgSV9CSVQpOw0KCX0NCglvcGNvZGVfc3RyID0gbWF0Y2hfc3RydmFs KG9wY29kZSwgaXNjc2lfb3Bjb2Rlcyk7DQoJaWYob3Bjb2RlID09IElTQ1NJX09QQ09ERV9T Q1NJX1RBU0tfTUFOQUdFTUVOVF9DT01NQU5EIHx8DQoJICAgb3Bjb2RlID09IElTQ1NJX09Q Q09ERV9TQ1NJX1RBU0tfTUFOQUdFTUVOVF9SRVNQT05TRSB8fA0KCSAgIG9wY29kZSA9PSBJ U0NTSV9PUENPREVfUjJUIHx8DQoJICAgb3Bjb2RlID09IElTQ1NJX09QQ09ERV9MT0dPVVRf Q09NTUFORCB8fA0KCSAgIG9wY29kZSA9PSBJU0NTSV9PUENPREVfTE9HT1VUX1JFU1BPTlNF IHx8DQoJICAgb3Bjb2RlID09IElTQ1NJX09QQ09ERV9TTkFDS19SRVFVRVNUKQ0KCSAgICBk YXRhX3NlZ21lbnRfbGVuID0gMDsNCgllbHNlDQoJICAgIGRhdGFfc2VnbWVudF9sZW4gPSB0 dmJfZ2V0X250b2hsKHR2Yiwgb2Zmc2V0ICsgNCkgJiAweDAwZmZmZmZmOw0KDQoJaWYob3Bj b2RlX3N0ciA9PSBOVUxMKSB7DQoJICAgIGJhZFBkdSA9IFRSVUU7DQoJfQ0KCWVsc2UgaWYo aXNjc2lfcG9ydCAhPSAwICYmDQoJCSgoKG9wY29kZSAmIFRBUkdFVF9PUENPREVfQklUKSAm JiBwaW5mby0+c3JjcG9ydCAhPSBpc2NzaV9wb3J0KSB8fA0KCQkgKCEob3Bjb2RlICYgVEFS R0VUX09QQ09ERV9CSVQpICYmIHBpbmZvLT5kZXN0cG9ydCAhPSBpc2NzaV9wb3J0KSkpIHsN CgkgICAgYmFkUGR1ID0gVFJVRTsNCgl9DQoJZWxzZSBpZihlbmFibGVfYm9nb3NpdHlfZmls dGVyKSB7DQoJICAgIC8qIHRyeSBhbmQgZGlzdGluZ3Vpc2ggYmV0d2VlbiBkYXRhIGFuZCBy ZWFsIGhlYWRlcnMgKi8NCgkgICAgaWYoZGF0YV9zZWdtZW50X2xlbiA+IGJvZ3VzX3BkdV9k YXRhX2xlbmd0aF90aHJlc2hvbGQpIHsNCgkJYmFkUGR1ID0gVFJVRTsNCgkgICAgfQ0KCSAg ICBlbHNlIGlmKCEoc2Vjb25kUGR1Qnl0ZSAmIDB4ODApICYmDQoJCSAgICAob3Bjb2RlID09 IElTQ1NJX09QQ09ERV9OT1BfT1VUIHx8DQoJCSAgICAgb3Bjb2RlID09IElTQ1NJX09QQ09E RV9OT1BfSU4gfHwNCgkJICAgICBvcGNvZGUgPT0gSVNDU0lfT1BDT0RFX0xPR09VVF9DT01N QU5EIHx8DQoJCSAgICAgb3Bjb2RlID09IElTQ1NJX09QQ09ERV9MT0dPVVRfUkVTUE9OU0Ug fHwNCgkJICAgICBvcGNvZGUgPT0gSVNDU0lfT1BDT0RFX1NDU0lfUkVTUE9OU0UgfHwNCgkJ ICAgICBvcGNvZGUgPT0gSVNDU0lfT1BDT0RFX1NDU0lfVEFTS19NQU5BR0VNRU5UX1JFU1BP TlNFIHx8DQoJCSAgICAgb3Bjb2RlID09IElTQ1NJX09QQ09ERV9SMlQgfHwNCgkJICAgICBv cGNvZGUgPT0gSVNDU0lfT1BDT0RFX0FTWU5DX01FU1NBR0UgfHwNCgkJICAgICBvcGNvZGUg PT0gSVNDU0lfT1BDT0RFX1NOQUNLX1JFUVVFU1QgfHwNCgkJICAgICBvcGNvZGUgPT0gSVND U0lfT1BDT0RFX1JFSkVDVCkpIHsNCgkJYmFkUGR1ID0gVFJVRTsNCgkgICAgfQ0KCX0NCg0K CWlmKGJhZFBkdSkgew0KCSAgICByZXR1cm4gaVNDU0lQZHVzRGlzc2VjdGVkID4gMDsNCgl9 DQoJZWxzZSB7DQoJICAgIGd1aW50MzIgcGR1TGVuID0gNDg7DQoJICAgIGludCBkaWdlc3Rz QWN0aXZlID0gMTsNCg0KCSAgICBpZihvcGNvZGUgPT0gSVNDU0lfT1BDT0RFX0xPR0lOX0NP TU1BTkQgfHwNCgkgICAgICAgb3Bjb2RlID09IElTQ1NJX09QQ09ERV9MT0dJTl9SRVNQT05T RSkgew0KCQlpZigoc2Vjb25kUGR1Qnl0ZSAmIENTR19NQVNLKSA9PSAwKSB7DQoJCSAgICAv KiBjdXJyZW50IHN0YWdlIGlzIFNlY3VyaXR5TmVnb3RpYXRpb24sIGRpZ2VzdHMNCgkJICAg ICAqIGFyZSBub3QgeWV0IHR1cm5lZCBvbiAqLw0KCQkgICAgZGlnZXN0c0FjdGl2ZSA9IDA7 DQoJCX0NCgkgICAgfQ0KDQoJICAgIGlmKG9wY29kZSA9PSBJU0NTSV9PUENPREVfU0NTSV9D T01NQU5EKSB7DQoJCS8qIGFoc0xlbiAqLw0KCQlwZHVMZW4gKz0gdHZiX2dldF9ndWludDgo dHZiLCBvZmZzZXQgKyA0KSAqIDQ7DQoJICAgIH0NCg0KCSAgICBwZHVMZW4gKz0gZGF0YV9z ZWdtZW50X2xlbjsNCgkgICAgaWYoKHBkdUxlbiAmIDMpICE9IDApDQoJCXBkdUxlbiArPSA0 IC0gKHBkdUxlbiAmIDMpOw0KCSAgICANCgkgICAgaWYoZGlnZXN0c0FjdGl2ZSAmJiBlbmFi bGVIZWFkZXJEaWdlc3RzKSB7DQoJCWlmKGhlYWRlckRpZ2VzdElzQ1JDMzIpDQoJCSAgICBw ZHVMZW4gKz0gNDsNCgkJZWxzZQ0KCQkgICAgcGR1TGVuICs9IGhlYWRlckRpZ2VzdFNpemU7 DQoJICAgIH0NCg0KCSAgICBpZihkaWdlc3RzQWN0aXZlICYmIGRhdGFfc2VnbWVudF9sZW4g PiAwICYmIGVuYWJsZURhdGFEaWdlc3RzKSB7DQoJCWlmKGRhdGFEaWdlc3RJc0NSQzMyKQ0K CQkgICAgcGR1TGVuICs9IDQ7DQoJCWVsc2UNCgkJICAgIHBkdUxlbiArPSBkYXRhRGlnZXN0 U2l6ZTsNCgkgICAgfQ0KCSAgICANCgkgICAgLyoNCgkgICAgICogRGVzZWdtZW50YXRpb24g Y2hlY2suDQoJICAgICAqLw0KCSAgICBpZihpc2NzaV9kZXNlZ21lbnQgJiYgcGluZm8tPmNh bl9kZXNlZ21lbnQpIHsNCgkJaWYocGR1TGVuID4gYXZhaWxhYmxlX2J5dGVzKSB7DQoJCSAg ICAvKg0KCQkgICAgICogVGhpcyBmcmFtZSBkb2Vzbid0IGhhdmUgYWxsIG9mIHRoZSBkYXRh IGZvcg0KCQkgICAgICogdGhpcyBtZXNzYWdlLCBidXQgd2UgY2FuIGRvIHJlYXNzZW1ibHkg b24gaXQuDQoJCSAgICAgKg0KCQkgICAgICogVGVsbCB0aGUgVENQIGRpc3NlY3RvciB3aGVy ZSB0aGUgZGF0YSBmb3IgdGhpcw0KCQkgICAgICogbWVzc2FnZSBzdGFydHMgaW4gdGhlIGRh dGEgaXQgaGFuZGVkIHVzLCBhbmQNCgkJICAgICAqIGhvdyBtYW55IG1vcmUgYnl0ZXMgd2Ug bmVlZCwgYW5kIHJldHVybi4NCgkJICAgICAqLw0KCQkgICAgcGluZm8tPmRlc2VnbWVudF9v ZmZzZXQgPSBvZmZzZXQ7DQoJCSAgICBwaW5mby0+ZGVzZWdtZW50X2xlbiA9IHBkdUxlbiAt IGF2YWlsYWJsZV9ieXRlczsNCgkJICAgIHJldHVybiBUUlVFOw0KCQl9DQoJICAgIH0NCgkg ICAgDQoJICAgIGRpc3NlY3RfaXNjc2lfcGR1KHR2YiwgcGluZm8sIHRyZWUsIG9mZnNldCwg b3Bjb2RlLCBvcGNvZGVfc3RyLCBkYXRhX3NlZ21lbnRfbGVuKTsNCgkgICAgb2Zmc2V0ICs9 IHBkdUxlbjsNCgkgICAgYXZhaWxhYmxlX2J5dGVzIC09IHBkdUxlbjsNCgkgICAgKytpU0NT SVBkdXNEaXNzZWN0ZWQ7DQoJfQ0KICAgIH0NCg0KICAgIHJldHVybiBpU0NTSVBkdXNEaXNz ZWN0ZWQgPiAwOw0KfQ0KDQoNCi8qIFJlZ2lzdGVyIHRoZSBwcm90b2NvbCB3aXRoIEV0aGVy ZWFsICovDQoNCi8qDQogKiB0aGlzIGZvcm1hdCBpcyByZXF1aXJlIGJlY2F1c2UgYSBzY3Jp cHQgaXMgdXNlZCB0byBidWlsZCB0aGUgQw0KICogZnVuY3Rpb24gdGhhdCBjYWxscyBhbGwg dGhlIHByb3RvY29sIHJlZ2lzdHJhdGlvbi4NCiovDQoNCnZvaWQNCnByb3RvX3JlZ2lzdGVy X2lzY3NpKHZvaWQpDQp7ICAgICAgICAgICAgICAgICANCg0KICAgIC8qIFNldHVwIGxpc3Qg b2YgaGVhZGVyIGZpZWxkcyAgU2VlIFNlY3Rpb24gMS42LjEgZm9yIGRldGFpbHMqLw0KICAg IHN0YXRpYyBoZl9yZWdpc3Rlcl9pbmZvIGhmW10gPSB7DQoJeyAmaGZfaXNjc2lfQUhTLA0K CSAgeyAiQUhTIiwgImlzY3NpLmFocyIsDQoJICAgIEZUX0JZVEVTLCBCQVNFX0hFWCwgTlVM TCwgMCwNCgkgICAgIkFkZGl0aW9uYWwgaGVhZGVyIHNlZ21lbnQiLCBIRklMTCB9DQoJfSwN Cgl7ICZoZl9pc2NzaV9QYWRkaW5nLA0KCSAgeyAiUGFkZGluZyIsICJpc2NzaS5wYWRkaW5n IiwNCgkgICAgRlRfQllURVMsIEJBU0VfSEVYLCBOVUxMLCAwLA0KCSAgICAiUGFkZGluZyB0 byA0IGJ5dGUgYm91bmRhcnkiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9waW5nX2Rh dGEsDQoJICB7ICJQaW5nRGF0YSIsICJpc2NzaS5waW5nZGF0YSIsDQoJICAgIEZUX0JZVEVT LCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkgICAgIlBpbmcgRGF0YSIsIEhGSUxMIH0NCgl9LA0K CXsgJmhmX2lzY3NpX2ltbWVkaWF0ZV9kYXRhLA0KCSAgeyAiSW1tZWRpYXRlRGF0YSIsICJp c2NzaS5pbW1lZGlhdGVkYXRhIiwNCgkgICAgRlRfQllURVMsIEJBU0VfSEVYLCBOVUxMLCAw LA0KCSAgICAiSW1tZWRpYXRlIERhdGEiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9z ZW5zZV9kYXRhLA0KCSAgeyAiU2Vuc2VEYXRhIiwgImlzY3NpLnNlbnNlZGF0YSIsDQoJICAg IEZUX0JZVEVTLCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkgICAgIlNlbnNlIERhdGEiLCBIRklM TCB9DQoJfSwNCgl7ICZoZl9pc2NzaV93cml0ZV9kYXRhLA0KCSAgeyAiV3JpdGVEYXRhIiwg ImlzY3NpLndyaXRlZGF0YSIsDQoJICAgIEZUX0JZVEVTLCBCQVNFX0hFWCwgTlVMTCwgMCwN CgkgICAgIldyaXRlIERhdGEiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9yZWFkX2Rh dGEsDQoJICB7ICJSZWFkRGF0YSIsICJpc2NzaS5yZWFkZGF0YSIsDQoJICAgIEZUX0JZVEVT LCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkgICAgIlJlYWQgRGF0YSIsIEhGSUxMIH0NCgl9LA0K CXsgJmhmX2lzY3NpX2Vycm9yX3BkdV9kYXRhLA0KCSAgeyAiRXJyb3JQRFVEYXRhIiwgImlz Y3NpLmVycm9ycGR1ZGF0YSIsDQoJICAgIEZUX0JZVEVTLCBCQVNFX0hFWCwgTlVMTCwgMCwN CgkgICAgIkVycm9yIFBEVSBEYXRhIiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lfSGVh ZGVyRGlnZXN0LA0KCSAgeyAiSGVhZGVyRGlnZXN0IiwgImlzY3NpLmhlYWRlcmRpZ2VzdCIs DQoJICAgIEZUX0JZVEVTLCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkgICAgIkhlYWRlciBEaWdl c3QiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9IZWFkZXJEaWdlc3QzMiwNCgkgIHsg IkhlYWRlckRpZ2VzdCIsICJpc2NzaS5oZWFkZXJkaWdlc3QzMiIsDQoJICAgIEZUX1VJTlQz MiwgQkFTRV9IRVgsIE5VTEwsIDAsDQoJICAgICJIZWFkZXIgRGlnZXN0IiwgSEZJTEwgfQ0K CX0sDQoJeyAmaGZfaXNjc2lfRGF0YURpZ2VzdCwNCgkgIHsgIkRhdGFEaWdlc3QiLCAiaXNj c2kuZGF0YWRpZ2VzdCIsDQoJICAgIEZUX0JZVEVTLCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkg ICAgIkRhdGEgRGlnZXN0IiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lfRGF0YURpZ2Vz dDMyLA0KCSAgeyAiRGF0YURpZ2VzdCIsICJpc2NzaS5kYXRhZGlnZXN0MzIiLA0KCSAgICBG VF9VSU5UMzIsIEJBU0VfSEVYLCBOVUxMLCAwLA0KCSAgICAiRGF0YSBEaWdlc3QiLCBIRklM TCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9PcGNvZGUsDQoJICB7ICJPcGNvZGUiLCAiaXNjc2ku b3Bjb2RlIiwNCgkgICAgRlRfVUlOVDgsIEJBU0VfSEVYLCBWQUxTKGlzY3NpX29wY29kZXMp LCAwLCAgICAgICAgICANCgkgICAgIk9wY29kZSIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lz Y3NpX1gsDQoJICB7ICJYIiwgImlzY3NpLlgiLA0KCSAgICBGVF9CT09MRUFOLCA4LCBURlMo JmlzY3NpX21lYW5pbmdfWCksIDB4ODAsICAgICAgICAgIA0KCSAgICAiQ29tbWFuZCBSZXRy eSIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3NpX0ksDQoJICB7ICJJIiwgImlzY3NpLkki LA0KCSAgICBGVF9CT09MRUFOLCA4LCBURlMoJmlzY3NpX21lYW5pbmdfSSksIDB4NDAsICAg ICAgICAgIA0KCSAgICAiSW1tZWRpYXRlIGRlbGl2ZXJ5IiwgSEZJTEwgfQ0KCX0sDQoJeyAm aGZfaXNjc2lfRmxhZ3MsDQoJICB7ICJGbGFncyIsICJpc2NzaS5mbGFncyIsDQoJICAgIEZU X1VJTlQ4LCBCQVNFX0hFWCwgTlVMTCwgMCwgICAgICAgICAgDQoJICAgICJPcGNvZGUgc3Bl Y2lmaWMgZmxhZ3MiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9TQ1NJQ29tbWFuZF9G LA0KCSAgeyAiRiIsICJpc2NzaS5zY3NpY29tbWFuZC5GIiwNCgkgICAgRlRfQk9PTEVBTiwg OCwgVEZTKCZpc2NzaV9tZWFuaW5nX0YpLCAweDgwLCAgICAgICAgICANCgkgICAgIlBEVSBj b21wbGV0ZXMgY29tbWFuZCIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3NpX1NDU0lDb21t YW5kX1IsDQoJICB7ICJSIiwgImlzY3NpLnNjc2ljb21tYW5kLlIiLA0KCSAgICBGVF9CT09M RUFOLCA4LCBURlMoJmlzY3NpX21lYW5pbmdfUiksIDB4NDAsICAgICAgICAgIA0KCSAgICAi Q29tbWFuZCByZWFkcyBmcm9tIFNDU0kgdGFyZ2V0IiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZf aXNjc2lfU0NTSUNvbW1hbmRfVywNCgkgIHsgIlciLCAiaXNjc2kuc2NzaWNvbW1hbmQuVyIs DQoJICAgIEZUX0JPT0xFQU4sIDgsIFRGUygmaXNjc2lfbWVhbmluZ19XKSwgMHgyMCwgICAg ICAgICAgDQoJICAgICJDb21tYW5kIHdyaXRlcyB0byBTQ1NJIHRhcmdldCIsIEhGSUxMIH0N Cgl9LA0KCXsgJmhmX2lzY3NpX1NDU0lDb21tYW5kX0F0dHIsDQoJICB7ICJBdHRyIiwgImlz Y3NpLnNjc2ljb21tYW5kLmF0dHIiLA0KCSAgICBGVF9VSU5UOCwgQkFTRV9IRVgsIFZBTFMo aXNjc2lfc2NzaWNvbW1hbmRfdGFza2F0dHJzKSwgMHgwNywgICAgICAgICAgDQoJICAgICJT Q1NJIHRhc2sgYXR0cmlidXRlcyIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3NpX1NDU0lD b21tYW5kX0NSTiwNCgkgIHsgIkNSTiIsICJpc2NzaS5zY3NpY29tbWFuZC5jcm4iLA0KCSAg ICBGVF9VSU5UOCwgQkFTRV9IRVgsIE5VTEwsIDAsICAgICAgICAgIA0KCSAgICAiU0NTSSBj b21tYW5kIHJlZmVyZW5jZSBudW1iZXIiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9T Q1NJQ29tbWFuZF9BZGRDREIsDQoJICB7ICJBZGRDREIiLCAiaXNjc2kuc2NzaWNvbW1hbmQu YWRkY2RiIiwNCgkgICAgRlRfVUlOVDgsIEJBU0VfSEVYLCBOVUxMLCAwLA0KCSAgICAiQWRk aXRpb25hbCBDREIgbGVuZ3RoIChpbiA0IGJ5dGUgdW5pdHMpIiwgSEZJTEwgfQ0KCX0sDQoJ eyAmaGZfaXNjc2lfRGF0YVNlZ21lbnRMZW5ndGgsDQoJICB7ICJEYXRhU2VnbWVudExlbmd0 aCIsICJpc2NzaS5kYXRhc2VnbWVudGxlbmd0aCIsDQoJICAgIEZUX1VJTlQzMiwgQkFTRV9I RVgsIE5VTEwsIDAsDQoJICAgICJEYXRhIHNlZ21lbnQgbGVuZ3RoIChieXRlcykiLCBIRklM TCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9Ub3RhbEFIU0xlbmd0aCwNCgkgIHsgIlRvdGFsQUhT TGVuZ3RoIiwgImlzY3NpLnRvdGFsYWhzbGVuZ3RoIiwNCgkgICAgRlRfVUlOVDgsIEJBU0Vf SEVYLCBOVUxMLCAwLA0KCSAgICAiVG90YWwgYWRkaXRpb25hbCBoZWFkZXIgc2VnbWVudCBs ZW5ndGggKDQgYnl0ZSB3b3JkcykiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9MVU4s DQoJICB7ICJMVU4iLCAiaXNjc2kubHVuIiwNCgkgICAgRlRfQllURVMsIEJBU0VfSEVYLCBO VUxMLCAwLA0KCSAgICAiTG9naWNhbCBVbml0IE51bWJlciIsIEhGSUxMIH0NCgl9LA0KCXsg JmhmX2lzY3NpX0luaXRpYXRvclRhc2tUYWcsDQoJICB7ICJJbml0aWF0b3JUYXNrVGFnIiwg ImlzY3NpLmluaXRpYXRvcnRhc2t0YWciLA0KCSAgICBGVF9VSU5UMzIsIEJBU0VfSEVYLCBO VUxMLCAwLA0KCSAgICAiSW5pdGlhdG9yJ3MgdGFzayB0YWciLCBIRklMTCB9DQoJfSwNCgl7 ICZoZl9pc2NzaV9FeHBlY3RlZERhdGFUcmFuc2Zlckxlbmd0aCwNCgkgIHsgIkV4cGVjdGVk RGF0YVRyYW5zZmVyTGVuZ3RoIiwgImlzY3NpLnNjc2ljb21tYW5kLmV4cGVjdGVkZGF0YXRy YW5zZmVybGVuZ3RoIiwNCgkgICAgRlRfVUlOVDMyLCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkg ICAgIkV4cGVjdGVkIGxlbmd0aCBvZiBkYXRhIHRyYW5zZmVyIiwgSEZJTEwgfQ0KCX0sDQoJ eyAmaGZfaXNjc2lfQ21kU04sDQoJICB7ICJDbWRTTiIsICJpc2NzaS5jbWRzbiIsDQoJICAg IEZUX1VJTlQzMiwgQkFTRV9IRVgsIE5VTEwsIDAsDQoJICAgICJTZXF1ZW5jZSBudW1iZXIg Zm9yIHRoaXMgY29tbWFuZCAoMCA9PSBpbW1lZGlhdGUpIiwgSEZJTEwgfQ0KCX0sDQoJeyAm aGZfaXNjc2lfRXhwU3RhdFNOLA0KCSAgeyAiRXhwU3RhdFNOIiwgImlzY3NpLmV4cHN0YXRz biIsDQoJICAgIEZUX1VJTlQzMiwgQkFTRV9IRVgsIE5VTEwsIDAsDQoJICAgICJOZXh0IGV4 cGVjdGVkIHN0YXR1cyBzZXF1ZW5jZSBudW1iZXIiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9p c2NzaV9TQ1NJQ29tbWFuZF9DREIsDQoJICB7ICJDREIiLCAiaXNjc2kuc2NzaWNvbW1hbmQu Y2RiIiwNCgkgICAgRlRfQllURVMsIEJBU0VfSEVYLCBOVUxMLCAwLA0KCSAgICAiU0NTSSBD REIiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9TQ1NJQ29tbWFuZF9DREIwLA0KCSAg eyAiQ0RCIiwgImlzY3NpLnNjc2ljb21tYW5kLmNkYjAiLA0KCSAgICBGVF9VSU5UOCwgQkFT RV9IRVgsIFZBTFMoaXNjc2lfc2NzaV9jZGIwKSwgMCwNCgkgICAgIlNDU0kgQ0RCWzBdIiwg SEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lfU0NTSVJlc3BvbnNlX1Jlc2lkdWFsQ291bnQs DQoJICB7ICJSZXNpZHVhbENvdW50IiwgImlzY3NpLnNjc2lyZXNwb25zZS5yZXNpZHVhbGNv dW50IiwNCgkgICAgRlRfVUlOVDMyLCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkgICAgIlJlc2lk dWFsIGNvdW50IiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lfU3RhdFNOLA0KCSAgeyAi U3RhdFNOIiwgImlzY3NpLnN0YXRzbiIsDQoJICAgIEZUX1VJTlQzMiwgQkFTRV9IRVgsIE5V TEwsIDAsDQoJICAgICJTdGF0dXMgc2VxdWVuY2UgbnVtYmVyIiwgSEZJTEwgfQ0KCX0sDQoJ eyAmaGZfaXNjc2lfRXhwQ21kU04sDQoJICB7ICJFeHBDbWRTTiIsICJpc2NzaS5leHBjbWRz biIsDQoJICAgIEZUX1VJTlQzMiwgQkFTRV9IRVgsIE5VTEwsIDAsDQoJICAgICJOZXh0IGV4 cGVjdGVkIGNvbW1hbmQgc2VxdWVuY2UgbnVtYmVyIiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZf aXNjc2lfTWF4Q21kU04sDQoJICB7ICJNYXhDbWRTTiIsICJpc2NzaS5tYXhjbWRzbiIsDQoJ ICAgIEZUX1VJTlQzMiwgQkFTRV9IRVgsIE5VTEwsIDAsDQoJICAgICJNYXhpbXVtIGFjY2Vw dGFibGUgY29tbWFuZCBzZXF1ZW5jZSBudW1iZXIiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9p c2NzaV9TQ1NJUmVzcG9uc2VfbywNCgkgIHsgIm8iLCAiaXNjc2kuc2NzaXJlc3BvbnNlLm8i LA0KCSAgICBGVF9CT09MRUFOLCA4LCBURlMoJmlzY3NpX21lYW5pbmdfbyksIDB4MTAsICAg ICAgICAgIA0KCSAgICAiQmktZGlyZWN0aW9uYWwgcmVhZCByZXNpZHVhbCBvdmVyZmxvdyIs IEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3NpX1NDU0lSZXNwb25zZV91LA0KCSAgeyAidSIs ICJpc2NzaS5zY3NpcmVzcG9uc2UudSIsDQoJICAgIEZUX0JPT0xFQU4sIDgsIFRGUygmaXNj c2lfbWVhbmluZ191KSwgMHgwOCwgICAgICAgICAgDQoJICAgICJCaS1kaXJlY3Rpb25hbCBy ZWFkIHJlc2lkdWFsIHVuZGVyZmxvdyIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3NpX1ND U0lSZXNwb25zZV9PLA0KCSAgeyAiTyIsICJpc2NzaS5zY3NpcmVzcG9uc2UuTyIsDQoJICAg IEZUX0JPT0xFQU4sIDgsIFRGUygmaXNjc2lfbWVhbmluZ19PKSwgMHgwNCwgICAgICAgICAg DQoJICAgICJSZXNpZHVhbCBvdmVyZmxvdyIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3Np X1NDU0lSZXNwb25zZV9VLA0KCSAgeyAiVSIsICJpc2NzaS5zY3NpcmVzcG9uc2UuVSIsDQoJ ICAgIEZUX0JPT0xFQU4sIDgsIFRGUygmaXNjc2lfbWVhbmluZ19VKSwgMHgwMiwgICAgICAg ICAgDQoJICAgICJSZXNpZHVhbCB1bmRlcmZsb3ciLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9p c2NzaV9TQ1NJUmVzcG9uc2VfU3RhdHVzLA0KCSAgeyAiU3RhdHVzIiwgImlzY3NpLnNjc2ly ZXNwb25zZS5zdGF0dXMiLA0KCSAgICBGVF9VSU5UOCwgQkFTRV9IRVgsIFZBTFMoaXNjc2lf c2NzaV9zdGF0dXNlcyksIDAsDQoJICAgICJTQ1NJIGNvbW1hbmQgc3RhdHVzIHZhbHVlIiwg SEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lfU0NTSVJlc3BvbnNlX1Jlc3BvbnNlLA0KCSAg eyAiUmVzcG9uc2UiLCAiaXNjc2kuc2NzaXJlc3BvbnNlLnJlc3BvbnNlIiwNCgkgICAgRlRf VUlOVDgsIEJBU0VfSEVYLCBWQUxTKGlzY3NpX3Njc2lfcmVzcG9uc2VzKSwgMCwNCgkgICAg IlNDU0kgY29tbWFuZCByZXNwb25zZSB2YWx1ZSIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lz Y3NpX1NDU0lSZXNwb25zZV9CaWRpUmVhZFJlc2lkdWFsQ291bnQsDQoJICB7ICJCaWRpUmVh ZFJlc2lkdWFsQ291bnQiLCAiaXNjc2kuc2NzaXJlc3BvbnNlLmJpZGlyZWFkcmVzaWR1YWxj b3VudCIsDQoJICAgIEZUX1VJTlQzMiwgQkFTRV9IRVgsIE5VTEwsIDAsDQoJICAgICJCaS1k aXJlY3Rpb25hbCByZWFkIHJlc2lkdWFsIGNvdW50IiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZf aXNjc2lfU0NTSURhdGFfRiwNCgkgIHsgIkYiLCAiaXNjc2kuc2NzaWRhdGEuRiIsDQoJICAg IEZUX0JPT0xFQU4sIDgsIFRGUygmaXNjc2lfbWVhbmluZ19GKSwgMHg4MCwgICAgICAgICAg DQoJICAgICJGaW5hbCBQRFUiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9TQ1NJRGF0 YV9TLA0KCSAgeyAiUyIsICJpc2NzaS5zY3NpZGF0YS5TIiwNCgkgICAgRlRfQk9PTEVBTiwg OCwgVEZTKCZpc2NzaV9tZWFuaW5nX1MpLCAweDAxLCAgICAgICAgICANCgkgICAgIlBEVSBD b250YWlucyBTQ1NJIGNvbW1hbmQgc3RhdHVzIiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNj c2lfU0NTSURhdGFfVSwNCgkgIHsgIlUiLCAiaXNjc2kuc2NzaWRhdGEuVSIsDQoJICAgIEZU X0JPT0xFQU4sIDgsICBURlMoJmlzY3NpX21lYW5pbmdfVSksIDB4MDIsICAgICAgICAgIA0K CSAgICAiUmVzaWR1YWwgdW5kZXJmbG93IiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lf U0NTSURhdGFfTywNCgkgIHsgIk8iLCAiaXNjc2kuc2NzaWRhdGEuTyIsDQoJICAgIEZUX0JP T0xFQU4sIDgsICBURlMoJmlzY3NpX21lYW5pbmdfTyksIDB4MDQsICAgICAgICAgIA0KCSAg ICAiUmVzaWR1YWwgb3ZlcmZsb3ciLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9UYXJn ZXRUcmFuc2ZlclRhZywNCgkgIHsgIlRhcmdldFRyYW5zZmVyVGFnIiwgImlzY3NpLnRhcmdl dHRyYW5zZmVydGFnIiwNCgkgICAgRlRfVUlOVDMyLCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkg ICAgIlRhcmdldCB0cmFuc2ZlciB0YWciLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9C dWZmZXJPZmZzZXQsDQoJICB7ICJCdWZmZXJPZmZzZXQiLCAiaXNjc2kuYnVmZmVyT2Zmc2V0 IiwNCgkgICAgRlRfVUlOVDMyLCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkgICAgIkJ1ZmZlciBv ZmZzZXQiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9TQ1NJRGF0YV9SZXNpZHVhbENv dW50LA0KCSAgeyAiUmVzaWR1YWxDb3VudCIsICJpc2NzaS5zY3NpZGF0YS5yZWFkcmVzaWR1 YWxjb3VudCIsDQoJICAgIEZUX1VJTlQzMiwgQkFTRV9IRVgsIE5VTEwsIDAsDQoJICAgICJS ZXNpZHVhbCBjb3VudCIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3NpX0RhdGFTTiwNCgkg IHsgIkRhdGFTTiIsICJpc2NzaS5kYXRhc24iLA0KCSAgICBGVF9VSU5UMzIsIEJBU0VfSEVY LCBOVUxMLCAwLA0KCSAgICAiRGF0YSBzZXF1ZW5jZSBudW1iZXIiLCBIRklMTCB9DQoJfSwN Cgl7ICZoZl9pc2NzaV9WZXJzaW9uTWF4LA0KCSAgeyAiVmVyc2lvbk1heCIsICJpc2NzaS52 ZXJzaW9ubWF4IiwNCgkgICAgRlRfVUlOVDgsIEJBU0VfSEVYLCBOVUxMLCAwLA0KCSAgICAi TWF4aW11bSBzdXBwb3J0ZWQgcHJvdG9jb2wgdmVyc2lvbiIsIEhGSUxMIH0NCgl9LA0KCXsg JmhmX2lzY3NpX1ZlcnNpb25NaW4sDQoJICB7ICJWZXJzaW9uTWluIiwgImlzY3NpLnZlcnNp b25taW4iLA0KCSAgICBGVF9VSU5UOCwgQkFTRV9IRVgsIE5VTEwsIDAsDQoJICAgICJNaW5p bXVtIHN1cHBvcnRlZCBwcm90b2NvbCB2ZXJzaW9uIiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZf aXNjc2lfVmVyc2lvbkFjdGl2ZSwNCgkgIHsgIlZlcnNpb25BY3RpdmUiLCAiaXNjc2kudmVy c2lvbmFjdGl2ZSIsDQoJICAgIEZUX1VJTlQ4LCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkgICAg Ik5lZ290aWF0ZWQgcHJvdG9jb2wgdmVyc2lvbiIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lz Y3NpX0NJRCwNCgkgIHsgIkNJRCIsICJpc2NzaS5jaWQiLA0KCSAgICBGVF9VSU5UMTYsIEJB U0VfSEVYLCBOVUxMLCAwLA0KCSAgICAiQ29ubmVjdGlvbiBpZGVudGlmaWVyIiwgSEZJTEwg fQ0KCX0sDQoJeyAmaGZfaXNjc2lfSVNJRCwNCgkgIHsgIklTSUQiLCAiaXNjc2kuaXNpZCIs DQoJICAgIEZUX1VJTlQxNiwgQkFTRV9IRVgsIE5VTEwsIDAsDQoJICAgICJJbml0aWF0b3Ig cGFydCBvZiBzZXNzaW9uIGlkZW50aWZpZXIiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2Nz aV9UU0lELA0KCSAgeyAiVFNJRCIsICJpc2NzaS50c2lkIiwNCgkgICAgRlRfVUlOVDE2LCBC QVNFX0hFWCwgTlVMTCwgMCwNCgkgICAgIlRhcmdldCBwYXJ0IG9mIHNlc3Npb24gaWRlbnRp ZmllciIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3NpX0luaXRTdGF0U04sDQoJICB7ICJJ bml0U3RhdFNOIiwgImlzY3NpLmluaXRzdGF0c24iLA0KCSAgICBGVF9VSU5UMzIsIEJBU0Vf SEVYLCBOVUxMLCAwLA0KCSAgICAiSW5pdGlhbCBzdGF0dXMgc2VxdWVuY2UgbnVtYmVyIiwg SEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lfSW5pdENtZFNOLA0KCSAgeyAiSW5pdENtZFNO IiwgImlzY3NpLmluaXRjbWRzbiIsDQoJICAgIEZUX1VJTlQzMiwgQkFTRV9IRVgsIE5VTEws IDAsDQoJICAgICJJbml0aWFsIGNvbW1hbmQgc2VxdWVuY2UgbnVtYmVyIiwgSEZJTEwgfQ0K CX0sDQoJeyAmaGZfaXNjc2lfTG9naW5fVCwNCgkgIHsgIlQiLCAiaXNjc2kubG9naW4uVCIs DQoJICAgIEZUX0JPT0xFQU4sIDgsIFRGUygmaXNjc2lfbWVhbmluZ19UKSwgMHg4MCwgICAg ICAgICAgDQoJICAgICJUcmFuc2l0IHRvIG5leHQgbG9naW4gc3RhZ2UiLCAgSEZJTEwgfQ0K CX0sDQoJeyAmaGZfaXNjc2lfTG9naW5fQ1NHLA0KCSAgeyAiQ1NHIiwgImlzY3NpLmxvZ2lu LmNzZyIsDQoJICAgIEZUX1VJTlQ4LCBCQVNFX0hFWCwgVkFMUyhpc2NzaV9sb2dpbl9zdGFn ZSksIENTR19NQVNLLCAgICAgICAgICANCgkgICAgIkN1cnJlbnQgc3RhZ2UiLCAgSEZJTEwg fQ0KCX0sDQoJeyAmaGZfaXNjc2lfTG9naW5fTlNHLA0KCSAgeyAiTlNHIiwgImlzY3NpLmxv Z2luLm5zZyIsDQoJICAgIEZUX1VJTlQ4LCBCQVNFX0hFWCwgVkFMUyhpc2NzaV9sb2dpbl9z dGFnZSksIDB4MDMsICAgICAgICAgIA0KCSAgICAiTmV4dCBzdGFnZSIsICBIRklMTCB9DQoJ fSwNCgl7ICZoZl9pc2NzaV9Mb2dpbl9TdGF0dXMsDQoJICB7ICJTdGF0dXMiLCAiaXNjc2ku bG9naW4uc3RhdHVzIiwNCgkgICAgRlRfVUlOVDE2LCBCQVNFX0hFWCwgVkFMUyhpc2NzaV9s b2dpbl9zdGF0dXMpLCAwLA0KCSAgICAiU3RhdHVzIGNsYXNzIGFuZCBkZXRhaWwiLCBIRklM TCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9LZXlWYWx1ZSwNCgkgIHsgIktleVZhbHVlIiwgImlz Y3NpLmtleXZhbHVlIiwNCgkgICAgRlRfU1RSSU5HLCAwLCBOVUxMLCAwLA0KCSAgICAiS2V5 L3ZhbHVlIHBhaXIiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9UZXh0X0YsDQoJICB7 ICJGIiwgImlzY3NpLnRleHQuRiIsDQoJICAgIEZUX0JPT0xFQU4sIDgsIFRGUygmaXNjc2lf bWVhbmluZ19GKSwgMHg4MCwgICAgICAgICAgDQoJICAgICJGaW5hbCBQRFUgaW4gdGV4dCBz ZXF1ZW5jZSIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3NpX0V4cERhdGFTTiwNCgkgIHsg IkV4cERhdGFTTiIsICJpc2NzaS5leHBkYXRhc24iLA0KCSAgICBGVF9VSU5UMzIsIEJBU0Vf SEVYLCBOVUxMLCAwLA0KCSAgICAiTmV4dCBleHBlY3RlZCBkYXRhIHNlcXVlbmNlIG51bWJl ciIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3NpX1IyVFNOLA0KCSAgeyAiUjJUU04iLCAi aXNjc2kucjJ0c24iLA0KCSAgICBGVF9VSU5UMzIsIEJBU0VfSEVYLCBOVUxMLCAwLA0KCSAg ICAiUjJUIFBEVSBOdW1iZXIiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9TQ1NJVGFz a19SZXNwb25zZSwNCgkgIHsgIlJlc3BvbnNlIiwgImlzY3NpLnNjc2l0YXNrLnJlc3BvbnNl IiwNCgkgICAgRlRfVUlOVDgsIEJBU0VfSEVYLCBWQUxTKGlzY3NpX3Rhc2tfcmVzcG9uc2Vz KSwgMCwNCgkgICAgIlJlc3BvbnNlIiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lfU0NT SVRhc2tfUmVmZXJlbmNlZFRhc2tUYWcsDQoJICB7ICJJbml0aWF0b3JUYXNrVGFnIiwgImlz Y3NpLnNjc2l0YXNrLnJlZmVyZW5jZWR0YXNrdGFnIiwNCgkgICAgRlRfVUlOVDMyLCBCQVNF X0hFWCwgTlVMTCwgMCwNCgkgICAgIlRhc2sncyBpbml0aWF0b3IgdGFzayB0YWciLCBIRklM TCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9SZWZDbWRTTiwNCgkgIHsgIlJlZkNtZFNOIiwgImlz Y3NpLnJlZmNtZHNuIiwNCgkgICAgRlRfVUlOVDMyLCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkg ICAgIkNvbW1hbmQgc2VxdWVuY2UgbnVtYmVyIGZvciBjb21tYW5kIHRvIGJlIGFib3J0ZWQi LCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9TQ1NJVGFza19GdW5jdGlvbiwNCgkgIHsg IkZ1bmN0aW9uIiwgImlzY3NpLnNjc2l0YXNrLmZ1bmN0aW9uIiwNCgkgICAgRlRfVUlOVDgs IEJBU0VfSEVYLCBWQUxTKGlzY3NpX3Rhc2tfZnVuY3Rpb25zKSwgMHg3RiwNCgkgICAgIlJl cXVlc3RlZCB0YXNrIGZ1bmN0aW9uIiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lfTG9n b3V0X1JlYXNvbiwNCgkgIHsgIlJlYXNvbiIsICJpc2NzaS5sb2dvdXQucmVhc29uIiwNCgkg ICAgRlRfVUlOVDgsIEJBU0VfSEVYLCBWQUxTKGlzY3NpX2xvZ291dF9yZWFzb25zKSwgMCwN CgkgICAgIlJlYXNvbiBmb3IgbG9nb3V0IiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lf TG9nb3V0X1Jlc3BvbnNlLA0KCSAgeyAiUmVzcG9uc2UiLCAiaXNjc2kubG9nb3V0LnJlc3Bv bnNlIiwNCgkgICAgRlRfVUlOVDgsIEJBU0VfSEVYLCBWQUxTKGlzY3NpX2xvZ291dF9yZXNw b25zZSksIDAsDQoJICAgICJMb2dvdXQgcmVzcG9uc2UiLCBIRklMTCB9DQoJfSwNCgl7ICZo Zl9pc2NzaV9UaW1lMldhaXQsDQoJICB7ICJUaW1lMldhaXQiLCAiaXNjc2kudGltZTJ3YWl0 IiwNCgkgICAgRlRfVUlOVDE2LCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkgICAgIlRpbWUyV2Fp dCIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3NpX1RpbWUyUmV0YWluLA0KCSAgeyAiVGlt ZTJSZXRhaW4iLCAiaXNjc2kudGltZTJyZXRhaW4iLA0KCSAgICBGVF9VSU5UMTYsIEJBU0Vf SEVYLCBOVUxMLCAwLA0KCSAgICAiVGltZTJSZXRhaW4iLCBIRklMTCB9DQoJfSwNCgl7ICZo Zl9pc2NzaV9EZXNpcmVkRGF0YUxlbmd0aCwNCgkgIHsgIkRlc2lyZWREYXRhTGVuZ3RoIiwg ImlzY3NpLmRlc2lyZWRkYXRhbGVuZ3RoIiwNCgkgICAgRlRfVUlOVDMyLCBCQVNFX0hFWCwg TlVMTCwgMCwNCgkgICAgIkRlc2lyZWQgZGF0YSBsZW5ndGggKGJ5dGVzKSIsIEhGSUxMIH0N Cgl9LA0KCXsgJmhmX2lzY3NpX0FzeW5jRXZlbnQsDQoJICB7ICJBc3luY0V2ZW50IiwgImlz Y3NpLmFzeW5jZXZlbnQiLA0KCSAgICBGVF9VSU5UOCwgQkFTRV9IRVgsIFZBTFMoaXNjc2lf YXN5bmNldmVudHMpLCAwLA0KCSAgICAiQXN5bmMgZXZlbnQgdHlwZSIsIEhGSUxMIH0NCgl9 LA0KCXsgJmhmX2lzY3NpX0V2ZW50VmVuZG9yQ29kZSwNCgkgIHsgIkV2ZW50VmVuZG9yQ29k ZSIsICJpc2NzaS5ldmVudHZlbmRvcmNvZGUiLA0KCSAgICBGVF9VSU5UOCwgQkFTRV9IRVgs IE5VTEwsIDAsDQoJICAgICJFdmVudCB2ZW5kb3IgY29kZSIsIEhGSUxMIH0NCgl9LA0KCXsg JmhmX2lzY3NpX1BhcmFtZXRlcjEsDQoJICB7ICJQYXJhbWV0ZXIxIiwgImlzY3NpLnBhcmFt ZXRlcjEiLA0KCSAgICBGVF9VSU5UMTYsIEJBU0VfSEVYLCBOVUxMLCAwLA0KCSAgICAiUGFy YW1ldGVyIDEiLCBIRklMTCB9DQoJfSwNCgl7ICZoZl9pc2NzaV9QYXJhbWV0ZXIyLA0KCSAg eyAiUGFyYW1ldGVyMiIsICJpc2NzaS5wYXJhbWV0ZXIyIiwNCgkgICAgRlRfVUlOVDE2LCBC QVNFX0hFWCwgTlVMTCwgMCwNCgkgICAgIlBhcmFtZXRlciAyIiwgSEZJTEwgfQ0KCX0sDQoJ eyAmaGZfaXNjc2lfUGFyYW1ldGVyMywNCgkgIHsgIlBhcmFtZXRlcjMiLCAiaXNjc2kucGFy YW1ldGVyMyIsDQoJICAgIEZUX1VJTlQxNiwgQkFTRV9IRVgsIE5VTEwsIDAsDQoJICAgICJQ YXJhbWV0ZXIgMyIsIEhGSUxMIH0NCgl9LA0KCXsgJmhmX2lzY3NpX1JlamVjdF9SZWFzb24s DQoJICB7ICJSZWFzb24iLCAiaXNjc2kucmVqZWN0LnJlYXNvbiIsDQoJICAgIEZUX1VJTlQ4 LCBCQVNFX0hFWCwgVkFMUyhpc2NzaV9yZWplY3RfcmVhc29ucyksIDAsDQoJICAgICJSZWFz b24gZm9yIGNvbW1hbmQgcmVqZWN0aW9uIiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lf c25hY2tfdHlwZSwNCgkgIHsgIlMiLCAiaXNjc2kuc25hY2sudHlwZSIsDQoJICAgIEZUX1VJ TlQ4LCBCQVNFX0RFQywgVkFMUyhpc2NzaV9zbmFja190eXBlcyksIDB4MGYsICAgICAgICAg IA0KCSAgICAiVHlwZSBvZiBTTkFDSyByZXF1ZXN0ZWQiLCBIRklMTCB9DQoJfSwNCgl7ICZo Zl9pc2NzaV9CZWdSdW4sDQoJICB7ICJCZWdSdW4iLCAiaXNjc2kuc25hY2suYmVncnVuIiwN CgkgICAgRlRfVUlOVDMyLCBCQVNFX0hFWCwgTlVMTCwgMCwNCgkgICAgIkZpcnN0IG1pc3Nl ZCBEYXRhU04gb3IgU3RhdFNOIiwgSEZJTEwgfQ0KCX0sDQoJeyAmaGZfaXNjc2lfUnVuTGVu Z3RoLA0KCSAgeyAiUnVuTGVuZ3RoIiwgImlzY3NpLnNuYWNrLnJ1bmxlbmd0aCIsDQoJICAg IEZUX1VJTlQzMiwgQkFTRV9IRVgsIE5VTEwsIDAsDQoJICAgICJOdW1iZXIgb2YgYWRkaXRp b25hbCBtaXNzaW5nIHN0YXR1cyBQRFVzIGluIHRoaXMgcnVuIiwgSEZJTEwgfQ0KCX0sDQog ICAgfTsNCg0KICAgIC8qIFNldHVwIHByb3RvY29sIHN1YnRyZWUgYXJyYXkgKi8NCiAgICBz dGF0aWMgZ2ludCAqZXR0W10gPSB7DQoJJmV0dF9pc2NzaV9LZXlWYWx1ZXMsDQoJJmV0dF9p c2NzaV9DREIsDQoJJmV0dF9pc2NzaV9GbGFncywNCiAgICB9Ow0KDQogICAgLyogUmVnaXN0 ZXIgdGhlIHByb3RvY29sIG5hbWUgYW5kIGRlc2NyaXB0aW9uICovDQogICAgcHJvdG9faXNj c2kgPSBwcm90b19yZWdpc3Rlcl9wcm90b2NvbCgiaVNDU0kiLCAiSVNDU0kiLCAiaXNjc2ki KTsNCg0KICAgIC8qIFJlcXVpcmVkIGZ1bmN0aW9uIGNhbGxzIHRvIHJlZ2lzdGVyIHRoZSBo ZWFkZXIgZmllbGRzIGFuZA0KICAgICAqIHN1YnRyZWVzIHVzZWQgKi8NCiAgICBwcm90b19y ZWdpc3Rlcl9maWVsZF9hcnJheShwcm90b19pc2NzaSwgaGYsIGFycmF5X2xlbmd0aChoZikp Ow0KICAgIHByb3RvX3JlZ2lzdGVyX3N1YnRyZWVfYXJyYXkoZXR0LCBhcnJheV9sZW5ndGgo ZXR0KSk7DQoNCiAgICB7DQoJbW9kdWxlX3QgKmlzY3NpX21vZHVsZSA9IHByZWZzX3JlZ2lz dGVyX3Byb3RvY29sKHByb3RvX2lzY3NpLCBOVUxMKTsNCg0KCXByZWZzX3JlZ2lzdGVyX2Jv b2xfcHJlZmVyZW5jZShpc2NzaV9tb2R1bGUsDQoJCQkJICAgICAgICJkZXNlZ21lbnRfaXNj c2lfbWVzc2FnZXMiLA0KCQkJCSAgICAgICAiRGVzZWdtZW50IGlTQ1NJIG1lc3NhZ2VzIiwN CgkJCQkgICAgICAgIldoZW4gZW5hYmxlZCwgaVNDU0kgbWVzc2FnZXMgdGhhdCBzcGFuIG11 bHRpcGxlIFRDUCBzZWdtZW50cyBhcmUgZGVzZWdtZW50ZWQiLA0KCQkJCSAgICAgICAmaXNj c2lfZGVzZWdtZW50KTsNCg0KCXByZWZzX3JlZ2lzdGVyX2Jvb2xfcHJlZmVyZW5jZShpc2Nz aV9tb2R1bGUsDQoJCQkJICAgICAgICJib2d1c19wZHVfZmlsdGVyIiwgDQoJCQkJICAgICAg ICJFbmFibGUgYm9ndXMgcGR1IGZpbHRlciIsDQoJCQkJICAgICAgICJXaGVuIGVuYWJsZWQs IHBhY2tldHMgdGhhdCBhcHBlYXIgYm9ndXMgYXJlIGlnbm9yZWQiLA0KCQkJCSAgICAgICAm ZW5hYmxlX2JvZ29zaXR5X2ZpbHRlcik7DQoNCglwcmVmc19yZWdpc3Rlcl91aW50X3ByZWZl cmVuY2UoaXNjc2lfbW9kdWxlLA0KCQkJCSAgICAgICAiYm9ndXNfcGR1X21heF9kYXRhX2xl biIsIA0KCQkJCSAgICAgICAiQm9ndXMgcGR1IG1heCBkYXRhIGxlbmd0aCB0aHJlc2hvbGQi LA0KCQkJCSAgICAgICAiVHJlYXQgcGFja2V0cyB3aG9zZSBkYXRhIHNlZ21lbnQgbGVuZ3Ro IGlzIGdyZWF0ZXIgdGhhbiB0aGlzIHZhbHVlIGFzIGJvZ3VzIiwNCgkJCQkgICAgICAgMTAs DQoJCQkJICAgICAgICZib2d1c19wZHVfZGF0YV9sZW5ndGhfdGhyZXNob2xkKTsNCg0KCXBy ZWZzX3JlZ2lzdGVyX3VpbnRfcHJlZmVyZW5jZShpc2NzaV9tb2R1bGUsDQoJCQkJICAgICAg ICJpc2NzaV9wb3J0IiwgDQoJCQkJICAgICAgICJUYXJnZXQgcG9ydCIsDQoJCQkJICAgICAg ICJQb3J0IG51bWJlciBvZiBpU0NTSSB0YXJnZXQiLA0KCQkJCSAgICAgICAxMCwNCgkJCQkg ICAgICAgJmlzY3NpX3BvcnQpOw0KDQoJcHJlZnNfcmVnaXN0ZXJfYm9vbF9wcmVmZXJlbmNl KGlzY3NpX21vZHVsZSwNCgkJCQkgICAgICAgImVuYWJsZV9oZWFkZXJfZGlnZXN0cyIsIA0K CQkJCSAgICAgICAiRW5hYmxlIGhlYWRlciBkaWdlc3RzIiwNCgkJCQkgICAgICAgIldoZW4g ZW5hYmxlZCwgcGR1cyBhcmUgYXNzdW1lZCB0byBjb250YWluIGEgaGVhZGVyIGRpZ2VzdCIs DQoJCQkJICAgICAgICZlbmFibGVIZWFkZXJEaWdlc3RzKTsNCglwcmVmc19yZWdpc3Rlcl9i b29sX3ByZWZlcmVuY2UoaXNjc2lfbW9kdWxlLA0KCQkJCSAgICAgICAiZW5hYmxlX2RhdGFf ZGlnZXN0cyIsIA0KCQkJCSAgICAgICAiRW5hYmxlIGRhdGEgZGlnZXN0cyIsDQoJCQkJICAg ICAgICJXaGVuIGVuYWJsZWQsIHBkdXMgYXJlIGFzc3VtZWQgdG8gY29udGFpbiBhIGRhdGEg ZGlnZXN0IiwNCgkJCQkgICAgICAgJmVuYWJsZURhdGFEaWdlc3RzKTsNCg0KCXByZWZzX3Jl Z2lzdGVyX2Jvb2xfcHJlZmVyZW5jZShpc2NzaV9tb2R1bGUsDQoJCQkJICAgICAgICJoZWFk ZXJfZGlnZXN0X2lzX2NyYzMyYyIsIA0KCQkJCSAgICAgICAiSGVhZGVyIGRpZ2VzdCBpcyBD UkMzMkMiLA0KCQkJCSAgICAgICAiV2hlbiBlbmFibGVkLCBoZWFkZXIgZGlnZXN0cyBhcmUg YXNzdW1lZCB0byBiZSBDUkMzMkMiLA0KCQkJCSAgICAgICAmaGVhZGVyRGlnZXN0SXNDUkMz Mik7DQoJcHJlZnNfcmVnaXN0ZXJfYm9vbF9wcmVmZXJlbmNlKGlzY3NpX21vZHVsZSwNCgkJ CQkgICAgICAgImRhdGFfZGlnZXN0X2lzX2NyYzMyYyIsIA0KCQkJCSAgICAgICAiRGF0YSBk aWdlc3QgaXMgQ1JDMzJDIiwNCgkJCQkgICAgICAgIldoZW4gZW5hYmxlZCwgZGF0YSBkaWdl c3RzIGFyZSBhc3N1bWVkIHRvIGJlIENSQzMyQyIsDQoJCQkJICAgICAgICZkYXRhRGlnZXN0 SXNDUkMzMik7DQoNCglwcmVmc19yZWdpc3Rlcl91aW50X3ByZWZlcmVuY2UoaXNjc2lfbW9k dWxlLA0KCQkJCSAgICAgICAiaGVhZGVyX2RpZ2VzdF9zaXplIiwgDQoJCQkJICAgICAgICJI ZWFkZXIgZGlnZXN0IHNpemUiLA0KCQkJCSAgICAgICAiVGhlIHNpemUgb2YgYSBoZWFkZXIg ZGlnZXN0IChieXRlcykiLA0KCQkJCSAgICAgICAxMCwNCgkJCQkgICAgICAgJmhlYWRlckRp Z2VzdFNpemUpOw0KCXByZWZzX3JlZ2lzdGVyX3VpbnRfcHJlZmVyZW5jZShpc2NzaV9tb2R1 bGUsDQoJCQkJICAgICAgICJkYXRhX2RpZ2VzdF9zaXplIiwgDQoJCQkJICAgICAgICJEYXRh IGRpZ2VzdCBzaXplIiwNCgkJCQkgICAgICAgIlRoZSBzaXplIG9mIGEgZGF0YSBkaWdlc3Qg KGJ5dGVzKSIsDQoJCQkJICAgICAgIDEwLA0KCQkJCSAgICAgICAmZGF0YURpZ2VzdFNpemUp Ow0KICAgIH0NCn0NCg0KDQovKg0KICogSWYgdGhpcyBkaXNzZWN0b3IgdXNlcyBzdWItZGlz c2VjdG9yIHJlZ2lzdHJhdGlvbiBhZGQgYQ0KICogcmVnaXN0cmF0aW9uIHJvdXRpbmUuDQog Ki8NCg0KLyoNCiAqIFRoaXMgZm9ybWF0IGlzIHJlcXVpcmVkIGJlY2F1c2UgYSBzY3JpcHQg aXMgdXNlZCB0byBmaW5kIHRoZXNlDQogKiByb3V0aW5lcyBhbmQgY3JlYXRlIHRoZSBjb2Rl IHRoYXQgY2FsbHMgdGhlc2Ugcm91dGluZXMuDQogKi8NCnZvaWQNCnByb3RvX3JlZ19oYW5k b2ZmX2lzY3NpKHZvaWQpDQp7DQogICAgaGV1cl9kaXNzZWN0b3JfYWRkKCJ0Y3AiLCBkaXNz ZWN0X2lzY3NpLCBwcm90b19pc2NzaSk7DQp9DQo= ----Next_Part(Sun_Oct_21_11:23:05_2001_533)---- From owner-ips@ece.cmu.edu Sun Oct 21 13:53: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 NAA15701 for ; Sun, 21 Oct 2001 13:53:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9LHSmc18047 for ips-outgoing; Sun, 21 Oct 2001 13:28:48 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f9LHKrl17573 for ; Sun, 21 Oct 2001 13:20:54 -0400 (EDT) Received: (qmail 3788 invoked from network); 21 Oct 2001 17:20:51 -0000 Received: from prop.sonic.net (208.201.224.193) by marine.sonic.net with SMTP; 21 Oct 2001 17:20:51 -0000 Received: from quadrajet.sonic.net (adsl-209-204-185-65.sonic.net [209.204.185.65]) by prop.sonic.net (8.11.6/8.8.5) with ESMTP id f9LHKoU24018; Sun, 21 Oct 2001 10:20:50 -0700 X-envelope-info: Received: (from guy@localhost) by quadrajet.sonic.net (8.9.3/8.9.3) id KAA09682; Sun, 21 Oct 2001 10:20:49 -0700 (PDT) (envelope-from gharris) Date: Sun, 21 Oct 2001 10:20:49 -0700 From: Guy Harris To: Mark Burton Cc: ethereal-dev@ethereal.com, ips@ece.cmu.edu Subject: Re: [Ethereal-dev] Improved iSCSI dissector Message-ID: <20011021102049.A334@quadrajet.sonic.net> References: <20011021.112305.635728618.markb@ordern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20011021.112305.635728618.markb@ordern.com>; from markb@ordern.com on Sun, Oct 21, 2001 at 11:23:05AM +0100 Sender: owner-ips@ece.cmu.edu Precedence: bulk On Sun, Oct 21, 2001 at 11:23:05AM +0100, Mark Burton wrote: > The enclosed code contains the following improvements: Checked in (with your subsequent patch added). From owner-ips@ece.cmu.edu Sun Oct 21 13:54: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 NAA15714 for ; Sun, 21 Oct 2001 13:54:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9LH38k16607 for ips-outgoing; Sun, 21 Oct 2001 13:03:08 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9LH36l16602 for ; Sun, 21 Oct 2001 13:03:06 -0400 (EDT) Received: from ordern.demon.co.uk ([158.152.10.215]) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 15vM09-000LHO-0K; Sun, 21 Oct 2001 17:03:05 +0000 Received: from localhost(rook.ordern.com[192.168.1.1]) (1236 bytes) by ordern.demon.co.uk via smtpd with P:esmtp/R:smart_host/T:smtp (sender: ) id for ; Sun, 21 Oct 2001 18:03:04 +0100 (BST) (Smail-3.2.0.108 1999-Sep-19 #7 built 2000-Feb-18) Date: Sun, 21 Oct 2001 18:03:03 +0100 (BST) Message-Id: <20011021.180303.756901484.markb@ordern.com> To: ethereal-dev@ethereal.com Cc: ips@ece.cmu.edu Subject: Re: Improved iSCSI dissector From: Mark Burton In-Reply-To: <20011021.112305.635728618.markb@ordern.com> References: <20011021.112305.635728618.markb@ordern.com> X-Mailer: Mew version 2.0 on XEmacs 21.4.4 (Artificial Intelligence) 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 Embarrassingly, my previous post contained a small, but significant bug. Please apply the enclosed patch to packet-iscsi.c. Silly me. Mark --- packet-iscsi.c- Sun Oct 21 11:24:06 2001 +++ packet-iscsi.c Sun Oct 21 17:51:38 2001 @@ -1212,6 +1212,8 @@ } dissect_iscsi_pdu(tvb, pinfo, tree, offset, opcode, opcode_str, data_segment_len); + if(pduLen > available_bytes) + pduLen = available_bytes; offset += pduLen; available_bytes -= pduLen; ++iSCSIPdusDissected; From owner-ips@ece.cmu.edu Mon Oct 22 04:14: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 EAA08794 for ; Mon, 22 Oct 2001 04:14:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9M7Cff02739 for ips-outgoing; Mon, 22 Oct 2001 03:12:41 -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 ([203.190.136.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9M7CTl02714 for ; Mon, 22 Oct 2001 03:12:38 -0400 (EDT) Received: by DCMTECHDOM with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Oct 2001 12:44:48 +0530 Message-ID: <7FADCB99FC82D41199F9000629A85D1A0293A537@DCMTECHDOM> From: Nitin Dhingra To: ips@ece.cmu.edu Subject: how much "Desired Data Transfer Length" in R2T Date: Mon, 22 Oct 2001 12:44:46 +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 How is the target going to decide how much "desired data transfer length" he has to fill apart from the negotiated "DataPDULength". Thanks in advance, nitin From owner-ips@ece.cmu.edu Mon Oct 22 07:25: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 HAA11126 for ; Mon, 22 Oct 2001 07:25:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MAsof24144 for ips-outgoing; Mon, 22 Oct 2001 06:54:50 -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 ([203.190.136.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9MAskl24139 for ; Mon, 22 Oct 2001 06:54:47 -0400 (EDT) Received: by DCMTECHDOM with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Oct 2001 16:27:05 +0530 Message-ID: <7FADCB99FC82D41199F9000629A85D1A0293A53D@DCMTECHDOM> From: Nitin Dhingra To: "'Subrahmanya Sastry K.V'" , Nitin Dhingra Cc: ips@ece.cmu.edu Subject: RE: how much "Desired Data Transfer Length" in R2T Date: Mon, 22 Oct 2001 16:27:00 +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 Hi sastry, What you specified is during negotiation, I am referring to after the negotiation, when DataPDULength has been decided. But Later when R2T's needs to be send from target, examples have been given in the draft that depicts one R2T is sent from the target and it receives 2 Data PDU's. It means that target specified more size than DataPDULength in the R2T, on what basis did the target decide that. Thanks, nitin -----Original Message----- From: Subrahmanya Sastry K.V [mailto:skotra@npd.hcltech.com] Sent: Monday, October 22, 2001 3:32 AM To: Nitin Dhingra Cc: ips@ece.cmu.edu Subject: Re: how much "Desired Data Transfer Length" in R2T Nitin, I think the "Desired Data Tranfer Length" field of R2T PDU should be equal to the DataPDULength value that the initiator has sent to the target during text parameter negotiation. Since the DataPDULength can be different in the two directions, the initiator sends this value to the target as DataPDULength=. So the initiator only sends/receives a PDU having length less than or equal to the negotiated DataPDULength (non-zero). Any comments are welcome.. Sastry Nitin Dhingra wrote: > How is the target going to decide how much "desired data transfer length" he > has > to fill apart from the negotiated "DataPDULength". > > Thanks in advance, > nitin From owner-ips@ece.cmu.edu Mon Oct 22 07:37: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 HAA11392 for ; Mon, 22 Oct 2001 07:37:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MAbuJ23369 for ips-outgoing; Mon, 22 Oct 2001 06:37:56 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f9MAbMl23343 for ; Mon, 22 Oct 2001 06:37:30 -0400 (EDT) Received: from npd.hcltech.com (skotra-pc.hcltech.com [192.168.100.57]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id f9MAXwJ20293; Mon, 22 Oct 2001 16:04:05 +0530 Message-ID: <3BD3F5B3.56EC8370@npd.hcltech.com> Date: Mon, 22 Oct 2001 16:02:19 +0530 From: "Subrahmanya Sastry K.V" Organization: HCL X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nitin Dhingra CC: ips@ece.cmu.edu Subject: Re: how much "Desired Data Transfer Length" in R2T References: <7FADCB99FC82D41199F9000629A85D1A0293A537@DCMTECHDOM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nitin, I think the "Desired Data Tranfer Length" field of R2T PDU should be equal to the DataPDULength value that the initiator has sent to the target during text parameter negotiation. Since the DataPDULength can be different in the two directions, the initiator sends this value to the target as DataPDULength=. So the initiator only sends/receives a PDU having length less than or equal to the negotiated DataPDULength (non-zero). Any comments are welcome.. Sastry Nitin Dhingra wrote: > How is the target going to decide how much "desired data transfer length" he > has > to fill apart from the negotiated "DataPDULength". > > Thanks in advance, > nitin From owner-ips@ece.cmu.edu Mon Oct 22 08: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 IAA12857 for ; Mon, 22 Oct 2001 08:22:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MBc7526322 for ips-outgoing; Mon, 22 Oct 2001 07:38:07 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f9MBbhl26302 for ; Mon, 22 Oct 2001 07:37:48 -0400 (EDT) Received: from npd.hcltech.com (skotra-pc.hcltech.com [192.168.100.57]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id f9MBTFJ22463; Mon, 22 Oct 2001 16:59:25 +0530 Message-ID: <3BD402A8.FFDE4CE8@npd.hcltech.com> Date: Mon, 22 Oct 2001 16:57:36 +0530 From: "Subrahmanya Sastry K.V" Organization: HCL X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nitin Dhingra CC: ips@ece.cmu.edu Subject: Re: how much "Desired Data Transfer Length" in R2T References: <7FADCB99FC82D41199F9000629A85D1A0293A53D@DCMTECHDOM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Nitin, It seems that the case you mentioned (send R2T, get two Data PDUs) can happen when the DataPDULength value of the target is greater than the DataPDULength value of the initiator because the minimum of the two DataPDULengths is selected. In that case, the target may get more than one DataPDU in response to one R2T. The target knows the end of data when the F bit is set in the DataPDU that it receives. Any more comments? Sastry Nitin Dhingra wrote: > Hi sastry, > What you specified is during negotiation, I am referring to after the > negotiation, when > DataPDULength has been decided. But Later when R2T's needs to be send from > target, > examples have been given in the draft that depicts one R2T is sent from the > target and it receives > 2 Data PDU's. It means that target specified more size than DataPDULength > in the R2T, on what > basis did the target decide that. > > Thanks, > nitin > From owner-ips@ece.cmu.edu Mon Oct 22 08:35: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 IAA13500 for ; Mon, 22 Oct 2001 08:35:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MC2Uw27631 for ips-outgoing; Mon, 22 Oct 2001 08:02:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9MC2Sl27624; Mon, 22 Oct 2001 08:02:28 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id GAA39666; Mon, 22 Oct 2001 06:59:57 -0500 Received: from d04nms27.raleigh.ibm.com (d04nms27.raleigh.ibm.com [9.67.228.30]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9MC2QP104574; Mon, 22 Oct 2001 08:02:26 -0400 Subject: RE: iSCSI: Login authentication SRP/CHAP To: "Bill Strahm" Cc: "IPS Reflector \(E-mail\)" , "John Hufferd" , owner-ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Joe Czap" Date: Mon, 22 Oct 2001 08:02:40 -0400 X-MIMETrack: Serialize by Router on D04NMS27/04/M/IBM(Release 5.0.8 |June 18, 2001) at 10/22/2001 08:02:26 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk The lack of information relating to SRP IP concerns make the issue seem a little like misdirection. Can anyone offer a clear explanation the SRP IP situation ? Joe Czap IBM Storage Networking zapper@us.ibm.com From owner-ips@ece.cmu.edu Mon Oct 22 09: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 JAA16557 for ; Mon, 22 Oct 2001 09:39:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MCena29767 for ips-outgoing; Mon, 22 Oct 2001 08:40:49 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web14507.mail.yahoo.com (web14507.mail.yahoo.com [216.136.224.70]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f9MCell29763 for ; Mon, 22 Oct 2001 08:40:47 -0400 (EDT) Message-ID: <20011022124045.81302.qmail@web14507.mail.yahoo.com> Received: from [192.9.25.11] by web14507.mail.yahoo.com via HTTP; Mon, 22 Oct 2001 05:40:45 PDT Date: Mon, 22 Oct 2001 05:40:45 -0700 (PDT) From: S T Subject: remove To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-ips@ece.cmu.edu Mon Oct 22 10: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 KAA18331 for ; Mon, 22 Oct 2001 10:24:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MDGqk02063 for ips-outgoing; Mon, 22 Oct 2001 09:16:52 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f9MDGil02051 for ; Mon, 22 Oct 2001 09:16:45 -0400 (EDT) Received: from npd.hcltech.com (skotra-pc.hcltech.com [192.168.100.57]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id f9MDFYJ26391; Mon, 22 Oct 2001 18:45:35 +0530 Message-ID: <3BD41B94.D2DC1D4F@npd.hcltech.com> Date: Mon, 22 Oct 2001 18:43:56 +0530 From: "Subrahmanya Sastry K.V" Organization: HCL X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nitin Dhingra CC: ips@ece.cmu.edu Subject: Re: how much "Desired Data Transfer Length" in R2T References: <7FADCB99FC82D41199F9000629A85D1A0293A53D@DCMTECHDOM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit inline Nitin Dhingra wrote: > Hi sastry, > What you specified is during negotiation, I am referring to after the > negotiation, when > DataPDULength has been decided. But Later when R2T's needs to be send from > target, > examples have been given in the draft that depicts one R2T is sent from the > target and it receives > 2 Data PDU's. It means that target specified more size than DataPDULength > in the R2T, As per section 3.8 of iscsi-draft-08: "The data length of the Data PDU MUST not exceed the Desired Data Transfer Length specified in the R2T. " This means that the target may mention a greater value for Desired Data Transfer Length than the initiator can send at a time i.e., the DataPDULength of the initiator. In that case the data lengths of one or more Data PDUs (from the initiator) add up to the value of Desired Data Transfer Length. This is indicated by the F bit of the last Data PDU set to 1. Suppose the initiator has the DataPDULength of 5k. The target asked for 10k (Desired Data Tranfer Length) and sent an R2T. Now the initiator sends two DataPDUs of data length 5k each to fulfill the request. > on what > basis did the target decide that. > > Thanks, > nitin This is what I understood. comments ? Sastry From owner-ips@ece.cmu.edu Mon Oct 22 11:26: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 LAA19897 for ; Mon, 22 Oct 2001 11:26:13 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MEHbb06839 for ips-outgoing; Mon, 22 Oct 2001 10:17:37 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gda-server ([202.88.152.146]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9MEHQl06825 for ; Mon, 22 Oct 2001 10:17:28 -0400 (EDT) Received: from [192.168.0.54] by gda-server (ArGoSoft Mail Server, Version 1.5 (1.5.0.8)); Mon, 22 Oct 2001 19:20:51 Message-ID: <007e01c15b01$be71aba0$3600a8c0@benjamin> From: "Benjamin" To: References: <20011022124045.81302.qmail@web14507.mail.yahoo.com> Subject: remove Date: Mon, 22 Oct 2001 19:29:17 +0530 Organization: GDA Technologies Limited, Chennai. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit remove From owner-ips@ece.cmu.edu Mon Oct 22 11:32: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 LAA20055 for ; Mon, 22 Oct 2001 11:32:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MEOUP07351 for ips-outgoing; Mon, 22 Oct 2001 10:24:30 -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 f9MEOSl07344 for ; Mon, 22 Oct 2001 10:24:28 -0400 (EDT) Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.44 2001/10/01 19:10:43 root Exp $) with SMTP id OAA27078 for ; Mon, 22 Oct 2001 14:24:26 GMT Received: from FMSMSX016.fm.intel.com ([132.233.42.195]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.6) with SMTP id M2001102207234200144 for ; Mon, 22 Oct 2001 07:23:42 -0700 Received: by fmsmsx016.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Oct 2001 07:22:56 -0700 Message-ID: From: "Harbin, Donald B" To: ips@ece.cmu.edu Subject: remove Date: Mon, 22 Oct 2001 07:27:50 -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 Mon Oct 22 12:18: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 MAA21716 for ; Mon, 22 Oct 2001 12:18:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MF55N10629 for ips-outgoing; Mon, 22 Oct 2001 11:05:05 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from gbo827n.gillette.com ([151.208.27.19]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9MF52l10620 for ; Mon, 22 Oct 2001 11:05:02 -0400 (EDT) Subject: remove To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.2a (Intl) 23 November 1999 Message-ID: From: Christopher_DelBrocco@gillette.com Date: Mon, 22 Oct 2001 10:39:23 -0400 X-MIMETrack: Serialize by Router on GBO827N/BO/Gillette(Release 5.0.5 |September 22, 2000) at 10/22/2001 11:05:01 AM MIME-Version: 1.0 Sender: owner-ips@ece.cmu.edu Precedence: bulk From owner-ips@ece.cmu.edu Mon Oct 22 13:08: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 NAA23856 for ; Mon, 22 Oct 2001 13:08:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MFknm14017 for ips-outgoing; Mon, 22 Oct 2001 11:46:49 -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 f9MFkll14011 for ; Mon, 22 Oct 2001 11:46: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 IAA03065; Mon, 22 Oct 2001 08:46:39 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWV9PGS>; Mon, 22 Oct 2001 08:46:37 -0700 Message-ID: From: Robert Snively To: ips@ece.cmu.edu, "'Julian Satran'" Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU Date: Mon, 22 Oct 2001 08:46:35 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Weren't all the other ordering issues associated with sessions (like CSN for example)? Doesn't that interact with the requirements for ordering of immediate data? As far as I can see, the ordering becomes significantly less important at the connection level because the session level management has to take things out of order in any case. Bob > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, October 20, 2001 3:18 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU > > > > Robert, > > The ordering rule is for a connection (not for a session). It's sole > purpose is to minimize the chance for a deadlock. > > Regards, > Julo > > > > > Robert Snively > > Harrison'" > ade.com> > , Julian > > Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > 16-10-01 18:02 cc: > > Please respond Subject: RE: > iSCSI: Addition of CmdSN in > to Robert Data-out PDU > > Snively > > > > > > > > > I am not quite sure what meaning "in-order" data has in > a multi-connection session. Does it mean that you actually > expect the data across multiple connections to arrive temporally > in the same order that is specified by the command sequence > numbers? Or does it mean that the data has to be arranged > in some order by the target session processing? > > Or is it better to step aside from the in-order question > for data transmission and do as Rob Harrison suggests: > > "As an initiator I would send the command PDU as soon as > I could if there were no immediate data, then queue the > DMA for the unsolicited data. Since there could be many > other DMAs queued ahead of the unsolicited data it is quite > possible that other commands, both read and write, will > be sent before the DMA completes." > > This would imply no strict ordering requirement. > > If an ordering requirement is necessary, I submit that it > is because of the problems with unsolicited data reception, > not with the actual data order. > > Bob > > > -----Original Message----- > > From: Rod Harrison [mailto:rod.harrison@windriver.com] > > Sent: Monday, October 15, 2001 4:06 AM > > To: Julian Satran; ips@ece.cmu.edu > > Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU > > > > > > Julian, > > > > I think you might have misunderstood what I meant. > I was not > > advocating we change the spec in favour of relaxing the > data ordering > > requirements. I was just point out there is a problem for the > > initiator to solve in order maintain correct ordering, and that I > > believe it is not a terribly difficult one. > > > > - Rod > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Sunday, October 14, 2001 9:30 PM > > To: ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > Immediate data are not mandatory (even if enabled). Having > one or ten > > DMAs > > does not change the fact that they share a TCP "pipe" and a decent > > transmitter will ship the TCP data in order - otherwise it > just throws > > his > > problems in the receiver's lap. Our additional requirement on order > > should > > make no difference. And it would be time to change the name of the > > thread. > > > > Julo > > > > > > > > > > > > "Rod Harrison" > > Hufferd/San > > Jose/IBM@IBMUS, "Robert > > river.com> Snively" > > > > Sent by: cc: > > , > > owner-ips@ece.cmu. "BURBRIDGE,MATTHEW > > (HP-UnitedKingdom,ex2)" > > edu > > , "'Binford, Charles'" > > , > > > > Subject: > RE: Addition > > of CmdSN in Data-out PDU > > 13-10-01 13:12 > > Please respond to > > "Rod Harrison" > > > > > > > > > > > > > > Even more common would be the DMA latency. As an > initiator > > I > > would > > send the command PDU as soon as I could if there were no immediate > > data, then queue the DMA for the unsolicited data. Since there could > > be many other DMAs queued ahead of the unsolicited data it is quite > > possible that other commands, both read and write, will be > sent before > > the DMA completes. > > > > You are spot one when you say the delay in obtaining the > > unsolicited > > data may be large and variable. If there are multiple DMA engines it > > does become a challenge for the initiator to ensure the correct > > ordering of the unsolicited data. Note that since there may be > > multiple unsolicited data PDUs in the same burst, and those may be > > filled with separate DMAs the ordering problem propagates down to > > within individual commands. > > > > I don't believe it is a particularly difficult > problem for > > the > > initiator to solve, but I do agree things would be easier for the > > initiator if the ordering requirement were removed. And > more so if the > > requirement to send in dataSN order were also removed, but this is > > probably too much pain for the target. > > > > - Rod > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > John Hufferd > > Sent: Saturday, October 13, 2001 1:01 AM > > To: Robert Snively > > Cc: 'somesh_gupta@silverbacksystems.com'; BURBRIDGE,MATTHEW > > (HP-UnitedKingdom,ex2); 'Binford, Charles'; ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > Robert, > > I think that an Initiator being able to send a waiting Read command, > > without having to wait for many large write segments -- > that are being > > sent > > (as unsolicited data) -- is very useful. And that would mean, the > > unsolicited data is waiting to be sent until the Read Commands are > > sent. > > This might be a very frequent case. > > > > . > > . > > . > > 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 10/12/2001 > > 03:56:06 PM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: "'somesh_gupta@silverbacksystems.com'" > > , "BURBRIDGE,MATTHEW > > (HP-UnitedKingdom,ex2)" , "'Binford, > > Charles'" , ips@ece.cmu.edu > > cc: > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > I have two small questions that would help me understand this. > > > > How do you know that unsolicited data is expected? By nature, > > unsolicited data is received as a "maximum surprise" which can > > only be determined after unpacking and parsing at least a > > part of the command structure, possibly even including the > > SCSI command (although there are some hints contained in the > > command header information). > > > > How can you constrain a generic system to posting the > > unsolicited data in the same order that the commands were > > emitted? In general, I would have expected the system to > > be emitting command followed immediately by the corresponding > > unsolicited data. If that is not the case, it means that there > > was a delay in obtaining the unsolicited data for transfer and > > that the delay was sufficient to allow the insertion of commands. > > If the delay is that large (and probably variable), the enforcement > > of transfer of unsolicited data in the same order as the > > commands are emitted seems to me to be a significant challenge, > > and certainly shouldn't be required as normal behavior. While it > > would make things simpler for targets (already challenged by > > unsolicited data), it seems to me that it would make things > > much more complex for initiators. > > > > Bob > > > > > -----Original Message----- > > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > > > Sent: Friday, October 12, 2001 2:51 PM > > > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > > > ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > Matthew, > > > > > > Since the unsolicited data does not follow the > > > command, you need the link list. But since the > > > unsolicited data must be sent in the same order > > > as the commands, a link list is enough. > > > > > > Let us say that you have 8 commands. The ones > > > for which we expect unsolicted data are marked > > > as Cnn(ud). And I have marked the unsolicted > > > data PDUs as UD(nn). The (nn) with data implies > > > that it is implicit and not actually carried with > > > the PDU itself. > > > > > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > > > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > > > --> UD(07) C08(ud) UD(08) ---> > > > > > > After the target receives the command C01, C02, and C03 > > > for which it expects unsolicited data, it puts them in > > > a link list. It also receives C04 and C05 for which > > > unsolicited data is not expected and they don't go > > > on the list. It then receives C06 for which unsolicited > > > data is expected, and it is added to then end of the list. > > > Then an unsolicited data PDU is received. It must go > > > with the command at the head of the list which is C01. > > > Use the ITT to make sure and you can then take C01 off > > > the list and so on. > > > > > > Somesh > > > > > > > > > > -----Original Message----- > > > > From: owner-ips@ece.cmu.edu > > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > > > Sent: Friday, October 12, 2001 7:53 AM > > > > To: 'Binford, Charles'; ips@ece.cmu.edu > > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > > > > Charles, > > > > > > > > As you have described the spec states that "that > > > unsolicited data MUST be > > > > sent in the same order as the commands". This is not > the same as > > > > unsolicited data must follow the command associated with > > > it: For example: > > > > > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > > > x in all the > > > > example can be the ITT. It is not the CmdSN. > > > > > > > > This is allowed: > > > > > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > > > > > and the target will have to use the ITT to associate the > > > data with the > > > > command. > > > > > > > > Matthew > > > > > > > > > > > > -----Original Message----- > > > > From: Binford, Charles [mailto:CBinford@pirus.com] > > > > Sent: Friday, October 12, 2001 2:50 PM > > > > To: ips@ece.cmu.edu > > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > > > > I have not verify version 8 is still the same, but version 07-97 > > > > had a rule > > > > that unsolicited data MUST be sent in the same order as the > > > commands. > > > > > > > > Thus, there is no need for a search on the ITT. The target > > > just needs to > > > > keep of linked list of I/Os waiting on unsolicited data. > > > New commands are > > > > added to the tail, any unsolicited data *should* be associated > > > > with the I/O > > > > at the head of the list. The ITT is used as a sanity check and > > > > you're done. > > > > > > > > What am I missing? > > > > > > > > Charles Binford > > > > Pirus Networks > > > > 316.315.0382 x222 > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon Oct 22 13:22: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 NAA24178 for ; Mon, 22 Oct 2001 13:22:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MGver19489 for ips-outgoing; Mon, 22 Oct 2001 12:57: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 f9MGvcl19485 for ; Mon, 22 Oct 2001 12:57: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 SAA49058 for ; Mon, 22 Oct 2001 18:57: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 f9MGvV890630 for ; Mon, 22 Oct 2001 18:57:31 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: ips : key response "NotUnderstood". X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Mon, 22 Oct 2001 19:57:29 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/10/2001 19:57:30, Serialize complete at 22/10/2001 19:57:30 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, Those have been fixed in a version of 2.2.4 that I've sent out to the list a while ago. Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 16-10-01 23:29 Please respond to Santosh Rao To: IPS Reflector cc: Subject: ips : key response "NotUnderstood". Julian, I suggest that the below quoted text in the draft be re-phrased to state it in terms of "originating party" and "responding party", since the target may originate X-* keys, in which case, the below text is applicable for initiators. Could you also please clarify what is the expected behaviour when an initiator receives a vendor specific X-* key ? Is the initiator compelled to respond with "NotUnderstood" or can it just discard the key ? Thanks, Santosh 2.2.4 ----- "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". The values "none" and "reject" are reserved and must be used only as described here. Any key not understood is answered with NotUnderstood. " 3.10.4 ------ "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." -- ################################## 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 Mon Oct 22 13:42: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 NAA24849 for ; Mon, 22 Oct 2001 13:42:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MGxMd19595 for ips-outgoing; Mon, 22 Oct 2001 12:59: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 f9MGxKl19590; Mon, 22 Oct 2001 12:59:20 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9MGxEu23790; Mon, 22 Oct 2001 09:59:14 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9MGx8B01654; Mon, 22 Oct 2001 09:59:08 -0700 From: "Bill Strahm" To: "Joe Czap" Cc: "IPS Reflector \(E-mail\)" , "John Hufferd" , Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Mon, 22 Oct 2001 09:58:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Directly from the Stanford license (http://otl.stanford.edu/pdf/97006.pdf) "Licensed Field of Use" means use of the Invention(s), Software and Licensed Patent(s) in Licensed Product(s) for implicit server authentication. By way of example, but not by limitation, RFC2945. The Licensed Field of Use specifically excludes use of the Invention(s), Software and Licensed Patent(s) machines and servers that deal with explicit bidirectional authentication (for example, SRP-Z for explicit server authentification). SOFTWARE may only be transferred under a Use Sublicense. Note that this applies only if Stanford is the only organization to own IP on this technology and there are no other patents in this field. Joe, can you warrant that IBM will make NO patent claims against this algorithm ? Can you warrant that I will not have to use SRP-Z to implement any iSCSI operations ? Again the problem isn't with the algorithm necissarily, but with the fact that it is the only MUST implement algorithm, I would rather see an algorithm with NO encumbrance against it... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Joe Czap Sent: Monday, October 22, 2001 5:03 AM To: Bill Strahm Cc: IPS Reflector (E-mail); John Hufferd; owner-ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP The lack of information relating to SRP IP concerns make the issue seem a little like misdirection. Can anyone offer a clear explanation the SRP IP situation ? Joe Czap IBM Storage Networking zapper@us.ibm.com From owner-ips@ece.cmu.edu Mon Oct 22 13:44: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 NAA24929 for ; Mon, 22 Oct 2001 13:44:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MGhux18439 for ips-outgoing; Mon, 22 Oct 2001 12:43: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 f9MGhrl18431 for ; Mon, 22 Oct 2001 12:43:54 -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 SAA67126 for ; Mon, 22 Oct 2001 18:43:46 +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 f9MGhj8194068 for ; Mon, 22 Oct 2001 18:43:45 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Mon, 22 Oct 2001 19:43:44 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/10/2001 19:43:45, Serialize complete at 22/10/2001 19:43:45 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Some of the ordering is session-wide (commands) and some is connection (Responses) or even "tag" scoped (Data). Session imposes additional order (beyond connection) but will not change connection ordering (except for recovery). Julo Robert Snively Sent by: owner-ips@ece.cmu.edu 22-10-01 17:46 Please respond to Robert Snively To: ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU Weren't all the other ordering issues associated with sessions (like CSN for example)? Doesn't that interact with the requirements for ordering of immediate data? As far as I can see, the ordering becomes significantly less important at the connection level because the session level management has to take things out of order in any case. Bob > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Saturday, October 20, 2001 3:18 PM > To: ips@ece.cmu.edu > Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU > > > > Robert, > > The ordering rule is for a connection (not for a session). It's sole > purpose is to minimize the chance for a deadlock. > > Regards, > Julo > > > > > Robert Snively > > Harrison'" > ade.com> > , Julian > > Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu > 16-10-01 18:02 cc: > > Please respond Subject: RE: > iSCSI: Addition of CmdSN in > to Robert Data-out PDU > > Snively > > > > > > > > > I am not quite sure what meaning "in-order" data has in > a multi-connection session. Does it mean that you actually > expect the data across multiple connections to arrive temporally > in the same order that is specified by the command sequence > numbers? Or does it mean that the data has to be arranged > in some order by the target session processing? > > Or is it better to step aside from the in-order question > for data transmission and do as Rob Harrison suggests: > > "As an initiator I would send the command PDU as soon as > I could if there were no immediate data, then queue the > DMA for the unsolicited data. Since there could be many > other DMAs queued ahead of the unsolicited data it is quite > possible that other commands, both read and write, will > be sent before the DMA completes." > > This would imply no strict ordering requirement. > > If an ordering requirement is necessary, I submit that it > is because of the problems with unsolicited data reception, > not with the actual data order. > > Bob > > > -----Original Message----- > > From: Rod Harrison [mailto:rod.harrison@windriver.com] > > Sent: Monday, October 15, 2001 4:06 AM > > To: Julian Satran; ips@ece.cmu.edu > > Subject: RE: iSCSI: Addition of CmdSN in Data-out PDU > > > > > > Julian, > > > > I think you might have misunderstood what I meant. > I was not > > advocating we change the spec in favour of relaxing the > data ordering > > requirements. I was just point out there is a problem for the > > initiator to solve in order maintain correct ordering, and that I > > believe it is not a terribly difficult one. > > > > - Rod > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > Julian Satran > > Sent: Sunday, October 14, 2001 9:30 PM > > To: ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > Immediate data are not mandatory (even if enabled). Having > one or ten > > DMAs > > does not change the fact that they share a TCP "pipe" and a decent > > transmitter will ship the TCP data in order - otherwise it > just throws > > his > > problems in the receiver's lap. Our additional requirement on order > > should > > make no difference. And it would be time to change the name of the > > thread. > > > > Julo > > > > > > > > > > > > "Rod Harrison" > > Hufferd/San > > Jose/IBM@IBMUS, "Robert > > river.com> Snively" > > > > Sent by: cc: > > , > > owner-ips@ece.cmu. "BURBRIDGE,MATTHEW > > (HP-UnitedKingdom,ex2)" > > edu > > , "'Binford, Charles'" > > , > > > > Subject: > RE: Addition > > of CmdSN in Data-out PDU > > 13-10-01 13:12 > > Please respond to > > "Rod Harrison" > > > > > > > > > > > > > > Even more common would be the DMA latency. As an > initiator > > I > > would > > send the command PDU as soon as I could if there were no immediate > > data, then queue the DMA for the unsolicited data. Since there could > > be many other DMAs queued ahead of the unsolicited data it is quite > > possible that other commands, both read and write, will be > sent before > > the DMA completes. > > > > You are spot one when you say the delay in obtaining the > > unsolicited > > data may be large and variable. If there are multiple DMA engines it > > does become a challenge for the initiator to ensure the correct > > ordering of the unsolicited data. Note that since there may be > > multiple unsolicited data PDUs in the same burst, and those may be > > filled with separate DMAs the ordering problem propagates down to > > within individual commands. > > > > I don't believe it is a particularly difficult > problem for > > the > > initiator to solve, but I do agree things would be easier for the > > initiator if the ordering requirement were removed. And > more so if the > > requirement to send in dataSN order were also removed, but this is > > probably too much pain for the target. > > > > - Rod > > > > -----Original Message----- > > From: owner-ips@ece.cmu.edu > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > John Hufferd > > Sent: Saturday, October 13, 2001 1:01 AM > > To: Robert Snively > > Cc: 'somesh_gupta@silverbacksystems.com'; BURBRIDGE,MATTHEW > > (HP-UnitedKingdom,ex2); 'Binford, Charles'; ips@ece.cmu.edu > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > Robert, > > I think that an Initiator being able to send a waiting Read command, > > without having to wait for many large write segments -- > that are being > > sent > > (as unsolicited data) -- is very useful. And that would mean, the > > unsolicited data is waiting to be sent until the Read Commands are > > sent. > > This might be a very frequent case. > > > > . > > . > > . > > 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 10/12/2001 > > 03:56:06 PM > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: "'somesh_gupta@silverbacksystems.com'" > > , "BURBRIDGE,MATTHEW > > (HP-UnitedKingdom,ex2)" , "'Binford, > > Charles'" , ips@ece.cmu.edu > > cc: > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > I have two small questions that would help me understand this. > > > > How do you know that unsolicited data is expected? By nature, > > unsolicited data is received as a "maximum surprise" which can > > only be determined after unpacking and parsing at least a > > part of the command structure, possibly even including the > > SCSI command (although there are some hints contained in the > > command header information). > > > > How can you constrain a generic system to posting the > > unsolicited data in the same order that the commands were > > emitted? In general, I would have expected the system to > > be emitting command followed immediately by the corresponding > > unsolicited data. If that is not the case, it means that there > > was a delay in obtaining the unsolicited data for transfer and > > that the delay was sufficient to allow the insertion of commands. > > If the delay is that large (and probably variable), the enforcement > > of transfer of unsolicited data in the same order as the > > commands are emitted seems to me to be a significant challenge, > > and certainly shouldn't be required as normal behavior. While it > > would make things simpler for targets (already challenged by > > unsolicited data), it seems to me that it would make things > > much more complex for initiators. > > > > Bob > > > > > -----Original Message----- > > > From: Somesh Gupta [mailto:somesh_gupta@silverbacksystems.com] > > > Sent: Friday, October 12, 2001 2:51 PM > > > To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Binford, Charles'; > > > ips@ece.cmu.edu > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > Matthew, > > > > > > Since the unsolicited data does not follow the > > > command, you need the link list. But since the > > > unsolicited data must be sent in the same order > > > as the commands, a link list is enough. > > > > > > Let us say that you have 8 commands. The ones > > > for which we expect unsolicted data are marked > > > as Cnn(ud). And I have marked the unsolicted > > > data PDUs as UD(nn). The (nn) with data implies > > > that it is implicit and not actually carried with > > > the PDU itself. > > > > > > C01(ud) C02(ud) C03(ud) C04 C05 C06(ud) UD(01) ---> > > > --> C07(ud) UD(02) UD(03) D04 D04 D05 D05 UD(06) ---> > > > --> UD(07) C08(ud) UD(08) ---> > > > > > > After the target receives the command C01, C02, and C03 > > > for which it expects unsolicited data, it puts them in > > > a link list. It also receives C04 and C05 for which > > > unsolicited data is not expected and they don't go > > > on the list. It then receives C06 for which unsolicited > > > data is expected, and it is added to then end of the list. > > > Then an unsolicited data PDU is received. It must go > > > with the command at the head of the list which is C01. > > > Use the ITT to make sure and you can then take C01 off > > > the list and so on. > > > > > > Somesh > > > > > > > > > > -----Original Message----- > > > > From: owner-ips@ece.cmu.edu > > > [mailto:owner-ips@ece.cmu.edu]On Behalf Of > > > > BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2) > > > > Sent: Friday, October 12, 2001 7:53 AM > > > > To: 'Binford, Charles'; ips@ece.cmu.edu > > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > > > > Charles, > > > > > > > > As you have described the spec states that "that > > > unsolicited data MUST be > > > > sent in the same order as the commands". This is not > the same as > > > > unsolicited data must follow the command associated with > > > it: For example: > > > > > > > > (Cx = SCSI Command PDU, Dx = The unsolicited data PDUs. The > > > x in all the > > > > example can be the ITT. It is not the CmdSN. > > > > > > > > This is allowed: > > > > > > > > C1 C2 C3 D1 D2 C4 D3 D4 > > > > > > > > and the target will have to use the ITT to associate the > > > data with the > > > > command. > > > > > > > > Matthew > > > > > > > > > > > > -----Original Message----- > > > > From: Binford, Charles [mailto:CBinford@pirus.com] > > > > Sent: Friday, October 12, 2001 2:50 PM > > > > To: ips@ece.cmu.edu > > > > Subject: RE: Addition of CmdSN in Data-out PDU > > > > > > > > > > > > I have not verify version 8 is still the same, but version 07-97 > > > > had a rule > > > > that unsolicited data MUST be sent in the same order as the > > > commands. > > > > > > > > Thus, there is no need for a search on the ITT. The target > > > just needs to > > > > keep of linked list of I/Os waiting on unsolicited data. > > > New commands are > > > > added to the tail, any unsolicited data *should* be associated > > > > with the I/O > > > > at the head of the list. The ITT is used as a sanity check and > > > > you're done. > > > > > > > > What am I missing? > > > > > > > > Charles Binford > > > > Pirus Networks > > > > 316.315.0382 x222 > > > > > > > > > > > > > > > > > > > > > From owner-ips@ece.cmu.edu Mon Oct 22 13:51: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 NAA25144 for ; Mon, 22 Oct 2001 13:51:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MH53a20009 for ips-outgoing; Mon, 22 Oct 2001 13:05:03 -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 f9MH51l20003 for ; Mon, 22 Oct 2001 13:05:01 -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 TAA120108 for ; Mon, 22 Oct 2001 19:04: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.97.1) with ESMTP id f9MH4s8173062 for ; Mon, 22 Oct 2001 19:04:54 +0200 To: ips@ece.cmu.edu Importance: High MIME-Version: 1.0 Subject: Re: iscsi : HeaderDigest & DataDigest as operational keys ? X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Mon, 22 Oct 2001 20:04:53 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 22/10/2001 20:04:54, Serialize complete at 22/10/2001 20:04:54 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, They are in the security area due to historical reasons. If I don't hear strong opposition I will move them to Operational. Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 16-10-01 20:22 Please respond to Santosh Rao To: IPS Reflector cc: Subject: iscsi : HeaderDigest & DataDigest as operational keys ? Julian, Can the keys HeaderDigest & DataDigest be moved to operational keys, instead of their current location in security keys ? This would allow an initiator that is using header & data digests, but no security authentication to complete all of its login key negotiation in 1 phase, namely, the operational phase. It reduces login to a single handshake for initiators that do not perform security authentication. The digest keys are meant for data integrity rather than security and I am wondering why they need to be placed in the security keys (?). 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 Mon Oct 22 14:38: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 OAA26705 for ; Mon, 22 Oct 2001 14:38:48 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MHh8r22955 for ips-outgoing; Mon, 22 Oct 2001 13:43:08 -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 f9MHh6l22950 for ; Mon, 22 Oct 2001 13:43:06 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f9MHgeM19072; Mon, 22 Oct 2001 13:42:40 -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 f9MHgci30267; Mon, 22 Oct 2001 13:42:39 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15316.23235.76000.335120@gargle.gargle.HOWL> Date: Mon, 22 Oct 2001 13:43:31 -0400 From: Paul Koning To: Julian_Satran@il.ibm.com Cc: ips@ece.cmu.edu Subject: Re: iSCSI - changes - PDULength and related 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 21 October 2001) by Julian Satran: > Some framing mechanisms (defined by other standards) work well with PDU > length not exceeding path MTU. > This may be suboptimal (and I assume will be seldomness in use) but may > help get things going. I don't see how that is relevant. Path MTUs below 512 have always been extremely rare and certainly are completely nonexistent for high speed networks. It makes no sense at all to add complexity to all implementations for the sake of supporting unreasonable path MTU values. Especially if the only effect is that the framing doesn't work as efficiently -- but still works. After all, if your path MTU is tiny, nothing works efficiently, and any optimization is a complete waste of effort. There is another issue here as well: it is not appropriate for such changes to be made without discussion. I don't see a reason for the change, but if the consensus is that the change is desirable, then it should be made. But it should NOT be made without discussion, as an obscure side effect of an unrelated change! That way you cannot arrive at a stable spec. paul > Paul Koning > > Excerpt of message (sent 12 October 2001) by Julian Satran: > > ... > > In addition text request and response key+value strings are not required > to > > be confined to a single PDU (as we PDULength can be a low as 64 bytes!) > > > > Comments? > > Why change the minimum value of PDULength (and the two burstsize > parameters)? It used to be 512, which makes more sense, although even > that is rather small. Allowing the length to be set to such tiny > values (like 64) adds a lot of complexity to the implementation to no > useful purpose. > > I'd prefer to see a minimum around 1500, but if not, at least it > should not be reduced from the existing value of 512. > > paul > > > ... > > 23 MaxRecvPDULength > > > > Use: All > > Who can send: Initiator and Target > > > > MaxRecvPDULength=<0|number-64-to-2**24> > > ... > > 24 MaxBurstSize > > > > Use: LO > > Who can send: Initiator and Target > > > > MaxBurstSize=<0|number-64-to-2**24> > > > > Default is 256 Kbytes. > > > > Initiator and target negotiate maximum SCSI data payload in bytes > > ... > > 25 FirstBurstSize > > > > Use: LO > > Who can send: Initiator and Target > > > > FirstBurstSize=<0|number-64-to-2**24> > > > ----- Forwarded by Julian Satran/Haifa/IBM on 20-10-01 23:58 ----- > > Paul Koning > > cc: > Sent by: Subject: Re: iSCSI - changes - PDULength > owner-ips@ece. and related > cmu.edu > > > 18-10-01 17:54 > Please respond > to Paul Koning > > > > > > (((resending this, since the previous copy seems to have gone AWOL))) > > Excerpt of message (sent 12 October 2001) by Julian Satran: > > ... > > In addition text request and response key+value strings are not required > to > > be confined to a single PDU (as we PDULength can be a low as 64 bytes!) > > > > Comments? > > Why change the minimum value of PDULength (and the two burstsize > parameters)? It used to be 512, which makes more sense, although even > that is rather small. Allowing the length to be set to such tiny > values (like 64) adds a lot of complexity to the implementation to no > useful purpose. > > I'd prefer to see a minimum around 1500, but if not, at least it > should not be reduced from the existing value of 512. > > paul > > > ... > > 23 MaxRecvPDULength > > > > Use: All > > Who can send: Initiator and Target > > > > MaxRecvPDULength=<0|number-64-to-2**24> > > ... > > 24 MaxBurstSize > > > > Use: LO > > Who can send: Initiator and Target > > > > MaxBurstSize=<0|number-64-to-2**24> > > > > Default is 256 Kbytes. > > > > Initiator and target negotiate maximum SCSI data payload in bytes > > ... > > 25 FirstBurstSize > > > > Use: LO > > Who can send: Initiator and Target > > > > FirstBurstSize=<0|number-64-to-2**24> > > > From owner-ips@ece.cmu.edu Mon Oct 22 16:03: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 QAA28657 for ; Mon, 22 Oct 2001 16:03:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9MJC0p29380 for ips-outgoing; Mon, 22 Oct 2001 15:12: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 f9MJBwl29370 for ; Mon, 22 Oct 2001 15:11:58 -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 PAA69194 for ; Mon, 22 Oct 2001 15:09: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 f9MJBqD259708 for ; Mon, 22 Oct 2001 13:11:52 -0600 X-Priority: 1 (High) Importance: Normal Subject: iSCSI: how much "Desired Data Transfer Length" in R2T To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 22 Oct 2001 12:11:06 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/22/2001 01:11:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Please prepend the Subject line with the "iSCSI" String as shown in this note. . . . 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 "Subrahmanya Sastry K.V" @ece.cmu.edu on 10/22/2001 03:32:19 AM Sent by: owner-ips@ece.cmu.edu To: Nitin Dhingra cc: ips@ece.cmu.edu Subject: Re: how much "Desired Data Transfer Length" in R2T Nitin, I think the "Desired Data Tranfer Length" field of R2T PDU should be equal to the DataPDULength value that the initiator has sent to the target during text parameter negotiation. Since the DataPDULength can be different in the two directions, the initiator sends this value to the target as DataPDULength=. So the initiator only sends/receives a PDU having length less than or equal to the negotiated DataPDULength (non-zero). Any comments are welcome.. Sastry Nitin Dhingra wrote: > How is the target going to decide how much "desired data transfer length" he > has > to fill apart from the negotiated "DataPDULength". > > Thanks in advance, > nitin From owner-ips@ece.cmu.edu Tue Oct 23 05:14: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 FAA24217 for ; Tue, 23 Oct 2001 05:14:07 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9N88jV18973 for ips-outgoing; Tue, 23 Oct 2001 04:08: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 f9N88gl18965 for ; Tue, 23 Oct 2001 04:08: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 KAA25690; Tue, 23 Oct 2001 10:08:31 +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 f9N88Rr265066; Tue, 23 Oct 2001 10:08:28 +0200 Importance: Normal Subject: RE: iSCSI: Login authentication SRP/CHAP To: "Bill Strahm" Cc: "Joe Czap" , "IPS Reflector \(E-mail\)" , "John Hufferd" X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Ofer Biran" Date: Tue, 23 Oct 2001 11:09:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 23/10/2001 11:08:29 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 f9N88hl18969 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit 1. It's good news that the Stanford license fee is zero (I verified this - see attached note). 2. > Can you warrant that I will not have to use SRP-Z to implement any iSCSI > operations ? The SRP usage defined in iSCSI is EXACTLY according to RFC-2945. This usage is explicitly covered by the Stanford free license. SRP-Z involves additional private/public keys for the server, and you will not have to use that if you only want to follow the iSCSI standard. 3. If anyone has information about any other IP claiming on the RFC-2945 usage (SRP-SHA1) please post the full information here. 4. There is no question about the superior cryptographic features of SRP over CHAP. In situations where underlying IPsec will not be implemented/used (and these are forecasted), basing the iSCSI security on plain CHAP is a poor solution which IMHO the iSCSI standard should not encourage (by mandating CHAP instead of SRP). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Kirsten Leute on 23/10/2001 00:18:00 Please respond to Kirsten Leute To: Ofer Biran/Haifa/IBM@IBMIL cc: Subject: Re: SRP Licensing terms Dear Ofer: Yes, this is correct.  For the type of usage described in the agreement, there are no licensing fees. As far as I know, there are no licensing issues from Stanford. Best, Kirsten At 06:58 PM 10/22/2001 +0300, you wrote: Kirsten, I'm working on the security aspects of the new iSCSI standard in the IPS working group of the IETF. Our intention is to define SRP (usage according to RFC2945) as the 'mandatory to implement' authentication algorithm. There were concerns in the working group about the licensing terms with Stanford. I looked in your "Ready-to-Sign Agreements" page and it seems to me that there are no fee involved in getting this license. I wanted to verify this with you. Also - are you aware of any other licensing issue with SRP   Thanks in advance,       Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com  972-4-8296253 ************************************** Kirsten Leute Licensing Associate Office of Technology Licensing, Stanford University 900 Welch Road, Suite 350, Palo Alto, CA 94304 Direct: (650) 725-9407; Fax: (650) 725-7295 website: http://otl.stanford.edu/ "Bill Strahm" @ece.cmu.edu on 22/10/2001 18:58:06 Please respond to "Bill Strahm" Sent by: owner-ips@ece.cmu.edu To: Joe Czap/Raleigh/IBM@IBMUS cc: "IPS Reflector \(E-mail\)" , John Hufferd/San Jose/IBM@IBMUS, Subject: RE: iSCSI: Login authentication SRP/CHAP Directly from the Stanford license (http://otl.stanford.edu/pdf/97006.pdf) "Licensed Field of Use" means use of the Invention(s), Software and Licensed Patent(s) in Licensed Product(s) for implicit server authentication. By way of example, but not by limitation, RFC2945. The Licensed Field of Use specifically excludes use of the Invention(s), Software and Licensed Patent(s) machines and servers that deal with explicit bidirectional authentication (for example, SRP-Z for explicit server authentification). SOFTWARE may only be transferred under a Use Sublicense. Note that this applies only if Stanford is the only organization to own IP on this technology and there are no other patents in this field. Joe, can you warrant that IBM will make NO patent claims against this algorithm ? Can you warrant that I will not have to use SRP-Z to implement any iSCSI operations ? Again the problem isn't with the algorithm necissarily, but with the fact that it is the only MUST implement algorithm, I would rather see an algorithm with NO encumbrance against it... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Joe Czap Sent: Monday, October 22, 2001 5:03 AM To: Bill Strahm Cc: IPS Reflector (E-mail); John Hufferd; owner-ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP The lack of information relating to SRP IP concerns make the issue seem a little like misdirection. Can anyone offer a clear explanation the SRP IP situation ? Joe Czap IBM Storage Networking zapper@us.ibm.com From owner-ips@ece.cmu.edu Tue Oct 23 08: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 IAA28175 for ; Tue, 23 Oct 2001 08:19:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NBlIb12891 for ips-outgoing; Tue, 23 Oct 2001 07:47:18 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f9NBl4l12879 for ; Tue, 23 Oct 2001 07:47:09 -0400 (EDT) Received: from npd.hcltech.com (skotra-pc.hcltech.com [192.168.100.57]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id f9NBkGJ26095 for ; Tue, 23 Oct 2001 17:16:19 +0530 Message-ID: <3BD5582A.AD7C272E@npd.hcltech.com> Date: Tue, 23 Oct 2001 17:14:42 +0530 From: "Subrahmanya Sastry K.V" Organization: HCL X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: ips@ece.cmu.edu Subject: iSCSI: Question on T bit in login request PDU Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello, Chapter 5 in the iscsi-draft-08 says that the T bit settings in one pair of login request-responses have no bearing on the T bit settings of the next pair and quotes : "An initiator having T bit set to 1 in one pair and being answered with an T bit setting of 0 may issue the next request with T bit set to 0. " But in section 5.3, the lines : "If the target responds to a Login request with the T bit set to 1, with a Login response with the T bit set to 0, the initiator must keep sending the Login request (even empty) with the T bit set to 1 until it gets the Login Response with the T bit set to 1." suggest a diffferent meaning. If I assume both are possible, what is the criterion for the initiator to set the T bit? Clarification please ? -Sastry From owner-ips@ece.cmu.edu Tue Oct 23 08: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 IAA28415 for ; Tue, 23 Oct 2001 08:26:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NBX2412070 for ips-outgoing; Tue, 23 Oct 2001 07:33:02 -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 ([203.190.136.130]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9NBWpl12061 for ; Tue, 23 Oct 2001 07:32:58 -0400 (EDT) Received: by DCMTECHDOM with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Oct 2001 17:05:06 +0530 Message-ID: <7FADCB99FC82D41199F9000629A85D1A0293A545@DCMTECHDOM> From: Nitin Dhingra To: "Ips (E-mail)" Subject: iSCSI: is itt same across login phase Date: Tue, 23 Oct 2001 17:05:06 +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 Is the "Itt" field same all across login phase?? From owner-ips@ece.cmu.edu Tue Oct 23 09:11: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 JAA00189 for ; Tue, 23 Oct 2001 09:11:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NCNOs14947 for ips-outgoing; Tue, 23 Oct 2001 08:23:24 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from marine.sonic.net (marine.sonic.net [208.201.224.37]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f9N6OVl13380 for ; Tue, 23 Oct 2001 02:24:31 -0400 (EDT) Received: (qmail 12192 invoked from network); 23 Oct 2001 06:24:28 -0000 Received: from buzz.sonic.net (208.201.224.78) by marine.sonic.net with SMTP; 23 Oct 2001 06:24:28 -0000 Received: from quadrajet.sonic.net (adsl-209-204-185-65.sonic.net [209.204.185.65]) by buzz.sonic.net (8.11.6/8.8.5) with ESMTP id f9N6OSk27138; Mon, 22 Oct 2001 23:24:28 -0700 X-envelope-info: Received: (from guy@localhost) by quadrajet.sonic.net (8.9.3/8.9.3) id XAA52255; Mon, 22 Oct 2001 23:24:27 -0700 (PDT) (envelope-from gharris) Date: Mon, 22 Oct 2001 23:24:26 -0700 From: Guy Harris To: Mark Burton Cc: ethereal-dev@ethereal.com, ips@ece.cmu.edu Subject: Re: [Ethereal-dev] Improved iSCSI dissector Message-ID: <20011022232426.B14257@quadrajet.sonic.net> References: <20011021.112305.635728618.markb@ordern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20011021.112305.635728618.markb@ordern.com>; from markb@ordern.com on Sun, Oct 21, 2001 at 11:23:05AM +0100 Sender: owner-ips@ece.cmu.edu Precedence: bulk On Sun, Oct 21, 2001 at 11:23:05AM +0100, Mark Burton wrote: > One problem that I haven't been able to track down is that if > desegmentation is enabled and you turn digests on or off ethereal > throws a SEGV. Is it still doing that, or did the small patch you later sent: *************** *** 1212,1217 **** --- 1212,1219 ---- } dissect_iscsi_pdu(tvb, pinfo, tree, offset, opcode, opcode_str, data_segment_len); + if(pduLen > available_bytes) + pduLen = available_bytes; offset += pduLen; available_bytes -= pduLen; ++iSCSIPdusDissected; fix that? I couldn't reproduce it with the capture files you've sent. From owner-ips@ece.cmu.edu Tue Oct 23 09:12: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 JAA00263 for ; Tue, 23 Oct 2001 09:12:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NCkZU16380 for ips-outgoing; Tue, 23 Oct 2001 08:46:35 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f9NCkBl16357 for ; Tue, 23 Oct 2001 08:46:17 -0400 (EDT) Received: from npd.hcltech.com (skotra-pc.hcltech.com [192.168.100.57]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id f9NCicJ28435; Tue, 23 Oct 2001 18:14:44 +0530 Message-ID: <3BD565D9.954CF0FD@npd.hcltech.com> Date: Tue, 23 Oct 2001 18:13:05 +0530 From: "Subrahmanya Sastry K.V" Organization: HCL X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nitin Dhingra CC: "Ips (E-mail)" Subject: Re: iSCSI: is itt same across login phase References: <7FADCB99FC82D41199F9000629A85D1A0293A545@DCMTECHDOM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please refer to Section 5 of iscsi-08 draft which says: "The whole login phase is considered as a single task and has a single Initiator Task Tag (similar to the linked SCSI commands)." -Sastry Nitin Dhingra wrote: > Is the "Itt" field same all across login phase?? From owner-ips@ece.cmu.edu Tue Oct 23 11:45: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 LAA08368 for ; Tue, 23 Oct 2001 11:45:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NEnp025311 for ips-outgoing; Tue, 23 Oct 2001 10:49:51 -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 f9NEnol25306 for ; Tue, 23 Oct 2001 10:49:50 -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 KAA24807 for ; Tue, 23 Oct 2001 10:49:40 -0400 (EDT) Message-ID: <3BD58149.C8F60367@cisco.com> Date: Tue, 23 Oct 2001 09:40:09 -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: iSCSI MIB Roadmap Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Several people have been asking about the iSCSI MIB status, and what will happen next. Here is what we are planning to do. The current iSCSI MIB is draft-ietf-ips-iscsi-mib-02. It uses the old deep table structure, which will be flattened in iscsi-mib-03. October, 2001 - Post iscsi-mib-03. Changes: - Flattened the table structure - Lots of editing as a result of flattening - Added failure counters to be used in notifications - Aligned session attributes with iscsi-08 Receive feedback from IPS reflector on the iSCSI MIB. November, 2001 - Post iscsi-mib-04 for IETF 52. Expected Changes: - Change some attributes to writable - Explore the addition of an initiator configuration table - Incorporate feedback from the reflector No structural changes are expected in this one. After this, there should be relatively little we can do with the MIB, other than tracking the iSCSI draft changes. As soon as iSCSI enters Last Call Expected Changes: - Update to match the Last Call iSCSI draft. One week after iSCSI completes Last Call: Update to match the final iSCSI RFC. Changes should be very minor. -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Oct 23 12:30: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 MAA10287 for ; Tue, 23 Oct 2001 12:30:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NFXWe28953 for ips-outgoing; Tue, 23 Oct 2001 11:33:32 -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 f9NFXTl28945 for ; Tue, 23 Oct 2001 11:33:30 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9NFXJu31533; Tue, 23 Oct 2001 08:33:19 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9NFXDB25578; Tue, 23 Oct 2001 08:33:13 -0700 From: "Bill Strahm" To: "Ofer Biran" Cc: "Joe Czap" , "IPS Reflector \(E-mail\)" , "John Hufferd" Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Tue, 23 Oct 2001 08:32:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Brian, Arguing for situations where IPsec is not implemented/used is a Red Herring. If it is not implemented it is not an iSCSI implementation (remember MUST implement IPsec) therefor it does not have to be considered. If it is not used, then that is an administrative descision that is made based on the security requirements of the environment. My arguement is that CHAP is understood, code is available, it plugs into other authentication services (RADIUS/SecureID) that I am not sure how I would plug an SRP implementation into anyway, and I think that I HAVE to implement it... now SRP doesn't seem to be buying me anything except for "improved security" on a administratively secured link, doesn't seem like much. So based on your statement below have you warrented that IBM will make NO IP claims on the usage of SRP in iSCSI ??? Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ofer Biran Sent: Tuesday, October 23, 2001 1:09 AM To: Bill Strahm Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP 1. It's good news that the Stanford license fee is zero (I verified this - see attached note). 2. > Can you warrant that I will not have to use SRP-Z to implement any iSCSI > operations ? The SRP usage defined in iSCSI is EXACTLY according to RFC-2945. This usage is explicitly covered by the Stanford free license. SRP-Z involves additional private/public keys for the server, and you will not have to use that if you only want to follow the iSCSI standard. 3. If anyone has information about any other IP claiming on the RFC-2945 usage (SRP-SHA1) please post the full information here. 4. There is no question about the superior cryptographic features of SRP over CHAP. In situations where underlying IPsec will not be implemented/used (and these are forecasted), basing the iSCSI security on plain CHAP is a poor solution which IMHO the iSCSI standard should not encourage (by mandating CHAP instead of SRP). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Kirsten Leute on 23/10/2001 00:18:00 Please respond to Kirsten Leute To: Ofer Biran/Haifa/IBM@IBMIL cc: Subject: Re: SRP Licensing terms Dear Ofer: Yes, this is correct.  For the type of usage described in the agreement, there are no licensing fees. As far as I know, there are no licensing issues from Stanford. Best, Kirsten At 06:58 PM 10/22/2001 +0300, you wrote: Kirsten, I'm working on the security aspects of the new iSCSI standard in the IPS working group of the IETF. Our intention is to define SRP (usage according to RFC2945) as the 'mandatory to implement' authentication algorithm. There were concerns in the working group about the licensing terms with Stanford. I looked in your "Ready-to-Sign Agreements" page and it seems to me that there are no fee involved in getting this license. I wanted to verify this with you. Also - are you aware of any other licensing issue with SRP   Thanks in advance,       Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com  972-4-8296253 ************************************** Kirsten Leute Licensing Associate Office of Technology Licensing, Stanford University 900 Welch Road, Suite 350, Palo Alto, CA 94304 Direct: (650) 725-9407; Fax: (650) 725-7295 website: http://otl.stanford.edu/ "Bill Strahm" @ece.cmu.edu on 22/10/2001 18:58:06 Please respond to "Bill Strahm" Sent by: owner-ips@ece.cmu.edu To: Joe Czap/Raleigh/IBM@IBMUS cc: "IPS Reflector \(E-mail\)" , John Hufferd/San Jose/IBM@IBMUS, Subject: RE: iSCSI: Login authentication SRP/CHAP Directly from the Stanford license (http://otl.stanford.edu/pdf/97006.pdf) "Licensed Field of Use" means use of the Invention(s), Software and Licensed Patent(s) in Licensed Product(s) for implicit server authentication. By way of example, but not by limitation, RFC2945. The Licensed Field of Use specifically excludes use of the Invention(s), Software and Licensed Patent(s) machines and servers that deal with explicit bidirectional authentication (for example, SRP-Z for explicit server authentification). SOFTWARE may only be transferred under a Use Sublicense. Note that this applies only if Stanford is the only organization to own IP on this technology and there are no other patents in this field. Joe, can you warrant that IBM will make NO patent claims against this algorithm ? Can you warrant that I will not have to use SRP-Z to implement any iSCSI operations ? Again the problem isn't with the algorithm necissarily, but with the fact that it is the only MUST implement algorithm, I would rather see an algorithm with NO encumbrance against it... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Joe Czap Sent: Monday, October 22, 2001 5:03 AM To: Bill Strahm Cc: IPS Reflector (E-mail); John Hufferd; owner-ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP The lack of information relating to SRP IP concerns make the issue seem a little like misdirection. Can anyone offer a clear explanation the SRP IP situation ? Joe Czap IBM Storage Networking zapper@us.ibm.com From owner-ips@ece.cmu.edu Tue Oct 23 12:57: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 MAA11292 for ; Tue, 23 Oct 2001 12:57:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NFxAh01156 for ips-outgoing; Tue, 23 Oct 2001 11:59:10 -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 f9NFx7l01144 for ; Tue, 23 Oct 2001 11:59:07 -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 f9NFxux21274 for ; Tue, 23 Oct 2001 11:59:56 -0400 (EDT) From: "Eddy Quicksall" To: Subject: iSCSI: Text Request ITT/TTT Date: Tue, 23 Oct 2001 11:59:05 -0400 Message-ID: <001401c15bdb$a6219a30$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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section 3.10.2 Initiator Task Tag says: If the command is sent as part of a sequence of text requests and responses, the Initiator Task Tag MUST be the same for all the requests within the sequence (similar to linked SCSI commands). Why is this restriction imposed? Since the Text Requests can't be overlapped, then there is no need for this. If this restriction must exist, then why doesn't it exist for the TTT as well? The target does not need to interpret the ITT and the initiator does not need to interpret the TTT (or does it?). By removing the restriction, the initiator could use the ITT as an indication of where to pick up with the next Text Response for long text exchanges. Also, the target could use the TTT the same way. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Tue Oct 23 14:38: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 OAA15482 for ; Tue, 23 Oct 2001 14:38:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NHqN410020 for ips-outgoing; Tue, 23 Oct 2001 13:52:23 -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 f9NHqLl10015 for ; Tue, 23 Oct 2001 13:52: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 1F4BA1F80E for ; Tue, 23 Oct 2001 10:52:16 -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 KAA06548 for ; Tue, 23 Oct 2001 10:52:11 -0700 (PDT) Message-ID: <3BD5B028.A3A21BBD@cup.hp.com> Date: Tue, 23 Oct 2001 11:00:08 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: ips : padding of ahs & data segment. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Can somebody clarify what the below wording is supposed to imply : 3.2.2.2 AHSLength The AHS is padded to an integer number of 4 byte words. 3.2.4 Data Segment The Data Segment is also padded to an integer number of 4 byte words. Does the above imply that there are EXACTLY 0 - 3 pad bytes so as to align the AHS and data segment to the nearest 4 byte aligned boundary, or can the AHS and data segment be aligned on any integer number of 4 byte words ?? For ex : Assume a data segment length of 41 bytes. Does the above wording imply that the data segment MUST be exactly padded to a length of 44 bytes, or does it allow for padding to 44, 48, 52, 56... bytes ? (multiple integer of 4 byte words.) My interpretation is that the wording is loose and allows for the latter (i.e. any multiple integer of 4 byte words.) However, in order for this to work, the padding must be to the next highest 4 byte word boundary beyond the ahs length or data segment length. i.e. The pad bytes MUST range between 0 - 3 bytes. I think the wording needs to be tightened to clarify this. 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 Tue Oct 23 14:51: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 OAA15910 for ; Tue, 23 Oct 2001 14:51:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NHigx09455 for ips-outgoing; Tue, 23 Oct 2001 13:44:42 -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 f9NHiel09450 for ; Tue, 23 Oct 2001 13:44:40 -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 KAA00896; Tue, 23 Oct 2001 10:42:31 -0700 (PDT) Received: from aimexc07.corp.adaptec.com (aimexc07.corp.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id KAA03191; Tue, 23 Oct 2001 10:28:27 -0700 (PDT) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Oct 2001 10:42:31 -0700 Message-ID: From: "Lee, CJ" To: "'Bill Strahm'" Cc: "IPS Reflector (E-mail)" , Ofer Biran Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Tue, 23 Oct 2001 10:42:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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 f9NHiel09451 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Personally, I'd think that we ought to select a mandatory to implement authentication protocol base on how secure it is rather than how convenient it is. Especially under the MUST to implement but optional to use nature of both the login authentication and IPSec. One could argue the clear text PAP could server equally well the very purpose of login authentication when running on top of an encrypted IPSec link. CJ Lee Adaptec, Inc. -----Original Message----- From: Bill Strahm [mailto:bill@sanera.net] Sent: Tuesday, October 23, 2001 8:33 AM To: Ofer Biran Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP Brian, Arguing for situations where IPsec is not implemented/used is a Red Herring. If it is not implemented it is not an iSCSI implementation (remember MUST implement IPsec) therefor it does not have to be considered. If it is not used, then that is an administrative descision that is made based on the security requirements of the environment. My arguement is that CHAP is understood, code is available, it plugs into other authentication services (RADIUS/SecureID) that I am not sure how I would plug an SRP implementation into anyway, and I think that I HAVE to implement it... now SRP doesn't seem to be buying me anything except for "improved security" on a administratively secured link, doesn't seem like much. So based on your statement below have you warrented that IBM will make NO IP claims on the usage of SRP in iSCSI ??? Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ofer Biran Sent: Tuesday, October 23, 2001 1:09 AM To: Bill Strahm Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP 1. It's good news that the Stanford license fee is zero (I verified this - see attached note). 2. > Can you warrant that I will not have to use SRP-Z to implement any iSCSI > operations ? The SRP usage defined in iSCSI is EXACTLY according to RFC-2945. This usage is explicitly covered by the Stanford free license. SRP-Z involves additional private/public keys for the server, and you will not have to use that if you only want to follow the iSCSI standard. 3. If anyone has information about any other IP claiming on the RFC-2945 usage (SRP-SHA1) please post the full information here. 4. There is no question about the superior cryptographic features of SRP over CHAP. In situations where underlying IPsec will not be implemented/used (and these are forecasted), basing the iSCSI security on plain CHAP is a poor solution which IMHO the iSCSI standard should not encourage (by mandating CHAP instead of SRP). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Kirsten Leute on 23/10/2001 00:18:00 Please respond to Kirsten Leute To: Ofer Biran/Haifa/IBM@IBMIL cc: Subject: Re: SRP Licensing terms Dear Ofer: Yes, this is correct.  For the type of usage described in the agreement, there are no licensing fees. As far as I know, there are no licensing issues from Stanford. Best, Kirsten At 06:58 PM 10/22/2001 +0300, you wrote: Kirsten, I'm working on the security aspects of the new iSCSI standard in the IPS working group of the IETF. Our intention is to define SRP (usage according to RFC2945) as the 'mandatory to implement' authentication algorithm. There were concerns in the working group about the licensing terms with Stanford. I looked in your "Ready-to-Sign Agreements" page and it seems to me that there are no fee involved in getting this license. I wanted to verify this with you. Also - are you aware of any other licensing issue with SRP   Thanks in advance,       Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com  972-4-8296253 ************************************** Kirsten Leute Licensing Associate Office of Technology Licensing, Stanford University 900 Welch Road, Suite 350, Palo Alto, CA 94304 Direct: (650) 725-9407; Fax: (650) 725-7295 website: http://otl.stanford.edu/ "Bill Strahm" @ece.cmu.edu on 22/10/2001 18:58:06 Please respond to "Bill Strahm" Sent by: owner-ips@ece.cmu.edu To: Joe Czap/Raleigh/IBM@IBMUS cc: "IPS Reflector \(E-mail\)" , John Hufferd/San Jose/IBM@IBMUS, Subject: RE: iSCSI: Login authentication SRP/CHAP Directly from the Stanford license (http://otl.stanford.edu/pdf/97006.pdf) "Licensed Field of Use" means use of the Invention(s), Software and Licensed Patent(s) in Licensed Product(s) for implicit server authentication. By way of example, but not by limitation, RFC2945. The Licensed Field of Use specifically excludes use of the Invention(s), Software and Licensed Patent(s) machines and servers that deal with explicit bidirectional authentication (for example, SRP-Z for explicit server authentification). SOFTWARE may only be transferred under a Use Sublicense. Note that this applies only if Stanford is the only organization to own IP on this technology and there are no other patents in this field. Joe, can you warrant that IBM will make NO patent claims against this algorithm ? Can you warrant that I will not have to use SRP-Z to implement any iSCSI operations ? Again the problem isn't with the algorithm necissarily, but with the fact that it is the only MUST implement algorithm, I would rather see an algorithm with NO encumbrance against it... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Joe Czap Sent: Monday, October 22, 2001 5:03 AM To: Bill Strahm Cc: IPS Reflector (E-mail); John Hufferd; owner-ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP The lack of information relating to SRP IP concerns make the issue seem a little like misdirection. Can anyone offer a clear explanation the SRP IP situation ? Joe Czap IBM Storage Networking zapper@us.ibm.com From owner-ips@ece.cmu.edu Tue Oct 23 14:52: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 OAA15940 for ; Tue, 23 Oct 2001 14:52:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NIEEU11748 for ips-outgoing; Tue, 23 Oct 2001 14:14:14 -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 f9NIECl11743 for ; Tue, 23 Oct 2001 14:14:12 -0400 (EDT) Received: from breinhold (h00e09871f366.ne.mediaone.net [24.128.217.119]) by chmls05.mediaone.net (8.11.1/8.11.1) with SMTP id f9NIDer20939; Tue, 23 Oct 2001 14:13:40 -0400 (EDT) From: "Barry Reinhold" To: "Santosh Rao" , "IPS Reflector" Subject: RE: ips : padding of ahs & data segment. Date: Tue, 23 Oct 2001 14:13:27 -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: <3BD5B028.A3A21BBD@cup.hp.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Santosh, I was not aware of any need to pad beyond the next word (adding 0-3 bytes)when we were working on the format. I agree that you can read the standard to imply that any 4 byte boundary would be valid and the wording could be tightened. >-----Original Message----- >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >Santosh Rao >Sent: Tuesday, October 23, 2001 2:00 PM >To: IPS Reflector >Subject: ips : padding of ahs & data segment. > > >All, > >Can somebody clarify what the below wording is supposed to imply : > >3.2.2.2 AHSLength > >The AHS is padded to an integer number of 4 byte words. > >3.2.4 Data Segment > >The Data Segment is also padded to an integer number of 4 byte words. > > >Does the above imply that there are EXACTLY 0 - 3 pad bytes so as to >align the AHS and data segment to the nearest 4 byte aligned boundary, >or can the AHS and data segment be aligned on any integer number of 4 >byte words ?? > >For ex : >Assume a data segment length of 41 bytes. Does the above wording imply >that the data segment MUST be exactly padded to a length of 44 bytes, or >does it allow for padding to 44, 48, 52, 56... bytes ? (multiple integer >of 4 byte words.) > >My interpretation is that the wording is loose and allows for the latter >(i.e. any multiple integer of 4 byte words.) > >However, in order for this to work, the padding must be to the next >highest 4 byte word boundary beyond the ahs length or data segment >length. i.e. The pad bytes MUST range between 0 - 3 bytes. > >I think the wording needs to be tightened to clarify this. > >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 Tue Oct 23 14:56: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 OAA16118 for ; Tue, 23 Oct 2001 14:56:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NHufI10379 for ips-outgoing; Tue, 23 Oct 2001 13:56:41 -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 f9NHucl10371 for ; Tue, 23 Oct 2001 13:56:39 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9NHuUu32489; Tue, 23 Oct 2001 10:56:30 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9NHuPB28820; Tue, 23 Oct 2001 10:56:25 -0700 From: "Bill Strahm" To: "Lee, CJ" Cc: "IPS Reflector \(E-mail\)" , "Ofer Biran" Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Tue, 23 Oct 2001 10:55:25 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit So you are perfectly willing to specify a MUST implement algorithm that can't be used (what happens if the user password is not available on the target) to clutter up the implementation space ??? I would rather that A SINGLE usable algorithm is labeled MUST implement (if you must in fact specify a MUST implement at all) and the others are left as SHOULD implment. You are right a clear text Username-> Password-> challenge response works great with a secure link (heck I do it every day with SSH) The idea is usable... Again if the problem is that no one will implmement IPsec/use IPsec, then the problem seems to be with IPsec, lets either make it usable, or pick another security protocol that is deployable. If the problem is to see how secure we can be by requiring as many unusable/unimplementable security algorithms as possible, well I guess we as vendors can just decide to implement the protocol, and the algorithms that make sense to us, and don't worry about interoperability... Bill -----Original Message----- From: Lee, CJ [mailto:CJ_Lee@adaptec.com] Sent: Tuesday, October 23, 2001 10:42 AM To: 'Bill Strahm' Cc: IPS Reflector (E-mail); Ofer Biran Subject: RE: iSCSI: Login authentication SRP/CHAP Personally, I'd think that we ought to select a mandatory to implement authentication protocol base on how secure it is rather than how convenient it is. Especially under the MUST to implement but optional to use nature of both the login authentication and IPSec. One could argue the clear text PAP could server equally well the very purpose of login authentication when running on top of an encrypted IPSec link. CJ Lee Adaptec, Inc. -----Original Message----- From: Bill Strahm [mailto:bill@sanera.net] Sent: Tuesday, October 23, 2001 8:33 AM To: Ofer Biran Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP Brian, Arguing for situations where IPsec is not implemented/used is a Red Herring. If it is not implemented it is not an iSCSI implementation (remember MUST implement IPsec) therefor it does not have to be considered. If it is not used, then that is an administrative descision that is made based on the security requirements of the environment. My arguement is that CHAP is understood, code is available, it plugs into other authentication services (RADIUS/SecureID) that I am not sure how I would plug an SRP implementation into anyway, and I think that I HAVE to implement it... now SRP doesn't seem to be buying me anything except for "improved security" on a administratively secured link, doesn't seem like much. So based on your statement below have you warrented that IBM will make NO IP claims on the usage of SRP in iSCSI ??? Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ofer Biran Sent: Tuesday, October 23, 2001 1:09 AM To: Bill Strahm Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP 1. It's good news that the Stanford license fee is zero (I verified this - see attached note). 2. > Can you warrant that I will not have to use SRP-Z to implement any iSCSI > operations ? The SRP usage defined in iSCSI is EXACTLY according to RFC-2945. This usage is explicitly covered by the Stanford free license. SRP-Z involves additional private/public keys for the server, and you will not have to use that if you only want to follow the iSCSI standard. 3. If anyone has information about any other IP claiming on the RFC-2945 usage (SRP-SHA1) please post the full information here. 4. There is no question about the superior cryptographic features of SRP over CHAP. In situations where underlying IPsec will not be implemented/used (and these are forecasted), basing the iSCSI security on plain CHAP is a poor solution which IMHO the iSCSI standard should not encourage (by mandating CHAP instead of SRP). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Kirsten Leute on 23/10/2001 00:18:00 Please respond to Kirsten Leute To: Ofer Biran/Haifa/IBM@IBMIL cc: Subject: Re: SRP Licensing terms Dear Ofer: Yes, this is correct.  For the type of usage described in the agreement, there are no licensing fees. As far as I know, there are no licensing issues from Stanford. Best, Kirsten At 06:58 PM 10/22/2001 +0300, you wrote: Kirsten, I'm working on the security aspects of the new iSCSI standard in the IPS working group of the IETF. Our intention is to define SRP (usage according to RFC2945) as the 'mandatory to implement' authentication algorithm. There were concerns in the working group about the licensing terms with Stanford. I looked in your "Ready-to-Sign Agreements" page and it seems to me that there are no fee involved in getting this license. I wanted to verify this with you. Also - are you aware of any other licensing issue with SRP   Thanks in advance,       Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com  972-4-8296253 ************************************** Kirsten Leute Licensing Associate Office of Technology Licensing, Stanford University 900 Welch Road, Suite 350, Palo Alto, CA 94304 Direct: (650) 725-9407; Fax: (650) 725-7295 website: http://otl.stanford.edu/ "Bill Strahm" @ece.cmu.edu on 22/10/2001 18:58:06 Please respond to "Bill Strahm" Sent by: owner-ips@ece.cmu.edu To: Joe Czap/Raleigh/IBM@IBMUS cc: "IPS Reflector \(E-mail\)" , John Hufferd/San Jose/IBM@IBMUS, Subject: RE: iSCSI: Login authentication SRP/CHAP Directly from the Stanford license (http://otl.stanford.edu/pdf/97006.pdf) "Licensed Field of Use" means use of the Invention(s), Software and Licensed Patent(s) in Licensed Product(s) for implicit server authentication. By way of example, but not by limitation, RFC2945. The Licensed Field of Use specifically excludes use of the Invention(s), Software and Licensed Patent(s) machines and servers that deal with explicit bidirectional authentication (for example, SRP-Z for explicit server authentification). SOFTWARE may only be transferred under a Use Sublicense. Note that this applies only if Stanford is the only organization to own IP on this technology and there are no other patents in this field. Joe, can you warrant that IBM will make NO patent claims against this algorithm ? Can you warrant that I will not have to use SRP-Z to implement any iSCSI operations ? Again the problem isn't with the algorithm necissarily, but with the fact that it is the only MUST implement algorithm, I would rather see an algorithm with NO encumbrance against it... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Joe Czap Sent: Monday, October 22, 2001 5:03 AM To: Bill Strahm Cc: IPS Reflector (E-mail); John Hufferd; owner-ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP The lack of information relating to SRP IP concerns make the issue seem a little like misdirection. Can anyone offer a clear explanation the SRP IP situation ? Joe Czap IBM Storage Networking zapper@us.ibm.com From owner-ips@ece.cmu.edu Tue Oct 23 15:36: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 PAA17427 for ; Tue, 23 Oct 2001 15:36:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NIg0714105 for ips-outgoing; Tue, 23 Oct 2001 14:42:00 -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 f9NIfwl14097 for ; Tue, 23 Oct 2001 14:41: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 UAA115742 for ; Tue, 23 Oct 2001 20:41:51 +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 f9NIfoj160128 for ; Tue, 23 Oct 2001 20:41:50 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI - Change Proposal X bit X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 23 Oct 2001 21:41:46 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 23/10/2001 21:41:51, Serialize complete at 23/10/2001 21:41:51 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, A while ago Santosh Rao suggested on this list to remove the X bit as the reassignment function is now handled by a Task Management and "delayed" PDUs can be caught be the command window check. The clear advantage of this change is that the target does not have to check for the X bit and may drop the command if it is out of the window or exists already. However in order to drop "old" commands that might in the pipe on a sluggish connection - removing the X bit will require the initiator to issue an immediate NOP requiring a NOP response on every open connection whenever CmdSN wraps around (becomes equal to InitCmdSN). We may want the new BHS to look like 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|I| Opcode | Opcode-specific fields | +---------------+---------------+---------------+---------------+ 4|TotalAHSLength | DataSegmentLength | +---------------+---------------+---------------+---------------+ 8| LUN or Opcode-specific fields | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag or Opcode-specific fields | +---------------+---------------+---------------+---------------+ 20/ Opcode-specific fields / +/ / +---------------+---------------+---------------+---------------+ 48 and move the direction bit in the opcode 1 bit up Alternatively we may make the X bit reserved. Comments? Julo From owner-ips@ece.cmu.edu Tue Oct 23 15:43: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 PAA17603 for ; Tue, 23 Oct 2001 15:43:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NIO5P12585 for ips-outgoing; Tue, 23 Oct 2001 14:24:05 -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 f9NIO1l12580 for ; Tue, 23 Oct 2001 14:24:01 -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 LAA05520; Tue, 23 Oct 2001 11:23:53 -0700 (PDT) Received: from aimexc07.corp.adaptec.com (aimexc07.corp.adaptec.com [162.62.62.47]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id LAA07943; Tue, 23 Oct 2001 11:09:49 -0700 (PDT) Received: by aimexc07.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Oct 2001 11:23:53 -0700 Message-ID: From: "Lee, CJ" To: "'Bill Strahm'" Cc: "IPS Reflector (E-mail)" , Ofer Biran Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Tue, 23 Oct 2001 11:23:51 -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 Bill, What I am trying to say is between SRP and CHAP (the subject) I would pick SRP as MUST to implement base on the security strength of the protocol. Forgive my naineness, I just don't understand why is > So you are perfectly willing to specify a MUST implement algorithm that > can't be used (what happens if the user password is not available on the > target) to clutter up the implementation space ??? Why 'can't be used' (SRP I suppose)? Don't you have the same per user secret that needs to be amnaged on target side with CHAP as well? cj -----Original Message----- From: Bill Strahm [mailto:bill@Sanera.net] Sent: Tuesday, October 23, 2001 10:55 AM To: Lee, CJ Cc: IPS Reflector (E-mail); Ofer Biran Subject: RE: iSCSI: Login authentication SRP/CHAP So you are perfectly willing to specify a MUST implement algorithm that can't be used (what happens if the user password is not available on the target) to clutter up the implementation space ??? I would rather that A SINGLE usable algorithm is labeled MUST implement (if you must in fact specify a MUST implement at all) and the others are left as SHOULD implment. You are right a clear text Username-> Password-> challenge response works great with a secure link (heck I do it every day with SSH) The idea is usable... Again if the problem is that no one will implmement IPsec/use IPsec, then the problem seems to be with IPsec, lets either make it usable, or pick another security protocol that is deployable. If the problem is to see how secure we can be by requiring as many unusable/unimplementable security algorithms as possible, well I guess we as vendors can just decide to implement the protocol, and the algorithms that make sense to us, and don't worry about interoperability... Bill -----Original Message----- From: Lee, CJ [mailto:CJ_Lee@adaptec.com] Sent: Tuesday, October 23, 2001 10:42 AM To: 'Bill Strahm' Cc: IPS Reflector (E-mail); Ofer Biran Subject: RE: iSCSI: Login authentication SRP/CHAP Personally, I'd think that we ought to select a mandatory to implement authentication protocol base on how secure it is rather than how convenient it is. Especially under the MUST to implement but optional to use nature of both the login authentication and IPSec. One could argue the clear text PAP could server equally well the very purpose of login authentication when running on top of an encrypted IPSec link. CJ Lee Adaptec, Inc. -----Original Message----- From: Bill Strahm [mailto:bill@sanera.net] Sent: Tuesday, October 23, 2001 8:33 AM To: Ofer Biran Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP Brian, Arguing for situations where IPsec is not implemented/used is a Red Herring. If it is not implemented it is not an iSCSI implementation (remember MUST implement IPsec) therefor it does not have to be considered. If it is not used, then that is an administrative descision that is made based on the security requirements of the environment. My arguement is that CHAP is understood, code is available, it plugs into other authentication services (RADIUS/SecureID) that I am not sure how I would plug an SRP implementation into anyway, and I think that I HAVE to implement it... now SRP doesn't seem to be buying me anything except for "improved security" on a administratively secured link, doesn't seem like much. So based on your statement below have you warrented that IBM will make NO IP claims on the usage of SRP in iSCSI ??? Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ofer Biran Sent: Tuesday, October 23, 2001 1:09 AM To: Bill Strahm Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP 1. It's good news that the Stanford license fee is zero (I verified this - see attached note). 2. > Can you warrant that I will not have to use SRP-Z to implement any iSCSI > operations ? The SRP usage defined in iSCSI is EXACTLY according to RFC-2945. This usage is explicitly covered by the Stanford free license. SRP-Z involves additional private/public keys for the server, and you will not have to use that if you only want to follow the iSCSI standard. 3. If anyone has information about any other IP claiming on the RFC-2945 usage (SRP-SHA1) please post the full information here. 4. There is no question about the superior cryptographic features of SRP over CHAP. In situations where underlying IPsec will not be implemented/used (and these are forecasted), basing the iSCSI security on plain CHAP is a poor solution which IMHO the iSCSI standard should not encourage (by mandating CHAP instead of SRP). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Kirsten Leute on 23/10/2001 00:18:00 Please respond to Kirsten Leute To: Ofer Biran/Haifa/IBM@IBMIL cc: Subject: Re: SRP Licensing terms Dear Ofer: Yes, this is correct.  For the type of usage described in the agreement, there are no licensing fees. As far as I know, there are no licensing issues from Stanford. Best, Kirsten At 06:58 PM 10/22/2001 +0300, you wrote: Kirsten, I'm working on the security aspects of the new iSCSI standard in the IPS working group of the IETF. Our intention is to define SRP (usage according to RFC2945) as the 'mandatory to implement' authentication algorithm. There were concerns in the working group about the licensing terms with Stanford. I looked in your "Ready-to-Sign Agreements" page and it seems to me that there are no fee involved in getting this license. I wanted to verify this with you. Also - are you aware of any other licensing issue with SRP   Thanks in advance,       Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com  972-4-8296253 ************************************** Kirsten Leute Licensing Associate Office of Technology Licensing, Stanford University 900 Welch Road, Suite 350, Palo Alto, CA 94304 Direct: (650) 725-9407; Fax: (650) 725-7295 website: http://otl.stanford.edu/ "Bill Strahm" @ece.cmu.edu on 22/10/2001 18:58:06 Please respond to "Bill Strahm" Sent by: owner-ips@ece.cmu.edu To: Joe Czap/Raleigh/IBM@IBMUS cc: "IPS Reflector \(E-mail\)" , John Hufferd/San Jose/IBM@IBMUS, Subject: RE: iSCSI: Login authentication SRP/CHAP Directly from the Stanford license (http://otl.stanford.edu/pdf/97006.pdf) "Licensed Field of Use" means use of the Invention(s), Software and Licensed Patent(s) in Licensed Product(s) for implicit server authentication. By way of example, but not by limitation, RFC2945. The Licensed Field of Use specifically excludes use of the Invention(s), Software and Licensed Patent(s) machines and servers that deal with explicit bidirectional authentication (for example, SRP-Z for explicit server authentification). SOFTWARE may only be transferred under a Use Sublicense. Note that this applies only if Stanford is the only organization to own IP on this technology and there are no other patents in this field. Joe, can you warrant that IBM will make NO patent claims against this algorithm ? Can you warrant that I will not have to use SRP-Z to implement any iSCSI operations ? Again the problem isn't with the algorithm necissarily, but with the fact that it is the only MUST implement algorithm, I would rather see an algorithm with NO encumbrance against it... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Joe Czap Sent: Monday, October 22, 2001 5:03 AM To: Bill Strahm Cc: IPS Reflector (E-mail); John Hufferd; owner-ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP The lack of information relating to SRP IP concerns make the issue seem a little like misdirection. Can anyone offer a clear explanation the SRP IP situation ? Joe Czap IBM Storage Networking zapper@us.ibm.com From owner-ips@ece.cmu.edu Tue Oct 23 15:50: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 PAA17802 for ; Tue, 23 Oct 2001 15:50:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NIuoh15342 for ips-outgoing; Tue, 23 Oct 2001 14:56:50 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9NIuml15337 for ; Tue, 23 Oct 2001 14:56:48 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.nortelnetworks.com (8.11.0/8.11.0) with ESMTP id f9NIu5S21767 for ; Tue, 23 Oct 2001 14:56:05 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 23 Oct 2001 14:56:24 -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 VPDAPSMA; Tue, 23 Oct 2001 14:55:53 -0400 Received: from travos.nortelnetworks.com (cse-ns-laptop.us.nortel.com [47.16.69.109]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VMJ2JZCQ; Tue, 23 Oct 2001 14:55:53 -0400 Message-Id: <5.0.2.1.2.20011023144202.03910dd0@zbl6c002.corpeast.baynetworks.com> X-Sender: travos@zbl6c002.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 23 Oct 2001 14:57:28 -0400 To: Robert Snively , "'Colin Kelly'" , ips@ece.cmu.edu From: "Franco Travostino" Subject: RE: FC encapsulation In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_22746158==_.ALT" X-Orig: Sender: owner-ips@ece.cmu.edu Precedence: bulk --=====================_22746158==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Should we then add a sentence to the 'FC Frame Encapsulation' draft (introduction?) to capture this restricted scope (class 2 & 3)? This scope is somewhat implied in the SOF table (close to the end) but not stated upfront. Like Colin, someone else may be oversold by the title. -franco At 07:06 PM 10/19/2001, Robert Snively wrote: > > > > Is there a fundamental reason why the FC encapsulation draft > > does not include class 1? The Fibre Channel standards (as far > > as I can tell) do not exclude the possibility of allowing > > class 1 connections through a fabric, so regardless of the intent > > of the FCIP, IFCP, and mFCP encapsulations, I do not see why > > this draft should exclude class 1. > >Yes, there really is a fundamental problem. Class 1 switch >behavior makes a full bandwidth lossless circuit connection >between one Fibre Channel node and another. If you push exactly >1 Gbit into it, it SHALL push exactly 1 Gbit out, totally in order and >without loss and with low latency. It will also change >from one circuit connection >to another rather dynamically under Fibre Channel protocol >control, with extremely low connection latencies. > >TCP/IP simply does not provide those capabilities, so we never >even considered including it. Class 6 is a clone of Class 1 in >those respects. Class 4 has the same general properties, but >with clocked fractional bandwidth, so it has the same problems. > >This did not upset most Fibre Channel implementers because all >the key applications that could truly exploit those additional >capabilities provided by TCP/IP were all implemented in Class 2 >and in Class 3. The few highly specialized legacy applications >that used Class 1 were perfectly happy with no IP connectivity. > >Hope that is some help, > >Bob Snively e-mail: rsnively@brocade.com >Brocade Communications Systems phone: 408 487 8135 >1745 Technology Drive >San Jose, CA 95110 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 --=====================_22746158==_.ALT Content-Type: text/html; charset="us-ascii"
Should we then add a sentence to the 'FC Frame Encapsulation' draft (introduction?) to capture this restricted scope (class 2 & 3)? This scope is somewhat implied in the SOF table (close to the end) but not stated upfront. Like Colin, someone else may be oversold by the title.

-franco


At 07:06 PM 10/19/2001, Robert Snively wrote:

>
> Is there a fundamental reason why the FC encapsulation draft
> does not include class 1?  The Fibre Channel standards (as far
> as I can tell) do not exclude the possibility of allowing
> class 1 connections through a fabric, so regardless of the intent
> of the FCIP, IFCP, and mFCP encapsulations, I do not see why
> this draft should exclude class 1.

Yes, there really is a fundamental problem.  Class 1 switch
behavior makes a full bandwidth lossless circuit connection
between one Fibre Channel node and another.  If you push exactly
1 Gbit into it, it SHALL push exactly 1 Gbit out, totally in order and
without loss and with low latency.  It will also change
from one circuit connection
to another rather dynamically under Fibre Channel protocol
control, with extremely low connection latencies.

TCP/IP simply does not provide those capabilities, so we never
even considered including it.  Class 6 is a clone of Class 1 in
those respects.  Class 4 has the same general properties, but
with clocked fractional bandwidth, so it has the same problems.

This did not upset most Fibre Channel implementers because all
the key applications that could truly exploit those additional
capabilities provided by TCP/IP were all implemented in Class 2
and in Class 3.  The few highly specialized legacy applications
that used Class 1 were perfectly happy with no IP connectivity.

Hope that is some help,

Bob Snively                        e-mail:    rsnively@brocade.com
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110


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
 --=====================_22746158==_.ALT-- From owner-ips@ece.cmu.edu Tue Oct 23 17:36: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 RAA20956 for ; Tue, 23 Oct 2001 17:36:27 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NKlts24486 for ips-outgoing; Tue, 23 Oct 2001 16:47:55 -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 f9NKlsl24479 for ; Tue, 23 Oct 2001 16:47:54 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 23E121F59C for ; Tue, 23 Oct 2001 13:47: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 NAA25041 for ; Tue, 23 Oct 2001 13:47:43 -0700 (PDT) Message-ID: <3BD5D94D.4AE23B13@cup.hp.com> Date: Tue, 23 Oct 2001 13:55:41 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re: ips : padding of ahs & data segment. 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 noticed that in certain other sections of the draft such as Appendix F, the following tighter wording is used to describe the use of padding : "Zero to three bytes set to zero shall be appended as padding so that the total length of the designation is a multiple of four." I suggest that wording along the lines of the above be used in Section 3.2.2.2 & 3.2.4, in order to avoid possible mis-interpretation of the number of pad bytes used in AHS and data segments. Thanks, Santosh Barry Reinhold wrote: > > Santosh, > I was not aware of any need to pad beyond the next word (adding 0-3 > bytes)when we were working on the format. I agree that you can read the > standard to imply that any 4 byte boundary would be valid and the wording > could be tightened. > > >-----Original Message----- > >From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > >Santosh Rao > >Sent: Tuesday, October 23, 2001 2:00 PM > >To: IPS Reflector > >Subject: ips : padding of ahs & data segment. > > > > > >All, > > > >Can somebody clarify what the below wording is supposed to imply : > > > >3.2.2.2 AHSLength > > > >The AHS is padded to an integer number of 4 byte words. > > > >3.2.4 Data Segment > > > >The Data Segment is also padded to an integer number of 4 byte words. > > > > > >Does the above imply that there are EXACTLY 0 - 3 pad bytes so as to > >align the AHS and data segment to the nearest 4 byte aligned boundary, > >or can the AHS and data segment be aligned on any integer number of 4 > >byte words ?? > > > >For ex : > >Assume a data segment length of 41 bytes. Does the above wording imply > >that the data segment MUST be exactly padded to a length of 44 bytes, or > >does it allow for padding to 44, 48, 52, 56... bytes ? (multiple integer > >of 4 byte words.) > > > >My interpretation is that the wording is loose and allows for the latter > >(i.e. any multiple integer of 4 byte words.) > > > >However, in order for this to work, the padding must be to the next > >highest 4 byte word boundary beyond the ahs length or data segment > >length. i.e. The pad bytes MUST range between 0 - 3 bytes. > > > >I think the wording needs to be tightened to clarify this. > > > >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 > >################################## -- ################################## 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 Tue Oct 23 17:37: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 RAA20978 for ; Tue, 23 Oct 2001 17:37:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NKhDD24133 for ips-outgoing; Tue, 23 Oct 2001 16:43:13 -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 f9NKhCl24128 for ; Tue, 23 Oct 2001 16:43:12 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel11.hp.com (Postfix) with ESMTP id 5B82D1F84A for ; Tue, 23 Oct 2001 13:43: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 NAA19799 for ; Tue, 23 Oct 2001 13:43:01 -0700 (PDT) Message-ID: <3BD5D833.E21FDFBF@cup.hp.com> Date: Tue, 23 Oct 2001 13:50:59 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re: iSCSI - Change Proposal X bit 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 Satran wrote: > > However in order to drop "old" commands that might in the pipe on a > sluggish connection - removing the X bit will require the initiator to > issue an immediate NOP requiring a NOP response on every open connection > whenever CmdSN wraps around (becomes equal to InitCmdSN). Julian, Can you please explain further the corner case you are describing above ? Are you suggesting that special action should be taken every time CmdSN wraps around, in case there were holes in the CmdSN sequence at the wrap time ? Why is that ? Here's my understanding of how this plays out : Rule 1) The CmdSN management rules at the target should be handling CmdSN wrap case and the initiator cannot issue more than 2^32 -1 commands beyond the last ExpCmdSN update it has received from the target, since the target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above the last ExpCmdSN. (per Section 2.2.2.1) Rule 2) Any holes that occur in the CmdSN sequence are attempted to be plugged by the initiator by re-issuing the original command. If the CmdSN never got acknowledged and the I/O's ULP timeout expired, the initiator MUST perform session recovery. (per Section 8.6) Thus, going by the above 2 rules, if the CmdSN sequence wraps upto ExpCmdSN, the initiator will not be able to issue further commands, since the target will keep the CmdSN window closed. The window can only re-open when the CmdSN holes are plugged allowing ExpCmdSN and thereby, MaxCmdSN to advance. (rule 1 above). Under the above circumstances, the initiator will possibly try to plug the CmdSN hole by re-issuing the original command. It may do this 1 or more times before its ULP timeout expires. Either the holes get plugged and the windoe re-opens, or ULP timeout occurs without the corresponding CmdSN for that I/O having been acknowledged, resulting in session logout. (rule 2 above). What is required over and beyond the above ? Why does removal of X-bit require an immediate NOP to be issued every time CmdSN wraps and a hole exists in the CmdSN sequence (??). 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 Tue Oct 23 17:55: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 RAA21292 for ; Tue, 23 Oct 2001 17:55:54 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NKcHo23714 for ips-outgoing; Tue, 23 Oct 2001 16:38:17 -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 f9NKcGl23710 for ; Tue, 23 Oct 2001 16:38:16 -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 f9NKc9k17190 for ; Tue, 23 Oct 2001 16:38:10 -0400 (EDT) Content-Class: urn:content-classes:message Subject: RE: FC encapsulation MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15C02.A04510FD" Date: Tue, 23 Oct 2001 16:38:09 -0400 Disposition-Notification-To: "Elizabeth Rodriguez" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D45382364983617B248@nc8220exchange.ral.lucent.com> Thread-Topic: FC encapsulation Thread-Index: AcFb9i/+hz7Hpqi6QIeh8P6sRVWBdwADDMIA From: "Elizabeth Rodriguez" To: "Franco Travostino" , "Robert Snively" , "Colin Kelly" , Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C15C02.A04510FD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I would agree with that. Might even want to add Bob's explanation to an informative annex, so that if this question comes up again, it will be answered in the doc... =20 (Personal opinion here -- w/ chair hat off.) =20 Elizabeth -----Original Message----- From: Franco Travostino [mailto:travos@nortelnetworks.com] Sent: Tuesday, October 23, 2001 1:57 PM To: Robert Snively; 'Colin Kelly'; ips@ece.cmu.edu Subject: RE: FC encapsulation Should we then add a sentence to the 'FC Frame Encapsulation' draft (introduction?) to capture this restricted scope (class 2 & 3)? This scope is somewhat implied in the SOF table (close to the end) but not stated upfront. Like Colin, someone else may be oversold by the title. -franco At 07:06 PM 10/19/2001, Robert Snively wrote: >=20 > Is there a fundamental reason why the FC encapsulation draft > does not include class 1? The Fibre Channel standards (as far > as I can tell) do not exclude the possibility of allowing > class 1 connections through a fabric, so regardless of the intent > of the FCIP, IFCP, and mFCP encapsulations, I do not see why > this draft should exclude class 1. Yes, there really is a fundamental problem. Class 1 switch behavior makes a full bandwidth lossless circuit connection between one Fibre Channel node and another. If you push exactly 1 Gbit into it, it SHALL push exactly 1 Gbit out, totally in order and without loss and with low latency. It will also change=20 from one circuit connection to another rather dynamically under Fibre Channel protocol=20 control, with extremely low connection latencies. TCP/IP simply does not provide those capabilities, so we never even considered including it. Class 6 is a clone of Class 1 in those respects. Class 4 has the same general properties, but with clocked fractional bandwidth, so it has the same problems. This did not upset most Fibre Channel implementers because all the key applications that could truly exploit those additional capabilities provided by TCP/IP were all implemented in Class 2 and in Class 3. The few highly specialized legacy applications that used Class 1 were perfectly happy with no IP connectivity. Hope that is some help, Bob Snively e-mail: rsnively@brocade.com Brocade Communications Systems phone: 408 487 8135 1745 Technology Drive San Jose, CA 95110 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_01C15C02.A04510FD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I=20 would agree with that.  Might even want to add Bob's explanation to = an=20 informative annex, so that if this question comes up again, it will be = answered=20 in the doc...
 
(Personal opinion here -- w/ chair hat=20 off.)
 
Elizabeth
-----Original Message-----
From: Franco Travostino=20 [mailto:travos@nortelnetworks.com]
Sent: Tuesday, October = 23, 2001=20 1:57 PM
To: Robert Snively; 'Colin Kelly';=20 ips@ece.cmu.edu
Subject: RE: FC=20 encapsulation


Should we then = add a=20 sentence to the 'FC Frame Encapsulation' draft (introduction?) to = capture this=20 restricted scope (class 2 & 3)? This scope is somewhat implied in = the SOF=20 table (close to the end) but not stated upfront. Like Colin, someone = else may=20 be oversold by the title.

-franco


At 07:06 PM = 10/19/2001,=20 Robert Snively wrote:
>
> Is there a = fundamental=20 reason why the FC encapsulation draft
> does not include class = 1?  The Fibre Channel standards (as far
> as I can tell) = do not=20 exclude the possibility of allowing
> class 1 connections = through a=20 fabric, so regardless of the intent
> of the FCIP, IFCP, and = mFCP=20 encapsulations, I do not see why
> this draft should exclude = class=20 1.

Yes, there really is a fundamental problem.  Class 1=20 switch
behavior makes a full bandwidth lossless circuit=20 connection
between one Fibre Channel node and another.  If = you push=20 exactly
1 Gbit into it, it SHALL push exactly 1 Gbit out, totally = in=20 order and
without loss and with low latency.  It will also = change=20
from one circuit connection
to another rather dynamically = under Fibre=20 Channel protocol
control, with extremely low connection=20 latencies.

TCP/IP simply does not provide those capabilities, = so we=20 never
even considered including it.  Class 6 is a clone of = Class 1=20 in
those respects.  Class 4 has the same general properties, = but
with clocked fractional bandwidth, so it has the same=20 problems.

This did not upset most Fibre Channel implementers = because=20 all
the key applications that could truly exploit those=20 additional
capabilities provided by TCP/IP were all implemented = in Class=20 2
and in Class 3.  The few highly specialized legacy=20 applications
that used Class 1 were perfectly happy with no IP=20 connectivity.

Hope that is some help,

Bob=20 = Snively           =              = e-mail:    rsnively@brocade.com
Brocade = Communications=20 Systems     phone:  408 487 8135
1745 = Technology=20 Drive
San Jose, CA 95110


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

------_=_NextPart_001_01C15C02.A04510FD-- From owner-ips@ece.cmu.edu Tue Oct 23 18:16: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 SAA21557 for ; Tue, 23 Oct 2001 18:16:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9NLEYZ26562 for ips-outgoing; Tue, 23 Oct 2001 17:14:34 -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 f9NLESl26549 for ; Tue, 23 Oct 2001 17:14: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 8095D1F514 for ; Tue, 23 Oct 2001 14:14:22 -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 OAA21481 for ; Tue, 23 Oct 2001 14:14:15 -0700 (PDT) Message-ID: <3BD5DF85.A2448DC0@cup.hp.com> Date: Tue, 23 Oct 2001 14:22:13 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: IPS Reflector Subject: Re: iSCSI - Change Proposal X bit References: <3BD5D833.E21FDFBF@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 Rao wrote: > Rule 1) > The CmdSN management rules at the target should be handling CmdSN wrap > case and the initiator cannot issue more than 2^32 -1 commands beyond ^^^^^^^^^^^^^^^^^^^^^^^^^^ The above should read " more than 2^31 - 1 commands beyond ......." > the last ExpCmdSN update it has received from the target, since the > target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above > the last ExpCmdSN. (per Section 2.2.2.1) > > Rule 2) > Any holes that occur in the CmdSN sequence are attempted to be plugged > by the initiator by re-issuing the original command. If the CmdSN never > got acknowledged and the I/O's ULP timeout expired, the initiator MUST > perform session recovery. (per Section 8.6) -- ################################## 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 Wed Oct 24 05: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 FAA19457 for ; Wed, 24 Oct 2001 05:09:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9O7qLH06961 for ips-outgoing; Wed, 24 Oct 2001 03:52:21 -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 f9O7qIl06949 for ; Wed, 24 Oct 2001 03:52:18 -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 JAA121854 for ; Wed, 24 Oct 2001 09:52: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 f9O7q9x126172 for ; Wed, 24 Oct 2001 09:52:09 +0200 Subject: Re: iSCSI - Change Proposal X bit To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Wed, 24 Oct 2001 09:42:41 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/10/2001 10:52:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, The scenarios I am talking about are all derivatives of an initiator trying to plug-in holes and switching connections. As the initiator does know the "extent" of a hole it can send-out commands that he did not have to. I have sent the attached not to Mallikarjun a while ago. I think that there might be many of this kind. I am also aware that X bit by itself might have some bad scenarios but the new proposal fixes them all. Julo _____________________________ Mallikarjun, Take the following sequence scenario: session has 3 connections on connection 1 I->T c1,c2,c3,C6 on connection 2 I->T c4,c5,c7,c8 Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 and 6 on connection 3 target receives all and starts executing and acks 8 on connection 3 but connection 2 stalls after c3 for a LONG TIME then (after 2 full sequence wraps) connection 2 is gets alive and delivers c4,c5 etc (that are now valid) That is not a very likely scenario, I admit, but it is possible. With X bit I could not find any such scenario since an X either follows a good one on the same connection or can be safely discarded. I suspect that there are some more scenarios that involve immediate commands or commands that carry their own ack in the status and are acked like: 2 connections: connection1 I->T c3,c4,c5 status of 3 contains ack up to 6 and it and all other statuses are lost connection2 resend c3, c4 & c5 (no logout) and those are executed! I think we can avoid those be requiring a NOP exchange before reissuing a command on a new connection or reissue the command with a task management (that has an implied ordering) but why do it if X is an obvious and safe solution. Julo Regards, Julo "Mallikarjun C." To: Julian Satran/Haifa/IBM@IBMIL Subject: Re: iscsi : X bit in SCSI Command PDU. 08-10-01 21:45 Please respond to cbm Julian, We currently have the following specified in section 2.2.2.1 - "The target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above the last ExpCmdSN." It appears to me that the above is sufficient to ward off the accidents of the sort you describe. Do you think otherwise? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > Mallikarjun, > > There is at least one theoretical scenario in which an "old" command > may appear in a "new window" and be reinstantiated. > At 10Gbs and several connection that does not take months. With X the > probability is far lower (not 0). I have no other strong arguments > but I am still thinking. Matt Wakeley that insisted on it (against > me) had some other argument that I am trying to find (I am note > remembering). > > Julo > > "Mallikarjun C." > To: Julian > Satran/Haifa/IBM@IBMIL > 08-10-01 20:39 cc: > Please respond to cbm Subject: Re: iscsi : X > bit in SCSI Command PDU. > > > > Julian, > > Now that you put me on the spot, :-), my response - > > Santosh argued with me privately that X-bit no longer serves a > useful purpose after the advent of task management commands to > reassign. My response was that it never was a requirement per se, > but always a "courtesy" extended by the initiator to help the > target. I also suggested that X-bit may be considered for its > usefulness in debugging. > > He still had some (very reasonable) comments for simplification > - the most appealing of which (to me) was the opportunity to do > away with the X-bit checking for *every* command PDU that the target > has to endure now. > > If I missed a legitimate use of X-bit, please comment. Do you > think it is a protocol requirement per se? I couldn't justify > to myself so far (except the Login). > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > > Julian Satran wrote: > > > > Santosh, > > > > I am not sure you went through all scenarios. A conversation with > your > > colleague - Mallikarjun - and getting through the state table may go > a > > long way to clarify the need for X. > > > > And I am sure that by now you found yourself several . > > > > Julo > > > > Santosh Rao > > To: IPS Reflector > > Sent by: owner-ips@ece.cmu.edu > > cc: > > 06-10-01 01:56 Subject: iscsi : X > > Please respond to Santosh Rao bit in SCSI Command PDU. > > > > > > > > All, > > > > With the elimination of command relay from iscsi [in the interests > of > > simplification ?], I believe that the X bit in the SCSI Command PDU > > can > > also be removed. As it exists today, the X bit is only being used > for > > command restart, which is at attempt by the initiator to plug a > > potential hole in the CmdSN sequence at the target. It does this on > > failing to get an ExpCmdSN ack for a previously sent command within > > some > > timeout period. > > > > Given the above usage of command restart, no X bit is required to be > > set > > in the SCSI Command PDU when command re-start is done. > > > > Either : > > (a) the target had dropped the command earlier due to a digest > error, > > in > > which case, the command restart plugs the CmdSN hole in the target. > > > > [OR] > > > > (b) the target had received the command and was working on it, when > > the > > initiator timed out too soon and attempted a command restart to plug > > [what it thought was] a possible hole in the CmdSN sequence. > > > > In case (a), no X bit was required, since the target knows nothing > of > > the original command. In case (b), no X bit is required again, since > > the > > (ExpCmdSN, MaxCmdSN) window would have advanced and the target can > > silently discard the received retry and continue working on the > > original > > command received. > > > > Removal of the X bit in the SCSI Command PDU has the following > > benefits > > : > > > > a) The CmdSN rules at the target are simplified. No need to look at > X > > bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) window. > > > > b) The reject reason code "command already in progress" can be > > removed. > > There's no need for this reject reason code anymore, since X bit > > itself > > is not required, and the targets can silently discard commands > outside > > the command window and continue to work on the original instance of > > the > > command already being processed at the target. > > > > c) Less work for the target and less resources consumed since it no > > longer needs to generate a Reject PDU of type "command in progress". > > It > > can just silently discard any command PDU outside the (ExpCmdSN, > > MaxCmdSN) window. > > > > d) Less code for the target, since it does not need : > > - any Reject code paths when it receives X bit command PDUs that are > > already in progress. > > - No special casing of CmdSN checking rules. > > - No overheads of verifying a received command based on its > initiator > > task tag, to check if the task is currently active, prior to sending > a > > Reject response with "command in progress". > > > > 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 > > ################################## Santosh Rao hp.com> cc: Sent by: Subject: Re: iSCSI - Change Proposal X bit owner-ips@ece. cmu.edu 23-10-01 22:50 Please respond to Santosh Rao Julian Satran wrote: > > However in order to drop "old" commands that might in the pipe on a > sluggish connection - removing the X bit will require the initiator to > issue an immediate NOP requiring a NOP response on every open connection > whenever CmdSN wraps around (becomes equal to InitCmdSN). Julian, Can you please explain further the corner case you are describing above ? Are you suggesting that special action should be taken every time CmdSN wraps around, in case there were holes in the CmdSN sequence at the wrap time ? Why is that ? Here's my understanding of how this plays out : Rule 1) The CmdSN management rules at the target should be handling CmdSN wrap case and the initiator cannot issue more than 2^32 -1 commands beyond the last ExpCmdSN update it has received from the target, since the target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above the last ExpCmdSN. (per Section 2.2.2.1) Rule 2) Any holes that occur in the CmdSN sequence are attempted to be plugged by the initiator by re-issuing the original command. If the CmdSN never got acknowledged and the I/O's ULP timeout expired, the initiator MUST perform session recovery. (per Section 8.6) Thus, going by the above 2 rules, if the CmdSN sequence wraps upto ExpCmdSN, the initiator will not be able to issue further commands, since the target will keep the CmdSN window closed. The window can only re-open when the CmdSN holes are plugged allowing ExpCmdSN and thereby, MaxCmdSN to advance. (rule 1 above). Under the above circumstances, the initiator will possibly try to plug the CmdSN hole by re-issuing the original command. It may do this 1 or more times before its ULP timeout expires. Either the holes get plugged and the windoe re-opens, or ULP timeout occurs without the corresponding CmdSN for that I/O having been acknowledged, resulting in session logout. (rule 2 above). What is required over and beyond the above ? Why does removal of X-bit require an immediate NOP to be issued every time CmdSN wraps and a hole exists in the CmdSN sequence (??). 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 Wed Oct 24 08:14: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 IAA23302 for ; Wed, 24 Oct 2001 08:14:46 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OBLGq29668 for ips-outgoing; Wed, 24 Oct 2001 07:21:16 -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 f9OBLFl29655 for ; Wed, 24 Oct 2001 07:21:15 -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 NAA53554 for ; Wed, 24 Oct 2001 13:21:07 +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 f9OBL7x60926 for ; Wed, 24 Oct 2001 13:21:07 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI Digests X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 24 Oct 2001 14:21:02 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/10/2001 14:21:06, Serialize complete at 24/10/2001 14:21:06 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, As it was discussed on the list - the standard digests (CRC32C) are now being only for integrity and it makes sense to move their negotiation in the Operational Negotiation stage of login. The text for the appendix section should look like: 01 HeaderDigest and DataDigest Use: IO Who can send: Initiator and Target HeaderDigest = DataDigest = Digests enable checking end-to-end data integrity beyond the integrity checks provided by the link layers and covering the whole communication path including all elements that may change the network level PDUs like routers, switches, proxies, etc. The following table lists cyclic integrity checksums that can be negotiated for the digests and MUST be implemented by every iSCSI initiator and target. Note that these digest options have only error detection significance. +---------------------------------------------+ | Name | Description | Generator | +---------------------------------------------+ | CRC32C | 32 bit CRC |0x11edc6f41| +---------------------------------------------+ | none | no digest | +---------------------------------------------+ The generator polynomial for this digest is given in hex-notation, for example 0x3b stands for 0011 1011 - the polynomial x**5+X**4+x**3+x+1. When Initiator and Target agree on a digest, this digest MUST be used for every PDU in Full Feature Phase. Padding bytes, when present, in a segment covered by a CRC, should be set to 0 and are included in the CRC. The CRC should be calculated as follows: - data are assumed to be in the numbering order that appears in the draft - start with byte 0 bit 0 continue byte 1 bit 0 etc. (Big Endian on bytes / Little Endian on bits) - the CRC register is initialized with all 1s (equivalent to complementing the first 32 bits of the message) - the n PDU bits are considered coefficients of a polynomial M(x) of order n-1, with bit 0 of byte 0 being x^(n-1) - the polynomial is multiplied by x^32 and divided by G(x)- the generator polynomial - producing a remainder R(x) of degree <= 31 - the coefficients of R(x) are considered a 32 bit sequence - the bit sequence is complemented and the result is the CRC - after the last bit of the original segment the CRC bits are transmitted with x^31 first followed by x^30 etc. ( whenever examples are given the value to be specified in examples follows the same rules of representation as the rest of this document) - a receiver of a "good" segment (data or header) built using the generator 0x11edc6f41 will end-up having in the CRC register the value 0x1c2d19ed (this a register value and not a word as outlined in this draft) Proprietary algorithms MAY also be negotiated for digests. Whenever a proprietary algorithm is negotiated, "none" or "CRC32C" should be listed as an option in order to guarantee compatibility Comments? Julo From owner-ips@ece.cmu.edu Wed Oct 24 10:01: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 KAA29730 for ; Wed, 24 Oct 2001 10:01:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OCuCj05053 for ips-outgoing; Wed, 24 Oct 2001 08:56:12 -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 f9OCuAl05048 for ; Wed, 24 Oct 2001 08:56:10 -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 OAA78306 for ; Wed, 24 Oct 2001 14:56: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 f9OCu2x262864 for ; Wed, 24 Oct 2001 14:56:02 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: Login authentication SRP/CHAP X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 24 Oct 2001 15:55:55 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/10/2001 15:56:02, Serialize complete at 24/10/2001 15:56:02 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 f9OCuAl05049 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Bill, You seem intent on having a working solution that fills a specific set of requirements. As the ideas you put forward are beyond a simple controversial technical item but not "fleshed out" enough for simple mortals to read, I think that the group (list) could benefit from you having all your ideas about requirements and how they should be implemented completely fleshed out in a submitted draft that we can read and judge. Thanks, Julo "Bill Strahm" Sent by: owner-ips@ece.cmu.edu 23-10-01 19:55 Please respond to "Bill Strahm" To: "Lee, CJ" cc: "IPS Reflector \(E-mail\)" , Ofer Biran/Haifa/IBM@IBMIL Subject: RE: iSCSI: Login authentication SRP/CHAP So you are perfectly willing to specify a MUST implement algorithm that can't be used (what happens if the user password is not available on the target) to clutter up the implementation space ??? I would rather that A SINGLE usable algorithm is labeled MUST implement (if you must in fact specify a MUST implement at all) and the others are left as SHOULD implment. You are right a clear text Username-> Password-> challenge response works great with a secure link (heck I do it every day with SSH) The idea is usable... Again if the problem is that no one will implmement IPsec/use IPsec, then the problem seems to be with IPsec, lets either make it usable, or pick another security protocol that is deployable. If the problem is to see how secure we can be by requiring as many unusable/unimplementable security algorithms as possible, well I guess we as vendors can just decide to implement the protocol, and the algorithms that make sense to us, and don't worry about interoperability... Bill -----Original Message----- From: Lee, CJ [mailto:CJ_Lee@adaptec.com] Sent: Tuesday, October 23, 2001 10:42 AM To: 'Bill Strahm' Cc: IPS Reflector (E-mail); Ofer Biran Subject: RE: iSCSI: Login authentication SRP/CHAP Personally, I'd think that we ought to select a mandatory to implement authentication protocol base on how secure it is rather than how convenient it is. Especially under the MUST to implement but optional to use nature of both the login authentication and IPSec. One could argue the clear text PAP could server equally well the very purpose of login authentication when running on top of an encrypted IPSec link. CJ Lee Adaptec, Inc. -----Original Message----- From: Bill Strahm [mailto:bill@sanera.net] Sent: Tuesday, October 23, 2001 8:33 AM To: Ofer Biran Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP Brian, Arguing for situations where IPsec is not implemented/used is a Red Herring. If it is not implemented it is not an iSCSI implementation (remember MUST implement IPsec) therefor it does not have to be considered. If it is not used, then that is an administrative descision that is made based on the security requirements of the environment. My arguement is that CHAP is understood, code is available, it plugs into other authentication services (RADIUS/SecureID) that I am not sure how I would plug an SRP implementation into anyway, and I think that I HAVE to implement it... now SRP doesn't seem to be buying me anything except for "improved security" on a administratively secured link, doesn't seem like much. So based on your statement below have you warrented that IBM will make NO IP claims on the usage of SRP in iSCSI ??? Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ofer Biran Sent: Tuesday, October 23, 2001 1:09 AM To: Bill Strahm Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP 1. It's good news that the Stanford license fee is zero (I verified this - see attached note). 2. > Can you warrant that I will not have to use SRP-Z to implement any iSCSI > operations ? The SRP usage defined in iSCSI is EXACTLY according to RFC-2945. This usage is explicitly covered by the Stanford free license. SRP-Z involves additional private/public keys for the server, and you will not have to use that if you only want to follow the iSCSI standard. 3. If anyone has information about any other IP claiming on the RFC-2945 usage (SRP-SHA1) please post the full information here. 4. There is no question about the superior cryptographic features of SRP over CHAP. In situations where underlying IPsec will not be implemented/used (and these are forecasted), basing the iSCSI security on plain CHAP is a poor solution which IMHO the iSCSI standard should not encourage (by mandating CHAP instead of SRP). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Kirsten Leute on 23/10/2001 00:18:00 Please respond to Kirsten Leute To: Ofer Biran/Haifa/IBM@IBMIL cc: Subject: Re: SRP Licensing terms Dear Ofer: Yes, this is correct.  For the type of usage described in the agreement, there are no licensing fees. As far as I know, there are no licensing issues from Stanford. Best, Kirsten At 06:58 PM 10/22/2001 +0300, you wrote: Kirsten, I'm working on the security aspects of the new iSCSI standard in the IPS working group of the IETF. Our intention is to define SRP (usage according to RFC2945) as the 'mandatory to implement' authentication algorithm. There were concerns in the working group about the licensing terms with Stanford. I looked in your "Ready-to-Sign Agreements" page and it seems to me that there are no fee involved in getting this license. I wanted to verify this with you. Also - are you aware of any other licensing issue with SRP   Thanks in advance,       Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com  972-4-8296253 ************************************** Kirsten Leute Licensing Associate Office of Technology Licensing, Stanford University 900 Welch Road, Suite 350, Palo Alto, CA 94304 Direct: (650) 725-9407; Fax: (650) 725-7295 website: http://otl.stanford.edu/ "Bill Strahm" @ece.cmu.edu on 22/10/2001 18:58:06 Please respond to "Bill Strahm" Sent by: owner-ips@ece.cmu.edu To: Joe Czap/Raleigh/IBM@IBMUS cc: "IPS Reflector \(E-mail\)" , John Hufferd/San Jose/IBM@IBMUS, Subject: RE: iSCSI: Login authentication SRP/CHAP Directly from the Stanford license (http://otl.stanford.edu/pdf/97006.pdf) "Licensed Field of Use" means use of the Invention(s), Software and Licensed Patent(s) in Licensed Product(s) for implicit server authentication. By way of example, but not by limitation, RFC2945. The Licensed Field of Use specifically excludes use of the Invention(s), Software and Licensed Patent(s) machines and servers that deal with explicit bidirectional authentication (for example, SRP-Z for explicit server authentification). SOFTWARE may only be transferred under a Use Sublicense. Note that this applies only if Stanford is the only organization to own IP on this technology and there are no other patents in this field. Joe, can you warrant that IBM will make NO patent claims against this algorithm ? Can you warrant that I will not have to use SRP-Z to implement any iSCSI operations ? Again the problem isn't with the algorithm necissarily, but with the fact that it is the only MUST implement algorithm, I would rather see an algorithm with NO encumbrance against it... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Joe Czap Sent: Monday, October 22, 2001 5:03 AM To: Bill Strahm Cc: IPS Reflector (E-mail); John Hufferd; owner-ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP The lack of information relating to SRP IP concerns make the issue seem a little like misdirection. Can anyone offer a clear explanation the SRP IP situation ? Joe Czap IBM Storage Networking zapper@us.ibm.com From owner-ips@ece.cmu.edu Wed Oct 24 12:51: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 MAA06119 for ; Wed, 24 Oct 2001 12:51:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OFk1Y17081 for ips-outgoing; Wed, 24 Oct 2001 11:46:01 -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 f9OFjwl17074 for ; Wed, 24 Oct 2001 11:45:58 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f9OFjSM00745; Wed, 24 Oct 2001 11:45:28 -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 f9OFjSj09867; Wed, 24 Oct 2001 11:45:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15318.57882.245000.822329@gargle.gargle.HOWL> Date: Wed, 24 Oct 2001 11:45:30 -0400 From: Paul Koning To: bill@sanera.net Cc: CJ_Lee@adaptec.com, ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP 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 23 October 2001) by Bill Strahm: > ... > I would rather that A SINGLE usable algorithm is labeled MUST implement (if > you must in fact specify a MUST implement at all) and the others are left as > SHOULD implment. You are right a clear text Username-> Password-> challenge > response works great with a secure link (heck I do it every day with SSH) > The idea is usable... > > Again if the problem is that no one will implmement IPsec/use IPsec, then > the problem seems to be with IPsec, lets either make it usable, or pick > another security protocol that is deployable. There seem to be two issues. 1. The IPSec requirement, as stated in the security draft, is that integrity is mandatory but confidentiality is optional to implement. So in fact there is no mandatory-to-implement lower layer confidentiality mechanism that protects the login authentication handshake. If the only vulnerability of a proposed login authentication protocol is in the presence of replay attacks, the IPSec based integrity requirement suffices. If, however, the mechanism is vulnerable to dictionary attacks or other similar problems that require only passive attack, then IPSec based integrity is of no help and its status is irrelevant. 2. It is not clear whether the "rough consensus" required to incorporate a mandate for IPSec in iSCSI exists in this working group. There is significant question on whether it makes technical sense as written. The issue with IPSec implementation/use is not a problem with IPSec that can be resolved by picking a different security protocol. Instead, it is with the choice of requirements as currently stated in the security draft vs. the requirements of a major part of the user community for iSCSI. paul From owner-ips@ece.cmu.edu Wed Oct 24 13:00: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 NAA06497 for ; Wed, 24 Oct 2001 13:00:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OGLjT19845 for ips-outgoing; Wed, 24 Oct 2001 12:21:45 -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 f9OGLhl19841 for ; Wed, 24 Oct 2001 12:21:43 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 94A9388E; Wed, 24 Oct 2001 09:21:33 -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 JAA27124; Wed, 24 Oct 2001 09:21:23 -0700 (PDT) Message-ID: <3BD6EC63.44A9146E@cup.hp.com> Date: Wed, 24 Oct 2001 09:29:23 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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 - Change Proposal X bit 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, Some comments on the below quoted scenarios : > session has 3 connections > on connection 1 I->T c1,c2,c3,C6 > on connection 2 I->T c4,c5,c7,c8 > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 and 6 > on connection 3 > target receives all and starts executing and acks 8 on connection 3 but > connection 2 stalls after c3 for a LONG TIME > then (after 2 full sequence wraps) connection 2 is gets alive and > delivers c4,c5 etc (that are now valid) When the target acks CmdSN 8 on connection 3, it has, in effect, sent CmdSN ack's for CMdSNs 3,4,5,6,7,8. This implies that the commands with CmdSN 3, 4, 5, 7, & 8 were received by the target on connection 2 and their processing was commenced. Hence, the following does not make sense : > connection 2 stalls after c3 for a LONG TIME > then (after 2 full sequence wraps) connection 2 is gets alive and > delivers c4,c5 etc (that are now valid) c4, c5, etc were already delivered to the target and are not being re-delivered. There is no problem in this case. (??). Take the next scenario : > 2 connections: > > connection1 I->T c3,c4,c5 > status of 3 contains ack up to 6 and it and all other statuses are > lost > connection2 resend c3, c4 & c5 (no logout) and those are executed! Since the initiator got CmdSN ack's upto 6, the initiator should not be re-issuing these I/Os ?? I still don't see justification to require that initiators send a immediate NOP-OUT in the manner being advocated. On a more fundamental note, I see some issues with the initiator being allowed to re-issue the commands on a different connection without having first logged out the previous connection successfully. I see nothing in the draft that suggests such behaviour, while at the same time, it is not forbidden. By resorting to command retries on a different connection in an attempt to plug the hole, without first logging out the previous connection, the initiator is susceptible to encountering I/O failure of that I/O due to ULP timeout. Here's the scenario why such recovery should not be allowed : - Initiator sends CmdSN 3 on connection 1. - No CmdSN updates for a while and initiator re-sends CmdSn 3 on connection 2. - At the same time, target has sent CmdSN ack's for CmdSN 3 on connection 1. - Initiator has transferred the command allegiance on its side from connection 1 to connection 2 and is attempting the command on connection 2. However, the command does not go through, since the (ExpCmdSN, MaxCmdSN) window has advanced and the trget discards the command. - Target sends in data and/or R2T and/or status for CmdSN 3 on connection 1. Since the initiator is not expecting any traffic for that I/O on connection 1, it discards any PDUs received on that connection 1 for which no I/O state existed. In the above scenario, initiator will never get a CmdSN ack on connection 2 and will never be able to plug the hole despite repeated retries, finally, causing a ULP timeout, followed by session recovery. Given the above scenario, I suggest that the initiator must only re-issue commands on the same connection, and can re-issue them on another connection only following a successful logout. Comments ? Thanks, Santosh Julian Satran wrote: > > Santosh, > > The scenarios I am talking about are all derivatives of an initiator trying > to plug-in holes and switching connections. > As the initiator does know the "extent" of a hole it can send-out commands > that he did not have to. > I have sent the attached not to Mallikarjun a while ago. I think that > there might be many of this kind. I am also aware that X bit by itself > might have some bad scenarios but the new proposal fixes them all. > > Julo > > _____________________________ > > Mallikarjun, > > Take the following sequence scenario: > > session has 3 connections > on connection 1 I->T c1,c2,c3,C6 > on connection 2 I->T c4,c5,c7,c8 > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 and 6 > on connection 3 > target receives all and starts executing and acks 8 on connection 3 but > connection 2 stalls after c3 for a LONG TIME > then (after 2 full sequence wraps) connection 2 is gets alive and > delivers c4,c5 etc (that are now valid) > > That is not a very likely scenario, I admit, but it is possible. > With X bit I could not find any such scenario since an X either follows a > good one on the same connection or can be safely discarded. > I suspect that there are some more scenarios that involve immediate > commands or commands that carry their own ack in the status and are acked > like: > > 2 connections: > > connection1 I->T c3,c4,c5 > status of 3 contains ack up to 6 and it and all other statuses are > lost > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > I think we can avoid those be requiring a NOP exchange before reissuing a > command on a new connection or reissue the command with a task management > (that has an implied ordering) but why do it if X is an obvious and safe > solution. > > Julo > > Regards, > Julo > > > "Mallikarjun > C." To: Julian Satran/Haifa/IBM@IBMIL > om> Subject: Re: iscsi : X bit in SCSI Command PDU. > > 08-10-01 21:45 > Please respond > to cbm > > > > Julian, > > We currently have the following specified in section 2.2.2.1 - > > "The target MUST NOT transmit a MaxCmdSN that is more than > 2**31 - 1 above the last ExpCmdSN." > > It appears to me that the above is sufficient to ward off the > accidents of the sort you describe. Do you think otherwise? > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Julian Satran wrote: > > > > Mallikarjun, > > > > There is at least one theoretical scenario in which an "old" command > > may appear in a "new window" and be reinstantiated. > > At 10Gbs and several connection that does not take months. With X the > > probability is far lower (not 0). I have no other strong arguments > > but I am still thinking. Matt Wakeley that insisted on it (against > > me) had some other argument that I am trying to find (I am note > > remembering). > > > > Julo > > > > "Mallikarjun C." > > To: Julian > > Satran/Haifa/IBM@IBMIL > > 08-10-01 20:39 cc: > > Please respond to cbm Subject: Re: iscsi : X > > bit in SCSI Command PDU. > > > > > > > > Julian, > > > > Now that you put me on the spot, :-), my response - > > > > Santosh argued with me privately that X-bit no longer serves a > > useful purpose after the advent of task management commands to > > reassign. My response was that it never was a requirement per se, > > but always a "courtesy" extended by the initiator to help the > > target. I also suggested that X-bit may be considered for its > > usefulness in debugging. > > > > He still had some (very reasonable) comments for simplification > > - the most appealing of which (to me) was the opportunity to do > > away with the X-bit checking for *every* command PDU that the target > > has to endure now. > > > > If I missed a legitimate use of X-bit, please comment. Do you > > think it is a protocol requirement per se? I couldn't justify > > to myself so far (except the Login). > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > > > > > Julian Satran wrote: > > > > > > Santosh, > > > > > > I am not sure you went through all scenarios. A conversation with > > your > > > colleague - Mallikarjun - and getting through the state table may go > > a > > > long way to clarify the need for X. > > > > > > And I am sure that by now you found yourself several . > > > > > > Julo > > > > > > Santosh Rao > > > To: IPS Reflector > > > Sent by: owner-ips@ece.cmu.edu > > > cc: > > > 06-10-01 01:56 Subject: iscsi : X > > > Please respond to Santosh Rao bit in SCSI Command PDU. > > > > > > > > > > > > All, > > > > > > With the elimination of command relay from iscsi [in the interests > > of > > > simplification ?], I believe that the X bit in the SCSI Command PDU > > > can > > > also be removed. As it exists today, the X bit is only being used > > for > > > command restart, which is at attempt by the initiator to plug a > > > potential hole in the CmdSN sequence at the target. It does this on > > > failing to get an ExpCmdSN ack for a previously sent command within > > > some > > > timeout period. > > > > > > Given the above usage of command restart, no X bit is required to be > > > set > > > in the SCSI Command PDU when command re-start is done. > > > > > > Either : > > > (a) the target had dropped the command earlier due to a digest > > error, > > > in > > > which case, the command restart plugs the CmdSN hole in the target. > > > > > > [OR] > > > > > > (b) the target had received the command and was working on it, when > > > the > > > initiator timed out too soon and attempted a command restart to plug > > > [what it thought was] a possible hole in the CmdSN sequence. > > > > > > In case (a), no X bit was required, since the target knows nothing > > of > > > the original command. In case (b), no X bit is required again, since > > > the > > > (ExpCmdSN, MaxCmdSN) window would have advanced and the target can > > > silently discard the received retry and continue working on the > > > original > > > command received. > > > > > > Removal of the X bit in the SCSI Command PDU has the following > > > benefits > > > : > > > > > > a) The CmdSN rules at the target are simplified. No need to look at > > X > > > bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) window. > > > > > > b) The reject reason code "command already in progress" can be > > > removed. > > > There's no need for this reject reason code anymore, since X bit > > > itself > > > is not required, and the targets can silently discard commands > > outside > > > the command window and continue to work on the original instance of > > > the > > > command already being processed at the target. > > > > > > c) Less work for the target and less resources consumed since it no > > > longer needs to generate a Reject PDU of type "command in progress". > > > It > > > can just silently discard any command PDU outside the (ExpCmdSN, > > > MaxCmdSN) window. > > > > > > d) Less code for the target, since it does not need : > > > - any Reject code paths when it receives X bit command PDUs that are > > > already in progress. > > > - No special casing of CmdSN checking rules. > > > - No overheads of verifying a received command based on its > > initiator > > > task tag, to check if the task is currently active, prior to sending > > a > > > Reject response with "command in progress". > > > > > > 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 > > > ################################## > > > Santosh Rao > > hp.com> cc: > Sent by: Subject: Re: iSCSI - Change Proposal X bit > owner-ips@ece. > cmu.edu > > > 23-10-01 22:50 > Please respond > to Santosh Rao > > > > Julian Satran wrote: > > > > However in order to drop "old" commands that might in the pipe on a > > sluggish connection - removing the X bit will require the initiator to > > issue an immediate NOP requiring a NOP response on every open connection > > whenever CmdSN wraps around (becomes equal to InitCmdSN). > > Julian, > > Can you please explain further the corner case you are describing above > ? Are you suggesting that special action should be taken every time > CmdSN wraps around, in case there were holes in the CmdSN sequence at > the wrap time ? Why is that ? > > Here's my understanding of how this plays out : > > Rule 1) > The CmdSN management rules at the target should be handling CmdSN wrap > case and the initiator cannot issue more than 2^32 -1 commands beyond > the last ExpCmdSN update it has received from the target, since the > target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above > the last ExpCmdSN. (per Section 2.2.2.1) > > Rule 2) > Any holes that occur in the CmdSN sequence are attempted to be plugged > by the initiator by re-issuing the original command. If the CmdSN never > got acknowledged and the I/O's ULP timeout expired, the initiator MUST > perform session recovery. (per Section 8.6) > > Thus, going by the above 2 rules, if the CmdSN sequence wraps upto > ExpCmdSN, the initiator will not be able to issue further commands, > since the target will keep the CmdSN window closed. The window can only > re-open when the CmdSN holes are plugged allowing ExpCmdSN and thereby, > MaxCmdSN to advance. (rule 1 above). > > Under the above circumstances, the initiator will possibly try to plug > the CmdSN hole by re-issuing the original command. It may do this 1 or > more times before its ULP timeout expires. Either the holes get plugged > and the windoe re-opens, or ULP timeout occurs without the corresponding > CmdSN for that I/O having been acknowledged, resulting in session > logout. (rule 2 above). > > What is required over and beyond the above ? Why does removal of X-bit > require an immediate NOP to be issued every time CmdSN wraps and a hole > exists in the CmdSN sequence (??). > > Regards, > 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 Wed Oct 24 13:37: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 MAA06120 for ; Wed, 24 Oct 2001 12:51:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OGAQC18983 for ips-outgoing; Wed, 24 Oct 2001 12:10:26 -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 f9OGAOl18977 for ; Wed, 24 Oct 2001 12:10:24 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9OGAIu06791; Wed, 24 Oct 2001 09:10:18 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9OGADB18549; Wed, 24 Oct 2001 09:10:13 -0700 From: "Bill Strahm" To: "Paul Koning" Cc: , Subject: RE: iSCSI: Login authentication SRP/CHAP Date: Wed, 24 Oct 2001 09:09: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) In-Reply-To: <15318.57882.245000.822329@gargle.gargle.HOWL> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit What do you mean... I have a MUST implement 3DES, SHA1, MD5, and DES (from the IPsec requirements) all though IPS wants to put a SHOULD NOT implement DES requirement in... IPsec therefor mandates implementation of confidentiality. It is up to the network administrator to determine what the security levels are, therefor you can say that ALL iSCSI links are administratively secure. Just because a link isn't encrypted doesn't mean it isn't secure (I can have a link in a guarded and locked room surrounded by M-16 wielding Marines -- I defy you to snoop it) I disagree with your call saying that there is not rough concensus to use IPsec with iSCSI. I believe David Black (correct me if I am wrong here David) has said the group has rough concensus to use IPsec as the security solution. Now it might be that the rough concensus is there because it is a forced solution from the IESG, however in that case I propose you take that up with the Area Directors (and Jeff Schiller/Marcus Leech the security ADs). You are right, I would prefer a TLS based solution, I think it is much more deployable... However this isn't the case so lets make IPsec work... I agree with you on user/protocol requirements. I worked for a couple of years on an IPsec product and am rather underwhelmed with its deployability. Some of that was the tool that was developed, much of it was the problems with getting a interoperable security policy that would work between my old companies product and several competitors products. The interesting thing is we were actually targetting end-end rather than tunneled VPN like most of the other vendors that I knew of... Some interesting things that I saw (and I am very afraid of in the iSCSI context were) 1) Micro policies just don't seem to work/scale - i.e. having a SA per connection, rather than per link 2) Bulk crypto to 100 Mbps is possible, but going beyond is expensive (2 years old multiply by 2.25 for Moores Law) 3) Asymetric Crypto Matters 4) Its all about deployability - I have yet to see a cross platform/interoperable security policy product 5) Encrypting traffic on subset of the corprate net has interesting results - Corperation IT departments (at least my former employers) tend to do a LOT of scanning, management traffic to your box... These are the negatives, the possitives are 1) You can get it to work and work well 2) With cheap crypto accelerators (ie built into your commodity NIC) it is cheap and fast without much CPU impact and can run above 80Mbs on a 100 Mbs network Bill -----Original Message----- From: Paul Koning [mailto:ni1d@arrl.net] Sent: Wednesday, October 24, 2001 8:46 AM To: bill@Sanera.net Cc: CJ_Lee@adaptec.com; ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP Excerpt of message (sent 23 October 2001) by Bill Strahm: > ... > I would rather that A SINGLE usable algorithm is labeled MUST implement (if > you must in fact specify a MUST implement at all) and the others are left as > SHOULD implment. You are right a clear text Username-> Password-> challenge > response works great with a secure link (heck I do it every day with SSH) > The idea is usable... > > Again if the problem is that no one will implmement IPsec/use IPsec, then > the problem seems to be with IPsec, lets either make it usable, or pick > another security protocol that is deployable. There seem to be two issues. 1. The IPSec requirement, as stated in the security draft, is that integrity is mandatory but confidentiality is optional to implement. So in fact there is no mandatory-to-implement lower layer confidentiality mechanism that protects the login authentication handshake. If the only vulnerability of a proposed login authentication protocol is in the presence of replay attacks, the IPSec based integrity requirement suffices. If, however, the mechanism is vulnerable to dictionary attacks or other similar problems that require only passive attack, then IPSec based integrity is of no help and its status is irrelevant. 2. It is not clear whether the "rough consensus" required to incorporate a mandate for IPSec in iSCSI exists in this working group. There is significant question on whether it makes technical sense as written. The issue with IPSec implementation/use is not a problem with IPSec that can be resolved by picking a different security protocol. Instead, it is with the choice of requirements as currently stated in the security draft vs. the requirements of a major part of the user community for iSCSI. paul From owner-ips@ece.cmu.edu Wed Oct 24 13:39: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 NAA08099 for ; Wed, 24 Oct 2001 13:39:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OGimJ21493 for ips-outgoing; Wed, 24 Oct 2001 12:44:48 -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 f9OGijl21484 for ; Wed, 24 Oct 2001 12:44:46 -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 SAA116140 for ; Wed, 24 Oct 2001 18:44:34 +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 f9OGiSx234552 for ; Wed, 24 Oct 2001 18:44:33 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - Change Proposal X bit X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 24 Oct 2001 19:44:22 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/10/2001 19:44:33, Serialize complete at 24/10/2001 19:44:33 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, There is nothing in a command that arrives late on a link (as in the example in which it was sent redundantly) to distinguish it from a new (valid) command. This wraparound problem exists in all protocols - even in TCP, and we use the CmdSN per session in the same fashion TCP uses sequence numbers per connection - and it is solved in different ways (TCP uses time-stamps). The NOP is meant to solve that wrap-around problem. I am sure that when rereading the example you will see the issue. Julo Santosh Rao Sent by: santoshr@cup.hp.com 24-10-01 18:29 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - Change Proposal X bit Julian, Some comments on the below quoted scenarios : > session has 3 connections > on connection 1 I->T c1,c2,c3,C6 > on connection 2 I->T c4,c5,c7,c8 > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 and 6 > on connection 3 > target receives all and starts executing and acks 8 on connection 3 but > connection 2 stalls after c3 for a LONG TIME > then (after 2 full sequence wraps) connection 2 is gets alive and > delivers c4,c5 etc (that are now valid) When the target acks CmdSN 8 on connection 3, it has, in effect, sent CmdSN ack's for CMdSNs 3,4,5,6,7,8. This implies that the commands with CmdSN 3, 4, 5, 7, & 8 were received by the target on connection 2 and their processing was commenced. Hence, the following does not make sense : > connection 2 stalls after c3 for a LONG TIME > then (after 2 full sequence wraps) connection 2 is gets alive and > delivers c4,c5 etc (that are now valid) c4, c5, etc were already delivered to the target and are not being re-delivered. There is no problem in this case. (??). Take the next scenario : > 2 connections: > > connection1 I->T c3,c4,c5 > status of 3 contains ack up to 6 and it and all other statuses are > lost > connection2 resend c3, c4 & c5 (no logout) and those are executed! Since the initiator got CmdSN ack's upto 6, the initiator should not be re-issuing these I/Os ?? I still don't see justification to require that initiators send a immediate NOP-OUT in the manner being advocated. On a more fundamental note, I see some issues with the initiator being allowed to re-issue the commands on a different connection without having first logged out the previous connection successfully. I see nothing in the draft that suggests such behaviour, while at the same time, it is not forbidden. By resorting to command retries on a different connection in an attempt to plug the hole, without first logging out the previous connection, the initiator is susceptible to encountering I/O failure of that I/O due to ULP timeout. Here's the scenario why such recovery should not be allowed : - Initiator sends CmdSN 3 on connection 1. - No CmdSN updates for a while and initiator re-sends CmdSn 3 on connection 2. - At the same time, target has sent CmdSN ack's for CmdSN 3 on connection 1. - Initiator has transferred the command allegiance on its side from connection 1 to connection 2 and is attempting the command on connection 2. However, the command does not go through, since the (ExpCmdSN, MaxCmdSN) window has advanced and the trget discards the command. - Target sends in data and/or R2T and/or status for CmdSN 3 on connection 1. Since the initiator is not expecting any traffic for that I/O on connection 1, it discards any PDUs received on that connection 1 for which no I/O state existed. In the above scenario, initiator will never get a CmdSN ack on connection 2 and will never be able to plug the hole despite repeated retries, finally, causing a ULP timeout, followed by session recovery. Given the above scenario, I suggest that the initiator must only re-issue commands on the same connection, and can re-issue them on another connection only following a successful logout. Comments ? Thanks, Santosh Julian Satran wrote: > > Santosh, > > The scenarios I am talking about are all derivatives of an initiator trying > to plug-in holes and switching connections. > As the initiator does know the "extent" of a hole it can send-out commands > that he did not have to. > I have sent the attached not to Mallikarjun a while ago. I think that > there might be many of this kind. I am also aware that X bit by itself > might have some bad scenarios but the new proposal fixes them all. > > Julo > > _____________________________ > > Mallikarjun, > > Take the following sequence scenario: > > session has 3 connections > on connection 1 I->T c1,c2,c3,C6 > on connection 2 I->T c4,c5,c7,c8 > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 and 6 > on connection 3 > target receives all and starts executing and acks 8 on connection 3 but > connection 2 stalls after c3 for a LONG TIME > then (after 2 full sequence wraps) connection 2 is gets alive and > delivers c4,c5 etc (that are now valid) > > That is not a very likely scenario, I admit, but it is possible. > With X bit I could not find any such scenario since an X either follows a > good one on the same connection or can be safely discarded. > I suspect that there are some more scenarios that involve immediate > commands or commands that carry their own ack in the status and are acked > like: > > 2 connections: > > connection1 I->T c3,c4,c5 > status of 3 contains ack up to 6 and it and all other statuses are > lost > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > I think we can avoid those be requiring a NOP exchange before reissuing a > command on a new connection or reissue the command with a task management > (that has an implied ordering) but why do it if X is an obvious and safe > solution. > > Julo > > Regards, > Julo > > > "Mallikarjun > C." To: Julian Satran/Haifa/IBM@IBMIL > om> Subject: Re: iscsi : X bit in SCSI Command PDU. > > 08-10-01 21:45 > Please respond > to cbm > > > > Julian, > > We currently have the following specified in section 2.2.2.1 - > > "The target MUST NOT transmit a MaxCmdSN that is more than > 2**31 - 1 above the last ExpCmdSN." > > It appears to me that the above is sufficient to ward off the > accidents of the sort you describe. Do you think otherwise? > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Julian Satran wrote: > > > > Mallikarjun, > > > > There is at least one theoretical scenario in which an "old" command > > may appear in a "new window" and be reinstantiated. > > At 10Gbs and several connection that does not take months. With X the > > probability is far lower (not 0). I have no other strong arguments > > but I am still thinking. Matt Wakeley that insisted on it (against > > me) had some other argument that I am trying to find (I am note > > remembering). > > > > Julo > > > > "Mallikarjun C." > > To: Julian > > Satran/Haifa/IBM@IBMIL > > 08-10-01 20:39 cc: > > Please respond to cbm Subject: Re: iscsi : X > > bit in SCSI Command PDU. > > > > > > > > Julian, > > > > Now that you put me on the spot, :-), my response - > > > > Santosh argued with me privately that X-bit no longer serves a > > useful purpose after the advent of task management commands to > > reassign. My response was that it never was a requirement per se, > > but always a "courtesy" extended by the initiator to help the > > target. I also suggested that X-bit may be considered for its > > usefulness in debugging. > > > > He still had some (very reasonable) comments for simplification > > - the most appealing of which (to me) was the opportunity to do > > away with the X-bit checking for *every* command PDU that the target > > has to endure now. > > > > If I missed a legitimate use of X-bit, please comment. Do you > > think it is a protocol requirement per se? I couldn't justify > > to myself so far (except the Login). > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > > > > > Julian Satran wrote: > > > > > > Santosh, > > > > > > I am not sure you went through all scenarios. A conversation with > > your > > > colleague - Mallikarjun - and getting through the state table may go > > a > > > long way to clarify the need for X. > > > > > > And I am sure that by now you found yourself several . > > > > > > Julo > > > > > > Santosh Rao > > > To: IPS Reflector > > > Sent by: owner-ips@ece.cmu.edu > > > cc: > > > 06-10-01 01:56 Subject: iscsi : X > > > Please respond to Santosh Rao bit in SCSI Command PDU. > > > > > > > > > > > > All, > > > > > > With the elimination of command relay from iscsi [in the interests > > of > > > simplification ?], I believe that the X bit in the SCSI Command PDU > > > can > > > also be removed. As it exists today, the X bit is only being used > > for > > > command restart, which is at attempt by the initiator to plug a > > > potential hole in the CmdSN sequence at the target. It does this on > > > failing to get an ExpCmdSN ack for a previously sent command within > > > some > > > timeout period. > > > > > > Given the above usage of command restart, no X bit is required to be > > > set > > > in the SCSI Command PDU when command re-start is done. > > > > > > Either : > > > (a) the target had dropped the command earlier due to a digest > > error, > > > in > > > which case, the command restart plugs the CmdSN hole in the target. > > > > > > [OR] > > > > > > (b) the target had received the command and was working on it, when > > > the > > > initiator timed out too soon and attempted a command restart to plug > > > [what it thought was] a possible hole in the CmdSN sequence. > > > > > > In case (a), no X bit was required, since the target knows nothing > > of > > > the original command. In case (b), no X bit is required again, since > > > the > > > (ExpCmdSN, MaxCmdSN) window would have advanced and the target can > > > silently discard the received retry and continue working on the > > > original > > > command received. > > > > > > Removal of the X bit in the SCSI Command PDU has the following > > > benefits > > > : > > > > > > a) The CmdSN rules at the target are simplified. No need to look at > > X > > > bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) window. > > > > > > b) The reject reason code "command already in progress" can be > > > removed. > > > There's no need for this reject reason code anymore, since X bit > > > itself > > > is not required, and the targets can silently discard commands > > outside > > > the command window and continue to work on the original instance of > > > the > > > command already being processed at the target. > > > > > > c) Less work for the target and less resources consumed since it no > > > longer needs to generate a Reject PDU of type "command in progress". > > > It > > > can just silently discard any command PDU outside the (ExpCmdSN, > > > MaxCmdSN) window. > > > > > > d) Less code for the target, since it does not need : > > > - any Reject code paths when it receives X bit command PDUs that are > > > already in progress. > > > - No special casing of CmdSN checking rules. > > > - No overheads of verifying a received command based on its > > initiator > > > task tag, to check if the task is currently active, prior to sending > > a > > > Reject response with "command in progress". > > > > > > 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 > > > ################################## > > > Santosh Rao > > hp.com> cc: > Sent by: Subject: Re: iSCSI - Change Proposal X bit > owner-ips@ece. > cmu.edu > > > 23-10-01 22:50 > Please respond > to Santosh Rao > > > > Julian Satran wrote: > > > > However in order to drop "old" commands that might in the pipe on a > > sluggish connection - removing the X bit will require the initiator to > > issue an immediate NOP requiring a NOP response on every open connection > > whenever CmdSN wraps around (becomes equal to InitCmdSN). > > Julian, > > Can you please explain further the corner case you are describing above > ? Are you suggesting that special action should be taken every time > CmdSN wraps around, in case there were holes in the CmdSN sequence at > the wrap time ? Why is that ? > > Here's my understanding of how this plays out : > > Rule 1) > The CmdSN management rules at the target should be handling CmdSN wrap > case and the initiator cannot issue more than 2^32 -1 commands beyond > the last ExpCmdSN update it has received from the target, since the > target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above > the last ExpCmdSN. (per Section 2.2.2.1) > > Rule 2) > Any holes that occur in the CmdSN sequence are attempted to be plugged > by the initiator by re-issuing the original command. If the CmdSN never > got acknowledged and the I/O's ULP timeout expired, the initiator MUST > perform session recovery. (per Section 8.6) > > Thus, going by the above 2 rules, if the CmdSN sequence wraps upto > ExpCmdSN, the initiator will not be able to issue further commands, > since the target will keep the CmdSN window closed. The window can only > re-open when the CmdSN holes are plugged allowing ExpCmdSN and thereby, > MaxCmdSN to advance. (rule 1 above). > > Under the above circumstances, the initiator will possibly try to plug > the CmdSN hole by re-issuing the original command. It may do this 1 or > more times before its ULP timeout expires. Either the holes get plugged > and the windoe re-opens, or ULP timeout occurs without the corresponding > CmdSN for that I/O having been acknowledged, resulting in session > logout. (rule 2 above). > > What is required over and beyond the above ? Why does removal of X-bit > require an immediate NOP to be issued every time CmdSN wraps and a hole > exists in the CmdSN sequence (??). > > Regards, > 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 Wed Oct 24 13:48: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 NAA08582 for ; Wed, 24 Oct 2001 13:48:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OHG7A23925 for ips-outgoing; Wed, 24 Oct 2001 13:16:07 -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 f9OHG5l23919 for ; Wed, 24 Oct 2001 13:16:05 -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 TAA80586 for ; Wed, 24 Oct 2001 19:15: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 f9OHFiC118158 for ; Wed, 24 Oct 2001 19:15:44 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Text Request ITT/TTT X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 24 Oct 2001 20:15:38 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/10/2001 20:15:44, Serialize complete at 24/10/2001 20:15:44 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, The format and usage of ITT and TTT are the same for all commands (and implementations can make use of this commonality). For text commands we just did not want to make an exception. On the long run we may find that today restriction of one text command per connection (that we introduced in order to avoid overlapping parameter negotiation contexts) could be removed (e.g. use a lock for negotiations and use other keys for actions). Regards, Julo "Eddy Quicksall" Sent by: owner-ips@ece.cmu.edu 23-10-01 17:59 Please respond to "Eddy Quicksall" To: cc: Subject: iSCSI: Text Request ITT/TTT Section 3.10.2 Initiator Task Tag says: If the command is sent as part of a sequence of text requests and responses, the Initiator Task Tag MUST be the same for all the requests within the sequence (similar to linked SCSI commands). Why is this restriction imposed? Since the Text Requests can't be overlapped, then there is no need for this. If this restriction must exist, then why doesn't it exist for the TTT as well? The target does not need to interpret the ITT and the initiator does not need to interpret the TTT (or does it?). By removing the restriction, the initiator could use the ITT as an indication of where to pick up with the next Text Response for long text exchanges. Also, the target could use the TTT the same way. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Wed Oct 24 13:48: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 NAA08624 for ; Wed, 24 Oct 2001 13:48:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OHOcV24623 for ips-outgoing; Wed, 24 Oct 2001 13:24: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 f9OHOZl24609 for ; Wed, 24 Oct 2001 13:24: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 TAA140572 for ; Wed, 24 Oct 2001 19:24: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.97.1) with ESMTP id f9OHOSC73650 for ; Wed, 24 Oct 2001 19:24:28 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Question on T bit in login request PDU X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 24 Oct 2001 20:24:23 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/10/2001 20:24:27, Serialize complete at 24/10/2001 20:24:27 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk It says that if the initiator wants to finish it has to set T=1 but if the target sets a key for which the initiator will have to answer with a sequence the initiator may set T back to 0 even if before it was 1 (on the condition that the target answered with T=0). If the target does set T=1 as a response to a request with T=1 but sends keys to which the initiator has to answer that is a protocol error. Julo "Subrahmanya Sastry K.V" Sent by: owner-ips@ece.cmu.edu 23-10-01 13:44 Please respond to "Subrahmanya Sastry K.V" To: ips@ece.cmu.edu cc: Subject: iSCSI: Question on T bit in login request PDU Hello, Chapter 5 in the iscsi-draft-08 says that the T bit settings in one pair of login request-responses have no bearing on the T bit settings of the next pair and quotes : "An initiator having T bit set to 1 in one pair and being answered with an T bit setting of 0 may issue the next request with T bit set to 0. " But in section 5.3, the lines : "If the target responds to a Login request with the T bit set to 1, with a Login response with the T bit set to 0, the initiator must keep sending the Login request (even empty) with the T bit set to 1 until it gets the Login Response with the T bit set to 1." suggest a diffferent meaning. If I assume both are possible, what is the criterion for the initiator to set the T bit? Clarification please ? -Sastry From owner-ips@ece.cmu.edu Wed Oct 24 14:14: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 OAA09995 for ; Wed, 24 Oct 2001 14:14:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OHYqw25393 for ips-outgoing; Wed, 24 Oct 2001 13:34: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 f9OHYol25386 for ; Wed, 24 Oct 2001 13:34: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 TAA07006 for ; Wed, 24 Oct 2001 19:34:43 +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 f9OHYhx254054 for ; Wed, 24 Oct 2001 19:34:43 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: iSCSI minimum PDU length X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 24 Oct 2001 20:34:38 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 24/10/2001 20:34:42, Serialize complete at 24/10/2001 20:34:42 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk With no votes against we have settled (again) on single PDU length (per connection, per direction) for all types of PDUs. But I think we erred on the low side by suggesting 64 as a minimum. It is low (it was mentioned) and bad for text request/response. How about settling for 1024? Julo From owner-ips@ece.cmu.edu Wed Oct 24 14: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 OAA10081 for ; Wed, 24 Oct 2001 14:15:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OHPKL24696 for ips-outgoing; Wed, 24 Oct 2001 13:25:20 -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 f9OHPIl24691 for ; Wed, 24 Oct 2001 13:25:18 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f9OHP2M01068; Wed, 24 Oct 2001 13:25:02 -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 f9OHP2f22852; Wed, 24 Oct 2001 13:25:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15318.63856.536000.172588@gargle.gargle.HOWL> Date: Wed, 24 Oct 2001 13:25:04 -0400 From: Paul Koning To: bill@sanera.net Cc: ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP References: <15318.57882.245000.822329@gargle.gargle.HOWL> 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 24 October 2001) by Bill Strahm: > What do you mean... I have a MUST implement 3DES, SHA1, MD5, and DES (from > the IPsec requirements) all though IPS wants to put a SHOULD NOT implement > DES requirement in... I thought that the IPS security draft made confidentiality optional, but apparently either I'm confused or I was thinking about an older version of that spec. > ... Just because > a link isn't encrypted doesn't mean it isn't secure (I can have a link in a > guarded and locked room surrounded by M-16 wielding Marines -- I defy you to > snoop it) Agreed, which is one of the problems with an IPSec (or other crypto) mandate. > I disagree with your call saying that there is not rough concensus to use > IPsec with iSCSI. I believe David Black (correct me if I am wrong here > David) has said the group has rough concensus to use IPsec as the security > solution. Now it might be that the rough concensus is there because it is a > forced solution from the IESG, ... That's a peculiar use of the term "consensus", if your speculation is accurate. My comment was based on observation of this list: I've seen a bunch of debate on the topic, and my reading of it is that there was (a) substantial opposition, (b) no clear technical justification for why "MUST" was needed. My reading of the IETF standards process is that technical considerations are supposed to govern standardization decisions, which is why I raised the point. paul From owner-ips@ece.cmu.edu Wed Oct 24 14: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 OAA10410 for ; Wed, 24 Oct 2001 14:24:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OHcrf25710 for ips-outgoing; Wed, 24 Oct 2001 13:38:53 -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 f9OHcql25705 for ; Wed, 24 Oct 2001 13:38:52 -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 f9OHcjO26249 for ; Wed, 24 Oct 2001 13:38:45 -0400 (EDT) Content-Class: urn:content-classes:message Subject: FCIP: Minutes of 10/17 FCIP Authors teleconference MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 24 Oct 2001 13:38:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D45382364983617B24C@nc8220exchange.ral.lucent.com> Thread-Topic: Minutes of 10/17 FCIP Authors teleconference Thread-Index: AcFXZMou3eR4y3POTIeDevOcClckmgFTL/Lg 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 f9OHcql25706 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Minutes from last week's FCIP author's call. Elizabeth -----Original Message----- Minutes of FCIP Authors teleconference 10/17/01 1. Security Bob raised the issue that compliance requirements are made in both the FCIP draft as well as the security framework draft, although the security draft is intended to be an informational RFC. Not clear what happens if the two start to get out of sync. In addition, requirements on the same function in different drafts is not desirable. Is it even legal to put compliance requirements (MUST, etc) in a non-standards-track RFC? Issue also applies to iSCSI and iFCP. Bob to send note on issue to IPS reflector. 2. NAPT Solution documented by Ralph was discussed. Two issues were brought up: how to address the ships-in-the-night behavior when two TCP connect requests between 2 FCIP Entities cross each other, and how to make one end of the FCIP Link aware of who is at the other hand in terms of its WWN+FCIP-identifier identity. Larry suggested a bi-directional Short Frame exchange instead of the current proposed unidirectional one, allowing each end to learn about the other, to solve the latter. Anil believes this may help to address the ships-in-the-night problem. Bob feels that this is better solved at a lower layer, and that bidirectional SF exchange could introduce problems. Larry as well as Bob to send out mail detailing the incremental changes and potential issues, respectively. Another area of discussion was the need for more than one FCIP Link between two FCIP Entities. Some discussion around why this should be allowed for FCIP, just as it is allowed for FC. Milan and Bob feel that there is a need to accomodate this behavior (while also allowing a single link with multiple TCP connections). Ralph to add front matter to clarify context of solution in the presence of NAPT gateways in the next draft. Further discussion of solution and choices by email, final solution to be agreed by next week. Attendees: Ralph Weber Jim Nelson Vi Chau Milan Merhar Anil Rijhsinghani Raj Bhagwat Dave Peterson Elizabeth Rodriguez Bob Snively Bill Creek Don Fraser Venkat Rangan Larry Lamers Andy Helland From owner-ips@ece.cmu.edu Wed Oct 24 14: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 OAA11135 for ; Wed, 24 Oct 2001 14:43:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OHujb27066 for ips-outgoing; Wed, 24 Oct 2001 13:56:45 -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 f9OHugl27059 for ; Wed, 24 Oct 2001 13:56:42 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel13.hp.com (Postfix) with ESMTP id 544231F827; Wed, 24 Oct 2001 10:56: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 KAA01686; Wed, 24 Oct 2001 10:56:31 -0700 (PDT) Message-ID: <3BD702B0.4D27DA65@cup.hp.com> Date: Wed, 24 Oct 2001 11:04:32 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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 minimum PDU length 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, Does the below imply that the length retriction of 4K on text & nop operations is also removed and we now need to handle multi-sequence nop operations ? I suggest that maximum nop operation length be restricted to the minimum PDU length that the draft will require. This will avoid adding multi-pdu sequence complexity for the nop-out/nop-in pdu's. The current login & text pdu's do allow for multi-sequence operations based on the T/F bit. This should be sufficient if the login/text payload exceeds 1K , as long as "key=value" operations are not going to span pdu's. Is that correct ? - Santosh Julian Satran wrote: > > With no votes against we have settled (again) on single PDU length (per > connection, per direction) for all types of PDUs. > But I think we erred on the low side by suggesting 64 as a minimum. It is > low (it was mentioned) and bad for text request/response. > > How about settling for 1024? > > 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 Wed Oct 24 15:38: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 PAA12650 for ; Wed, 24 Oct 2001 15:38:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OIcfr00703 for ips-outgoing; Wed, 24 Oct 2001 14:38:41 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f165.pav2.hotmail.com [64.4.37.165]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9OIccl00696 for ; Wed, 24 Oct 2001 14:38:38 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 24 Oct 2001 11:38:32 -0700 Received: from 129.219.25.77 by pv2fd.pav2.hotmail.msn.com with HTTP; Wed, 24 Oct 2001 18:38:32 GMT X-Originating-IP: [129.219.25.77] From: "shesha bhushan" To: ips@ece.cmu.edu Subject: Question Date: Wed, 24 Oct 2001 18:38:32 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Oct 2001 18:38:32.0274 (UTC) FILETIME=[14EC1320:01C15CBB] Sender: owner-ips@ece.cmu.edu Precedence: bulk Hi, I am doing a research project at Arizona State University on SCSI and iSCSI. I was going through both the protocols. I have a crazy question. iSCSI = SCSI/(TCP/IP). But SCSI is a reliable protocol so is TCP. so can't we just try to send SCSI packets on IP or SCSI/UDP. Any & All comments are welcome. Thanks Shesha Bhushan S Research Assistant Arizona State University _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-ips@ece.cmu.edu Wed Oct 24 16:11: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 QAA13426 for ; Wed, 24 Oct 2001 16:11:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OJYNI05382 for ips-outgoing; Wed, 24 Oct 2001 15:34:23 -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 f9OJYKl05372 for ; Wed, 24 Oct 2001 15:34:20 -0400 (EDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 7F0A0FFC; Wed, 24 Oct 2001 14:34:14 -0500 (CDT) Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.110.250.119]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 7729D24B8; Wed, 24 Oct 2001 14:34:14 -0500 (CDT) Received: from cceexc18.americas.cpqcorp.net ([16.110.250.64]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Oct 2001 14:34:14 -0500 content-class: urn:content-classes:message Subject: RE: iSCSI minimum PDU length MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Wed, 24 Oct 2001 14:26:52 -0500 Message-ID: <31891B757C09184BBFEC5275F85D559501F22AA5@cceexc18.americas.cpqcorp.net> Thread-Topic: iSCSI minimum PDU length Thread-Index: AcFcsp+C6Tnq5tjRTKqql8DDs1S9rQADdH9w From: "Martin, Nick" To: "Julian Satran" Cc: X-OriginalArrivalTime: 24 Oct 2001 19:34:14.0266 (UTC) FILETIME=[DCE795A0:01C15CC2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f9OJYKl05375 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Julian, This is for the data after the PDU header right? This will be the guaranteed lowest value anyone will be forced to deal with. Implementations may negotiate for any value greater than or equal to this value. This is acceptable and it is a good choice because it is the largest power of 2 that will fit within minimum Ethernet MTU of ~1500 and leaves plenty of room for iSCSI and LLP headers. Thanks, Nick -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, October 24, 2001 12:35 PM To: ips@ece.cmu.edu Subject: iSCSI minimum PDU length With no votes against we have settled (again) on single PDU length (per connection, per direction) for all types of PDUs. But I think we erred on the low side by suggesting 64 as a minimum. It is low (it was mentioned) and bad for text request/response. How about settling for 1024? Julo From owner-ips@ece.cmu.edu Wed Oct 24 16:14: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 QAA13487 for ; Wed, 24 Oct 2001 16:14:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OJNZv04485 for ips-outgoing; Wed, 24 Oct 2001 15:23:35 -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 f9OJNXl04476 for ; Wed, 24 Oct 2001 15:23:33 -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 PAA36314 for ; Wed, 24 Oct 2001 15:21:01 -0400 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9OJMFP221134 for ; Wed, 24 Oct 2001 13:22:15 -0600 Subject: iSCSI: Start of digest activity To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Prasenjit Sarkar" Date: Wed, 24 Oct 2001 12:22:10 -0700 X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/24/2001 12:22:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Now that digest negotiation has been moved to the operational phase, does this mean digest activity starts after the login is accepted? Clarification requested, Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose From owner-ips@ece.cmu.edu Wed Oct 24 16: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 QAA13502 for ; Wed, 24 Oct 2001 16:14:11 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OJZRa05463 for ips-outgoing; Wed, 24 Oct 2001 15:35:27 -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 f9OJZQl05459 for ; Wed, 24 Oct 2001 15:35:26 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Wed Oct 24 15:35:32 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 f9OJYul12545 for ; Wed, 24 Oct 2001 15:34:56 -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 PAA25845 for ; Wed, 24 Oct 2001 15:34:56 -0400 (EDT) Message-ID: <3BD717E0.A7529E1E@research.bell-labs.com> Date: Wed, 24 Oct 2001 15:34:56 -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) Question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit (iSCSI added to subject header..) SCSI is a layered protocol. In iSCSI, TCP is being used as the "SCSI transport" within the SCSI protocol hierarchy. The slides below contain a good overview.. (see pages 6 and 11) http://WWW.ECE.CMU.EDU/~ips/documents/haagens.08.02.2000.pdf You may also want to lookup the SAM-2 documents on http://www.t10.org/drafts.htm to get a feel for the SCSI architecture in general. -Sandeep > Hi, > I am doing a research project at Arizona State University on SCSI and > iSCSI. I was going through both the protocols. I have a crazy question. > iSCSI = SCSI/(TCP/IP). But SCSI is a reliable protocol so is TCP. so can't > we just try to send SCSI packets on IP or SCSI/UDP. Any & All comments are > welcome. > > Thanks > Shesha Bhushan S > Research Assistant > Arizona State University From owner-ips@ece.cmu.edu Wed Oct 24 17: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 RAA14734 for ; Wed, 24 Oct 2001 17:25:18 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OKj6G11338 for ips-outgoing; Wed, 24 Oct 2001 16:45:06 -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 f9OKj4l11334 for ; Wed, 24 Oct 2001 16:45: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 F2A421F544; Wed, 24 Oct 2001 13:44: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 NAA23704; Wed, 24 Oct 2001 13:44:54 -0700 (PDT) Message-ID: <3BD72A26.DEB7E024@cup.hp.com> Date: Wed, 24 Oct 2001 13:52:54 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: "Martin, Nick" Cc: Julian Satran , ips@ece.cmu.edu Subject: Re: iSCSI minimum PDU length References: <31891B757C09184BBFEC5275F85D559501F22AA5@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 Does the MaxRecvPDULength include the AHS length ? - Santosh "Martin, Nick" wrote: > > Julian, > > This is for the data after the PDU header right? > This will be the guaranteed lowest value anyone will be forced to deal > with. > Implementations may negotiate for any value greater than or equal to > this value. > > This is acceptable and it is a good choice because it is the largest > power of 2 that will fit within minimum Ethernet MTU of ~1500 and leaves > plenty of room for iSCSI and LLP headers. > > Thanks, > Nick > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, October 24, 2001 12:35 PM > To: ips@ece.cmu.edu > Subject: iSCSI minimum PDU length > > With no votes against we have settled (again) on single PDU length (per > connection, per direction) for all types of PDUs. > But I think we erred on the low side by suggesting 64 as a minimum. It > is > low (it was mentioned) and bad for text request/response. > > How about settling for 1024? > > 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 Wed Oct 24 17:26: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 RAA14748 for ; Wed, 24 Oct 2001 17:26:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OKjgA11388 for ips-outgoing; Wed, 24 Oct 2001 16:45:42 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9OKjfl11380 for ; Wed, 24 Oct 2001 16:45:41 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id 5C716C28 for ; Wed, 24 Oct 2001 14:45:40 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 3417F504 for ; Wed, 24 Oct 2001 14:45:40 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Wed, 24 Oct 2001 14:45:39 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 14:45:39 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF65C@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'ips@ece.cmu.edu'" Cc: "CAVANNA,VICENTE V (A-Roseville,ex1)" , "SHEEHY,DAVE (A-Americas,unix1)" , "ALBERTSON,LYLE (A-PaloAlto,ex1)" Subject: trust security claims of incoming packets? Date: Wed, 24 Oct 2001 14:45:38 -0600 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 Most vendors of IPSec components that I have talked to do not verify, against their local policy database, if an inbound packet has claimed and been afforded the security processing that the local policy specifies. Doing this verification may, of course, introduce a performance bottleneck in the processing of unsecured packets which would be undesireable, as most users would expect performance not to degrade unless secured packets are being processed. If a packet arrives demanding security processing (e.g. has an ESP header) then, after processing, the local policy is inspected to confirm that the appropriate processing was applied but if the packet arrives unsecured all security processing is bypassed, trusting instead that the packet was indeed meant to be insecure. This method of handling unsecured packets goes against my interpretation of the IPSec specs and seems to be a security hole. What point am I missing that will mitigate my concern? Thanks. Vicente Cavanna Agilent Technologies From owner-ips@ece.cmu.edu Wed Oct 24 17:27: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 RAA14760 for ; Wed, 24 Oct 2001 17:27:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OKUxR10100 for ips-outgoing; Wed, 24 Oct 2001 16:30:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sj1-3-1-21.iserver.com (sj1-3-1-21.iserver.com [128.121.122.118]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9OKUvl10094 for ; Wed, 24 Oct 2001 16:30:57 -0400 (EDT) Received: (qmail 81364 invoked by uid 24410); 24 Oct 2001 20:30:49 -0000 Message-ID: <20011024203049.81363.qmail@bswd.com> Subject: Re: (iSCSI) Question To: sandeepj@research.bell-labs.com (Sandeep Joshi) Date: Wed, 24 Oct 2001 14:30:49 -0600 (MDT) Cc: ips@ece.cmu.edu Reply-To: bberg@bswd.com (Brian A. Berg) In-Reply-To: <3BD717E0.A7529E1E@research.bell-labs.com> from "Sandeep Joshi" at Oct 24, 2001 03:34:56 PM From: bberg@bswd.com (Brian A. Berg) Organization: Berg Software Design ( http://www.bswd.com/ ) X-Mailer: ELM [version 2.5 PL6] 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 You can also check out the presentations made during an IP Storage Tutorial at last week's FCTC conference in San Jose. Of particular note are ones I have posted at http://www.bswd.com/cornucop.htm#fctciscsi Look at Ahmad Zamer's presentation starting at Slide 16, as well as John Hufferd's excellent tutorial. ___________________________________________________________________ Brian A. Berg bberg@bswd.com Voice: 408.741.5010 Berg Software Design FAX: 408.741.5234 P.O. Box 3488 visit the Storage Cornucopia at www.bswd.com 14500 Big Basin Way, Suite F Consulting: SCSI/FC/SAN/storage Saratoga, CA 95070 USA Cell: 408.406.3699 > (iSCSI added to subject header..) > > SCSI is a layered protocol. In iSCSI, TCP is being used as > the "SCSI transport" within the SCSI protocol hierarchy. > > The slides below contain a good overview.. > (see pages 6 and 11) > http://WWW.ECE.CMU.EDU/~ips/documents/haagens.08.02.2000.pdf > > You may also want to lookup the SAM-2 documents on > http://www.t10.org/drafts.htm to get a feel for the SCSI > architecture in general. > > -Sandeep > > > > Hi, > > I am doing a research project at Arizona State University on SCSI and > > iSCSI. I was going through both the protocols. I have a crazy question. > > iSCSI = SCSI/(TCP/IP). But SCSI is a reliable protocol so is TCP. so can't > > we just try to send SCSI packets on IP or SCSI/UDP. Any & All comments are > > welcome. > > > > Thanks > > Shesha Bhushan S > > Research Assistant > > Arizona State University From owner-ips@ece.cmu.edu Wed Oct 24 18:24: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 SAA15489 for ; Wed, 24 Oct 2001 18:24:49 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OLp2n16824 for ips-outgoing; Wed, 24 Oct 2001 17:51:02 -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 f9OLowl16812 for ; Wed, 24 Oct 2001 17:50:59 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9OLopu09361; Wed, 24 Oct 2001 14:50:51 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9OLokB28229; Wed, 24 Oct 2001 14:50:46 -0700 From: "Bill Strahm" To: "CAVANNA,VICENTE V \(A-Roseville,ex1\)" , Cc: "SHEEHY,DAVE \(A-Americas,unix1\)" , "ALBERTSON,LYLE \(A-PaloAlto,ex1\)" Subject: RE: trust security claims of incoming packets? Date: Wed, 24 Oct 2001 14:50:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <01A7DAF31F93D511AEE300D0B706ED920CF65C@axcs13.cos.agilent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit I can't vouch for other implelmentors, but the implementation I worked on checked... It is required in the specification. This basically turned into a single look into a hash table... not a huge overhead... some, but not much, and we were able to get darned close to theoretical wire speed at 100Mbps full duplex... I know that some vendors did not check after ESP processing if the packet should have been covered by the negotiated SA... We didn't initially, we did in a second version that never made it to market (to my knowledge) I'd like to know what vendors you talk to that don't follow the standard, I can actually see many VPN vendors not doing this, because they will turn around and drop all clear packets anyway... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of CAVANNA,VICENTE V (A-Roseville,ex1) Sent: Wednesday, October 24, 2001 1:46 PM To: 'ips@ece.cmu.edu' Cc: CAVANNA,VICENTE V (A-Roseville,ex1); SHEEHY,DAVE (A-Americas,unix1); ALBERTSON,LYLE (A-PaloAlto,ex1) Subject: trust security claims of incoming packets? Most vendors of IPSec components that I have talked to do not verify, against their local policy database, if an inbound packet has claimed and been afforded the security processing that the local policy specifies. Doing this verification may, of course, introduce a performance bottleneck in the processing of unsecured packets which would be undesireable, as most users would expect performance not to degrade unless secured packets are being processed. If a packet arrives demanding security processing (e.g. has an ESP header) then, after processing, the local policy is inspected to confirm that the appropriate processing was applied but if the packet arrives unsecured all security processing is bypassed, trusting instead that the packet was indeed meant to be insecure. This method of handling unsecured packets goes against my interpretation of the IPSec specs and seems to be a security hole. What point am I missing that will mitigate my concern? Thanks. Vicente Cavanna Agilent Technologies From owner-ips@ece.cmu.edu Wed Oct 24 18: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 SAA15512 for ; Wed, 24 Oct 2001 18:25:09 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OLSGL14872 for ips-outgoing; Wed, 24 Oct 2001 17:28:16 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9OLSFl14868 for ; Wed, 24 Oct 2001 17:28:15 -0400 (EDT) Received: from somesh ([12.81.70.177]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20011024212807.QNQT4554.mtiwmhc22.worldnet.att.net@somesh>; Wed, 24 Oct 2001 21:28:07 +0000 Reply-To: From: "Somesh Gupta" To: "shesha bhushan" , Subject: RE: Question Date: Wed, 24 Oct 2001 14:25:56 -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: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The question is not crazy at all (the answer might be :-)). New protocols are required (and really should for everyone's benefit) implement some congestion avoidance mechanism. Currently the easiest way to achieve this is to use TCP. Unfortunately we do not depend enough on it, leading to significant complexity in the protocol. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > shesha bhushan > Sent: Wednesday, October 24, 2001 6:39 PM > To: ips@ece.cmu.edu > Subject: Question > > > Hi, > I am doing a research project at Arizona State University on SCSI and > iSCSI. I was going through both the protocols. I have a crazy question. > iSCSI = SCSI/(TCP/IP). But SCSI is a reliable protocol so is TCP. > so can't > we just try to send SCSI packets on IP or SCSI/UDP. Any & All > comments are > welcome. > > Thanks > Shesha Bhushan S > Research Assistant > Arizona State University > > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > From owner-ips@ece.cmu.edu Wed Oct 24 18:30: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 SAA15620 for ; Wed, 24 Oct 2001 18:30:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OLdVx15744 for ips-outgoing; Wed, 24 Oct 2001 17:39:31 -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 f9OLdQl15733 for ; Wed, 24 Oct 2001 17:39:26 -0400 (EDT) Received: (from mailgate@localhost) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) id RAA11166 for ips@ece.cmu.edu; Wed, 24 Oct 2001 17:39:20 -0400 (EDT) Received: from compuserve.com (dal-tgn-tkt-vty57.as.wcom.net [216.192.231.57]) by siaar2ab.compuserve.com (8.9.3/8.9.3/SUN-REL-1.3) with ESMTP id RAA11151 for ; Wed, 24 Oct 2001 17:39:10 -0400 (EDT) Message-ID: <3BD73607.75972C10@compuserve.com> Date: Wed, 24 Oct 2001 16:43:35 -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: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit The following is proposed as a solution to the NAPTs problem in FCIP. This proposal is based on draft-ietf-ips-fcovertcpip-06.txt and should contain sufficient detail for evaluation purposes. This is not a detailed proposal for changes and it is assumed that the FCIP editor will cleanup any loose ends. This proposal assumes familiarity with FCIP and makes no attempt to explain existing FCIP models, structures, or functionality. Those who were at the Irvine Interim meeting will remember that the problem with FCIP and NAPTS is a reliance on IP address in the determination of which incoming TCP connections belong in a given FCIP Link. This proposal solves that problem by requiring that FC Entity World Wide Name be transmitted in the first bytes sent by the FCIP Entity that initiates a TCP Connect request. This allows the FCIP Entity that receives a TCP Connect request to match it with any previously received TCP Connect requests from the same source. Since the transmitted World Wide Name is required to be unique within Fibre Channel, the FCIP Entity that receives this information can correctly assign FCIP Link relationships without relying on IP Addresses. To allow a given FC Entity to have multiple distinct FC/FCIP ports, the World Wide Name is qualified by a 32-bit FC/FCIP Entity identifier. Optional suggestions about how a TCP Connection should be used are also provided in the first bytes send by the FCIP Entity that initiates a TCP Connect request. It is believed that the proposed changes will work even with the manual discovery option provided for in the FCIP draft. However, the most reliable end-to-end knowledge of who is talking to whom is achieved if SLPv2 discovery is used and each SLP service advertisement includes the advertiser's World Wide Name and FC/FCIP Entity identifier. A summary of the proposed changes follows. [Change 1] Add a new section between 6 and 7. Note all other section number have been adjusted to reflect this addition. 7. FCIP Short Frame Figure x shows the FCIP Short Frame format. W|------------------------------Bit------------------------------| o| | r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 1| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 2| pFlags | Reserved | -pFlags | -Reserved | | (0x01) | (0x00) | (0xFE) | (0xFF) | +-----------+---+---------------+-----------+---+---------------+ 3| Flags | Frame Length | -Flags | -Frame Length | | (0x00) | (0x00-0E) | (0x3F) | (0x03-F1) | +-----------+-------------------+-----------+-------------------+ 4| Time Stamp [integer] | +---------------------------------------------------------------+ 5| Time Stamp [fraction] | +---------------------------------------------------------------+ 6| CRC (Reserved in FCIP) | | (0x00-00-00-00) | +-------------------------------+-------------------------------+ 7| Reserved | -Reserved | | (0x00-00) | (0xFF-FF) | +-------------------------------+-------------------------------+ 8| | +----- FC Fabric Entity World Wide Name -----+ 9| | +---------------------------------------------------------------+ 10| FC/FCIP Entity Identifier | +---------------+---------------+-------------------------------+ 11| Connection | Reserved | Connection Usage Code | | Usage Flags | (0x00) | | +---------------+---------------+-------------------------------+ 12| Reserved | | (0x00-00-00-00) | +---------------------------------------------------------------+ 13| Reserved | -Reserved | | (0x00-00) | (0xFF-FF) | +-------------------------------+-------------------------------+ Fig. x FCIP Short Frame Format pFlags: The pFlags bits provide information about the protocol specific usage of the FC Encapsulation Header as shown in figure y. |----------------Bit--------------------| | | | 31 30 29 28 27 26 25 24 | +----------------------------------+----+ | Reserved | SF | +----------------------------------+----+ Fig. y - pFlags Field Format In the Short Frame, the SF (Short Frame) bit SHALL be one. FCIP Encapsulated frames the SF bit SHALL be zero. The FC Fabric Entity World Wide Name field SHALL contain the Fibre Channel Name_Identifier [FC-FS] for the FC Fabric entity associated with the FC Entity FCIP Entity pair that generated the Short Frame. For example, if the FC Fabric entity is a FC Switch, the FC Fabric Entity World Wide Name field SHALL contain the Switch_Name [FC-SW-2] provided that name is world wide unique. The FC Fabric Entity World Wide Name SHALL be world wide unique. The FC/FCIP Entity Identifier field SHALL contain a unique identifier for the FC Entity FCIP Entity pair that generated the Short Frame that is assigned by the FC Fabric entity whose world wide name appears in the FC Fabric Entity World Wide Name field. The FC/FCIP Entity Identifier is statically assigned to represent the configuration relationship of the FC Entity FCIP Entity pair to the FC Fabric entity. Note: The combination of the FC Entity World Wide Name and FCIP Entity Identifier fields uniquely identifies every FC Entity FCIP Entity pair in the IP Network. An FCIP Entity that receives a TCP Connect request SHALL use the contents of the FC Fabric Entity World Wide Name and FC/FCIP Identifier fields to determine the FCIP_LEP to which the FCIP_DE associated with the TCP connection is assigned. This may be an existing FCIP_LEP or a new FCIP_LEP, depending on whether the FCIP Entity has received the same FC Fabric Entity World Wide Name and FC/FCIP Identifier field values before. If an FCIP Short Frame is received on a TCP connection that has already been assigned to an FCIP_LEP, the FC Fabric Entity World Wide Name and FC/FCIP Identifier fields SHALL be ignored. The Connection Usage Flags field identifies the types of SOF values [FC Encapsulation] to be carried on the connection as shown in figure z. |------------------------------Bit------------------------------| | | | 31 30 29 28 27 26 25 24 | +---------------------------------------------------------------+ | SOFf | SOF?2 | SOF?3 | Reserved | +---------------------------------------------------------------+ Fig. z - Connection Usage Flags Field Format If the SOFf bit is one, then frames containing SOFf are intended to be carried on the connection. If the SOF?2 bit is one, then frames containing SOFi2 and SOFn2 are intended to be carried on the connection. If the SOF?3 bit is one, then frames containing SOFi3 and SOFn3 are intended to be carried on the connection. All or none of the SOFf, SOF?2, and SOF?3 bits MAY be set to one. If all of the SOFf, SOF?2, and SOF?3 bits are zero, then the types of FC Frames intended to be carried on the connection has no specific relationship to SOF code. The FCIP Entity SHALL NOT enforce the SOF usage described by the Connection Usage Flags field and SHALL only use the contents of the field as described below. The Connection Usage Code field contains Fibre Channel defined information regarding the intended usage of the connection as specified in FC-BB-2. The FCIP Entity SHALL use the contents of the Connection Usage Flags and Connection Usage Code fields to locate appropriate QoS settings in the "shared" database of TCP connection information (see 8.1.1) and apply those settings to a newly formed connection. If an FCIP Short Frame is received after QOS settings have been established, the Connection Usage Flags and Connection Usage Code fields SHOULD be ignored. For each new incoming TCP Connect request received, the FCIP Entity SHALL send the contents of the FC Fabric Entity World Wide Name, FC/FCIP Identifier, Connection Usage Flags and Connection Usage Code fields to the FC Entity along with the other new connection information. [Change 2] In 5.6.1, add the pFlags field definition and require all FCIP Encapsulated Frames except Short Frames to have SF equal to zero. Note: Some part of the pFlags description above will go in 5.6.1 not in the new section but the description above is structured for easier reading in this proposal. [Change 3] Some place in 5.6 (the description of the FCIP_DE), require the FCIP_DE to pass all FCIP Short Frames to the Control & Services Module. [Change 4] In 7.1.3 and 7.1.4 (the two sections where TCP Connect requests are generated), require the FCIP Entity to: 1) Acquire the Connection Usage and other information from the "shared" database (see section 7.1.1); 2) Send a FCIP Short Frame as the first bytes passing through the Encapsulated Frame Transmitter Portal following establishment of a TCP connection; 3) Compare the first bytes received through the Encapsulated Frame Receiver Portal to the FCIP Short Frame sent and close the TCP connection if the bytes are not an FCIP Short Frame whose contents (words 7 through 13 inclusive) exactly match the FCIP Short Frame passed through the Encapsulated Frame Transmitter Portal. It is recommended that an FCIP Entity not initiate TCP Connect requests to another FCIP Entity if incoming TCP Connects requests from that FCIP Entity have already been accepted. [Change 5] In 7.1.5 (the section where TCP Connect requests are accepted) change the requirements about binding the new connection to an FCIP_LEP more or less as follows: 1) Require the FCIP Entity to expect a FCIP Short Frame as the first bytes to pass through the Encapsulated Frame Receiver Portal following completion of an incoming TCP Connect request; 2) Require the FCIP Entity to transmit the FCIP Short Frame contents received (words 7 through 13 inclusive) through the Encapsulated Frame Transmitter Portal immediately upon receipt with out alteration of any kind; 3) Require use of the FC Entity WWN and FCIP Entity Identifier fields in the FCIP Short Frames to determine if there is an existing FCIP_LEP to bind to; and 4) Recommend that the Connection Usage fields contents be used in conjunction with the "shared" database (see section 7.1.1) to determine the QOS settings for the newly created connection. If the local FCIP Entity determines that the TCP Connect request just received is for a remote FCIP Entity to which the local FCIP Entity has already initiated TCP Connect requests and the connection request is otherwise valid, the local FCIP Entity SHALL accept TCP Connect request. The FCIP Entity SHALL notify the FC Entity of the reverse direction TCP Connect request and the FC Entity SHALL determine whether both connections are permitted and, if one is not permitted, request that the FCIP Entity close the appropriate connection. [Change 6] In 5.4, replace the following sentence: "An FC Fabric to IP Network interface product SHALL contain one FCIP Entity for each IP Address assigned to the product." with: "An FC Fabric to IP Network interface product SHALL provide each FC Entity FCIP Entity pair contained in the product with a unique combination of FC Fabric Entity World Wide Identifier and FC/FCIP Entity Identifier values (see section 7)." From owner-ips@ece.cmu.edu Wed Oct 24 18:34: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 SAA15728 for ; Wed, 24 Oct 2001 18:34:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OMCU118449 for ips-outgoing; Wed, 24 Oct 2001 18:12:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from msgbas2.cos.agilent.com (msgbas2x.cos.agilent.com [192.25.240.37]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9OMCSl18444 for ; Wed, 24 Oct 2001 18:12:28 -0400 (EDT) Received: from msgrel1.cos.agilent.com (msgrel1.cos.agilent.com [130.29.152.77]) by msgbas2.cos.agilent.com (Postfix) with ESMTP id DD1CEE95 for ; Wed, 24 Oct 2001 16:12:27 -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 F3FAB502 for ; Wed, 24 Oct 2001 16:12:26 -0600 (MDT) Received: (from dbs@localhost) by acropora.rose.agilent.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.1.0) id PAA05259 for ips@ece.cmu.edu; Wed, 24 Oct 2001 15:11:23 -0700 (PDT) From: Dave Sheehy Message-Id: <200110242211.PAA05259@acropora.rose.agilent.com> Subject: re: iSCSI minimum PDU length To: ips@ece.cmu.edu (IETF IP SAN Reflector) Date: Wed, 24 Oct 2001 15:11:22 PDT X-Mailer: Elm [revision: 212.4] Sender: owner-ips@ece.cmu.edu Precedence: bulk > > With no votes against we have settled (again) on single PDU length (per > connection, per direction) for all types of PDUs. > But I think we erred on the low side by suggesting 64 as a minimum. It is > low (it was mentioned) and bad for text request/response. > > How about settling for 1024? Too big (since the MSS can be smaller than 1024). 512 is a better number. Dave Sheehy From owner-ips@ece.cmu.edu Wed Oct 24 19:04: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 TAA16442 for ; Wed, 24 Oct 2001 19:04:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9OMHxr18810 for ips-outgoing; Wed, 24 Oct 2001 18:17:59 -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 f9OMHwl18805 for ; Wed, 24 Oct 2001 18:17:58 -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 f9OMHuA13341 for ; Wed, 24 Oct 2001 18:17:56 -0400 (EDT) Content-Class: urn:content-classes:message Subject: IPS-All: FCIP: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 24 Oct 2001 18:17:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D45382364983617B254@nc8220exchange.ral.lucent.com> Thread-Topic: FCIP: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting) Thread-Index: AcFc2KfnGQVBQJNmS6+aoczg3g2rUQAACz3Q From: "Elizabeth Rodriguez" To: , "IPS Reflector" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f9OMHwl18806 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, The authors of the FCIP document have requested that the following NAT/NAPT solution be reviewed. This and the security requirements are the two remaining outstanding issues of the FCIP document. The NAT/NAPT problem is a difficult one for the FCIP draft, and the authors would like input on this proposal prior to incorporating the text into the final draft before Salt Lake City. The are especially interested in input from those interested in FCIP as well as those who have experience in NAPTs. Comments and feedback by November 9 would be appreciated. Thanks, Elizabeth -----Original Message----- From: Ralph Weber [mailto:ralphoweber@compuserve.com] Sent: Wednesday, October 24, 2001 4:44 PM To: IPS Reflector Subject: FCIP: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting) The following is proposed as a solution to the NAPTs problem in FCIP. This proposal is based on draft-ietf-ips-fcovertcpip-06.txt and should contain sufficient detail for evaluation purposes. This is not a detailed proposal for changes and it is assumed that the FCIP editor will cleanup any loose ends. This proposal assumes familiarity with FCIP and makes no attempt to explain existing FCIP models, structures, or functionality. Those who were at the Irvine Interim meeting will remember that the problem with FCIP and NAPTS is a reliance on IP address in the determination of which incoming TCP connections belong in a given FCIP Link. This proposal solves that problem by requiring that FC Entity World Wide Name be transmitted in the first bytes sent by the FCIP Entity that initiates a TCP Connect request. This allows the FCIP Entity that receives a TCP Connect request to match it with any previously received TCP Connect requests from the same source. Since the transmitted World Wide Name is required to be unique within Fibre Channel, the FCIP Entity that receives this information can correctly assign FCIP Link relationships without relying on IP Addresses. To allow a given FC Entity to have multiple distinct FC/FCIP ports, the World Wide Name is qualified by a 32-bit FC/FCIP Entity identifier. Optional suggestions about how a TCP Connection should be used are also provided in the first bytes send by the FCIP Entity that initiates a TCP Connect request. It is believed that the proposed changes will work even with the manual discovery option provided for in the FCIP draft. However, the most reliable end-to-end knowledge of who is talking to whom is achieved if SLPv2 discovery is used and each SLP service advertisement includes the advertiser's World Wide Name and FC/FCIP Entity identifier. A summary of the proposed changes follows. [Change 1] Add a new section between 6 and 7. Note all other section number have been adjusted to reflect this addition. 7. FCIP Short Frame Figure x shows the FCIP Short Frame format. W|------------------------------Bit------------------------------| o| | r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 1| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 2| pFlags | Reserved | -pFlags | -Reserved | | (0x01) | (0x00) | (0xFE) | (0xFF) | +-----------+---+---------------+-----------+---+---------------+ 3| Flags | Frame Length | -Flags | -Frame Length | | (0x00) | (0x00-0E) | (0x3F) | (0x03-F1) | +-----------+-------------------+-----------+-------------------+ 4| Time Stamp [integer] | +---------------------------------------------------------------+ 5| Time Stamp [fraction] | +---------------------------------------------------------------+ 6| CRC (Reserved in FCIP) | | (0x00-00-00-00) | +-------------------------------+-------------------------------+ 7| Reserved | -Reserved | | (0x00-00) | (0xFF-FF) | +-------------------------------+-------------------------------+ 8| | +----- FC Fabric Entity World Wide Name -----+ 9| | +---------------------------------------------------------------+ 10| FC/FCIP Entity Identifier | +---------------+---------------+-------------------------------+ 11| Connection | Reserved | Connection Usage Code | | Usage Flags | (0x00) | | +---------------+---------------+-------------------------------+ 12| Reserved | | (0x00-00-00-00) | +---------------------------------------------------------------+ 13| Reserved | -Reserved | | (0x00-00) | (0xFF-FF) | +-------------------------------+-------------------------------+ Fig. x FCIP Short Frame Format pFlags: The pFlags bits provide information about the protocol specific usage of the FC Encapsulation Header as shown in figure y. |----------------Bit--------------------| | | | 31 30 29 28 27 26 25 24 | +----------------------------------+----+ | Reserved | SF | +----------------------------------+----+ Fig. y - pFlags Field Format In the Short Frame, the SF (Short Frame) bit SHALL be one. FCIP Encapsulated frames the SF bit SHALL be zero. The FC Fabric Entity World Wide Name field SHALL contain the Fibre Channel Name_Identifier [FC-FS] for the FC Fabric entity associated with the FC Entity FCIP Entity pair that generated the Short Frame. For example, if the FC Fabric entity is a FC Switch, the FC Fabric Entity World Wide Name field SHALL contain the Switch_Name [FC-SW-2] provided that name is world wide unique. The FC Fabric Entity World Wide Name SHALL be world wide unique. The FC/FCIP Entity Identifier field SHALL contain a unique identifier for the FC Entity FCIP Entity pair that generated the Short Frame that is assigned by the FC Fabric entity whose world wide name appears in the FC Fabric Entity World Wide Name field. The FC/FCIP Entity Identifier is statically assigned to represent the configuration relationship of the FC Entity FCIP Entity pair to the FC Fabric entity. Note: The combination of the FC Entity World Wide Name and FCIP Entity Identifier fields uniquely identifies every FC Entity FCIP Entity pair in the IP Network. An FCIP Entity that receives a TCP Connect request SHALL use the contents of the FC Fabric Entity World Wide Name and FC/FCIP Identifier fields to determine the FCIP_LEP to which the FCIP_DE associated with the TCP connection is assigned. This may be an existing FCIP_LEP or a new FCIP_LEP, depending on whether the FCIP Entity has received the same FC Fabric Entity World Wide Name and FC/FCIP Identifier field values before. If an FCIP Short Frame is received on a TCP connection that has already been assigned to an FCIP_LEP, the FC Fabric Entity World Wide Name and FC/FCIP Identifier fields SHALL be ignored. The Connection Usage Flags field identifies the types of SOF values [FC Encapsulation] to be carried on the connection as shown in figure z. |------------------------------Bit------------------------------| | | | 31 30 29 28 27 26 25 24 | +---------------------------------------------------------------+ | SOFf | SOF?2 | SOF?3 | Reserved | +---------------------------------------------------------------+ Fig. z - Connection Usage Flags Field Format If the SOFf bit is one, then frames containing SOFf are intended to be carried on the connection. If the SOF?2 bit is one, then frames containing SOFi2 and SOFn2 are intended to be carried on the connection. If the SOF?3 bit is one, then frames containing SOFi3 and SOFn3 are intended to be carried on the connection. All or none of the SOFf, SOF?2, and SOF?3 bits MAY be set to one. If all of the SOFf, SOF?2, and SOF?3 bits are zero, then the types of FC Frames intended to be carried on the connection has no specific relationship to SOF code. The FCIP Entity SHALL NOT enforce the SOF usage described by the Connection Usage Flags field and SHALL only use the contents of the field as described below. The Connection Usage Code field contains Fibre Channel defined information regarding the intended usage of the connection as specified in FC-BB-2. The FCIP Entity SHALL use the contents of the Connection Usage Flags and Connection Usage Code fields to locate appropriate QoS settings in the "shared" database of TCP connection information (see 8.1.1) and apply those settings to a newly formed connection. If an FCIP Short Frame is received after QOS settings have been established, the Connection Usage Flags and Connection Usage Code fields SHOULD be ignored. For each new incoming TCP Connect request received, the FCIP Entity SHALL send the contents of the FC Fabric Entity World Wide Name, FC/FCIP Identifier, Connection Usage Flags and Connection Usage Code fields to the FC Entity along with the other new connection information. [Change 2] In 5.6.1, add the pFlags field definition and require all FCIP Encapsulated Frames except Short Frames to have SF equal to zero. Note: Some part of the pFlags description above will go in 5.6.1 not in the new section but the description above is structured for easier reading in this proposal. [Change 3] Some place in 5.6 (the description of the FCIP_DE), require the FCIP_DE to pass all FCIP Short Frames to the Control & Services Module. [Change 4] In 7.1.3 and 7.1.4 (the two sections where TCP Connect requests are generated), require the FCIP Entity to: 1) Acquire the Connection Usage and other information from the "shared" database (see section 7.1.1); 2) Send a FCIP Short Frame as the first bytes passing through the Encapsulated Frame Transmitter Portal following establishment of a TCP connection; 3) Compare the first bytes received through the Encapsulated Frame Receiver Portal to the FCIP Short Frame sent and close the TCP connection if the bytes are not an FCIP Short Frame whose contents (words 7 through 13 inclusive) exactly match the FCIP Short Frame passed through the Encapsulated Frame Transmitter Portal. It is recommended that an FCIP Entity not initiate TCP Connect requests to another FCIP Entity if incoming TCP Connects requests from that FCIP Entity have already been accepted. [Change 5] In 7.1.5 (the section where TCP Connect requests are accepted) change the requirements about binding the new connection to an FCIP_LEP more or less as follows: 1) Require the FCIP Entity to expect a FCIP Short Frame as the first bytes to pass through the Encapsulated Frame Receiver Portal following completion of an incoming TCP Connect request; 2) Require the FCIP Entity to transmit the FCIP Short Frame contents received (words 7 through 13 inclusive) through the Encapsulated Frame Transmitter Portal immediately upon receipt with out alteration of any kind; 3) Require use of the FC Entity WWN and FCIP Entity Identifier fields in the FCIP Short Frames to determine if there is an existing FCIP_LEP to bind to; and 4) Recommend that the Connection Usage fields contents be used in conjunction with the "shared" database (see section 7.1.1) to determine the QOS settings for the newly created connection. If the local FCIP Entity determines that the TCP Connect request just received is for a remote FCIP Entity to which the local FCIP Entity has already initiated TCP Connect requests and the connection request is otherwise valid, the local FCIP Entity SHALL accept TCP Connect request. The FCIP Entity SHALL notify the FC Entity of the reverse direction TCP Connect request and the FC Entity SHALL determine whether both connections are permitted and, if one is not permitted, request that the FCIP Entity close the appropriate connection. [Change 6] In 5.4, replace the following sentence: "An FC Fabric to IP Network interface product SHALL contain one FCIP Entity for each IP Address assigned to the product." with: "An FC Fabric to IP Network interface product SHALL provide each FC Entity FCIP Entity pair contained in the product with a unique combination of FC Fabric Entity World Wide Identifier and FC/FCIP Entity Identifier values (see section 7)." From owner-ips@ece.cmu.edu Thu Oct 25 02:36: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 CAA08892 for ; Thu, 25 Oct 2001 02:36:45 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9P5puB16200 for ips-outgoing; Thu, 25 Oct 2001 01:51:56 -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 f9P5psl16191 for ; Thu, 25 Oct 2001 01:51:54 -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 HAA236896 for ; Thu, 25 Oct 2001 07:51: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 f9P5plQ17002 for ; Thu, 25 Oct 2001 07:51:47 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI minimum PDU length X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Oct 2001 08:51:40 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 08:51:46, Serialize complete at 25/10/2001 08:51:46 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, The restriction applies to NOP (every PDU) too. The Ping response will be the Ping data or a ping data cut to the length of the reverse direction PDU. The curent 4k was also for responses. Julo Santosh Rao Sent by: santoshr@cup.hp.com 24-10-01 20:04 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI minimum PDU length Julian, Does the below imply that the length retriction of 4K on text & nop operations is also removed and we now need to handle multi-sequence nop operations ? I suggest that maximum nop operation length be restricted to the minimum PDU length that the draft will require. This will avoid adding multi-pdu sequence complexity for the nop-out/nop-in pdu's. The current login & text pdu's do allow for multi-sequence operations based on the T/F bit. This should be sufficient if the login/text payload exceeds 1K , as long as "key=value" operations are not going to span pdu's. Is that correct ? - Santosh Julian Satran wrote: > > With no votes against we have settled (again) on single PDU length (per > connection, per direction) for all types of PDUs. > But I think we erred on the low side by suggesting 64 as a minimum. It is > low (it was mentioned) and bad for text request/response. > > How about settling for 1024? > > 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 Thu Oct 25 02:36: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 CAA08927 for ; Thu, 25 Oct 2001 02:36:58 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9P6Lj617875 for ips-outgoing; Thu, 25 Oct 2001 02:21: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 f9P6Lil17870 for ; Thu, 25 Oct 2001 02:21: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 IAA111176 for ; Thu, 25 Oct 2001 08:21: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 f9P6LbU195516 for ; Thu, 25 Oct 2001 08:21:37 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Start of digest activity X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Oct 2001 09:21:30 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 09:21:36, Serialize complete at 25/10/2001 09:21:36 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Correct - Julo Prasenjit Sarkar/Almaden/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 24-10-01 21:22 Please respond to Prasenjit Sarkar To: ips@ece.cmu.edu cc: Subject: iSCSI: Start of digest activity Now that digest negotiation has been moved to the operational phase, does this mean digest activity starts after the login is accepted? Clarification requested, Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose From owner-ips@ece.cmu.edu Thu Oct 25 02:38: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 CAA09028 for ; Thu, 25 Oct 2001 02:38:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9P6G5217559 for ips-outgoing; Thu, 25 Oct 2001 02:16: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 f9P6G3l17553 for ; Thu, 25 Oct 2001 02:16:03 -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 IAA48724 for ; Thu, 25 Oct 2001 08:15: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 f9P6FuU181048 for ; Thu, 25 Oct 2001 08:15:57 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: Question X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Oct 2001 09:15:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 09:15:56, Serialize complete at 25/10/2001 09:15:57, Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 09:15:57 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Shesha, SCSI is not a "reliable protocol". It assumes a reliable delivery subsystem. That is what iSCSI does (as well as FCP, SPI, SBP etc.). This is why only two transports where considered (TCP and SCTP) and TCP was selected to start with due to its maturity. Julo "shesha bhushan" Sent by: owner-ips@ece.cmu.edu 24-10-01 20:38 Please respond to "shesha bhushan" To: ips@ece.cmu.edu cc: Subject: Question Hi, I am doing a research project at Arizona State University on SCSI and iSCSI. I was going through both the protocols. I have a crazy question. iSCSI = SCSI/(TCP/IP). But SCSI is a reliable protocol so is TCP. so can't we just try to send SCSI packets on IP or SCSI/UDP. Any & All comments are welcome. Thanks Shesha Bhushan S Research Assistant Arizona State University _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-ips@ece.cmu.edu Thu Oct 25 02: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 CAA09049 for ; Thu, 25 Oct 2001 02:38:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9P67UW17120 for ips-outgoing; Thu, 25 Oct 2001 02:07:30 -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 f9P67Sl17115 for ; Thu, 25 Oct 2001 02:07: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 IAA72964 for ; Thu, 25 Oct 2001 08:07: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 f9P67MU243512 for ; Thu, 25 Oct 2001 08:07:22 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI minimum PDU length X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Oct 2001 09:07:16 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 09:07:22, Serialize complete at 25/10/2001 09:07:22 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, About the login issue - during login the default of 8k holds (MaxRecvPDULength is not negotiated yet). This should make login swift. Julo Santosh Rao Sent by: santoshr@cup.hp.com 24-10-01 20:04 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI minimum PDU length Julian, Does the below imply that the length retriction of 4K on text & nop operations is also removed and we now need to handle multi-sequence nop operations ? I suggest that maximum nop operation length be restricted to the minimum PDU length that the draft will require. This will avoid adding multi-pdu sequence complexity for the nop-out/nop-in pdu's. The current login & text pdu's do allow for multi-sequence operations based on the T/F bit. This should be sufficient if the login/text payload exceeds 1K , as long as "key=value" operations are not going to span pdu's. Is that correct ? - Santosh Julian Satran wrote: > > With no votes against we have settled (again) on single PDU length (per > connection, per direction) for all types of PDUs. > But I think we erred on the low side by suggesting 64 as a minimum. It is > low (it was mentioned) and bad for text request/response. > > How about settling for 1024? > > 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 Thu Oct 25 02:44: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 CAA09489 for ; Thu, 25 Oct 2001 02:44:29 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9P6R6H18150 for ips-outgoing; Thu, 25 Oct 2001 02:27: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 f9P6R4l18145 for ; Thu, 25 Oct 2001 02:27: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 IAA91956 for ; Thu, 25 Oct 2001 08:26:58 +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 f9P6QwQ46128 for ; Thu, 25 Oct 2001 08:26:58 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI minimum PDU length X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Oct 2001 09:26:51 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 09:26:57, Serialize complete at 25/10/2001 09:26:57 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk no - the minimum mentioned includes only the data segment. Julo Santosh Rao Sent by: santoshr@cup.hp.com 24-10-01 22:52 Please respond to Santosh Rao To: "Martin, Nick" cc: Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu Subject: Re: iSCSI minimum PDU length Does the MaxRecvPDULength include the AHS length ? - Santosh "Martin, Nick" wrote: > > Julian, > > This is for the data after the PDU header right? > This will be the guaranteed lowest value anyone will be forced to deal > with. > Implementations may negotiate for any value greater than or equal to > this value. > > This is acceptable and it is a good choice because it is the largest > power of 2 that will fit within minimum Ethernet MTU of ~1500 and leaves > plenty of room for iSCSI and LLP headers. > > Thanks, > Nick > > -----Original Message----- > From: Julian Satran [mailto:Julian_Satran@il.ibm.com] > Sent: Wednesday, October 24, 2001 12:35 PM > To: ips@ece.cmu.edu > Subject: iSCSI minimum PDU length > > With no votes against we have settled (again) on single PDU length (per > connection, per direction) for all types of PDUs. > But I think we erred on the low side by suggesting 64 as a minimum. It > is > low (it was mentioned) and bad for text request/response. > > How about settling for 1024? > > 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 Thu Oct 25 02:47: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 CAA09732 for ; Thu, 25 Oct 2001 02:47:01 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9P6UAd18311 for ips-outgoing; Thu, 25 Oct 2001 02:30: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 f9P6U9l18307 for ; Thu, 25 Oct 2001 02:30:09 -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 IAA116678 for ; Thu, 25 Oct 2001 08:30: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 f9P6U2Q185800 for ; Thu, 25 Oct 2001 08:30:02 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: re: iSCSI minimum PDU length X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Oct 2001 09:29:56 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 09:30:02, Serialize complete at 25/10/2001 09:30:02 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Dave, The minimum MSS is under 300 bytes. 512 is as bad as 1024. Framing will have to be adjusted to deal with it. Julo Dave Sheehy Sent by: owner-ips@ece.cmu.edu 25-10-01 00:11 Please respond to Dave Sheehy To: ips@ece.cmu.edu (IETF IP SAN Reflector) cc: Subject: re: iSCSI minimum PDU length > > With no votes against we have settled (again) on single PDU length (per > connection, per direction) for all types of PDUs. > But I think we erred on the low side by suggesting 64 as a minimum. It is > low (it was mentioned) and bad for text request/response. > > How about settling for 1024? Too big (since the MSS can be smaller than 1024). 512 is a better number. Dave Sheehy From owner-ips@ece.cmu.edu Thu Oct 25 04:19: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 EAA11537 for ; Thu, 25 Oct 2001 04:19:47 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9P74iq20005 for ips-outgoing; Thu, 25 Oct 2001 03:04:44 -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 f9P74gl20000 for ; Thu, 25 Oct 2001 03:04:42 -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 JAA79364 for ; Thu, 25 Oct 2001 09:04: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 f9P74ZU118944 for ; Thu, 25 Oct 2001 09:04:35 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - Change Proposal X bit X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Oct 2001 10:04:28 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 10:04:35, Serialize complete at 25/10/2001 10:04:35 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, Some comments in text. I suggest you discuss the scenarios with Mallikarjun or if you can't do that for some reason please call me. We can't go on with this ad nauseam on the list. Julo Santosh Rao Sent by: owner-ips@ece.cmu.edu 24-10-01 18:29 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - Change Proposal X bit Julian, Some comments on the below quoted scenarios : > session has 3 connections > on connection 1 I->T c1,c2,c3,C6 > on connection 2 I->T c4,c5,c7,c8 > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 and 6 > on connection 3 > target receives all and starts executing and acks 8 on connection 3 but > connection 2 stalls after c3 for a LONG TIME > then (after 2 full sequence wraps) connection 2 is gets alive and > delivers c4,c5 etc (that are now valid) When the target acks CmdSN 8 on connection 3, it has, in effect, sent CmdSN ack's for CMdSNs 3,4,5,6,7,8. This implies that the commands with CmdSN 3, 4, 5, 7, & 8 were received by the target on connection 2 and their processing was commenced. +++ to understand fully the scenario make a timeline and observe taht after 3 and 6 where received 4-8 can be executed and their answers sent (connection 2 has not died). But c3 and the rest reach the pipe (depending on implementation this may happen after statuses have reached the initiator and TCP acks have been sent) and then the pipe stalls with the duplicates in the pipe without the target knowing about them+++ Hence, the following does not make sense : > connection 2 stalls after c3 for a LONG TIME > then (after 2 full sequence wraps) connection 2 is gets alive and > delivers c4,c5 etc (that are now valid) c4, c5, etc were already delivered to the target and are not being re-delivered. There is no problem in this case. (??). Take the next scenario : > 2 connections: > > connection1 I->T c3,c4,c5 > status of 3 contains ack up to 6 and it and all other statuses are > lost > connection2 resend c3, c4 & c5 (no logout) and those are executed! Since the initiator got CmdSN ack's upto 6, the initiator should not be re-issuing these I/Os ?? I still don't see justification to require that initiators send a immediate NOP-OUT in the manner being advocated. On a more fundamental note, I see some issues with the initiator being allowed to re-issue the commands on a different connection without having first logged out the previous connection successfully. I see nothing in the draft that suggests such behaviour, while at the same time, it is not forbidden. +++ the problem appears WHEN THE INITIATOR REISSUES THE COMANDS ON THE SAME CONNECTION +++ By resorting to command retries on a different connection in an attempt to plug the hole, without first logging out the previous connection, the initiator is susceptible to encountering I/O failure of that I/O due to ULP timeout. +++ That is not what the first scenario says. The second is trickier and involves the fact Here's the scenario why such recovery should not be allowed : - Initiator sends CmdSN 3 on connection 1. - No CmdSN updates for a while and initiator re-sends CmdSn 3 on connection 2. - At the same time, target has sent CmdSN ack's for CmdSN 3 on connection 1. - Initiator has transferred the command allegiance on its side from connection 1 to connection 2 and is attempting the command on connection 2. However, the command does not go through, since the (ExpCmdSN, MaxCmdSN) window has advanced and the trget discards the command. - Target sends in data and/or R2T and/or status for CmdSN 3 on connection 1. Since the initiator is not expecting any traffic for that I/O on connection 1, it discards any PDUs received on that connection 1 for which no I/O state existed. In the above scenario, initiator will never get a CmdSN ack on connection 2 and will never be able to plug the hole despite repeated retries, finally, causing a ULP timeout, followed by session recovery. Given the above scenario, I suggest that the initiator must only re-issue commands on the same connection, and can re-issue them on another connection only following a successful logout. +++ That is what the current text says explicitly. Scenario 2 has not been properly stated. +++ Comments ? Thanks, Santosh Julian Satran wrote: > > Santosh, > > The scenarios I am talking about are all derivatives of an initiator trying > to plug-in holes and switching connections. > As the initiator does know the "extent" of a hole it can send-out commands > that he did not have to. > I have sent the attached not to Mallikarjun a while ago. I think that > there might be many of this kind. I am also aware that X bit by itself > might have some bad scenarios but the new proposal fixes them all. > > Julo > > _____________________________ > > Mallikarjun, > > Take the following sequence scenario: > > session has 3 connections > on connection 1 I->T c1,c2,c3,C6 > on connection 2 I->T c4,c5,c7,c8 > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 and 6 > on connection 3 > target receives all and starts executing and acks 8 on connection 3 but > connection 2 stalls after c3 for a LONG TIME > then (after 2 full sequence wraps) connection 2 is gets alive and > delivers c4,c5 etc (that are now valid) > > That is not a very likely scenario, I admit, but it is possible. > With X bit I could not find any such scenario since an X either follows a > good one on the same connection or can be safely discarded. > I suspect that there are some more scenarios that involve immediate > commands or commands that carry their own ack in the status and are acked > like: > > 2 connections: > > connection1 I->T c3,c4,c5 > status of 3 contains ack up to 6 and it and all other statuses are > lost > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > I think we can avoid those be requiring a NOP exchange before reissuing a > command on a new connection or reissue the command with a task management > (that has an implied ordering) but why do it if X is an obvious and safe > solution. > > Julo > > Regards, > Julo > > > "Mallikarjun > C." To: Julian Satran/Haifa/IBM@IBMIL > om> Subject: Re: iscsi : X bit in SCSI Command PDU. > > 08-10-01 21:45 > Please respond > to cbm > > > > Julian, > > We currently have the following specified in section 2.2.2.1 - > > "The target MUST NOT transmit a MaxCmdSN that is more than > 2**31 - 1 above the last ExpCmdSN." > > It appears to me that the above is sufficient to ward off the > accidents of the sort you describe. Do you think otherwise? > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Julian Satran wrote: > > > > Mallikarjun, > > > > There is at least one theoretical scenario in which an "old" command > > may appear in a "new window" and be reinstantiated. > > At 10Gbs and several connection that does not take months. With X the > > probability is far lower (not 0). I have no other strong arguments > > but I am still thinking. Matt Wakeley that insisted on it (against > > me) had some other argument that I am trying to find (I am note > > remembering). > > > > Julo > > > > "Mallikarjun C." > > To: Julian > > Satran/Haifa/IBM@IBMIL > > 08-10-01 20:39 cc: > > Please respond to cbm Subject: Re: iscsi : X > > bit in SCSI Command PDU. > > > > > > > > Julian, > > > > Now that you put me on the spot, :-), my response - > > > > Santosh argued with me privately that X-bit no longer serves a > > useful purpose after the advent of task management commands to > > reassign. My response was that it never was a requirement per se, > > but always a "courtesy" extended by the initiator to help the > > target. I also suggested that X-bit may be considered for its > > usefulness in debugging. > > > > He still had some (very reasonable) comments for simplification > > - the most appealing of which (to me) was the opportunity to do > > away with the X-bit checking for *every* command PDU that the target > > has to endure now. > > > > If I missed a legitimate use of X-bit, please comment. Do you > > think it is a protocol requirement per se? I couldn't justify > > to myself so far (except the Login). > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > > > > > Julian Satran wrote: > > > > > > Santosh, > > > > > > I am not sure you went through all scenarios. A conversation with > > your > > > colleague - Mallikarjun - and getting through the state table may go > > a > > > long way to clarify the need for X. > > > > > > And I am sure that by now you found yourself several . > > > > > > Julo > > > > > > Santosh Rao > > > To: IPS Reflector > > > Sent by: owner-ips@ece.cmu.edu > > > cc: > > > 06-10-01 01:56 Subject: iscsi : X > > > Please respond to Santosh Rao bit in SCSI Command PDU. > > > > > > > > > > > > All, > > > > > > With the elimination of command relay from iscsi [in the interests > > of > > > simplification ?], I believe that the X bit in the SCSI Command PDU > > > can > > > also be removed. As it exists today, the X bit is only being used > > for > > > command restart, which is at attempt by the initiator to plug a > > > potential hole in the CmdSN sequence at the target. It does this on > > > failing to get an ExpCmdSN ack for a previously sent command within > > > some > > > timeout period. > > > > > > Given the above usage of command restart, no X bit is required to be > > > set > > > in the SCSI Command PDU when command re-start is done. > > > > > > Either : > > > (a) the target had dropped the command earlier due to a digest > > error, > > > in > > > which case, the command restart plugs the CmdSN hole in the target. > > > > > > [OR] > > > > > > (b) the target had received the command and was working on it, when > > > the > > > initiator timed out too soon and attempted a command restart to plug > > > [what it thought was] a possible hole in the CmdSN sequence. > > > > > > In case (a), no X bit was required, since the target knows nothing > > of > > > the original command. In case (b), no X bit is required again, since > > > the > > > (ExpCmdSN, MaxCmdSN) window would have advanced and the target can > > > silently discard the received retry and continue working on the > > > original > > > command received. > > > > > > Removal of the X bit in the SCSI Command PDU has the following > > > benefits > > > : > > > > > > a) The CmdSN rules at the target are simplified. No need to look at > > X > > > bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) window. > > > > > > b) The reject reason code "command already in progress" can be > > > removed. > > > There's no need for this reject reason code anymore, since X bit > > > itself > > > is not required, and the targets can silently discard commands > > outside > > > the command window and continue to work on the original instance of > > > the > > > command already being processed at the target. > > > > > > c) Less work for the target and less resources consumed since it no > > > longer needs to generate a Reject PDU of type "command in progress". > > > It > > > can just silently discard any command PDU outside the (ExpCmdSN, > > > MaxCmdSN) window. > > > > > > d) Less code for the target, since it does not need : > > > - any Reject code paths when it receives X bit command PDUs that are > > > already in progress. > > > - No special casing of CmdSN checking rules. > > > - No overheads of verifying a received command based on its > > initiator > > > task tag, to check if the task is currently active, prior to sending > > a > > > Reject response with "command in progress". > > > > > > 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 > > > ################################## > > > Santosh Rao > > hp.com> cc: > Sent by: Subject: Re: iSCSI - Change Proposal X bit > owner-ips@ece. > cmu.edu > > > 23-10-01 22:50 > Please respond > to Santosh Rao > > > > Julian Satran wrote: > > > > However in order to drop "old" commands that might in the pipe on a > > sluggish connection - removing the X bit will require the initiator to > > issue an immediate NOP requiring a NOP response on every open connection > > whenever CmdSN wraps around (becomes equal to InitCmdSN). > > Julian, > > Can you please explain further the corner case you are describing above > ? Are you suggesting that special action should be taken every time > CmdSN wraps around, in case there were holes in the CmdSN sequence at > the wrap time ? Why is that ? > > Here's my understanding of how this plays out : > > Rule 1) > The CmdSN management rules at the target should be handling CmdSN wrap > case and the initiator cannot issue more than 2^32 -1 commands beyond > the last ExpCmdSN update it has received from the target, since the > target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above > the last ExpCmdSN. (per Section 2.2.2.1) > > Rule 2) > Any holes that occur in the CmdSN sequence are attempted to be plugged > by the initiator by re-issuing the original command. If the CmdSN never > got acknowledged and the I/O's ULP timeout expired, the initiator MUST > perform session recovery. (per Section 8.6) > > Thus, going by the above 2 rules, if the CmdSN sequence wraps upto > ExpCmdSN, the initiator will not be able to issue further commands, > since the target will keep the CmdSN window closed. The window can only > re-open when the CmdSN holes are plugged allowing ExpCmdSN and thereby, > MaxCmdSN to advance. (rule 1 above). > > Under the above circumstances, the initiator will possibly try to plug > the CmdSN hole by re-issuing the original command. It may do this 1 or > more times before its ULP timeout expires. Either the holes get plugged > and the windoe re-opens, or ULP timeout occurs without the corresponding > CmdSN for that I/O having been acknowledged, resulting in session > logout. (rule 2 above). > > What is required over and beyond the above ? Why does removal of X-bit > require an immediate NOP to be issued every time CmdSN wraps and a hole > exists in the CmdSN sequence (??). > > Regards, > 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 Thu Oct 25 05:02: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 FAA12012 for ; Thu, 25 Oct 2001 05:02:40 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9P87wk23190 for ips-outgoing; Thu, 25 Oct 2001 04:07:58 -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 f9P87vl23186 for ; Thu, 25 Oct 2001 04:07:57 -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 KAA116332 for ; Thu, 25 Oct 2001 10:07: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 f9P87gU58886 for ; Thu, 25 Oct 2001 10:07:43 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - Change Proposal X bit X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Oct 2001 11:07:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 11:07:45, Serialize complete at 25/10/2001 11:07:45 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Santosh, The draft DOES NOT ALLOW commands to be reissued on another connection without an intervening logout. Julo Santosh Rao Sent by: santoshr@cup.hp.com 25-10-01 01:44 Please respond to Santosh Rao To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI - Change Proposal X bit Julian, The one scenario where I do see stale CmdSNs creating a problem is the following : - 2 connections. - CmdSN 3 issued on connection 1. - Initiator does not get CmdSN ack for 1 and re-issues CmdSN 1 on connection 2. - CmdSN ack for 1 received on connection 2. All further I/O traffic on connection 2 only (nothing on connection 1) and CmdSN sequence wraps around. - Finally, connection 1 clears up and CmdSN 1 is delivered on connection 1. In the above situation, the stale CmdSN 1 is a problem. However, the problem only occurs if the draft allows previously issued commands to be re-issued on a different connection without first logging out the previous connection. Why is it not possible to disallow commands to be re-issued on a different connection unless the original connection used for that command was first logged out successfully ? This would avoid this stale CmdSN on wrap around problem, as well as avoid sporadic ULP timeout of I/Os due to race condition b/n initiator re-issuing command on another connection and target sending CmdSN update on the first connection. Thanks, Santosh ps : I still don't see how your scenario below holds good. When the target ack's CmdSNs upto 8 on connection 3, it has received all CmdSNs. Hence, there can be no stalled commands on connection 2. However, a different scenario which does cause a problem is the one I describe above. Julian Satran wrote: > > Santosh, > > There is nothing in a command that arrives late on a link (as in the > example in which it was sent redundantly) to distinguish it from a new > (valid) command. > > This wraparound problem exists in all protocols - even in TCP, and we use > the CmdSN per session in the same fashion TCP uses sequence numbers per > connection - and it is solved in different ways (TCP uses time-stamps). > > The NOP is meant to solve that wrap-around problem. > > I am sure that when rereading the example you will see the issue. > > Julo > > Santosh Rao > Sent by: santoshr@cup.hp.com > 24-10-01 18:29 > Please respond to Santosh Rao > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI - Change Proposal X bit > > > > Julian, > > Some comments on the below quoted scenarios : > > > session has 3 connections > > on connection 1 I->T c1,c2,c3,C6 > > on connection 2 I->T c4,c5,c7,c8 > > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 and > 6 > > on connection 3 > > target receives all and starts executing and acks 8 on connection 3 > but > > connection 2 stalls after c3 for a LONG TIME > > then (after 2 full sequence wraps) connection 2 is gets alive and > > delivers c4,c5 etc (that are now valid) > > When the target acks CmdSN 8 on connection 3, it has, in effect, sent > CmdSN ack's for CMdSNs 3,4,5,6,7,8. This implies that the commands with > CmdSN 3, 4, 5, 7, & 8 were received by the target on connection 2 and > their processing was commenced. > > Hence, the following does not make sense : > > > connection 2 stalls after c3 for a LONG TIME > > then (after 2 full sequence wraps) connection 2 is gets alive and > > delivers c4,c5 etc (that are now valid) > > c4, c5, etc were already delivered to the target and are not being > re-delivered. There is no problem in this case. (??). > > Take the next scenario : > > 2 connections: > > > > connection1 I->T c3,c4,c5 > > status of 3 contains ack up to 6 and it and all other statuses are > > lost > > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > Since the initiator got CmdSN ack's upto 6, the initiator should not be > re-issuing these I/Os ?? > > I still don't see justification to require that initiators send a > immediate NOP-OUT in the manner being advocated. > > On a more fundamental note, I see some issues with the initiator being > allowed to re-issue the commands on a different connection without > having first logged out the previous connection successfully. I see > nothing in the draft that suggests such behaviour, while at the same > time, it is not forbidden. > > By resorting to command retries on a different connection in an attempt > to plug the hole, without first logging out the previous connection, the > initiator is susceptible to encountering I/O failure of that I/O due to > ULP timeout. > > Here's the scenario why such recovery should not be allowed : > - Initiator sends CmdSN 3 on connection 1. > - No CmdSN updates for a while and initiator re-sends CmdSn 3 on > connection 2. > - At the same time, target has sent CmdSN ack's for CmdSN 3 on > connection 1. > > - Initiator has transferred the command allegiance on its side from > connection 1 to connection 2 and is attempting the command on connection > 2. However, the command does not go through, since the (ExpCmdSN, > MaxCmdSN) window has advanced and the trget discards the command. > > - Target sends in data and/or R2T and/or status for CmdSN 3 on > connection 1. Since the initiator is not expecting any traffic for that > I/O on connection 1, it discards any PDUs received on that connection 1 > for which no I/O state existed. > > In the above scenario, initiator will never get a CmdSN ack on > connection 2 and will never be able to plug the hole despite repeated > retries, finally, causing a ULP timeout, followed by session recovery. > > Given the above scenario, I suggest that the initiator must only > re-issue commands on the same connection, and can re-issue them on > another connection only following a successful logout. > > Comments ? > > Thanks, > Santosh > > Julian Satran wrote: > > > > Santosh, > > > > The scenarios I am talking about are all derivatives of an initiator > trying > > to plug-in holes and switching connections. > > As the initiator does know the "extent" of a hole it can send-out > commands > > that he did not have to. > > I have sent the attached not to Mallikarjun a while ago. I think that > > there might be many of this kind. I am also aware that X bit by itself > > might have some bad scenarios but the new proposal fixes them all. > > > > Julo > > > > _____________________________ > > > > Mallikarjun, > > > > Take the following sequence scenario: > > > > session has 3 connections > > on connection 1 I->T c1,c2,c3,C6 > > on connection 2 I->T c4,c5,c7,c8 > > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 and > 6 > > on connection 3 > > target receives all and starts executing and acks 8 on connection 3 > but > > connection 2 stalls after c3 for a LONG TIME > > then (after 2 full sequence wraps) connection 2 is gets alive and > > delivers c4,c5 etc (that are now valid) > > > > That is not a very likely scenario, I admit, but it is possible. > > With X bit I could not find any such scenario since an X either follows > a > > good one on the same connection or can be safely discarded. > > I suspect that there are some more scenarios that involve immediate > > commands or commands that carry their own ack in the status and are > acked > > like: > > > > 2 connections: > > > > connection1 I->T c3,c4,c5 > > status of 3 contains ack up to 6 and it and all other statuses are > > lost > > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > > > I think we can avoid those be requiring a NOP exchange before reissuing > a > > command on a new connection or reissue the command with a task > management > > (that has an implied ordering) but why do it if X is an obvious and safe > > solution. > > > > Julo > > > > Regards, > > Julo > > > > > > "Mallikarjun > > C." To: Julian > Satran/Haifa/IBM@IBMIL > > > om> Subject: Re: iscsi : X bit > in SCSI Command PDU. > > > > 08-10-01 21:45 > > Please respond > > to cbm > > > > > > > > Julian, > > > > We currently have the following specified in section 2.2.2.1 - > > > > "The target MUST NOT transmit a MaxCmdSN that is more than > > 2**31 - 1 above the last ExpCmdSN." > > > > It appears to me that the above is sufficient to ward off the > > accidents of the sort you describe. Do you think otherwise? > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > Julian Satran wrote: > > > > > > Mallikarjun, > > > > > > There is at least one theoretical scenario in which an "old" command > > > may appear in a "new window" and be reinstantiated. > > > At 10Gbs and several connection that does not take months. With X the > > > probability is far lower (not 0). I have no other strong arguments > > > but I am still thinking. Matt Wakeley that insisted on it (against > > > me) had some other argument that I am trying to find (I am note > > > remembering). > > > > > > Julo > > > > > > "Mallikarjun C." > > > To: Julian > > > Satran/Haifa/IBM@IBMIL > > > 08-10-01 20:39 cc: > > > Please respond to cbm Subject: Re: iscsi : X > > > bit in SCSI Command PDU. > > > > > > > > > > > > Julian, > > > > > > Now that you put me on the spot, :-), my response - > > > > > > Santosh argued with me privately that X-bit no longer serves a > > > useful purpose after the advent of task management commands to > > > reassign. My response was that it never was a requirement per se, > > > but always a "courtesy" extended by the initiator to help the > > > target. I also suggested that X-bit may be considered for its > > > usefulness in debugging. > > > > > > He still had some (very reasonable) comments for simplification > > > - the most appealing of which (to me) was the opportunity to do > > > away with the X-bit checking for *every* command PDU that the target > > > has to endure now. > > > > > > If I missed a legitimate use of X-bit, please comment. Do you > > > think it is a protocol requirement per se? I couldn't justify > > > to myself so far (except the Login). > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > MS 5668 Hewlett-Packard, Roseville. > > > cbm@rose.hp.com > > > > > > > > > > > > Julian Satran wrote: > > > > > > > > Santosh, > > > > > > > > I am not sure you went through all scenarios. A conversation with > > > your > > > > colleague - Mallikarjun - and getting through the state table may go > > > a > > > > long way to clarify the need for X. > > > > > > > > And I am sure that by now you found yourself several . > > > > > > > > Julo > > > > > > > > Santosh Rao > > > > To: IPS Reflector > > > > Sent by: owner-ips@ece.cmu.edu > > > > cc: > > > > 06-10-01 01:56 Subject: iscsi : X > > > > Please respond to Santosh Rao bit in SCSI Command PDU. > > > > > > > > > > > > > > > > All, > > > > > > > > With the elimination of command relay from iscsi [in the interests > > > of > > > > simplification ?], I believe that the X bit in the SCSI Command PDU > > > > can > > > > also be removed. As it exists today, the X bit is only being used > > > for > > > > command restart, which is at attempt by the initiator to plug a > > > > potential hole in the CmdSN sequence at the target. It does this on > > > > failing to get an ExpCmdSN ack for a previously sent command within > > > > some > > > > timeout period. > > > > > > > > Given the above usage of command restart, no X bit is required to be > > > > set > > > > in the SCSI Command PDU when command re-start is done. > > > > > > > > Either : > > > > (a) the target had dropped the command earlier due to a digest > > > error, > > > > in > > > > which case, the command restart plugs the CmdSN hole in the target. > > > > > > > > [OR] > > > > > > > > (b) the target had received the command and was working on it, when > > > > the > > > > initiator timed out too soon and attempted a command restart to plug > > > > [what it thought was] a possible hole in the CmdSN sequence. > > > > > > > > In case (a), no X bit was required, since the target knows nothing > > > of > > > > the original command. In case (b), no X bit is required again, since > > > > the > > > > (ExpCmdSN, MaxCmdSN) window would have advanced and the target can > > > > silently discard the received retry and continue working on the > > > > original > > > > command received. > > > > > > > > Removal of the X bit in the SCSI Command PDU has the following > > > > benefits > > > > : > > > > > > > > a) The CmdSN rules at the target are simplified. No need to look at > > > X > > > > bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) window. > > > > > > > > b) The reject reason code "command already in progress" can be > > > > removed. > > > > There's no need for this reject reason code anymore, since X bit > > > > itself > > > > is not required, and the targets can silently discard commands > > > outside > > > > the command window and continue to work on the original instance of > > > > the > > > > command already being processed at the target. > > > > > > > > c) Less work for the target and less resources consumed since it no > > > > longer needs to generate a Reject PDU of type "command in progress". > > > > It > > > > can just silently discard any command PDU outside the (ExpCmdSN, > > > > MaxCmdSN) window. > > > > > > > > d) Less code for the target, since it does not need : > > > > - any Reject code paths when it receives X bit command PDUs that are > > > > already in progress. > > > > - No special casing of CmdSN checking rules. > > > > - No overheads of verifying a received command based on its > > > initiator > > > > task tag, to check if the task is currently active, prior to sending > > > a > > > > Reject response with "command in progress". > > > > > > > > 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 > > > > ################################## > > > > > > Santosh Rao > > > > hp.com> cc: > > Sent by: Subject: Re: iSCSI - Change > Proposal X bit > > owner-ips@ece. > > cmu.edu > > > > > > 23-10-01 22:50 > > Please respond > > to Santosh Rao > > > > > > > > Julian Satran wrote: > > > > > > However in order to drop "old" commands that might in the pipe on a > > > sluggish connection - removing the X bit will require the initiator to > > > issue an immediate NOP requiring a NOP response on every open > connection > > > whenever CmdSN wraps around (becomes equal to InitCmdSN). > > > > Julian, > > > > Can you please explain further the corner case you are describing above > > ? Are you suggesting that special action should be taken every time > > CmdSN wraps around, in case there were holes in the CmdSN sequence at > > the wrap time ? Why is that ? > > > > Here's my understanding of how this plays out : > > > > Rule 1) > > The CmdSN management rules at the target should be handling CmdSN wrap > > case and the initiator cannot issue more than 2^32 -1 commands beyond > > the last ExpCmdSN update it has received from the target, since the > > target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above > > the last ExpCmdSN. (per Section 2.2.2.1) > > > > Rule 2) > > Any holes that occur in the CmdSN sequence are attempted to be plugged > > by the initiator by re-issuing the original command. If the CmdSN never > > got acknowledged and the I/O's ULP timeout expired, the initiator MUST > > perform session recovery. (per Section 8.6) > > > > Thus, going by the above 2 rules, if the CmdSN sequence wraps upto > > ExpCmdSN, the initiator will not be able to issue further commands, > > since the target will keep the CmdSN window closed. The window can only > > re-open when the CmdSN holes are plugged allowing ExpCmdSN and thereby, > > MaxCmdSN to advance. (rule 1 above). > > > > Under the above circumstances, the initiator will possibly try to plug > > the CmdSN hole by re-issuing the original command. It may do this 1 or > > more times before its ULP timeout expires. Either the holes get plugged > > and the windoe re-opens, or ULP timeout occurs without the corresponding > > CmdSN for that I/O having been acknowledged, resulting in session > > logout. (rule 2 above). > > > > What is required over and beyond the above ? Why does removal of X-bit > > require an immediate NOP to be issued every time CmdSN wraps and a hole > > exists in the CmdSN sequence (??). > > > > 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 Thu Oct 25 06:11: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 GAA12720 for ; Thu, 25 Oct 2001 06:11:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9P9brs08519 for ips-outgoing; Thu, 25 Oct 2001 05:37:53 -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 f9P9bql08515 for ; Thu, 25 Oct 2001 05:37:52 -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 EAA37140 for ; Thu, 25 Oct 2001 04:35: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 f9P9aYP14780 for ; Thu, 25 Oct 2001 03:36:34 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI minimum PDU length 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: Thu, 25 Oct 2001 02:35:38 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/25/2001 03:36:34 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk If you are only talking about Data PDUs, then at least I understand. . . . 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 ---------------------- Forwarded by John Hufferd/San Jose/IBM on 10/25/2001 02:34 AM --------------------------- John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 10/25/2001 02:12:07 AM Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI minimum PDU length Julian, Perhaps I do not understand what you are getting at here, but since there will be implementations with only R2T type Sessions, then there should be a lot of PDUs that just carry the Command (48 bytes + digest) it seems that a 1024 is kind of big. What am I missing? . . . 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 10/24/2001 10:34:38 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI minimum PDU length With no votes against we have settled (again) on single PDU length (per connection, per direction) for all types of PDUs. But I think we erred on the low side by suggesting 64 as a minimum. It is low (it was mentioned) and bad for text request/response. How about settling for 1024? Julo From owner-ips@ece.cmu.edu Thu Oct 25 06:14: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 GAA12740 for ; Thu, 25 Oct 2001 06:14:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9P9EhM07440 for ips-outgoing; Thu, 25 Oct 2001 05:14:43 -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 f9P9Efl07436 for ; Thu, 25 Oct 2001 05:14:41 -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 FAA15958 for ; Thu, 25 Oct 2001 05:12:09 -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 f9P9DNP37886 for ; Thu, 25 Oct 2001 03:13:23 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI minimum PDU length 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: Thu, 25 Oct 2001 02:12:07 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/25/2001 03:13:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Perhaps I do not understand what you are getting at here, but since there will be implementations with only R2T type Sessions, then there should be a lot of PDUs that just carry the Command (48 bytes + digest) it seems that a 1024 is kind of big. What am I missing? . . . 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 10/24/2001 10:34:38 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI minimum PDU length With no votes against we have settled (again) on single PDU length (per connection, per direction) for all types of PDUs. But I think we erred on the low side by suggesting 64 as a minimum. It is low (it was mentioned) and bad for text request/response. How about settling for 1024? Julo From owner-ips@ece.cmu.edu Thu Oct 25 09:20: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 JAA18465 for ; Thu, 25 Oct 2001 09:20:16 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PCKpw16924 for ips-outgoing; Thu, 25 Oct 2001 08:20: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 f9PCKml16914 for ; Thu, 25 Oct 2001 08:20: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 OAA102652 for ; Thu, 25 Oct 2001 14:20: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.97.1) with ESMTP id f9PCKbU59074 for ; Thu, 25 Oct 2001 14:20:37 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI minimum PDU length X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Oct 2001 15:20:25 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 15:20:37, Serialize complete at 25/10/2001 15:20:37 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk John, We are talking about the payload (i.e. DataSegment Length) maximum length that a receiver will accept and I suggested 1024 as the minimum value for it. Julo John Hufferd@IBMUS 25-10-01 11:12 To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI minimum PDU length Julian, Perhaps I do not understand what you are getting at here, but since there will be implementations with only R2T type Sessions, then there should be a lot of PDUs that just carry the Command (48 bytes + digest) it seems that a 1024 is kind of big. What am I missing? . . . 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 Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI minimum PDU length With no votes against we have settled (again) on single PDU length (per connection, per direction) for all types of PDUs. But I think we erred on the low side by suggesting 64 as a minimum. It is low (it was mentioned) and bad for text request/response. How about settling for 1024? Julo From owner-ips@ece.cmu.edu Thu Oct 25 09:26: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 JAA18755 for ; Thu, 25 Oct 2001 09:26:39 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PCdr918011 for ips-outgoing; Thu, 25 Oct 2001 08:39:53 -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 f9PCdpl18006 for ; Thu, 25 Oct 2001 08:39:51 -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 OAA101520; Thu, 25 Oct 2001 14:39:12 +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 f9PCdCQ39476; Thu, 25 Oct 2001 14:39:12 +0200 To: ips@ece.cmu.edu, bassoon@YOGI.PDL.CMU.EDU MIME-Version: 1.0 Subject: Re: IPS search engine X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Oct 2001 15:39:05 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 15:39:12, Serialize complete at 25/10/2001 15:39:12 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Eddy, I am rarely using the archive. But I assume many would like digging into it so I forward this to the list and to Dave Nagle whom we all should be thankful for maintaining this list so patiently. Regards, Julo Eddy Quicksall 17-10-01 16:37 Please respond to Eddy Quicksall To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: IPS search engine Julian, I'm not sure if you are the right person for this request ... can you please forward if not. I would like someone to investigate a better search engine for http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html. For example, you can't search for a fixed string. If you search for "iSCSI: ISID issue summary" you get 2941 hits and none of them with 4 stars are the correct message. I have tried quoting, using + and using other gueses with no success on how to search for a fixed string. Eddy_Quicksall@iVivity.com From owner-ips@ece.cmu.edu Thu Oct 25 09:27: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 JAA18774 for ; Thu, 25 Oct 2001 09:27:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PCN8W17062 for ips-outgoing; Thu, 25 Oct 2001 08:23:08 -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 f9PCN5l17051 for ; Thu, 25 Oct 2001 08:23:05 -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 OAA87988 for ; Thu, 25 Oct 2001 14:22: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.97.1) with ESMTP id f9PCMwQ76890 for ; Thu, 25 Oct 2001 14:22:58 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI minimum PDU length X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Thu, 25 Oct 2001 15:22:50 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 25/10/2001 15:22:57, Serialize complete at 25/10/2001 15:22:57 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk We are attempting to make it a uniform limit for the DataSegment for all PDUs (Data, Login, Text, NOP etc.). Julo John Hufferd@IBMUS 25-10-01 11:35 To: Julian Satran/Haifa/IBM@IBMIL@IBMDE cc: ips@ece.cmu.edu From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: iSCSI minimum PDU length If you are only talking about Data PDUs, then at least I understand. . . . 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 ---------------------- Forwarded by John Hufferd/San Jose/IBM on 10/25/2001 02:34 AM --------------------------- Sent by: owner-ips@ece.cmu.edu To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI minimum PDU length Julian, Perhaps I do not understand what you are getting at here, but since there will be implementations with only R2T type Sessions, then there should be a lot of PDUs that just carry the Command (48 bytes + digest) it seems that a 1024 is kind of big. What am I missing? . . . 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 10/24/2001 10:34:38 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: iSCSI minimum PDU length With no votes against we have settled (again) on single PDU length (per connection, per direction) for all types of PDUs. But I think we erred on the low side by suggesting 64 as a minimum. It is low (it was mentioned) and bad for text request/response. How about settling for 1024? Julo From owner-ips@ece.cmu.edu Thu Oct 25 11:11: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 LAA21263 for ; Thu, 25 Oct 2001 11:11:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PE1xg23690 for ips-outgoing; Thu, 25 Oct 2001 10:01:59 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from imo-m01.mx.aol.com (imo-m01.mx.aol.com [64.12.136.4]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9PE1vl23685 for ; Thu, 25 Oct 2001 10:01:57 -0400 (EDT) Received: from Petedub@aol.com by imo-m01.mx.aol.com (mail_out_v31_r1.8.) id 3.b0.1c3de1d9 (15865) for ; Thu, 25 Oct 2001 10:01:50 -0400 (EDT) Received: from web29.aolmail.aol.com (web29.aolmail.aol.com [205.188.222.5]) by air-id06.mx.aol.com (v81.9) with ESMTP id MAILINID64-1025100150; Thu, 25 Oct 2001 10:01:50 -0400 Date: Thu, 25 Oct 2001 10:01:50 EDT From: Petedub@aol.com Subject: remove To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Message-ID: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit remove From owner-ips@ece.cmu.edu Thu Oct 25 11:11: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 LAA21274 for ; Thu, 25 Oct 2001 11:11:34 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PEOCR25537 for ips-outgoing; Thu, 25 Oct 2001 10:24:12 -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 f9PEOAl25527 for ; Thu, 25 Oct 2001 10:24:10 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Thu Oct 25 10:19:29 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 f9PENZl82123; Thu, 25 Oct 2001 10:23:35 -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 KAA11924; Thu, 25 Oct 2001 10:23:34 -0400 (EDT) Message-ID: <3BD82066.707EEBA@research.bell-labs.com> Date: Thu, 25 Oct 2001 10:23:34 -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 CC: bassoon@YOGI.PDL.CMU.EDU Subject: Re: IPS search engine References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eddy, Try Google. Its better at searching the archives though it could be behind by a month or more sometimes. If you add "site:www.ece.cmu.edu" within your search strings, Google will only match pages within that domain. See "Domain Restrict" on http://www.google.com/help/refinesearch.html -Sandeep Julian Satran wrote: > > Eddy, > > I am rarely using the archive. But I assume many would like digging into > it so I forward this to the list and to Dave Nagle > whom we all should be thankful for maintaining this list so patiently. > > Regards, > Julo > > Eddy Quicksall > 17-10-01 16:37 > Please respond to Eddy Quicksall > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: IPS search engine > > > > Julian, > > I'm not sure if you are the right person for this request ... can you > please forward if not. > > I would like someone to investigate a better search engine for http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html. For example, you can't search for a fixed string. If you search for > "iSCSI: ISID issue summary" you get 2941 hits and none of them with 4 > stars are the correct message. I have tried quoting, using + and using > other gueses with no success on how to search for a fixed string. > > Eddy_Quicksall@iVivity.com > From owner-ips@ece.cmu.edu Thu Oct 25 11:13: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 LAA21299 for ; Thu, 25 Oct 2001 11:13:17 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PE8eq24232 for ips-outgoing; Thu, 25 Oct 2001 10:08:40 -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 f9PE8cl24228 for ; Thu, 25 Oct 2001 10:08:38 -0400 (EDT) Received: from sahara (114.sanjose-05-10rs16rt.ca.dial-access.att.net [12.81.6.114]) by host32.cedant.com (8.10.2/8.10.2) with ESMTP id f9PE8DF16559; Thu, 25 Oct 2001 10:08:23 -0400 Message-ID: <200110250721060496.1349598B@opulentsystems.com> In-Reply-To: References: X-Mailer: Calypso Version 3.30.00.00 (4) Date: Thu, 25 Oct 2001 07:21:06 -0700 Reply-To: sganguly@opulentsystems.com From: "Sukanta Ganguly" To: somesh_gupta@silverbacksystems.com, "shesha bhushan" , "IPS" Subject: RE: Question 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 f9PE8cl24229 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Well TCP's congestion control will still be functional but the the iSCSI cannot make much use of it as it sits at a higher layer than TCP. What really is required is a congestion control within the iSCSI layer and run it over plain IP, that would be the most efficient way of doing it. I agree to that some amount of TCP like congestion control will be built into iSCSI but will be much less than the overheads of the TCP layer (their are multiple ways of achieving reliability and congestion avoidance on UDP), and also will make useful sense for the iSCSI layer. I don't know whether it is too late of not, cause I see many companies spending a huge amount of money doing TCP offloads. According to them iSCSI is going to benefit out of it. Yeah it make the un-optimal way of doing SCSI over IP a little more fast by having a dedicated processor, but is it the most optimal way of doing the work ???? I have nothing against TCP offload. but lets have a good iSCSI solution rather than patching up a unoptimal one. SG *********** REPLY SEPARATOR *********** On 10/24/2001 at 2:25 PM Somesh Gupta wrote: >The question is not crazy at all (the answer >might be :-)). New protocols are required (and >really should for everyone's benefit) implement >some congestion avoidance mechanism. > >Currently the easiest way to achieve this is to >use TCP. Unfortunately we do not depend enough >on it, leading to significant complexity >in the protocol. > >Somesh > >> -----Original Message----- >> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of >> shesha bhushan >> Sent: Wednesday, October 24, 2001 6:39 PM >> To: ips@ece.cmu.edu >> Subject: Question >> >> >> Hi, >> I am doing a research project at Arizona State University on SCSI and >> iSCSI. I was going through both the protocols. I have a crazy question. >> iSCSI = SCSI/(TCP/IP). But SCSI is a reliable protocol so is TCP. >> so can't >> we just try to send SCSI packets on IP or SCSI/UDP. Any & All >> comments are >> welcome. >> >> Thanks >> Shesha Bhushan S >> Research Assistant >> Arizona State University >> >> >> _________________________________________________________________ >> Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp >> >> From owner-ips@ece.cmu.edu Thu Oct 25 11:55: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 LAA22133 for ; Thu, 25 Oct 2001 11:55:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PEnQY27546 for ips-outgoing; Thu, 25 Oct 2001 10:49:26 -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 f9PB3ml12811 for ; Thu, 25 Oct 2001 07:03:48 -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 HAA13265; Thu, 25 Oct 2001 07:03:43 -0400 (EDT) Message-Id: <200110251103.HAA13265@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-security-04.txt Date: Thu, 25 Oct 2001 07:03:43 -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 : Securing iSCSI, iFCP and FCIP Author(s) : B. Aboba et al. Filename : draft-ietf-ips-security-04.txt Pages : 56 Date : 24-Oct-01 This document discusses how iSCSI, iFCP, and FCIP utilize IPsec to provide security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ips-security-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ips-security-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ips-security-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011024125231.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-security-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ips-security-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011024125231.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ips@ece.cmu.edu Thu Oct 25 12:15: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 MAA22687 for ; Thu, 25 Oct 2001 12:15:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PFZDm01062 for ips-outgoing; Thu, 25 Oct 2001 11:35:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9PFZBl01058 for ; Thu, 25 Oct 2001 11:35:11 -0400 (EDT) To: ips@ece.cmu.edu Subject: Re: iSCSI minimum PDU length In-Reply-To: Message from "Julian Satran" of "Thu, 25 Oct 2001 09:29:56 +0300." References: Date: Thu, 25 Oct 2001 11:33:27 -0400 From: Stephen Bailey Message-Id: <20011025153459.79C9C4E7A@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk > The minimum MSS is under 300 bytes. As I understand it, the minimum MSS is 8 bytes. Yes, this is a pathological case. What you really seem to be talking about here is the minimum allowable maximum PDU length, NOT, as the subject indicates, and JohnH points out, the true `minimum PDU length'. One number relevant to this discussion is the one below which you would not expect (or desire) good performance anyway. When MSS shrinks below this performance limit you may have to fall back to a slow path (e.g. reassembly & copying instead of on-the-fly direct placement) in your implementation, but you won't feel bad because you know there's no way performance could be good at that MSS under ANY circumstances. The minimum allowable maximum PDU length should be NO LARGER than this number. I personally think that you will want to maintain performance at an EMSS smaller than 1024. I agree with Dave that 512 is certainly headed in the right direction. Looking at it from the other direction, the minimum allowable maximum PDU could definitely be smaller than this performance target number. The lower limit is a result of the protocol design---what is the smallest limit larger than fixed sized PDUs which also allows variable sized PDUs to carry a minimum amount of data. There's no reason why the minimum allowable maximum PDU size could not be chosen to exactly fit the current iSCSI PDUs (or, within a power-of-two stones throw). Just because the protocol allows you to scale PDUs down to a minimum of xxx bytes and still operate does not mean that implementations won't chose a larger value for the limit of their performance design point. Implementations care about bounding the maximum PDU size. They must handle the smallest PDUs the protocol can create already anyway. In other words, nobody is going to say `ok, you mean I can make all the PDUs I send carry only 1 byte of data, GREAT! I'm going to do that'. Where you're headed, it really comes down to ensuring that all variably sized data can be chunked, which means you have to solve the chunking problem for text in one way or another. Steph From owner-ips@ece.cmu.edu Thu Oct 25 12:47: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 MAA23566 for ; Thu, 25 Oct 2001 12:47:36 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PFN5800125 for ips-outgoing; Thu, 25 Oct 2001 11:23: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 f9PFN2l00108 for ; Thu, 25 Oct 2001 11:23: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 IAA25101; Thu, 25 Oct 2001 08:22:23 -0700 (PDT) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id <4YWWAZA3>; Thu, 25 Oct 2001 08:22:22 -0700 Message-ID: <176B85B0D4E0D411BA5200508B692E0A2E60C1@hq-ex-1.brocade.com> From: Kha Sin Teow To: "'sganguly@opulentsystems.com'" , somesh_gupta@silverbacksystems.com, shesha bhushan , IPS Subject: RE: Question Date: Thu, 25 Oct 2001 08:22:22 -0700 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk Another important requirement of the SCSI "transport" layer is the "in-order delivery" which TCP provides. Otherwise, the new protocol needs to provide that capability above IP. Kha Sin/ From owner-ips@ece.cmu.edu Thu Oct 25 13:47: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 NAA25314 for ; Thu, 25 Oct 2001 13:47:25 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PGgZf06235 for ips-outgoing; Thu, 25 Oct 2001 12:42:35 -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 f9PGgYl06230 for ; Thu, 25 Oct 2001 12:42:34 -0400 (EDT) Received: from 66.122.195.194 (localhost [127.0.0.1]) by host32.cedant.com (8.10.2/8.10.2) with ESMTP id f9PGZnF11802; Thu, 25 Oct 2001 12:35:49 -0400 To: Kha Sin Teow From: Sukanta Ganguly Subject: RE: Question Reply-To: sganguly@opulentsystems.com CC: "'sganguly@opulentsystems.com'" , somesh_gupta@silverbacksystems.com, shesha bhushan , IPS Date: Thu, 25 Oct 2001 09:30:52 -0700 X-Sender: sganguly@opulentsystems.com X-Originating-Host: 66.122.195.194 [66.122.195.194]; Thu, 25 Oct 2001 16:35:49 GMT X-Mailer: WebMail Check v2.3.21 (2000-7-19) X-Browser: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0), JavaScript: On Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi, In a reliability protocol, the guarantee of packet delivery as well as the ordering of the packets and buffering , etc should be taken care of. I did not imply that IP would offer them. I am actually stating that it should be built in as a newer protocol which we could call "iSCSIReal" (I am not good with name -:)) SG At Thursday, 25 October 2001, Kha Sin Teow wrote: >Another important requirement of the SCSI "transport" layer is the >"in-order delivery" which TCP provides. >Otherwise, the new protocol needs to provide that capability >above IP. > >Kha Sin/ > From owner-ips@ece.cmu.edu Thu Oct 25 13: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 NAA25431 for ; Thu, 25 Oct 2001 13:49:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PGXa305596 for ips-outgoing; Thu, 25 Oct 2001 12:33:36 -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 f9PGXYl05590 for ; Thu, 25 Oct 2001 12:33:34 -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 A2FD13E51; Thu, 25 Oct 2001 10:33:33 -0600 (MDT) Received: from axcsbh4.cos.agilent.com (axcsbh4.cos.agilent.com [130.29.152.145]) by msgrel1.cos.agilent.com (Postfix) with SMTP id 51C1D612; Thu, 25 Oct 2001 10:33:33 -0600 (MDT) Received: from 130.29.152.145 by axcsbh4.cos.agilent.com (InterScan E-Mail VirusWall NT); Thu, 25 Oct 2001 10:33:33 -0600 Received: by axcsbh4.cos.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Oct 2001 10:33:32 -0600 Message-ID: <01A7DAF31F93D511AEE300D0B706ED920CF664@axcs13.cos.agilent.com> From: "CAVANNA,VICENTE V (A-Roseville,ex1)" To: "'Bill Strahm'" Cc: "SHEEHY,DAVE (A-Americas,unix1)" , "ALBERTSON,LYLE (A-PaloAlto,ex1)" , "CAVANNA,VICENTE V (A-Roseville,ex1)" , ips@ece.cmu.edu Subject: RE: trust security claims of incoming packets? Date: Thu, 25 Oct 2001 10:33:29 -0600 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, Thanks for the confirmation that the spec requires verification of policy. I too have come accross more than one vendor who does not lookup the policy after ESP processing - they assume that this double-checking is redundant since a check already occurred when the Security Association was established. I had been somewhat willing to accept that although I now think this is also a security hole. What I could not accept is not checking the policy at all when the packet arrives in the clear since in such a case there has been no prior check that the packet _should_ be in the clear. Vince |-----Original Message----- |From: Bill Strahm [mailto:bill@Sanera.net] |Sent: Wednesday, October 24, 2001 2:50 PM |To: CAVANNA,VICENTE V (A-Roseville,ex1); ips@ece.cmu.edu |Cc: SHEEHY,DAVE (A-Americas,unix1); ALBERTSON,LYLE (A-PaloAlto,ex1) |Subject: RE: trust security claims of incoming packets? | | |I can't vouch for other implelmentors, but the implementation |I worked on |checked... It is required in the specification. This |basically turned into |a single look into a hash table... not a huge overhead... some, but not |much, and we were able to get darned close to theoretical wire speed at |100Mbps full duplex... I know that some vendors did not check |after ESP |processing if the packet should have been covered by the |negotiated SA... |We didn't initially, we did in a second version that never |made it to market |(to my knowledge) | |I'd like to know what vendors you talk to that don't follow |the standard, I |can actually see many VPN vendors not doing this, because they |will turn |around and drop all clear packets anyway... | |Bill |+========+=========+=========+=========+=========+=========+=========+ |Bill Strahm Software Development is a race between Programmers |Member of the trying to build bigger and better idiot proof software |Technical Staff and the Universe trying to produce bigger and better |bill@sanera.net idiots. |(503) 601-0263 So far the Universe is winning --- Rich Cook | |-----Original Message----- |From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of |CAVANNA,VICENTE V (A-Roseville,ex1) |Sent: Wednesday, October 24, 2001 1:46 PM |To: 'ips@ece.cmu.edu' |Cc: CAVANNA,VICENTE V (A-Roseville,ex1); SHEEHY,DAVE |(A-Americas,unix1); |ALBERTSON,LYLE (A-PaloAlto,ex1) |Subject: trust security claims of incoming packets? | | |Most vendors of IPSec components that I have talked to do not verify, |against their local policy database, if an inbound packet has |claimed and |been afforded the security processing that the local policy |specifies. Doing |this verification may, of course, introduce a performance |bottleneck in the |processing of unsecured packets which would be undesireable, |as most users |would expect performance not to degrade unless secured packets |are being |processed. | |If a packet arrives demanding security processing (e.g. has an |ESP header) |then, after processing, the local policy is inspected to |confirm that the |appropriate processing was applied but if the packet arrives |unsecured all |security processing is bypassed, trusting instead that the |packet was indeed |meant to be insecure. | |This method of handling unsecured packets goes against my |interpretation of |the IPSec specs and seems to be a security hole. | |What point am I missing that will mitigate my concern? | |Thanks. | |Vicente Cavanna |Agilent Technologies | From owner-ips@ece.cmu.edu Thu Oct 25 13:50: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 NAA25465 for ; Thu, 25 Oct 2001 13:50:41 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PHLV409231 for ips-outgoing; Thu, 25 Oct 2001 13:21:32 -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 f9PHLTl09222 for ; Thu, 25 Oct 2001 13:21:29 -0400 (EDT) Received: from deneb.dev.equallogic.com (deneb.dev.equallogic.com [172.16.1.99]) by cygnus.equallogic.com (8.11.6/8.11.6) with ESMTP id f9PHLFM06038; Thu, 25 Oct 2001 13:21:15 -0400 Received: from pkoning.dev.equallogic.com.equallogic.com (localhost.localdomain [127.0.0.1]) by deneb.dev.equallogic.com (8.11.2/8.11.2) with SMTP id f9PHLFX26753; Thu, 25 Oct 2001 13:21:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15320.18958.603386.189666@pkoning.dev.equallogic.com> Date: Thu, 25 Oct 2001 13:21:18 -0400 (EDT) From: Paul Koning To: steph@cs.uchicago.edu Cc: ips@ece.cmu.edu Subject: Re: iSCSI minimum PDU length References: <20011025153459.79C9C4E7A@sandmail.sandburst.com> X-Mailer: VM 6.75 under 21.1 (patch 11) "Carlsbad Caverns" XEmacs Lucid Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> "Stephen" == Stephen Bailey writes: >> The minimum MSS is under 300 bytes. Stephen> ... Stephen> What you really seem to be talking about here is the minimum Stephen> allowable maximum PDU length, NOT, as the subject indicates, Stephen> and JohnH points out, the true `minimum PDU length'. Stephen> One number relevant to this discussion is the one below Stephen> which you would not expect (or desire) good performance Stephen> anyway. When MSS shrinks below this performance limit you Stephen> may have to fall back to a slow path (e.g. reassembly & Stephen> copying instead of on-the-fly direct placement) in your Stephen> implementation, but you won't feel bad because you know Stephen> there's no way performance could be good at that MSS under Stephen> ANY circumstances. Stephen> The minimum allowable maximum PDU length should be NO LARGER Stephen> than this number. Stephen> I personally think that you will want to maintain Stephen> performance at an EMSS smaller than 1024. I agree with Dave Stephen> that 512 is certainly headed in the right direction. Nice analysis. I don't see any need to maintain performance at MSS values that small. MTU values below 1480 are ancient history at this point, and sensible MSS values are surely not way below MTU. So, given the design center of what we're building, 1024 is the logical value. The one argument I can see for picking 512 is that it is the value that was in the spec before. paul From owner-ips@ece.cmu.edu Thu Oct 25 13:50: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 NAA25476 for ; Thu, 25 Oct 2001 13:50:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PHICq08915 for ips-outgoing; Thu, 25 Oct 2001 13:18:12 -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 f9PHIBl08909 for ; Thu, 25 Oct 2001 13:18:11 -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 NAA74216; Thu, 25 Oct 2001 13:15: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.98) with ESMTP id f9PHI80259482; Thu, 25 Oct 2001 11:18:08 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: Question To: sganguly@opulentsystems.com Cc: Kha Sin Teow , "'sganguly@opulentsystems.com'" , somesh_gupta@silverbacksystems.com, shesha bhushan , IPS X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 25 Oct 2001 10:17:11 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/25/2001 11:18:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I do not understand where you are going with the question here. But if you read the Draft Spec. you may find answers to many of your questions. . . . 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 Sukanta Ganguly @ece.cmu.edu on 10/25/2001 09:30:52 AM Please respond to sganguly@opulentsystems.com Sent by: owner-ips@ece.cmu.edu To: Kha Sin Teow cc: "'sganguly@opulentsystems.com'" , somesh_gupta@silverbacksystems.com, shesha bhushan , IPS Subject: RE: Question Hi, In a reliability protocol, the guarantee of packet delivery as well as the ordering of the packets and buffering , etc should be taken care of. I did not imply that IP would offer them. I am actually stating that it should be built in as a newer protocol which we could call "iSCSIReal" (I am not good with name -:)) SG At Thursday, 25 October 2001, Kha Sin Teow wrote: >Another important requirement of the SCSI "transport" layer is the >"in-order delivery" which TCP provides. >Otherwise, the new protocol needs to provide that capability >above IP. > >Kha Sin/ > From owner-ips@ece.cmu.edu Thu Oct 25 14:44: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 OAA27166 for ; Thu, 25 Oct 2001 14:44:50 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PHEEM08604 for ips-outgoing; Thu, 25 Oct 2001 13:14:14 -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 f9PHEBl08599 for ; Thu, 25 Oct 2001 13:14:11 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id B07F77B2 for ; Thu, 25 Oct 2001 10:14: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 KAA12904 for ; Thu, 25 Oct 2001 10:14:06 -0700 (PDT) Message-ID: <3BD84A41.73CDFE8E@cup.hp.com> Date: Thu, 25 Oct 2001 10:22:09 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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 - Change Proposal X bit 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 the clarification. I would suggest that the wording on this issue be made more explicit to indicate that commands MUST be re-issued on the same connection as the original command, unless the original command was successfully logged out. For example, in Section 8.1.1, in addition to the following wording : "When the X-bit is specified, the command PDU MUST carry the original Initiator Task Tag and the original operational attributes (ex. flags, function names, LUN, CDB etc.). In addition, it MUST hold the original CmdSN.", I suggest that it be explicitly called out in the above wording that the command MUST be sent on the same connection. Thanks, Santosh Julian Satran wrote: > > Santosh, > > The draft DOES NOT ALLOW commands to be reissued on another connection > without an intervening logout. > > Julo > > Santosh Rao > Sent by: santoshr@cup.hp.com > 25-10-01 01:44 > Please respond to Santosh Rao > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: Re: iSCSI - Change Proposal X bit > > > > Julian, > > The one scenario where I do see stale CmdSNs creating a problem is the > following : > > - 2 connections. > - CmdSN 3 issued on connection 1. > - Initiator does not get CmdSN ack for 1 and re-issues CmdSN 1 on > connection 2. > - CmdSN ack for 1 received on connection 2. All further I/O traffic on > connection 2 only (nothing on connection 1) and CmdSN sequence wraps > around. > - Finally, connection 1 clears up and CmdSN 1 is delivered on connection > 1. > > In the above situation, the stale CmdSN 1 is a problem. However, the > problem only occurs if the draft allows previously issued commands to be > re-issued on a different connection without first logging out the > previous connection. > > Why is it not possible to disallow commands to be re-issued on a > different connection unless the original connection used for that > command was first logged out successfully ? > > This would avoid this stale CmdSN on wrap around problem, as well as > avoid sporadic ULP timeout of I/Os due to race condition b/n initiator > re-issuing command on another connection and target sending CmdSN update > on the first connection. > > Thanks, > Santosh > > ps : I still don't see how your scenario below holds good. When the > target ack's CmdSNs upto 8 on connection 3, it has received all CmdSNs. > Hence, there can be no stalled commands on connection 2. However, a > different scenario which does cause a problem is the one I describe > above. > > Julian Satran wrote: > > > > Santosh, > > > > There is nothing in a command that arrives late on a link (as in the > > example in which it was sent redundantly) to distinguish it from a new > > (valid) command. > > > > This wraparound problem exists in all protocols - even in TCP, and we > use > > the CmdSN per session in the same fashion TCP uses sequence numbers per > > connection - and it is solved in different ways (TCP uses time-stamps). > > > > The NOP is meant to solve that wrap-around problem. > > > > I am sure that when rereading the example you will see the issue. > > > > Julo > > > > Santosh Rao > > Sent by: santoshr@cup.hp.com > > 24-10-01 18:29 > > Please respond to Santosh Rao > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI - Change Proposal X bit > > > > > > > > Julian, > > > > Some comments on the below quoted scenarios : > > > > > session has 3 connections > > > on connection 1 I->T c1,c2,c3,C6 > > > on connection 2 I->T c4,c5,c7,c8 > > > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > > > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 > and > > 6 > > > on connection 3 > > > target receives all and starts executing and acks 8 on connection 3 > > but > > > connection 2 stalls after c3 for a LONG TIME > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > delivers c4,c5 etc (that are now valid) > > > > When the target acks CmdSN 8 on connection 3, it has, in effect, sent > > CmdSN ack's for CMdSNs 3,4,5,6,7,8. This implies that the commands with > > CmdSN 3, 4, 5, 7, & 8 were received by the target on connection 2 and > > their processing was commenced. > > > > Hence, the following does not make sense : > > > > > connection 2 stalls after c3 for a LONG TIME > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > delivers c4,c5 etc (that are now valid) > > > > c4, c5, etc were already delivered to the target and are not being > > re-delivered. There is no problem in this case. (??). > > > > Take the next scenario : > > > 2 connections: > > > > > > connection1 I->T c3,c4,c5 > > > status of 3 contains ack up to 6 and it and all other statuses > are > > > lost > > > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > > > Since the initiator got CmdSN ack's upto 6, the initiator should not be > > re-issuing these I/Os ?? > > > > I still don't see justification to require that initiators send a > > immediate NOP-OUT in the manner being advocated. > > > > On a more fundamental note, I see some issues with the initiator being > > allowed to re-issue the commands on a different connection without > > having first logged out the previous connection successfully. I see > > nothing in the draft that suggests such behaviour, while at the same > > time, it is not forbidden. > > > > By resorting to command retries on a different connection in an attempt > > to plug the hole, without first logging out the previous connection, the > > initiator is susceptible to encountering I/O failure of that I/O due to > > ULP timeout. > > > > Here's the scenario why such recovery should not be allowed : > > - Initiator sends CmdSN 3 on connection 1. > > - No CmdSN updates for a while and initiator re-sends CmdSn 3 on > > connection 2. > > - At the same time, target has sent CmdSN ack's for CmdSN 3 on > > connection 1. > > > > - Initiator has transferred the command allegiance on its side from > > connection 1 to connection 2 and is attempting the command on connection > > 2. However, the command does not go through, since the (ExpCmdSN, > > MaxCmdSN) window has advanced and the trget discards the command. > > > > - Target sends in data and/or R2T and/or status for CmdSN 3 on > > connection 1. Since the initiator is not expecting any traffic for that > > I/O on connection 1, it discards any PDUs received on that connection 1 > > for which no I/O state existed. > > > > In the above scenario, initiator will never get a CmdSN ack on > > connection 2 and will never be able to plug the hole despite repeated > > retries, finally, causing a ULP timeout, followed by session recovery. > > > > Given the above scenario, I suggest that the initiator must only > > re-issue commands on the same connection, and can re-issue them on > > another connection only following a successful logout. > > > > Comments ? > > > > Thanks, > > Santosh > > > > Julian Satran wrote: > > > > > > Santosh, > > > > > > The scenarios I am talking about are all derivatives of an initiator > > trying > > > to plug-in holes and switching connections. > > > As the initiator does know the "extent" of a hole it can send-out > > commands > > > that he did not have to. > > > I have sent the attached not to Mallikarjun a while ago. I think > that > > > there might be many of this kind. I am also aware that X bit by > itself > > > might have some bad scenarios but the new proposal fixes them all. > > > > > > Julo > > > > > > _____________________________ > > > > > > Mallikarjun, > > > > > > Take the following sequence scenario: > > > > > > session has 3 connections > > > on connection 1 I->T c1,c2,c3,C6 > > > on connection 2 I->T c4,c5,c7,c8 > > > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > > > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 > and > > 6 > > > on connection 3 > > > target receives all and starts executing and acks 8 on connection 3 > > but > > > connection 2 stalls after c3 for a LONG TIME > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > delivers c4,c5 etc (that are now valid) > > > > > > That is not a very likely scenario, I admit, but it is possible. > > > With X bit I could not find any such scenario since an X either > follows > > a > > > good one on the same connection or can be safely discarded. > > > I suspect that there are some more scenarios that involve immediate > > > commands or commands that carry their own ack in the status and are > > acked > > > like: > > > > > > 2 connections: > > > > > > connection1 I->T c3,c4,c5 > > > status of 3 contains ack up to 6 and it and all other statuses > are > > > lost > > > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > > > > > I think we can avoid those be requiring a NOP exchange before > reissuing > > a > > > command on a new connection or reissue the command with a task > > management > > > (that has an implied ordering) but why do it if X is an obvious and > safe > > > solution. > > > > > > Julo > > > > > > Regards, > > > Julo > > > > > > > > > "Mallikarjun > > > C." To: Julian > > Satran/Haifa/IBM@IBMIL > > > > > om> Subject: Re: iscsi : X > bit > > in SCSI Command PDU. > > > > > > 08-10-01 21:45 > > > Please respond > > > to cbm > > > > > > > > > > > > Julian, > > > > > > We currently have the following specified in section 2.2.2.1 - > > > > > > "The target MUST NOT transmit a MaxCmdSN that is more than > > > 2**31 - 1 above the last ExpCmdSN." > > > > > > It appears to me that the above is sufficient to ward off the > > > accidents of the sort you describe. Do you think otherwise? > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > MS 5668 Hewlett-Packard, Roseville. > > > cbm@rose.hp.com > > > > > > Julian Satran wrote: > > > > > > > > Mallikarjun, > > > > > > > > There is at least one theoretical scenario in which an "old" command > > > > may appear in a "new window" and be reinstantiated. > > > > At 10Gbs and several connection that does not take months. With X > the > > > > probability is far lower (not 0). I have no other strong arguments > > > > but I am still thinking. Matt Wakeley that insisted on it (against > > > > me) had some other argument that I am trying to find (I am note > > > > remembering). > > > > > > > > Julo > > > > > > > > "Mallikarjun C." > > > > To: Julian > > > > Satran/Haifa/IBM@IBMIL > > > > 08-10-01 20:39 cc: > > > > Please respond to cbm Subject: Re: iscsi : X > > > > bit in SCSI Command PDU. > > > > > > > > > > > > > > > > Julian, > > > > > > > > Now that you put me on the spot, :-), my response - > > > > > > > > Santosh argued with me privately that X-bit no longer serves a > > > > useful purpose after the advent of task management commands to > > > > reassign. My response was that it never was a requirement per se, > > > > but always a "courtesy" extended by the initiator to help the > > > > target. I also suggested that X-bit may be considered for its > > > > usefulness in debugging. > > > > > > > > He still had some (very reasonable) comments for simplification > > > > - the most appealing of which (to me) was the opportunity to do > > > > away with the X-bit checking for *every* command PDU that the target > > > > has to endure now. > > > > > > > > If I missed a legitimate use of X-bit, please comment. Do you > > > > think it is a protocol requirement per se? I couldn't justify > > > > to myself so far (except the Login). > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions Organization > > > > MS 5668 Hewlett-Packard, Roseville. > > > > cbm@rose.hp.com > > > > > > > > > > > > > > > > Julian Satran wrote: > > > > > > > > > > Santosh, > > > > > > > > > > I am not sure you went through all scenarios. A conversation with > > > > your > > > > > colleague - Mallikarjun - and getting through the state table may > go > > > > a > > > > > long way to clarify the need for X. > > > > > > > > > > And I am sure that by now you found yourself several . > > > > > > > > > > Julo > > > > > > > > > > Santosh Rao > > > > > To: IPS Reflector > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > cc: > > > > > 06-10-01 01:56 Subject: iscsi : > X > > > > > Please respond to Santosh Rao bit in SCSI Command PDU. > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > With the elimination of command relay from iscsi [in the interests > > > > of > > > > > simplification ?], I believe that the X bit in the SCSI Command > PDU > > > > > can > > > > > also be removed. As it exists today, the X bit is only being used > > > > for > > > > > command restart, which is at attempt by the initiator to plug a > > > > > potential hole in the CmdSN sequence at the target. It does this > on > > > > > failing to get an ExpCmdSN ack for a previously sent command > within > > > > > some > > > > > timeout period. > > > > > > > > > > Given the above usage of command restart, no X bit is required to > be > > > > > set > > > > > in the SCSI Command PDU when command re-start is done. > > > > > > > > > > Either : > > > > > (a) the target had dropped the command earlier due to a digest > > > > error, > > > > > in > > > > > which case, the command restart plugs the CmdSN hole in the > target. > > > > > > > > > > [OR] > > > > > > > > > > (b) the target had received the command and was working on it, > when > > > > > the > > > > > initiator timed out too soon and attempted a command restart to > plug > > > > > [what it thought was] a possible hole in the CmdSN sequence. > > > > > > > > > > In case (a), no X bit was required, since the target knows nothing > > > > of > > > > > the original command. In case (b), no X bit is required again, > since > > > > > the > > > > > (ExpCmdSN, MaxCmdSN) window would have advanced and the target can > > > > > silently discard the received retry and continue working on the > > > > > original > > > > > command received. > > > > > > > > > > Removal of the X bit in the SCSI Command PDU has the following > > > > > benefits > > > > > : > > > > > > > > > > a) The CmdSN rules at the target are simplified. No need to look > at > > > > X > > > > > bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) > window. > > > > > > > > > > b) The reject reason code "command already in progress" can be > > > > > removed. > > > > > There's no need for this reject reason code anymore, since X bit > > > > > itself > > > > > is not required, and the targets can silently discard commands > > > > outside > > > > > the command window and continue to work on the original instance > of > > > > > the > > > > > command already being processed at the target. > > > > > > > > > > c) Less work for the target and less resources consumed since it > no > > > > > longer needs to generate a Reject PDU of type "command in > progress". > > > > > It > > > > > can just silently discard any command PDU outside the (ExpCmdSN, > > > > > MaxCmdSN) window. > > > > > > > > > > d) Less code for the target, since it does not need : > > > > > - any Reject code paths when it receives X bit command PDUs that > are > > > > > already in progress. > > > > > - No special casing of CmdSN checking rules. > > > > > - No overheads of verifying a received command based on its > > > > initiator > > > > > task tag, to check if the task is currently active, prior to > sending > > > > a > > > > > Reject response with "command in progress". > > > > > > > > > > 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 > > > > > ################################## > > > > > > > > > Santosh Rao > > > > > > > hp.com> cc: > > > Sent by: Subject: Re: iSCSI - > Change > > Proposal X bit > > > owner-ips@ece. > > > cmu.edu > > > > > > > > > 23-10-01 22:50 > > > Please respond > > > to Santosh Rao > > > > > > > > > > > > Julian Satran wrote: > > > > > > > > However in order to drop "old" commands that might in the pipe on a > > > > sluggish connection - removing the X bit will require the initiator > to > > > > issue an immediate NOP requiring a NOP response on every open > > connection > > > > whenever CmdSN wraps around (becomes equal to InitCmdSN). > > > > > > Julian, > > > > > > Can you please explain further the corner case you are describing > above > > > ? Are you suggesting that special action should be taken every time > > > CmdSN wraps around, in case there were holes in the CmdSN sequence at > > > the wrap time ? Why is that ? > > > > > > Here's my understanding of how this plays out : > > > > > > Rule 1) > > > The CmdSN management rules at the target should be handling CmdSN wrap > > > case and the initiator cannot issue more than 2^32 -1 commands beyond > > > the last ExpCmdSN update it has received from the target, since the > > > target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above > > > the last ExpCmdSN. (per Section 2.2.2.1) > > > > > > Rule 2) > > > Any holes that occur in the CmdSN sequence are attempted to be plugged > > > by the initiator by re-issuing the original command. If the CmdSN > never > > > got acknowledged and the I/O's ULP timeout expired, the initiator MUST > > > perform session recovery. (per Section 8.6) > > > > > > Thus, going by the above 2 rules, if the CmdSN sequence wraps upto > > > ExpCmdSN, the initiator will not be able to issue further commands, > > > since the target will keep the CmdSN window closed. The window can > only > > > re-open when the CmdSN holes are plugged allowing ExpCmdSN and > thereby, > > > MaxCmdSN to advance. (rule 1 above). > > > > > > Under the above circumstances, the initiator will possibly try to plug > > > the CmdSN hole by re-issuing the original command. It may do this 1 or > > > more times before its ULP timeout expires. Either the holes get > plugged > > > and the windoe re-opens, or ULP timeout occurs without the > corresponding > > > CmdSN for that I/O having been acknowledged, resulting in session > > > logout. (rule 2 above). > > > > > > What is required over and beyond the above ? Why does removal of X-bit > > > require an immediate NOP to be issued every time CmdSN wraps and a > hole > > > exists in the CmdSN sequence (??). > > > > > > Regards, > > > 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 Thu Oct 25 16:10: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 QAA29030 for ; Thu, 25 Oct 2001 16:10:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PItFU16331 for ips-outgoing; Thu, 25 Oct 2001 14:55:15 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from hotmail.com (f4.pav2.hotmail.com [64.4.37.4]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9PItDl16326 for ; Thu, 25 Oct 2001 14:55:13 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Oct 2001 11:55:07 -0700 Received: from 129.219.25.77 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 25 Oct 2001 18:55:06 GMT X-Originating-IP: [129.219.25.77] From: "shesha bhushan" To: sganguly@opulentsystems.com, somesh_gupta@silverbacksystems.com, ips@ece.cmu.edu Subject: RE: Question Date: Thu, 25 Oct 2001 18:55:06 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Oct 2001 18:55:07.0102 (UTC) FILETIME=[904C87E0:01C15D86] Sender: owner-ips@ece.cmu.edu Precedence: bulk If we assumme that we are transferring scsi packets over the local LAN where there is no congestion, can we actually send the packets only on IP ???? I have read thru the some doccuments. But i havent got a clear picture. can you also suggest me how to go about in this ????? Thanks Shesha Bhushan S Research Assistant Arizona State University >From: "Sukanta Ganguly" >Reply-To: sganguly@opulentsystems.com >To: somesh_gupta@silverbacksystems.com, "shesha bhushan" >, "IPS" >Subject: RE: Question >Date: Thu, 25 Oct 2001 07:21:06 -0700 > >Well TCP's congestion control will still be functional but the the iSCSI >cannot make much use of it as it sits at a higher layer than TCP. What >really is required is a congestion control within the iSCSI layer and run >it over plain IP, that would be the most efficient way of doing it. I agree >to that some amount of TCP like congestion control will be built into iSCSI >but will be much less than the overheads of the TCP layer (their are >multiple ways of achieving reliability and congestion avoidance on UDP), >and also will make useful sense for the iSCSI layer. > I don't know whether it is too late of not, cause I see many companies >spending a huge amount of money doing TCP offloads. According to them iSCSI >is going to benefit out of it. Yeah it make the un-optimal way of doing >SCSI over IP a little more fast by having a dedicated processor, but is it >the most optimal way of doing the work ???? > I have nothing against TCP offload. but lets have a good iSCSI solution >rather than patching up a unoptimal one. > >SG > > >*********** REPLY SEPARATOR *********** > >On 10/24/2001 at 2:25 PM Somesh Gupta wrote: > > >The question is not crazy at all (the answer > >might be :-)). New protocols are required (and > >really should for everyone's benefit) implement > >some congestion avoidance mechanism. > > > >Currently the easiest way to achieve this is to > >use TCP. Unfortunately we do not depend enough > >on it, leading to significant complexity > >in the protocol. > > > >Somesh > > > >> -----Original Message----- > >> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > >> shesha bhushan > >> Sent: Wednesday, October 24, 2001 6:39 PM > >> To: ips@ece.cmu.edu > >> Subject: Question > >> > >> > >> Hi, > >> I am doing a research project at Arizona State University on SCSI and > >> iSCSI. I was going through both the protocols. I have a crazy question. > >> iSCSI = SCSI/(TCP/IP). But SCSI is a reliable protocol so is TCP. > >> so can't > >> we just try to send SCSI packets on IP or SCSI/UDP. Any & All > >> comments are > >> welcome. > >> > >> Thanks > >> Shesha Bhushan S > >> Research Assistant > >> Arizona State University > >> > >> > >> _________________________________________________________________ > >> Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > >> > >> > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-ips@ece.cmu.edu Thu Oct 25 17:54: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 RAA00939 for ; Thu, 25 Oct 2001 17:54:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9PKlPQ25032 for ips-outgoing; Thu, 25 Oct 2001 16:47:25 -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 f9PKlNl25027 for ; Thu, 25 Oct 2001 16:47:24 -0400 (EDT) Received: from icarus.sanera.net (icarus [192.168.254.11]) by sentinel.sanera.net (8.11.2/8.11.2) with ESMTP id f9PKlHu16423; Thu, 25 Oct 2001 13:47:17 -0700 Received: from strahmw2k (dhcp-pc-100-165.sanera.net [192.168.100.165]) by icarus.sanera.net (8.11.6/8.11.2) with SMTP id f9PKlBB17569; Thu, 25 Oct 2001 13:47:11 -0700 From: "Bill Strahm" To: "shesha bhushan" , , , Subject: RE: Question Date: Thu, 25 Oct 2001 13:45: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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok, first question I guess, is why do you want to save 20 bytes in the face of the extra user level protocol complexity (to get in-order, reliability, etc.). Also it is a VERY carefully engineered LAN that doesn't have any congestion at any time. If you go through all of that effort, you might as well just deploy FC.. To answer your other question, just open a RAW socket, pick a random unused protocol number, and put the iSCSI packet into the IP data... Not hard to do, but don't expect it to go through firewalls, NAT, etc. and you will have to add something to the header to help address it (removing a few bytes from the 20 that you are saving, maybe 2 for a small implementation) Those that try to implement around TCP are doomed to re-implement it (usually poorly) Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of shesha bhushan Sent: Thursday, October 25, 2001 6:55 PM To: sganguly@opulentsystems.com; somesh_gupta@silverbacksystems.com; ips@ece.cmu.edu Subject: RE: Question If we assumme that we are transferring scsi packets over the local LAN where there is no congestion, can we actually send the packets only on IP ???? I have read thru the some doccuments. But i havent got a clear picture. can you also suggest me how to go about in this ????? Thanks Shesha Bhushan S Research Assistant Arizona State University >From: "Sukanta Ganguly" >Reply-To: sganguly@opulentsystems.com >To: somesh_gupta@silverbacksystems.com, "shesha bhushan" >, "IPS" >Subject: RE: Question >Date: Thu, 25 Oct 2001 07:21:06 -0700 > >Well TCP's congestion control will still be functional but the the iSCSI >cannot make much use of it as it sits at a higher layer than TCP. What >really is required is a congestion control within the iSCSI layer and run >it over plain IP, that would be the most efficient way of doing it. I agree >to that some amount of TCP like congestion control will be built into iSCSI >but will be much less than the overheads of the TCP layer (their are >multiple ways of achieving reliability and congestion avoidance on UDP), >and also will make useful sense for the iSCSI layer. > I don't know whether it is too late of not, cause I see many companies >spending a huge amount of money doing TCP offloads. According to them iSCSI >is going to benefit out of it. Yeah it make the un-optimal way of doing >SCSI over IP a little more fast by having a dedicated processor, but is it >the most optimal way of doing the work ???? > I have nothing against TCP offload. but lets have a good iSCSI solution >rather than patching up a unoptimal one. > >SG > > >*********** REPLY SEPARATOR *********** > >On 10/24/2001 at 2:25 PM Somesh Gupta wrote: > > >The question is not crazy at all (the answer > >might be :-)). New protocols are required (and > >really should for everyone's benefit) implement > >some congestion avoidance mechanism. > > > >Currently the easiest way to achieve this is to > >use TCP. Unfortunately we do not depend enough > >on it, leading to significant complexity > >in the protocol. > > > >Somesh > > > >> -----Original Message----- > >> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > >> shesha bhushan > >> Sent: Wednesday, October 24, 2001 6:39 PM > >> To: ips@ece.cmu.edu > >> Subject: Question > >> > >> > >> Hi, > >> I am doing a research project at Arizona State University on SCSI and > >> iSCSI. I was going through both the protocols. I have a crazy question. > >> iSCSI = SCSI/(TCP/IP). But SCSI is a reliable protocol so is TCP. > >> so can't > >> we just try to send SCSI packets on IP or SCSI/UDP. Any & All > >> comments are > >> welcome. > >> > >> Thanks > >> Shesha Bhushan S > >> Research Assistant > >> Arizona State University > >> > >> > >> _________________________________________________________________ > >> Get your FREE download of MSN Explorer at > >http://explorer.msn.com/intl.asp > >> > >> > > > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp From owner-ips@ece.cmu.edu Fri Oct 26 00:27: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 AAA08273 for ; Fri, 26 Oct 2001 00:27:15 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9Q3TtF22030 for ips-outgoing; Thu, 25 Oct 2001 23:29:55 -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 f9Q3Tql22019 for ; Thu, 25 Oct 2001 23:29:52 -0400 (EDT) Received: from ahganemw2k (sjc-vpn-tmp44.cisco.com [10.21.64.44]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id XAA01861 for ; Thu, 25 Oct 2001 23:29:45 -0400 (EDT) From: "Ayman Ghanem" To: Subject: iSCSI: NOPs on discovery session Date: Thu, 25 Oct 2001 22:29:00 -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, I am not sure if this came up before, but we also need to include NOP-OUT to the set of commands allowed on the discovery session. An initiator may keep the discovery session active, and send NOP-OUT to ping the target, or in response to a target ping. -Ayman From owner-ips@ece.cmu.edu Fri Oct 26 01:20: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 BAA09489 for ; Fri, 26 Oct 2001 01:20:06 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9Q4Ka125122 for ips-outgoing; Fri, 26 Oct 2001 00:20: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 f9Q4KYl25114 for ; Fri, 26 Oct 2001 00:20: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 AAA84980; Fri, 26 Oct 2001 00:18: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 f9Q4KW052202; Thu, 25 Oct 2001 22:20:32 -0600 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: NOPs on discovery session To: "Ayman Ghanem" Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Thu, 25 Oct 2001 21:19:37 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/25/2001 10:20:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Ayman, SendTargets is not that long of a process, if it times out, drop it and try again, or issue the SendTargets again. . . . 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 "Ayman Ghanem" @ece.cmu.edu on 10/25/2001 08:29:00 PM Sent by: owner-ips@ece.cmu.edu To: cc: Subject: iSCSI: NOPs on discovery session Julian, I am not sure if this came up before, but we also need to include NOP-OUT to the set of commands allowed on the discovery session. An initiator may keep the discovery session active, and send NOP-OUT to ping the target, or in response to a target ping. -Ayman From owner-ips@ece.cmu.edu Fri Oct 26 03:14: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 DAA24868 for ; Fri, 26 Oct 2001 03:14:24 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9Q6GBM01759 for ips-outgoing; Fri, 26 Oct 2001 02:16:11 -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 f9Q6G9l01753 for ; Fri, 26 Oct 2001 02:16:09 -0400 (EDT) Received: from COORS (coors.eurologic.com [192.168.7.111]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id HAA27042 for ; Fri, 26 Oct 2001 07:12:49 +0100 (BST) Message-ID: <04cb01c15de5$be3c2070$6f07a8c0@COORS> From: "Ron Cohen" To: "ips" References: Subject: Re: iSCSI: NOPs on discovery session Date: Fri, 26 Oct 2001 07:16:25 +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.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 This brings up an interesting point: Is it intended that discovery sessions remain open? Should an initiator close a discovery session after the SendTargets command has completed? Should a target request a logout and session closure if an initiator does not close the session? What would the application of leaving a discovery session open be? Ron ----- Original Message ----- From: "Ayman Ghanem" To: Sent: Friday, October 26, 2001 4:29 AM Subject: iSCSI: NOPs on discovery session > Julian, > > I am not sure if this came up before, but we also need to include NOP-OUT to > the set of commands allowed on the discovery session. An initiator may keep > the discovery session active, and send NOP-OUT to ping the target, or in > response to a target ping. > > -Ayman > > From owner-ips@ece.cmu.edu Fri Oct 26 05:36: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 FAA26119 for ; Fri, 26 Oct 2001 05:36:08 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9Q8cTM19862 for ips-outgoing; Fri, 26 Oct 2001 04:38: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 f9Q8cRl19857 for ; Fri, 26 Oct 2001 04:38: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 KAA25774 for ; Fri, 26 Oct 2001 10:38:20 +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 f9Q8cJW76824 for ; Fri, 26 Oct 2001 10:38:20 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: NOPs on discovery session X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Fri, 26 Oct 2001 11:38:17 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/10/2001 11:38:19, Serialize complete at 26/10/2001 11:38:19 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Ron, We are defining a wire protocol so that we should not be concerned if closing is mandatary or not. An open discovery session could be used (with proprietary exchanges) to announce new LUN and target creation. Julo "Ron Cohen" Sent by: owner-ips@ece.cmu.edu 26-10-01 08:16 Please respond to "Ron Cohen" To: "ips" cc: Subject: Re: iSCSI: NOPs on discovery session This brings up an interesting point: Is it intended that discovery sessions remain open? Should an initiator close a discovery session after the SendTargets command has completed? Should a target request a logout and session closure if an initiator does not close the session? What would the application of leaving a discovery session open be? Ron ----- Original Message ----- From: "Ayman Ghanem" To: Sent: Friday, October 26, 2001 4:29 AM Subject: iSCSI: NOPs on discovery session > Julian, > > I am not sure if this came up before, but we also need to include NOP-OUT to > the set of commands allowed on the discovery session. An initiator may keep > the discovery session active, and send NOP-OUT to ping the target, or in > response to a target ping. > > -Ayman > > From owner-ips@ece.cmu.edu Fri Oct 26 05: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 FAA26161 for ; Fri, 26 Oct 2001 05:42:20 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9Q8fkr20051 for ips-outgoing; Fri, 26 Oct 2001 04:41: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 f9Q8fjl20046 for ; Fri, 26 Oct 2001 04:41:45 -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 KAA20472 for ; Fri, 26 Oct 2001 10:41: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 f9Q8fbW158448 for ; Fri, 26 Oct 2001 10:41:37 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: NOPs on discovery session X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Fri, 26 Oct 2001 11:41:34 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/10/2001 11:41:37, Serialize complete at 26/10/2001 11:41:37 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk You are probably right. Messages could be used for new target discovery. Comments? Julo "Ayman Ghanem" Sent by: owner-ips@ece.cmu.edu 26-10-01 05:29 Please respond to "Ayman Ghanem" To: cc: Subject: iSCSI: NOPs on discovery session Julian, I am not sure if this came up before, but we also need to include NOP-OUT to the set of commands allowed on the discovery session. An initiator may keep the discovery session active, and send NOP-OUT to ping the target, or in response to a target ping. -Ayman From owner-ips@ece.cmu.edu Fri Oct 26 13:31: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 NAA12008 for ; Fri, 26 Oct 2001 13:31:04 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9QGLv717742 for ips-outgoing; Fri, 26 Oct 2001 12:21:57 -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 f9QGLtl17734 for ; Fri, 26 Oct 2001 12:21:55 -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 f9QGLrf14616 for ; Fri, 26 Oct 2001 12:21:53 -0400 (EDT) Content-Class: urn:content-classes:message Subject: FCIP: Minutes of FCIP author's call 10/24/01 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15E3A.52AE7325" Date: Fri, 26 Oct 2001 12:21:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <9410A0F67DFE7F4D998D45382364983617B264@nc8220exchange.ral.lucent.com> Thread-Topic: Minutes of FCIP author's call 10/24/01 Thread-Index: AcFc1NS+a+17QyyNQXiihb6bJX7LfABZJrzg From: "Elizabeth Rodriguez" To: "IPS Mailing List (E-mail)" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C15E3A.52AE7325 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Participating: Elizabeth Rodriguez, Milan Merhar (taking these notes,) Ralph Weber, Jim Nelson, Dave Peterson, Vi Chau, Raj B, Venkat Rangan , Bob Snively, Kha Sin Teow (from Brocade), Larry Lamberts, Ken Hirata =20 Comment on last draft - still unclear re handling of one TCP option. Will be reworded to clarify disabling Nagle "Telnet" handling. Kha Sin Teow from Brocade, Bill Krieg from Lucent asked to participate in conf call. Updating of current author's list to reflect actual participation may need to be reviewed. Side discussion on topic of Security Draft Questions: On Security draft: currently informative -- do such informative documents expire? No, they are RFCs. Are they reviewed, or do they express a consensus? Not subject to review by or consensus of working group. =20 Venkat - in the past when people have wanted to contribute, they could do so through the mailing list. This is not available to such private submissions. Ralph - Larry and Bob are well within their rights in stating they were unfairly excluded from participation in development of security document, which directly affects them. =20 Bob - there are basically three paths; either this is a standards track document, in which case all interested parties must be able to participate (e.g. by email.) Or, it's a proposed set of information recorded in each standard document, or it's informative information for reference only. The Security document as it stands is unacceptable for any of these three uses.=20 Proposed NAPT draft discussion=20 Discussion of NAPT draft Ralph distributed. Larry raised a concern regarding the statement that an ISL connecting R to W is different than an ISL connecting W to R. He believes we should have bidirectional messages, making those two connections identical. Ralph said this document does not use bidirectional messaging, so there is a need to handle the two unidirectional paths separately. Larry points out that until a short frame has been received, there is no way of knowing that a new TCP connection does or does not connect the same FC addresses as does a previous connection. Ralph - note that there is also a change at the end of this same paragraph, indicating that BB-2 now allows additional behavior beyond shutting down the connection. Larry - so, this is to be handled up at the fabric layer? I believe there is much more intelligence at the FCIP device (for connection management,) rather than being exclusively at the fabric level. The way this is written, you're precluding me from doing lots of things that I could use to create a reliable FCIP link using multiple TCP sessions. Bob - but, we don't want to create a command set at the link level. Larry - and I don't have to. Let the FCIP entity decide which connections can be incorporated into a link. Ralph - what happens if the information passed across that bidirectional link is inconsistent? =20 Should there be one or more than one link between FCIP devices? Ralph - that's something that changes as a result of NAPT. Bob - yes, the information that had to be provided to resolve NAPT now allows creation of multiple links, and multiple FCIP entities. If you have NAPTs, there is no way of knowing what the entity is via address; you connect to some address and well-known port, and then you need to exchange short-frame information, which carries FCIP world-wide name. Question - and you can't provide this world-wide name via another mechanism, such as manual configuration? Larry - yes, but I don't want to have to be sitting at the console whenever the connection comes in. Bob - the fundamental problem, is that I want this information to come from the FC-BB2 level, but Larry would prefer to have it happen at the FCIP level. To a first approximation, there would always be two connections made, from R to W and W to R, and then FC-BB2 would throw one away. Larry - when I ship a box out there won't be any fixed information, the WWN will probably be derived from the Eport name. I don't want to have to rely on manual configuration or the existence of SLP to make this work. Bob - but, you have absolutely no idea how these connections are to be combined. Larry - I will assign them to a virtual E-port, as the connections come in and identify themselves. =20 Bob - As I understand it, there have been some proposals floating around FC-SW for trunking of multiple E ports, which would have similar effects to what you're proposing. That's why I want to make the FCIP decision process as naive as possible, so we can take best advantage of it later in FC-BB2. Larry - but I don't see what that has to do with bidirectional messages. Bob - it makes it redundant. Ralph - the more it looks like a login, the greater the complexity, and the greater the risk of problems. Elizabeth - does it make any sense to make any of this optional - e.g. ability to make a query. Consensus is no. Do people think they have enough information to make a decision? Milan - as I don't participate in FC-BB2, I must admit that I see a protocol, but not a model for how that protocol is to be used, as I don't have access to the upper level documents where that is described. So, I'm going to have to abstain. =20 Bob - the question Elizabeth asks is do you need a bidirectional short frame, and the answer is 'no'. Larry - or, if you have SLP (and that provides WWN information,) you don't even need short frames. Ralph - you do need short frames to identify particular connections within the collection that makes up a link. Elizabeth - consensus we have sufficient information. Should we actually implement the bidirectional short frame? One vote "yes," three votes "no", out of fourteen some companies, nine of which are represented on this call. Should this go to the author's mailing list? Ralph suggests that won't fundamentally change the vote. Elizabeth agrees, and recommends that -08 draft of NAPT be posted to the reflector (as a separate item.) Suggests that a discussion period be requested ending around November 9th, so there is time to meet the final draft cutoff date. Ralph - this would give us a draft to be reviewed by the 14th, with a final submission shortly thereafter. Bob - and that would be ready for final call, excepting the security issues. Ralph - we could take those two paragraphs out, and leave it to the reader to figure it out whether you can or can not merge parallel connections. Elizabeth - yes, but would it be interoperable? Larry - not without the bidirectional short frame. Bob - bidirectional short frame is a red herring here, real question is whether you attempt to merge the connections or not. Ralph - and we're back to the same question again. Elizabeth - I'll ask the question again. Do we need those two paragraphs or not?=20 Larry - if those paragraphs go, the one paragraph further down (about handing an incoming connnection) needs to go too. Elizabeth - my perspective is that the two paragraphs should go. Bob - interoperability aside? Ralph - interoperability is at another level anyway. Raj - does this then say that the parallel connections represent the same link? Ralph - The wording to describe the effect remains, but the wording that describes the results of that effect would be eliminated. Elizabeth - Raj, do you think they should stay? Raj - I have no problem with this, but they will be in separate links. =20 Elizabeth - Since I hear no one on the call who believes the paragraphs should stay in, I recommend they be taken out. Raj - I have one question about the connection use flags. Do both ends have to agree on how many connections will be used? Larry - if your Class F connection goes down, are you not going to send Class F, or are you going to send it on another connection? I think you should make a new connection, but the way it's worded we have to wait for the other guy to make the connection, and you're sitting on Class F, or you're sending it mixed with Class 2 or Class 3 stuff and hoping the other guy can sort it out. Ralph - Raj's question is a routing question, and therefore has to be answered in BB. Bob - I would expect that the connection initiated for Class F would be used for Class F, and that no other connection would carry Class F because of ordering issues. What happens when the Class F connection goes down? What happens when any other connection goes down? Of course, if you're using something like the Virtual Channel stuff Larry was talking about for Class 4, you could use one of them for Class F. Ralph has submitted document to the email reflector. Next call will be hosted by Qlogic . =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C15E3A.52AE7325 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable NAPTs Solution r08
 

Participating:

Elizabeth Rodriguez, = Milan Merhar=20 (taking these notes,) Ralph Weber, Jim Nelson, Dave Peterson, Vi Chau, = Raj B,=20 Venkat  Rangan , Bob = Snively,=20 Kha Sin Teow (from Brocade), Larry Lamberts, Ken Hirata

 

Comment on last draft - = still unclear=20 re handling of one TCP option. Will be reworded to clarify disabling = Nagle=20 "Telnet" handling.

Kha Sin Teow  from Brocade, Bill = Krieg from Lucent asked to = participate in=20 conf call. Updating of current author's list to reflect actual = participation may=20 need to be reviewed.

Side = discussion on topic=20 of Security Draft

Questions:  On=20 Security draft: currently informative -- do such = informative=20 documents expire?  No, they are RFCs.  Are they reviewed, or = do they=20 express a consensus?   Not subject = to review=20 by or consensus of=20  working group. 

Venkat - in the past when people have wanted = to=20 contribute, they could do so through the mailing list.  This is not = available to such private submissions.   Ralph - Larry and Bob are well within their = rights in=20 stating they were unfairly excluded from participation in development of security  = document,=20 which directly affects them. 

Bob -=20 there are basically three paths; either this is a standards track = document, in=20 which case all interested parties must be able to participate (e.g. by=20 email.)  Or, it's a proposed set of information recorded in each = standard=20 document, or it's informative information for reference only.  The = Security=20 document as it stands is unacceptable for any of these three uses.=20

Proposed = NAPT draft=20 discussion 


Discussion of NAPT draft Ralph = distributed.  Larry=20 raised a concern regarding the statement that an ISL connecting R to W = is=20 different than an ISL connecting W to R.  He believes we should = have=20 bidirectional messages, making those two connections identical.  = Ralph said=20 this document does not use bidirectional messaging, so there is a need = to handle=20 the two unidirectional paths separately.  Larry points out that = until a=20 short frame has been received, there is no way of knowing that a new TCP = connection does or does not connect the same FC addresses as does a = previous=20 connection.

Ralph -=20 note that there is also a change at the end of this same paragraph, = indicating=20 that BB-2 now allows additional behavior beyond shutting down the=20 connection.  Larry - so, this is to be handled up at the fabric=20 layer?  I believe there is much more intelligence at the FCIP = device (for=20 connection management,) rather than being exclusively at the fabric = level. =20 The way this is written, you're precluding me from doing lots of things = that I=20 could use to create a reliable FCIP link using multiple TCP = sessions.  Bob=20 - but, we don't want to create a command set at the link level.  = Larry -=20 and I don't have to.  Let the FCIP entity decide which connections = can be=20 incorporated into a link.  Ralph - what happens if the = information=20 passed across that bidirectional link is inconsistent?  =

Should=20 there be one or more than one link between FCIP devices?  Ralph - = that's=20 something that changes as a result of NAPT.  Bob - yes, the = information=20 that had to be provided to resolve NAPT now allows creation of multiple = links,=20 and multiple FCIP entities.

If you=20 have NAPTs, there is no way of knowing what the entity is via address; = you=20 connect to some address and well-known port, and then you need to = exchange=20 short-frame information, which carries FCIP world-wide name.  = Question -=20 and you can't provide this world-wide name via another mechanism, such = as manual=20 configuration?  Larry - yes, but I don't want to have to be sitting = at the=20 console whenever the connection comes in.  Bob - the fundamental = problem,=20 is that I want this information to come from the FC-BB2 level, but Larry = would=20 prefer to have it happen at the FCIP level.  To a first = approximation,=20 there would always be two connections made, from R to W and W to R, and = then=20 FC-BB2 would throw one away.

Larry -=20 when I ship a box out there won't be any fixed information, the WWN will = probably be derived from the Eport name.  I don't want to have to = rely on=20 manual configuration or the existence of SLP to make this work.  = Bob - but,=20 you have absolutely no idea how these connections are to be = combined. =20 Larry - I will assign them to a virtual E-port, as the connections come = in and=20 identify themselves. 

Bob - As=20 I understand it, there have been some proposals floating around FC-SW = for=20 trunking of multiple E ports, which would have similar effects to what = you're=20 proposing.  That's why I want to make the FCIP decision process as = naive as=20 possible, so we can take best advantage of it later in FC-BB2.  = Larry - but=20 I don't see what that has to do with bidirectional messages.  Bob - = it=20 makes it redundant. Ralph - the more it looks like a login, the greater = the=20 complexity, and the greater the risk of problems.

Elizabeth - does it make any sense to make = any of this=20 optional - e.g. ability to make a query.  Consensus is = no.   Do=20 people think they have enough information to make a = decision?

Milan -=20 as I don't participate in FC-BB2, I must admit that I see a protocol, = but not a=20 model for how that protocol is to be used, as I don't have access to the = upper=20 level documents where that is described. So, I'm going to have to = abstain. =20

Bob - the question Elizabeth = asks is do=20 you need a bidirectional short frame, and the answer is 'no'.  = Larry - or,=20 if you have SLP (and that provides WWN information,) you don't even need = short=20 frames.  Ralph - you do need short frames to identify particular=20 connections within the collection that makes up a = link.

Elizabeth - consensus we have sufficient=20 information.  Should we actually implement the bidirectional short=20 frame?  One vote "yes," three votes "no", out of fourteen some = companies,=20 nine of which are represented on this call.  Should this go to the = author's=20 mailing list?  Ralph suggests that won't fundamentally change the=20 vote.  Elizabeth agrees, and recommends that -08 draft of NAPT be = posted to=20 the reflector (as a separate item.)  Suggests that a discussion = period be=20 requested ending around November 9th, so there is time to meet the final = draft=20 cutoff date.

Ralph -=20 this would give us a draft to be reviewed by the 14th, with a final = submission=20 shortly thereafter.  Bob - and that would be ready for final call,=20 excepting the security issues.

Ralph -=20 we could take those two paragraphs out, and leave it to the reader to = figure it=20 out whether you can or can not merge parallel connections.  = Elizabeth -=20 yes, but would it be interoperable?  Larry - not without the = bidirectional=20 short frame.  Bob - bidirectional short frame is a red herring = here, real=20 question is whether you attempt to merge the connections or not.  = Ralph -=20 and we're back to the same question again.

Elizabeth - I'll ask the question = again.  Do we=20 need those two paragraphs or not?

Larry -=20 if those paragraphs go, the one paragraph further down (about handing an = incoming connnection) needs to go too.  Elizabeth - my = perspective is=20 that the two paragraphs should go.  Bob - interoperability = aside? =20 Ralph - interoperability is at another level anyway.  Raj - does = this then=20 say that the parallel connections represent the same link?  Ralph - = The=20 wording to describe the effect remains, but the wording that describes = the=20 results of that effect would be eliminated. Elizabeth - Raj, do you = think they=20 should stay?  Raj - I have no problem with this, but they will be = in=20 separate links. 

Elizabeth - Since I hear no one on the call = who=20 believes the paragraphs should stay in, I recommend they be taken=20 out.

Raj - I=20 have one question about the connection use flags.  Do both ends = have to=20 agree on how many connections will be used?  Larry - if your Class = F=20 connection goes down, are you not going to send Class F, or are you = going to=20 send it on another connection?  I think you should make a new=20 connection, but the way it's worded we have to wait for the other guy to = make=20 the connection, and you're sitting on Class F, or you're sending it = mixed with=20 Class 2 or Class 3 stuff and hoping the other guy can sort it=20 out.

Ralph -=20 Raj's question is a routing question, and therefore has to be answered = in=20 BB.

Bob - I=20 would expect that the connection initiated for Class F would be used for = Class=20 F, and that no other connection would carry Class F because of ordering=20 issues.  What happens when the Class F connection goes down?  = What=20 happens when any other connection goes down? Of course, if you're using=20 something like the Virtual Channel stuff Larry was talking about for = Class 4,=20 you could use one of them for Class F.

Ralph=20 has submitted document to the email reflector.

Next=20 call will be hosted by Qlogic .

 

 

 

 

 

 

------_=_NextPart_001_01C15E3A.52AE7325-- From owner-ips@ece.cmu.edu Fri Oct 26 13:37: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 NAA12291 for ; Fri, 26 Oct 2001 13:37:43 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9QH2QX20840 for ips-outgoing; Fri, 26 Oct 2001 13:02:26 -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 f9QH2Pl20836 for ; Fri, 26 Oct 2001 13:02: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 MAA25714 for ; Fri, 26 Oct 2001 12:59:52 -0400 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9QH2EN101810 for ; Fri, 26 Oct 2001 11:02:14 -0600 Importance: Normal Subject: iSCSI: proposal to solve the ISID issues To: ips@ece.cmu.edu From: "Jim Hafner" Date: Fri, 26 Oct 2001 10:02:12 -0700 Message-ID: X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/26/2001 10:02:13 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Folks, (David Black in particular). Apologies for the long note, but the issue is complicated. The NDTeam have a proposal to resolve the concerns surrounding use of ISIDs as essential components (along with iSCSI Initiator Name) of SCSI Initiator Portname. (This was rooted in private discussions between John Hufferd, Julian and myself -- and came about as a result of the lengthy (and boring) discussions mostly myself and David Black.) There are two somewhat orthogonal issues involved in this discussion: 1) How to coordinate ISIDs in the initiator to minimize the risk of accidentally breaking the ISID RULE (no parallel nexus) when independent vendors co-exist in the same OS. 2) What ISID "reuse" rules should be specified to facilitate current and future (soon?) SCSI reservation semantics (and also internal OS views of SCSI Initiator Ports). To address these two issues, we (NDT) propose the following: 1) Enlarge the ISID field in the Login Request and Response to 6bytes and structure it with a component that corresponds to a "naming authority" (essentially the vendor generating the ISID). So vendors each have a piece of the ISID namespace to work with their own components (HBAs, SW, etc). More details below. 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used as conservatively as possible ("conservative reuse"). What this means is that a given ISID should be reused for as many sessions (across multiple target portal groups) as possible (but never to the same target portal group twice -- that's the ISID RULE). NOTES and ADVANTAGES: (1-a) Each vendor owns his own piece of the ISID namespace, so in effect, at the vendor-level, this provides a "partitioning" of that namespace. (1-b) We don't need to specify an OS infrastructure requirement for configuration of ISIDs -- each vendor can do it any way it chooses (within its naming authority). (1-c) Breaking of the ISID RULE will only occur if a vendor messes up its own implementation. (1-d) This is not fundamentally different from David Black's suggestion for a "key"; it just (a) defines it precisely and (b) embeds it in an already defined (but enlarged) field. (1-e) Looking towards the future, as common ISID coordination mechanisms are implemented between vendors (say, SNIA banding together to define a precise API), this "naming authority" can be elevated to the coordinating entity or even the OS vendor. (1-f) ISIDs have no global uniqueness property. They need only be unique between a named iSCSI initiator and iSCSI target portal group. That means that a vendor implementation can use the same algorithm to generate ISIDs (under its naming authority) in every machine (OS). (2-a) If a SCSI target (or logical unit) is holding state (say persistent reservation) for a SCSI Initiator Port (named by iSCSI Name and ISID), and the associated nexus/session is dropped for some reason, "reuse" by that initiator of that ISID will restore to the resulting new session that state (with no other action on the part of the upper SCSI layers). (2-b) "Reuse" of an ISID on different sessions to (necessarily) different SCSI Target Ports (iSCSI Target portal groups), will enable the SCSI target/logical unit to recognize a common SCSI Initiator Port for those two paths. This facilitates future changes to SCSI reservations (at least). (2-c) An initiator driver implementated with "conservative reuse" can present to the OS a stable and fairly static view of the SCSI Initiator Ports (one for each ISID). Current OS driver stacks (including current wedge drivers) that are built on the presumption of such a stable view, will not need modification to handle the more dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence of a SCSI Initiator Port presented to the OS does not *require* that this port discover all possible targets; what the initiator builds sessions to using a specific ISID will determine what is presented to the OS as "devices" and LUs visible to that SCSI Initiator Port (could be none if that ISID is never actually used!).] (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator Port is as simple as configuring another ISID! (2-e) Its debatable whether "conservative reuse" is a MUST or a SHOULD. My personal opinion is "SHOULD", because many systems, particularly low-end that don't use reservations, can function more or less OK without it. This is an open question. DETAILS: 1) ISID Structure: The 6byte ISID structure would be split into three parts: "type" field (1byte) -- identifies the format of the naming authority field "naming authority" field (3bytes) -- identifies the vendor (or group of vendors) generating this ISID "qualifier" (2bytes) -- the free-space for ISID uniqueness The type field takes on three defined values with all other values reserved: Type naming authority format 00h IEEE OUI 01h IANA Enterprise Number (EN) 02h "Random" The first types two provide a mechanism to uniquely (world wide) identify the naming authority. A vendor with one or more OUIs and possibly also Enterprise number MUST use at least one of these numbers when it generates ISIDs. The "Random" type is for the case where the ISID generator (SW or HW) is provided by an entity that has no OUI or EN. This includes, for example, -- a user-written program that builds sessions (and has access to the system level iSCSI Name) -- a university or other organization providing the component -- a testing tool For the "Random" type, the naming authority field should be a random or pseudo-random number. (See below on how this affects "conservative reuse"). [Note: the "type" field needn't be this big, but NDT felt that (a) 2bits was insufficient for the future, (b) the "type" field should be first, and (c) the "naming authority" field should be byte-aligned.] 2) Conservative Reuse The "conservative reuse" principle of this proposal just says that SCSI Initiator Portnames should be viewed as static things (as much as possible) and reused (when feasible) to give the most stable presentation of SCSI Initiator Ports to both the OS above and to SCSU targets across the wire. Whereas the current draft says "The ISID RULE does not preclude the use of the same ISID to different Target portal groups", the "conservative reuse" requirement would say that such reuse (using the same ISID to many target portal groups) is a SHOULD (or is that MUST?). So, in one implementation, each iSCSI Initiator Portal group would get configured with iSCSI Name, and a (small) set of ISIDs. The portal group might take this set of ISIDs as an ordered list. The first session to a Target portal group would use the first ISID, the second to the *same* target portal group would use the second in the list, etc. The number of ISIDs would then define a configuration parameter that can be interpreted as the maximum number of sessions that can be built to a given target portal group. To facilitate "conservative reuse", the "qualifier" field of a set of ISIDs SHOULD be generated using either a repeatable algorithm (non-random or pseudo-random but based on a fixed seed) or any algorithm and stored in a persistent location (e.g., registry or /etc file). For the "Random" type, "conservative reuse" may not be an issue (say, user application that doesn't care about reservations, etc.). When it is, the "naming authority" field SHOULD also be generated by a mechanism similar to that for the "qualifier" field as specified above (e.g., defined in the SW at compilation time.) DOCUMENTATING CHANGES: The iscsi drafts would need the following minor changes to support this proposal: NDT doc (a) define the structure of the ISID field (as described above) (b) add some notes about implementation in the presense of "conservative reuse" (e.g., that ISID should be configured once, say at install time, then reused on subsequent reboots, even for "Random" type). iSCSI MAIN doc: (a) move the CID field in Login Request to another reserved field. (b) expand the ISID field in Login Request and Response to encompass the previous 4 bytes. (c) add a sentence where the ISID field is defined indicating that this field is a structured value, showing the structure (as above) and point to the NDT document. (d) add some text to "Note to Implementors" on "conservative reuse". Comments? Jim Hafner From owner-ips@ece.cmu.edu Fri Oct 26 13:55: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 NAA13131 for ; Fri, 26 Oct 2001 13:55:22 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9QHDRM21644 for ips-outgoing; Fri, 26 Oct 2001 13:13:27 -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 f9QHDPl21640 for ; Fri, 26 Oct 2001 13:13:25 -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 TAA04232; Fri, 26 Oct 2001 19:13: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 f9QHDFW236654; Fri, 26 Oct 2001 19:13:16 +0200 Importance: Normal Subject: RE: iSCSI: Login authentication SRP/CHAP To: "Bill Strahm" Cc: "Joe Czap" , "IPS Reflector \(E-mail\)" , "John Hufferd" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Ofer Biran" Date: Fri, 26 Oct 2001 19:14:04 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/10/2001 20:13:18 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 f9QHDQl21641 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit Bill, > So based on your statement below have you warrented that IBM will make NO IP > claims on the usage of SRP in iSCSI ??? I'm not aware of any IBM claims on SRP, but I cannot make any such official statement for IBM. Do yo have any specific IBM patent in mind or you asked the above just because you answered ME, and I happen to work for IBM ? Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 "Bill Strahm" on 23/10/2001 17:32:51 Please respond to "Bill Strahm" To: Ofer Biran/Haifa/IBM@IBMIL cc: Joe Czap/Raleigh/IBM@IBMUS, "IPS Reflector \(E-mail\)" , John Hufferd/San Jose/IBM@IBMUS Subject: RE: iSCSI: Login authentication SRP/CHAP Brian, Arguing for situations where IPsec is not implemented/used is a Red Herring. If it is not implemented it is not an iSCSI implementation (remember MUST implement IPsec) therefor it does not have to be considered. If it is not used, then that is an administrative descision that is made based on the security requirements of the environment. My arguement is that CHAP is understood, code is available, it plugs into other authentication services (RADIUS/SecureID) that I am not sure how I would plug an SRP implementation into anyway, and I think that I HAVE to implement it... now SRP doesn't seem to be buying me anything except for "improved security" on a administratively secured link, doesn't seem like much. So based on your statement below have you warrented that IBM will make NO IP claims on the usage of SRP in iSCSI ??? Bill -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ofer Biran Sent: Tuesday, October 23, 2001 1:09 AM To: Bill Strahm Cc: Joe Czap; IPS Reflector (E-mail); John Hufferd Subject: RE: iSCSI: Login authentication SRP/CHAP 1. It's good news that the Stanford license fee is zero (I verified this - see attached note). 2. > Can you warrant that I will not have to use SRP-Z to implement any iSCSI > operations ? The SRP usage defined in iSCSI is EXACTLY according to RFC-2945. This usage is explicitly covered by the Stanford free license. SRP-Z involves additional private/public keys for the server, and you will not have to use that if you only want to follow the iSCSI standard. 3. If anyone has information about any other IP claiming on the RFC-2945 usage (SRP-SHA1) please post the full information here. 4. There is no question about the superior cryptographic features of SRP over CHAP. In situations where underlying IPsec will not be implemented/used (and these are forecasted), basing the iSCSI security on plain CHAP is a poor solution which IMHO the iSCSI standard should not encourage (by mandating CHAP instead of SRP). Regards, Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com 972-4-8296253 Kirsten Leute on 23/10/2001 00:18:00 Please respond to Kirsten Leute To: Ofer Biran/Haifa/IBM@IBMIL cc: Subject: Re: SRP Licensing terms Dear Ofer: Yes, this is correct.  For the type of usage described in the agreement, there are no licensing fees. As far as I know, there are no licensing issues from Stanford. Best, Kirsten At 06:58 PM 10/22/2001 +0300, you wrote: Kirsten, I'm working on the security aspects of the new iSCSI standard in the IPS working group of the IETF. Our intention is to define SRP (usage according to RFC2945) as the 'mandatory to implement' authentication algorithm. There were concerns in the working group about the licensing terms with Stanford. I looked in your "Ready-to-Sign Agreements" page and it seems to me that there are no fee involved in getting this license. I wanted to verify this with you. Also - are you aware of any other licensing issue with SRP   Thanks in advance,       Ofer Ofer Biran Storage and Systems Technology IBM Research Lab in Haifa biran@il.ibm.com  972-4-8296253 ************************************** Kirsten Leute Licensing Associate Office of Technology Licensing, Stanford University 900 Welch Road, Suite 350, Palo Alto, CA 94304 Direct: (650) 725-9407; Fax: (650) 725-7295 website: http://otl.stanford.edu/ "Bill Strahm" @ece.cmu.edu on 22/10/2001 18:58:06 Please respond to "Bill Strahm" Sent by: owner-ips@ece.cmu.edu To: Joe Czap/Raleigh/IBM@IBMUS cc: "IPS Reflector \(E-mail\)" , John Hufferd/San Jose/IBM@IBMUS, Subject: RE: iSCSI: Login authentication SRP/CHAP Directly from the Stanford license (http://otl.stanford.edu/pdf/97006.pdf) "Licensed Field of Use" means use of the Invention(s), Software and Licensed Patent(s) in Licensed Product(s) for implicit server authentication. By way of example, but not by limitation, RFC2945. The Licensed Field of Use specifically excludes use of the Invention(s), Software and Licensed Patent(s) machines and servers that deal with explicit bidirectional authentication (for example, SRP-Z for explicit server authentification). SOFTWARE may only be transferred under a Use Sublicense. Note that this applies only if Stanford is the only organization to own IP on this technology and there are no other patents in this field. Joe, can you warrant that IBM will make NO patent claims against this algorithm ? Can you warrant that I will not have to use SRP-Z to implement any iSCSI operations ? Again the problem isn't with the algorithm necissarily, but with the fact that it is the only MUST implement algorithm, I would rather see an algorithm with NO encumbrance against it... Bill +========+=========+=========+=========+=========+=========+=========+ Bill Strahm Software Development is a race between Programmers Member of the trying to build bigger and better idiot proof software Technical Staff and the Universe trying to produce bigger and better bill@sanera.net idiots. (503) 601-0263 So far the Universe is winning --- Rich Cook -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Joe Czap Sent: Monday, October 22, 2001 5:03 AM To: Bill Strahm Cc: IPS Reflector (E-mail); John Hufferd; owner-ips@ece.cmu.edu Subject: RE: iSCSI: Login authentication SRP/CHAP The lack of information relating to SRP IP concerns make the issue seem a little like misdirection. Can anyone offer a clear explanation the SRP IP situation ? Joe Czap IBM Storage Networking zapper@us.ibm.com From owner-ips@ece.cmu.edu Fri Oct 26 15: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 PAA17782 for ; Fri, 26 Oct 2001 15:57:19 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9QJQDk02207 for ips-outgoing; Fri, 26 Oct 2001 15:26:13 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from pop.mainstreet.net (smtp.mainstreet.net [207.5.0.46]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9QIvil29930 for ; Fri, 26 Oct 2001 14:57:45 -0400 (EDT) Received: from vip (saqibj.mainstreet.net [207.5.1.168]) by pop.mainstreet.net (8.11.3/8.11.3) with SMTP id f9QIsJP97776 for ; Fri, 26 Oct 2001 11:54:20 -0700 (PDT) Reply-To: From: "Saqib Jang" To: Subject: RE: I-D ACTION:draft-ietf-ips-security-04.txt Date: Fri, 26 Oct 2001 12:02:05 -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 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200110251103.HAA13265@ietf.org> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Have a couple of quick questions about the transport vs. tunnel mode; discussion in the firewall traversal section of the latest draft. The section reads: Firewall traversal. Where a storage protocol is to traverse administrative domains, the firewall administrator may desire to verify the integrity and authenticity of each transiting packet, rather than opening a hole in the firewall for the storage protocol. IPsec tunnel mode lends itself to such verification, since the firewall can terminate the tunnel mode connection while still allowing the endpoints to communicate end-to-end. If desired, the endpoints can in addition utilize IPsec transport mode for end- to-end security, so that they can also verify authenticity and integrity of each packet for themselves. My question is how important is the requirement for firewall adminstrators to "verify the integrity and authenticity of each transiting packet" if the iSCSI endpoints are using transport-mode IPsec/ESP (implying authentication and integrity checking) connections. Why would (in this case) opening a hole in the firewall to allow traversal of IPsec traffic not be sufficient? Also, are there potential latency issues that may arise if the firewall is terminating IPsec (vs. iSCSI end-points terminating IPsec). I see the emergence of IPsec acceleration in iSCSI end-points (vs. in general-purpose firewalls) to be a more like scenario. Saqib Saqib Jang Margalla Communications, Inc. 3301 El Camino Real, Suite 220 Atherton, CA 94027 Ph: 650 298 8462 Fax: 650 851 1613 From owner-ips@ece.cmu.edu Fri Oct 26 15:58: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 PAA17798 for ; Fri, 26 Oct 2001 15:58:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9QInTm29287 for ips-outgoing; Fri, 26 Oct 2001 14:49:29 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web14203.mail.yahoo.com (web14203.mail.yahoo.com [216.136.172.145]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f9QInSl29283 for ; Fri, 26 Oct 2001 14:49:28 -0400 (EDT) Message-ID: <20011026184927.50502.qmail@web14203.mail.yahoo.com> Received: from [216.217.36.162] by web14203.mail.yahoo.com via HTTP; Fri, 26 Oct 2001 11:49:27 PDT Date: Fri, 26 Oct 2001 11:49:27 -0700 (PDT) From: englin koay Subject: remove To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk remove __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-ips@ece.cmu.edu Fri Oct 26 17:02: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 RAA18992 for ; Fri, 26 Oct 2001 17:02:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9QKD8V06140 for ips-outgoing; Fri, 26 Oct 2001 16:13:08 -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 f9QKD7l06136 for ; Fri, 26 Oct 2001 16:13:07 -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 WAA11162 for ; Fri, 26 Oct 2001 22:13:00 +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 f9QKCxW158456 for ; Fri, 26 Oct 2001 22:13:00 +0200 Importance: High Subject: iSCSI - Change proposal Removing the X bit To: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Julian Satran" Date: Fri, 26 Oct 2001 23:07:24 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 26/10/2001 23:13:00 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Dear colleagues, We intend to publish very soon version 09 of the draft in its current format (not many changes) and postpone the editorial changes (already under way) for 10. One of the latest change proposal involves removing the X bit. The X bit has been used in several types of restart/replay but is somewhat made redundant by the removal of the command replay. This involves removing the X bit from request byte 0 and either making it reserved or "shifting left" the rest of the general-use bits (I and the direction bit). It also involves mandating a cleaning NOP. The cleaning NOP is needed in order to "flush out" old command PDU that can be left over by simple sequences like the one in the following scenario: 2 connections On connection 1 I->T c1,c2,c3 On connection 2 I->T c4,c5,c6 Targets receives everything and acts on commands but responses are sluggish and initiators sees only an ack for c1. It then retransmits c2, and c3 while there answer are in flight back after which the connection is almost dead and not used by initiator. After a complete wrap around, involving only connection 2, the target suddenly gets c2, c3 in a correct window and acts on them. The need to clean-up old PDUs is common to all protocols that use a sequence that wraps and we suggested cleaning up using a NOP. We will mandate a cleaning NOP only on connections that had at least one "retry". It looks like we might e able also to abandon the task management - reassign function and do it with a reissue (with the same NOP cleanout implication) since retiring the replay function makes the reassign unambiguous (reissuing a command, after logout, on a new connection - implies reassign). Please comment - I need your input urgently. Julo From owner-ips@ece.cmu.edu Fri Oct 26 17:05: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 RAA19058 for ; Fri, 26 Oct 2001 17:05:30 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9QKf2k08335 for ips-outgoing; Fri, 26 Oct 2001 16:41:02 -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 f9QKf0l08328 for ; Fri, 26 Oct 2001 16:41:00 -0400 (EDT) Received: from hqmailweb.COMMSTOR.Crossroads.com (HQMailWeb.Crossroads.com [63.237.99.250:25]) by va2mc.ummailbox.net with ESMTP id D1026-1640-3a0f07; Fri, 26 Oct 2001 20:40:56 GMT Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by hqmailweb.COMMSTOR.Crossroads.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 26 Oct 2001 15:40:46 -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: Question on Version-min of iSCSI v.08 Date: Fri, 26 Oct 2001 15:40:46 -0500 Message-ID: Thread-Topic: iSCSI SNW plugfest summary Thread-Index: AcFc3bX4LESVKKrSTcGsjcC50LCMZwADkiEAAAUYBLAABCjb0AAITBqgADyYpKAAAxAnoAALNZCQ From: "Lee Xing" To: X-OriginalArrivalTime: 26 Oct 2001 20:40:47.0149 (UTC) FILETIME=[7DACADD0:01C15E5E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ece.cmu.edu id f9QKf0l08329 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 8bit > v.08, p88 "The version number of the current draft is 0x2" > v.07, p69 "The version number of the current draft is 0x2" > v.06, p53 "The version number of the current draft is 0x1" > Why does v.08 use the same version number as v.07 does? > Thanks. > > > Lee > From owner-ips@ece.cmu.edu Fri Oct 26 18: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 SAA20277 for ; Fri, 26 Oct 2001 18:52:38 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9QLlPI12998 for ips-outgoing; Fri, 26 Oct 2001 17:47:25 -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 f9QLlOl12993 for ; Fri, 26 Oct 2001 17:47:24 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Oct 26 17:47:15 EDT 2001 Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id f9QLkak77110; Fri, 26 Oct 2001 17:46:36 -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 RAA02117; Fri, 26 Oct 2001 17:46:36 -0400 (EDT) Message-ID: <3BD9D9BC.C0DFE858@research.bell-labs.com> Date: Fri, 26 Oct 2001 17:46:36 -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 - Change proposal Removing the X bit 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 When would the initiator decide to issue the cleaning NOP ? Would this be done on a sequence wraparound ? My one concern is that this puts the onus of doing things correctly on the initiator, and the target susceptible to initiator bugs. Here's an alternate idea.. It seems that for this scenario to occur the following condition must also be valid : A target MUST have a positive (expStatSN-statSN) for connection c1 when it receives c2&c3 in a new window on the same connection c1 - since the status acks are pending in-order after the retried c2&c3. If this is correct.. then would the following condition detect a connection which has gone stale ? A target MUST NOT allow a new CmdSN which is 2^31-1 greater than the unacknowledged status PDU for the last cmdSN sent on all connections. This would involve maintaining an additional counter per connection. (e.g. Connection->cmdSN_of_last_unacknowledged_statSN) In other words, if connection C1 sent status PDU for (c3) which has not yet been acked thru expStatSN, then the target will not allow a new command (Cn) which is 2^31-1 greater than c3. This must hold for all connections. This ensures that sequence wraparound does not cause old commands to reappear. Either the connection is closed or the target issues a NOP-IN which flushes that connection. If this is true, there is no need to issue the cleaning NOP since the target ensures that stale connections dont exist. Note that currently, we have a very loose requirement Sec 2.2.2.2 "A large difference between StatSN and ExpStatSN may indicate a failed connection." If we can strengthen this condition, we can ensure that the target as well as the initiator detect the sequence wrap-around without relying on one end too much. Comments ? -Sandeep Julian Satran wrote: > > Dear colleagues, > > We intend to publish very soon version 09 of the draft in its current > format (not many changes) and postpone the editorial changes (already under > way) for 10. > > One of the latest change proposal involves removing the X bit. > > The X bit has been used in several types of restart/replay but is somewhat > made redundant by the removal > of the command replay. > > This involves removing the X bit from request byte 0 and either making it > reserved or "shifting left" the rest of the general-use bits (I and the > direction bit). > > It also involves mandating a cleaning NOP. > > The cleaning NOP is needed in order to "flush out" old command PDU that can > be left over by simple sequences like the one in the following scenario: > > 2 connections > > On connection 1 I->T c1,c2,c3 > On connection 2 I->T c4,c5,c6 > > Targets receives everything and acts on commands but responses are sluggish > and initiators sees only an ack for > c1. It then retransmits c2, and c3 while there answer are in flight back > after which the connection is almost dead and not used by initiator. > > After a complete wrap around, involving only connection 2, the target > suddenly gets c2, c3 in a correct window and acts on them. > > The need to clean-up old PDUs is common to all protocols that use a > sequence that wraps and we suggested cleaning up using a NOP. We will > mandate a cleaning NOP only on connections that had at least one "retry". > > It looks like we might e able also to abandon the task management - > reassign function and do it with a reissue (with the same NOP cleanout > implication) since retiring the replay function makes the reassign > unambiguous (reissuing a command, after logout, on a new connection - > implies reassign). > > Please comment - I need your input urgently. > > Julo From owner-ips@ece.cmu.edu Fri Oct 26 19:29: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 TAA20506 for ; Fri, 26 Oct 2001 19:29:33 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9QMcHG16441 for ips-outgoing; Fri, 26 Oct 2001 18:38:17 -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 f9QMcFl16436 for ; Fri, 26 Oct 2001 18:38:15 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 238921F613 for ; Fri, 26 Oct 2001 18:35:40 -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 PAA17919 for ; Fri, 26 Oct 2001 15:39:31 -0700 (PDT) Message-Id: <200110262239.PAA17919@core.rose.hp.com> Date: Fri, 26 Oct 2001 15:50:10 -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 - Change Proposal X bit Content-Type: multipart/mixed; boundary="------------19BEE9CC345A46C821A6AE01" Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. --------------19BEE9CC345A46C821A6AE01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here's a private email I sent to Julian on this topic, FYI. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com --------------19BEE9CC345A46C821A6AE01 Content-Type: message/rfc822 Content-Disposition: inline Date: Thu, 25 Oct 2001 12:50:51 -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: Julian Satran Subject: Re: iSCSI - Change Proposal X bit References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian, We need to call out that all (X-bit) retries should go out on the same connection, and I will make that explicit in the error recovery section. In effect, the "connection allegiance" should exist once the first copy of a command is sent. In helping others walk through your scenario here in HP, we all realized that the core solution to the problem is to mandate a complete execution of a numbered command (some I/O activity that is trackable) on each connection once at least every (2^32 -1) commands. It may be a NOP, or any regular command. So, here is my suggestion - An initiator MUST send at least one non-immediate command on each of the connections participating in the session, for every (2^31 -1) numbered commands. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > Santosh, > > The draft DOES NOT ALLOW commands to be reissued on another connection > without an intervening logout. > > Julo > > Santosh Rao > Sent by: santoshr@cup.hp.com > 25-10-01 01:44 > Please respond to Santosh Rao > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: Re: iSCSI - Change Proposal X bit > > > > Julian, > > The one scenario where I do see stale CmdSNs creating a problem is the > following : > > - 2 connections. > - CmdSN 3 issued on connection 1. > - Initiator does not get CmdSN ack for 1 and re-issues CmdSN 1 on > connection 2. > - CmdSN ack for 1 received on connection 2. All further I/O traffic on > connection 2 only (nothing on connection 1) and CmdSN sequence wraps > around. > - Finally, connection 1 clears up and CmdSN 1 is delivered on connection > 1. > > In the above situation, the stale CmdSN 1 is a problem. However, the > problem only occurs if the draft allows previously issued commands to be > re-issued on a different connection without first logging out the > previous connection. > > Why is it not possible to disallow commands to be re-issued on a > different connection unless the original connection used for that > command was first logged out successfully ? > > This would avoid this stale CmdSN on wrap around problem, as well as > avoid sporadic ULP timeout of I/Os due to race condition b/n initiator > re-issuing command on another connection and target sending CmdSN update > on the first connection. > > Thanks, > Santosh > > ps : I still don't see how your scenario below holds good. When the > target ack's CmdSNs upto 8 on connection 3, it has received all CmdSNs. > Hence, there can be no stalled commands on connection 2. However, a > different scenario which does cause a problem is the one I describe > above. > > Julian Satran wrote: > > > > Santosh, > > > > There is nothing in a command that arrives late on a link (as in the > > example in which it was sent redundantly) to distinguish it from a new > > (valid) command. > > > > This wraparound problem exists in all protocols - even in TCP, and we > use > > the CmdSN per session in the same fashion TCP uses sequence numbers per > > connection - and it is solved in different ways (TCP uses time-stamps). > > > > The NOP is meant to solve that wrap-around problem. > > > > I am sure that when rereading the example you will see the issue. > > > > Julo > > > > Santosh Rao > > Sent by: santoshr@cup.hp.com > > 24-10-01 18:29 > > Please respond to Santosh Rao > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI - Change Proposal X bit > > > > > > > > Julian, > > > > Some comments on the below quoted scenarios : > > > > > session has 3 connections > > > on connection 1 I->T c1,c2,c3,C6 > > > on connection 2 I->T c4,c5,c7,c8 > > > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > > > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 > and > > 6 > > > on connection 3 > > > target receives all and starts executing and acks 8 on connection 3 > > but > > > connection 2 stalls after c3 for a LONG TIME > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > delivers c4,c5 etc (that are now valid) > > > > When the target acks CmdSN 8 on connection 3, it has, in effect, sent > > CmdSN ack's for CMdSNs 3,4,5,6,7,8. This implies that the commands with > > CmdSN 3, 4, 5, 7, & 8 were received by the target on connection 2 and > > their processing was commenced. > > > > Hence, the following does not make sense : > > > > > connection 2 stalls after c3 for a LONG TIME > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > delivers c4,c5 etc (that are now valid) > > > > c4, c5, etc were already delivered to the target and are not being > > re-delivered. There is no problem in this case. (??). > > > > Take the next scenario : > > > 2 connections: > > > > > > connection1 I->T c3,c4,c5 > > > status of 3 contains ack up to 6 and it and all other statuses > are > > > lost > > > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > > > Since the initiator got CmdSN ack's upto 6, the initiator should not be > > re-issuing these I/Os ?? > > > > I still don't see justification to require that initiators send a > > immediate NOP-OUT in the manner being advocated. > > > > On a more fundamental note, I see some issues with the initiator being > > allowed to re-issue the commands on a different connection without > > having first logged out the previous connection successfully. I see > > nothing in the draft that suggests such behaviour, while at the same > > time, it is not forbidden. > > > > By resorting to command retries on a different connection in an attempt > > to plug the hole, without first logging out the previous connection, the > > initiator is susceptible to encountering I/O failure of that I/O due to > > ULP timeout. > > > > Here's the scenario why such recovery should not be allowed : > > - Initiator sends CmdSN 3 on connection 1. > > - No CmdSN updates for a while and initiator re-sends CmdSn 3 on > > connection 2. > > - At the same time, target has sent CmdSN ack's for CmdSN 3 on > > connection 1. > > > > - Initiator has transferred the command allegiance on its side from > > connection 1 to connection 2 and is attempting the command on connection > > 2. However, the command does not go through, since the (ExpCmdSN, > > MaxCmdSN) window has advanced and the trget discards the command. > > > > - Target sends in data and/or R2T and/or status for CmdSN 3 on > > connection 1. Since the initiator is not expecting any traffic for that > > I/O on connection 1, it discards any PDUs received on that connection 1 > > for which no I/O state existed. > > > > In the above scenario, initiator will never get a CmdSN ack on > > connection 2 and will never be able to plug the hole despite repeated > > retries, finally, causing a ULP timeout, followed by session recovery. > > > > Given the above scenario, I suggest that the initiator must only > > re-issue commands on the same connection, and can re-issue them on > > another connection only following a successful logout. > > > > Comments ? > > > > Thanks, > > Santosh > > > > Julian Satran wrote: > > > > > > Santosh, > > > > > > The scenarios I am talking about are all derivatives of an initiator > > trying > > > to plug-in holes and switching connections. > > > As the initiator does know the "extent" of a hole it can send-out > > commands > > > that he did not have to. > > > I have sent the attached not to Mallikarjun a while ago. I think > that > > > there might be many of this kind. I am also aware that X bit by > itself > > > might have some bad scenarios but the new proposal fixes them all. > > > > > > Julo > > > > > > _____________________________ > > > > > > Mallikarjun, > > > > > > Take the following sequence scenario: > > > > > > session has 3 connections > > > on connection 1 I->T c1,c2,c3,C6 > > > on connection 2 I->T c4,c5,c7,c8 > > > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > > > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 > and > > 6 > > > on connection 3 > > > target receives all and starts executing and acks 8 on connection 3 > > but > > > connection 2 stalls after c3 for a LONG TIME > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > delivers c4,c5 etc (that are now valid) > > > > > > That is not a very likely scenario, I admit, but it is possible. > > > With X bit I could not find any such scenario since an X either > follows > > a > > > good one on the same connection or can be safely discarded. > > > I suspect that there are some more scenarios that involve immediate > > > commands or commands that carry their own ack in the status and are > > acked > > > like: > > > > > > 2 connections: > > > > > > connection1 I->T c3,c4,c5 > > > status of 3 contains ack up to 6 and it and all other statuses > are > > > lost > > > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > > > > > I think we can avoid those be requiring a NOP exchange before > reissuing > > a > > > command on a new connection or reissue the command with a task > > management > > > (that has an implied ordering) but why do it if X is an obvious and > safe > > > solution. > > > > > > Julo > > > > > > Regards, > > > Julo > > > > > > > > > "Mallikarjun > > > C." To: Julian > > Satran/Haifa/IBM@IBMIL > > > > > om> Subject: Re: iscsi : X > bit > > in SCSI Command PDU. > > > > > > 08-10-01 21:45 > > > Please respond > > > to cbm > > > > > > > > > > > > Julian, > > > > > > We currently have the following specified in section 2.2.2.1 - > > > > > > "The target MUST NOT transmit a MaxCmdSN that is more than > > > 2**31 - 1 above the last ExpCmdSN." > > > > > > It appears to me that the above is sufficient to ward off the > > > accidents of the sort you describe. Do you think otherwise? > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > MS 5668 Hewlett-Packard, Roseville. > > > cbm@rose.hp.com > > > > > > Julian Satran wrote: > > > > > > > > Mallikarjun, > > > > > > > > There is at least one theoretical scenario in which an "old" command > > > > may appear in a "new window" and be reinstantiated. > > > > At 10Gbs and several connection that does not take months. With X > the > > > > probability is far lower (not 0). I have no other strong arguments > > > > but I am still thinking. Matt Wakeley that insisted on it (against > > > > me) had some other argument that I am trying to find (I am note > > > > remembering). > > > > > > > > Julo > > > > > > > > "Mallikarjun C." > > > > To: Julian > > > > Satran/Haifa/IBM@IBMIL > > > > 08-10-01 20:39 cc: > > > > Please respond to cbm Subject: Re: iscsi : X > > > > bit in SCSI Command PDU. > > > > > > > > > > > > > > > > Julian, > > > > > > > > Now that you put me on the spot, :-), my response - > > > > > > > > Santosh argued with me privately that X-bit no longer serves a > > > > useful purpose after the advent of task management commands to > > > > reassign. My response was that it never was a requirement per se, > > > > but always a "courtesy" extended by the initiator to help the > > > > target. I also suggested that X-bit may be considered for its > > > > usefulness in debugging. > > > > > > > > He still had some (very reasonable) comments for simplification > > > > - the most appealing of which (to me) was the opportunity to do > > > > away with the X-bit checking for *every* command PDU that the target > > > > has to endure now. > > > > > > > > If I missed a legitimate use of X-bit, please comment. Do you > > > > think it is a protocol requirement per se? I couldn't justify > > > > to myself so far (except the Login). > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions Organization > > > > MS 5668 Hewlett-Packard, Roseville. > > > > cbm@rose.hp.com > > > > > > > > > > > > > > > > Julian Satran wrote: > > > > > > > > > > Santosh, > > > > > > > > > > I am not sure you went through all scenarios. A conversation with > > > > your > > > > > colleague - Mallikarjun - and getting through the state table may > go > > > > a > > > > > long way to clarify the need for X. > > > > > > > > > > And I am sure that by now you found yourself several . > > > > > > > > > > Julo > > > > > > > > > > Santosh Rao > > > > > To: IPS Reflector > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > cc: > > > > > 06-10-01 01:56 Subject: iscsi : > X > > > > > Please respond to Santosh Rao bit in SCSI Command PDU. > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > With the elimination of command relay from iscsi [in the interests > > > > of > > > > > simplification ?], I believe that the X bit in the SCSI Command > PDU > > > > > can > > > > > also be removed. As it exists today, the X bit is only being used > > > > for > > > > > command restart, which is at attempt by the initiator to plug a > > > > > potential hole in the CmdSN sequence at the target. It does this > on > > > > > failing to get an ExpCmdSN ack for a previously sent command > within > > > > > some > > > > > timeout period. > > > > > > > > > > Given the above usage of command restart, no X bit is required to > be > > > > > set > > > > > in the SCSI Command PDU when command re-start is done. > > > > > > > > > > Either : > > > > > (a) the target had dropped the command earlier due to a digest > > > > error, > > > > > in > > > > > which case, the command restart plugs the CmdSN hole in the > target. > > > > > > > > > > [OR] > > > > > > > > > > (b) the target had received the command and was working on it, > when > > > > > the > > > > > initiator timed out too soon and attempted a command restart to > plug > > > > > [what it thought was] a possible hole in the CmdSN sequence. > > > > > > > > > > In case (a), no X bit was required, since the target knows nothing > > > > of > > > > > the original command. In case (b), no X bit is required again, > since > > > > > the > > > > > (ExpCmdSN, MaxCmdSN) window would have advanced and the target can > > > > > silently discard the received retry and continue working on the > > > > > original > > > > > command received. > > > > > > > > > > Removal of the X bit in the SCSI Command PDU has the following > > > > > benefits > > > > > : > > > > > > > > > > a) The CmdSN rules at the target are simplified. No need to look > at > > > > X > > > > > bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) > window. > > > > > > > > > > b) The reject reason code "command already in progress" can be > > > > > removed. > > > > > There's no need for this reject reason code anymore, since X bit > > > > > itself > > > > > is not required, and the targets can silently discard commands > > > > outside > > > > > the command window and continue to work on the original instance > of > > > > > the > > > > > command already being processed at the target. > > > > > > > > > > c) Less work for the target and less resources consumed since it > no > > > > > longer needs to generate a Reject PDU of type "command in > progress". > > > > > It > > > > > can just silently discard any command PDU outside the (ExpCmdSN, > > > > > MaxCmdSN) window. > > > > > > > > > > d) Less code for the target, since it does not need : > > > > > - any Reject code paths when it receives X bit command PDUs that > are > > > > > already in progress. > > > > > - No special casing of CmdSN checking rules. > > > > > - No overheads of verifying a received command based on its > > > > initiator > > > > > task tag, to check if the task is currently active, prior to > sending > > > > a > > > > > Reject response with "command in progress". > > > > > > > > > > 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 > > > > > ################################## > > > > > > > > > Santosh Rao > > > > > > > hp.com> cc: > > > Sent by: Subject: Re: iSCSI - > Change > > Proposal X bit > > > owner-ips@ece. > > > cmu.edu > > > > > > > > > 23-10-01 22:50 > > > Please respond > > > to Santosh Rao > > > > > > > > > > > > Julian Satran wrote: > > > > > > > > However in order to drop "old" commands that might in the pipe on a > > > > sluggish connection - removing the X bit will require the initiator > to > > > > issue an immediate NOP requiring a NOP response on every open > > connection > > > > whenever CmdSN wraps around (becomes equal to InitCmdSN). > > > > > > Julian, > > > > > > Can you please explain further the corner case you are describing > above > > > ? Are you suggesting that special action should be taken every time > > > CmdSN wraps around, in case there were holes in the CmdSN sequence at > > > the wrap time ? Why is that ? > > > > > > Here's my understanding of how this plays out : > > > > > > Rule 1) > > > The CmdSN management rules at the target should be handling CmdSN wrap > > > case and the initiator cannot issue more than 2^32 -1 commands beyond > > > the last ExpCmdSN update it has received from the target, since the > > > target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above > > > the last ExpCmdSN. (per Section 2.2.2.1) > > > > > > Rule 2) > > > Any holes that occur in the CmdSN sequence are attempted to be plugged > > > by the initiator by re-issuing the original command. If the CmdSN > never > > > got acknowledged and the I/O's ULP timeout expired, the initiator MUST > > > perform session recovery. (per Section 8.6) > > > > > > Thus, going by the above 2 rules, if the CmdSN sequence wraps upto > > > ExpCmdSN, the initiator will not be able to issue further commands, > > > since the target will keep the CmdSN window closed. The window can > only > > > re-open when the CmdSN holes are plugged allowing ExpCmdSN and > thereby, > > > MaxCmdSN to advance. (rule 1 above). > > > > > > Under the above circumstances, the initiator will possibly try to plug > > > the CmdSN hole by re-issuing the original command. It may do this 1 or > > > more times before its ULP timeout expires. Either the holes get > plugged > > > and the windoe re-opens, or ULP timeout occurs without the > corresponding > > > CmdSN for that I/O having been acknowledged, resulting in session > > > logout. (rule 2 above). > > > > > > What is required over and beyond the above ? Why does removal of X-bit > > > require an immediate NOP to be issued every time CmdSN wraps and a > hole > > > exists in the CmdSN sequence (??). > > > > > > Regards, > > > Santosh > > -- > ################################## > Santosh Rao > Software Design Engineer, > HP-UX iSCSI Driver Team, > Hewlett Packard, Cupertino. > email : santoshr@cup.hp.com > Phone : 408-447-3751 > ################################## --------------19BEE9CC345A46C821A6AE01-- From owner-ips@ece.cmu.edu Sat Oct 27 02:55: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 CAA09860 for ; Sat, 27 Oct 2001 02:55:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9QNX7Q19727 for ips-outgoing; Fri, 26 Oct 2001 19:33:07 -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 f9QNX6l19723 for ; Fri, 26 Oct 2001 19:33:06 -0400 (EDT) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id TAA06158; Fri, 26 Oct 2001 19:33:04 -0400 (EDT) Date: Fri, 26 Oct 2001 19:33:04 -0400 From: "Robert D. Russell" To: Julian Satran cc: ips@ece.cmu.edu Subject: Re: iSCSI - Change proposal Removing the X bit 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 vote for making the X bit reserved and leaving the I bit and direction bits unchanged and unshifted. This will cause the least disruption to everything developed so far, in our case, a lot of our testing software. There seems to be no urgent need to "shift" the these other bits, and there may be some future use for the unused X bit. Thanks, Bob Russell On Fri, 26 Oct 2001, Julian Satran wrote: > Dear colleagues, > > We intend to publish very soon version 09 of the draft in its current > format (not many changes) and postpone the editorial changes (already under > way) for 10. > > One of the latest change proposal involves removing the X bit. > > The X bit has been used in several types of restart/replay but is somewhat > made redundant by the removal > of the command replay. > > This involves removing the X bit from request byte 0 and either making it > reserved or "shifting left" the rest of the general-use bits (I and the > direction bit). > > It also involves mandating a cleaning NOP. > > The cleaning NOP is needed in order to "flush out" old command PDU that can > be left over by simple sequences like the one in the following scenario: > > 2 connections > > On connection 1 I->T c1,c2,c3 > On connection 2 I->T c4,c5,c6 > > Targets receives everything and acts on commands but responses are sluggish > and initiators sees only an ack for > c1. It then retransmits c2, and c3 while there answer are in flight back > after which the connection is almost dead and not used by initiator. > > After a complete wrap around, involving only connection 2, the target > suddenly gets c2, c3 in a correct window and acts on them. > > The need to clean-up old PDUs is common to all protocols that use a > sequence that wraps and we suggested cleaning up using a NOP. We will > mandate a cleaning NOP only on connections that had at least one "retry". > > It looks like we might e able also to abandon the task management - > reassign function and do it with a reissue (with the same NOP cleanout > implication) since retiring the replay function makes the reassign > unambiguous (reissuing a command, after logout, on a new connection - > implies reassign). > > Please comment - I need your input urgently. > > Julo > > > From owner-ips@ece.cmu.edu Sat Oct 27 04:00: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 EAA10870 for ; Sat, 27 Oct 2001 04:00:51 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9R1ACT24834 for ips-outgoing; Fri, 26 Oct 2001 21:10:12 -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 f9R1ABl24830 for ; Fri, 26 Oct 2001 21:10:11 -0400 (EDT) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by crufty; Fri Oct 26 21:04:16 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 f9R18Ol37261; Fri, 26 Oct 2001 21:08:24 -0400 (EDT) Received: (from sandeepj@localhost) by aura.research.bell-labs.com (8.9.1/8.9.1) id VAA09228; Fri, 26 Oct 2001 21:08:16 -0400 (EDT) Date: Fri, 26 Oct 2001 21:08:16 -0400 (EDT) Message-Id: <200110270108.VAA09228@aura.research.bell-labs.com> From: sandeepj@research.bell-labs.com (Sandeep Joshi) To: cbm@rose.hp.com, ips@ece.cmu.edu Subject: Re: iSCSI - Change Proposal X bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, This problem can be solved _without_ introducing any additional I/O activity. Notice that it occurs because we allow the maxCmdSN to increase unbounded in the presence of unacked statSNs. The target can prevent this from happening. Imagine some connection A at the target : (1) Everytime the target sends a new statSN out, it records the cmdSN for that statSN (say Connection_A.cmdSN_of_last_statSN = 200) (2) While growing maxCmdSN at target, ensure that (maxCmdSN - Connection_A.cmdSN_of_last_statSN < 2^31-1) This is stricter than current condition (maxCmdSN - expCmdSN) < 2^31-1 If there are N connections, use least value of cmdSN_of_last_statSN. (3) All retried commands will always fall outside the window. They will be on the "dark side". (4) If the target cant grow maxCmdSN, it closes the offending connection, or sends out NOPs. Works ..? -Sandeep > In helping others walk through your scenario here in HP, > we all realized that the core solution to the problem > is to mandate a complete execution of a numbered command > (some I/O activity that is trackable) on each connection > once at least every (2^32 -1) commands. It may be a NOP, > or any regular command. So, here is my suggestion - > > An initiator MUST send at least one non-immediate command > on each of the connections participating in the session, > for every (2^31 -1) numbered commands. > > Comments? > -- > Mallikarjun From owner-ips@ece.cmu.edu Sat Oct 27 04:00: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 EAA10889 for ; Sat, 27 Oct 2001 04:00:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9R1FTf25166 for ips-outgoing; Fri, 26 Oct 2001 21:15:29 -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 f9R1FRl25161 for ; Fri, 26 Oct 2001 21:15:28 -0400 (EDT) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id 10E799BA for ; Fri, 26 Oct 2001 17:13: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 RAA06563 for ; Fri, 26 Oct 2001 17:13:26 -0700 (PDT) Message-ID: <3BD9FE0D.8A36A70B@cup.hp.com> Date: Fri, 26 Oct 2001 17:21:33 -0700 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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 - Change proposal Removing the X bit 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, In response to your below proposed changes : 1) I am in favor of your proposal to remove task re-assign and simply re-issue the command on a new connection. 2) Regarding the removal of X bit, I suggest that the bit be made reserved and the position of the I bit and opcode be retained as is. Thanks, Santosh Julian Satran wrote: > > Dear colleagues, > > We intend to publish very soon version 09 of the draft in its current > format (not many changes) and postpone the editorial changes (already under > way) for 10. > > One of the latest change proposal involves removing the X bit. > > The X bit has been used in several types of restart/replay but is somewhat > made redundant by the removal > of the command replay. > > This involves removing the X bit from request byte 0 and either making it > reserved or "shifting left" the rest of the general-use bits (I and the > direction bit). > > It also involves mandating a cleaning NOP. > > The cleaning NOP is needed in order to "flush out" old command PDU that can > be left over by simple sequences like the one in the following scenario: > > 2 connections > > On connection 1 I->T c1,c2,c3 > On connection 2 I->T c4,c5,c6 > > Targets receives everything and acts on commands but responses are sluggish > and initiators sees only an ack for > c1. It then retransmits c2, and c3 while there answer are in flight back > after which the connection is almost dead and not used by initiator. > > After a complete wrap around, involving only connection 2, the target > suddenly gets c2, c3 in a correct window and acts on them. > > The need to clean-up old PDUs is common to all protocols that use a > sequence that wraps and we suggested cleaning up using a NOP. We will > mandate a cleaning NOP only on connections that had at least one "retry". > > It looks like we might e able also to abandon the task management - > reassign function and do it with a reissue (with the same NOP cleanout > implication) since retiring the replay function makes the reassign > unambiguous (reissuing a command, after logout, on a new connection - > implies reassign). > > Please comment - I need your input urgently. > > 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 Sat Oct 27 04:01: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 EAA10917 for ; Sat, 27 Oct 2001 04:01:31 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9QN5UO18104 for ips-outgoing; Fri, 26 Oct 2001 19:05:30 -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 f9QN5Sl18100 for ; Fri, 26 Oct 2001 19:05:28 -0400 (EDT) Received: by esply02.cnt.com with Internet Mail Service (5.5.2653.19) id <4R3P5Y04>; Fri, 26 Oct 2001 18:05:23 -0500 Message-ID: <3C7122FAF06DD5118ED600500473364826313F@esply01.cnt.com> From: Michael Schoberg To: "IPS Reflector (E-mail)" Subject: RE: iSCSI: proposal to solve the ISID issues Date: Fri, 26 Oct 2001 18:02:00 -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 don't want to pour gas on this. I know a lot has gone into resolving this issue, and at one point I thought I understood it. After all the online debate I'm convinced I must be missing something. At this point I'm not even sure why SSID is useful. ISID // iSCSI initiator defined session ID + TSID // iSCSI target defined session ID ---- SSID // iSCSI Session ID == I_T NEXUS Is SSID used to establish an I_T nexus? But iSCSI uses login authentication to identify the initiator (InitiatorName=) & target (TargetName=). What extra information is being gained through SSID? [Login] InitiatorName=MyInitiator TargetName=YourTarget NexusID=controller_1 SSID use in LOGIN: 1) An unknown initiator sends an iSCSI login request to an iSCSI target address/port. 2) The target gathers the ISID, TSID, CID, X-Bit fields from the login request. This tells who the initiator is and what it's requesting. The target takes in all of this is with a grain of salt, because it's not yet sure the initiator is who it says it is. 3) Mutual security authentication takes place between the target and initiator. This may be as simple as "AuthMode=none", but in any case InitiatorName= and TargetName= have been stated and authenticated to the satisfaction of both. 4) The target looks back at ISID/TSID/CID/X-bits passed in the first login. Now it must decide whether or not it can continue or drop the connection. On TSID: How can a target determine this value such that each I_T nexus can be reformed consistently? The target must assign a TSID value each unique I_T nexus it can identify. It could use this new unique 6-byte ISID field, but an initiator could still masquerade as someone else: Controller A & B have valid logins to target X. Controller B knows controller A's ISID. Controller B specifies controller A's ISID in login. Controller B uses its InitiatorName= to pass authentication. Unless X knows the valid ISID values for login A/B, it will assign A's SSID to B. This mistake can be avoided by using (TSID ~> InitiatorName). Each InitiatorName= allowed by the target is assigned a unique TID. Taking over someone's SSID now becomes a pure administration issue not a fault in the protocol. On ISID: It's configured by the initiator. Whether it be a 16-bit or 48-bit value, the idea is to allow each vendor multiple controller instances (I of I_T nexus) if desired. This value is expected to be assigned and permanent with each I_T (portal group) nexus. So why does iSCSI use two methods of identification? InitiatorName/TargetName requires super encryption algorithms for verification while ISID/TSID uses cleartext with the motto, "we trust you'll play nice." Why does iSCSI need SSID to describe the session at all? Why not roll it into the authentication parameters? Wrapping ISIDs into a new naming authority seems excessive for a local issue (SSIDs are local to each target)? Or is there a future iSCSI going to make SSIDs unique so they can be inherited along iSCSI networks? : -----Original Message----- : From: Jim Hafner [mailto:hafner@almaden.ibm.com] : Sent: Friday, October 26, 2001 12:02 PM : To: ips@ece.cmu.edu : Subject: iSCSI: proposal to solve the ISID issues : : : Folks, (David Black in particular). : : Apologies for the long note, but the issue is complicated. : : The NDTeam have a proposal to resolve the concerns surrounding use of : ISIDs as essential components (along with iSCSI Initiator Name) of : SCSI Initiator Portname. (This was rooted in private discussions : between John Hufferd, Julian and myself -- and came about as a result : of the lengthy (and boring) discussions mostly myself and David : Black.) : : There are two somewhat orthogonal issues involved in this discussion: : : 1) How to coordinate ISIDs in the initiator to minimize the risk of : accidentally breaking the ISID RULE (no parallel nexus) when : independent vendors co-exist in the same OS. : : 2) What ISID "reuse" rules should be specified to facilitate current : and future (soon?) SCSI reservation semantics (and also internal OS : views of SCSI Initiator Ports). : : To address these two issues, we (NDT) propose the following: : : 1) Enlarge the ISID field in the Login Request and Response to 6bytes : and structure it with a component that corresponds to a "naming : authority" (essentially the vendor generating the ISID). So vendors : each have a piece of the ISID namespace to work with their own : components (HBAs, SW, etc). More details below. : : 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used as : conservatively as possible ("conservative reuse"). What this means is : that a given ISID should be reused for as many sessions (across : multiple target portal groups) as possible (but never to the same : target portal group twice -- that's the ISID RULE). : : NOTES and ADVANTAGES: : : (1-a) Each vendor owns his own piece of the ISID namespace, so in : effect, at the vendor-level, this provides a "partitioning" of that : namespace. : : (1-b) We don't need to specify an OS infrastructure requirement for : configuration of ISIDs -- each vendor can do it any way it chooses : (within its naming authority). : : (1-c) Breaking of the ISID RULE will only occur if a vendor messes up : its own implementation. : : (1-d) This is not fundamentally different from David Black's : suggestion for a "key"; it just (a) defines it precisely and (b) : embeds it in an already defined (but enlarged) field. : : (1-e) Looking towards the future, as common ISID coordination : mechanisms are implemented between vendors (say, SNIA banding together : to define a precise API), this "naming authority" can be elevated to : the coordinating entity or even the OS vendor. : : (1-f) ISIDs have no global uniqueness property. They need only be : unique between a named iSCSI initiator and iSCSI target portal group. : That means that a vendor implementation can use the same algorithm to : generate ISIDs (under its naming authority) in every machine (OS). : : (2-a) If a SCSI target (or logical unit) is holding state (say : persistent reservation) for a SCSI Initiator Port (named by iSCSI Name : and ISID), and the associated nexus/session is dropped for some : reason, "reuse" by that initiator of that ISID will restore to the : resulting new session that state (with no other action on the part of : the upper SCSI layers). : : (2-b) "Reuse" of an ISID on different sessions to (necessarily) : different SCSI Target Ports (iSCSI Target portal groups), will enable : the SCSI target/logical unit to recognize a common SCSI Initiator Port : for those two paths. This facilitates future changes to SCSI : reservations (at least). : : (2-c) An initiator driver implementated with "conservative reuse" can : present to the OS a stable and fairly static view of the SCSI : Initiator Ports (one for each ISID). Current OS driver stacks : (including current wedge drivers) that are built on the presumption of : such a stable view, will not need modification to handle the more : dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence of : a SCSI Initiator Port presented to the OS does not *require* that this : port discover all possible targets; what the initiator builds sessions : to using a specific ISID will determine what is presented to the OS as : "devices" and LUs visible to that SCSI Initiator Port (could be none : if that ISID is never actually used!).] : : (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator : Port is as simple as configuring another ISID! : : (2-e) Its debatable whether "conservative reuse" is a MUST or a : SHOULD. My personal opinion is "SHOULD", because many systems, : particularly low-end that don't use reservations, can function more or : less OK without it. This is an open question. : : DETAILS: : : 1) ISID Structure: : The 6byte ISID structure would be split into three parts: : "type" field (1byte) -- identifies the format of the naming : authority field : "naming authority" field (3bytes) -- identifies the vendor (or : group of vendors) generating this ISID : "qualifier" (2bytes) -- the free-space for ISID uniqueness : : The type field takes on three defined values with all other values : reserved: : Type naming authority format : 00h IEEE OUI : 01h IANA Enterprise Number (EN) : 02h "Random" : : The first types two provide a mechanism to uniquely (world wide) : identify the naming authority. A vendor with one or more OUIs and : possibly also Enterprise number MUST use at least one of these numbers : when it generates ISIDs. : : The "Random" type is for the case where the ISID generator (SW or HW) : is provided by an entity that has no OUI or EN. This includes, for : example, : -- a user-written program that builds sessions (and has access to the : system level iSCSI Name) : -- a university or other organization providing the component : -- a testing tool : : For the "Random" type, the naming authority field should be a random : or pseudo-random number. (See below on how this affects "conservative : reuse"). : : [Note: the "type" field needn't be this big, but NDT felt that (a) : 2bits was insufficient for the future, (b) the "type" field should be : first, and (c) the "naming authority" field should be byte-aligned.] : : 2) Conservative Reuse : : The "conservative reuse" principle of this proposal just says that : SCSI Initiator Portnames should be viewed as static things (as much as : possible) and reused (when feasible) to give the most stable : presentation of SCSI Initiator Ports to both the OS above and to SCSU : targets across the wire. : : Whereas the current draft says "The ISID RULE does not preclude the : use of the same ISID to different Target portal groups", the : "conservative reuse" requirement would say that such reuse (using the : same ISID to many target portal groups) is a SHOULD (or is that : MUST?). So, in one implementation, each iSCSI Initiator Portal group : would get configured with iSCSI Name, and a (small) set of ISIDs. The : portal group might take this set of ISIDs as an ordered list. The : first session to a Target portal group would use the first ISID, the : second to the *same* target portal group would use the second in the : list, etc. The number of ISIDs would then define a configuration : parameter that can be interpreted as the maximum number of sessions : that can be built to a given target portal group. : : To facilitate "conservative reuse", the "qualifier" field of a set of : ISIDs SHOULD be generated using either a repeatable algorithm : (non-random or pseudo-random but based on a fixed seed) or any : algorithm and stored in a persistent location (e.g., registry or /etc : file). : : For the "Random" type, "conservative reuse" may not be an issue (say, : user application that doesn't care about reservations, etc.). When it : is, the "naming authority" field SHOULD also be generated by a : mechanism similar to that for the "qualifier" field as specified above : (e.g., defined in the SW at compilation time.) : : : DOCUMENTATING CHANGES: : : The iscsi drafts would need the following minor changes to support : this proposal: : : NDT doc : (a) define the structure of the ISID field (as described above) : (b) add some notes about implementation in the presense of : "conservative reuse" (e.g., that ISID should be configured once, say : at install time, then reused on subsequent reboots, even for "Random" : type). : : iSCSI MAIN doc: : (a) move the CID field in Login Request to another reserved field. : (b) expand the ISID field in Login Request and Response to encompass : the previous 4 bytes. : (c) add a sentence where the ISID field is defined indicating that : this field is a structured value, showing the structure (as above) and : point to the NDT document. : (d) add some text to "Note to Implementors" on "conservative reuse". : : Comments? : : : Jim Hafner : From owner-ips@ece.cmu.edu Sat Oct 27 04: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 EAA11061 for ; Sat, 27 Oct 2001 04:35:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9R5Zu809448 for ips-outgoing; Sat, 27 Oct 2001 01:35:56 -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 f9R5Zsl09443 for ; Sat, 27 Oct 2001 01:35:54 -0400 (EDT) Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Oct 2001 22:30:34 -0700 Message-ID: From: Joshua Tseng To: ips@ece.cmu.edu Subject: iSNS: User Port Number 3205 Date: Fri, 26 Oct 2001 22:30: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 -----Original Message----- From: IANA [mailto:iana@icann.org] Sent: Friday, October 26, 2001 11:37 AM To: jtseng@nishansystems.com Subject: RE: Application for port-number (3205) Dear Josh, We have assigned the following user port number with you as the point of contact: isns 3205/tcp iSNS Server Port isns 3205/udp iSNS Server Port # Josh Tseng Please notify the IANA if there is a change in contact information. Thank you, Michelle S. Cotton IANA Administrator *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 Voice: (310) 823-9358 x12 FAX: (310) 823-8649 email: iana@iana.org *************************************************************** From owner-ips@ece.cmu.edu Sat Oct 27 04:59: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 EAA10908 for ; Sat, 27 Oct 2001 04:01:03 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9R1aUn26418 for ips-outgoing; Fri, 26 Oct 2001 21:36:30 -0400 (EDT) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from lysimachus.hosting.pacbell.net (lysimachus.hosting.pacbell.net [216.100.98.17]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9R1YAl26257 for ; Fri, 26 Oct 2001 21:34:29 -0400 (EDT) Received: from somesh (sdsl-64-139-0-182.dsl.sca.megapath.net [64.139.0.182]) by lysimachus.hosting.pacbell.net id VAA14515; Fri, 26 Oct 2001 21:33:33 -0400 (EDT) [ConcentricHost SMTP Relay 1.7] Reply-To: From: "Somesh Gupta" To: "Ayman Ghanem" , Subject: RE: iSCSI: NOPs on discovery session Date: Fri, 26 Oct 2001 18:31:18 -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.6700 Importance: Normal In-Reply-To: Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ayman, It is not completely clear what the objective of the NOP command is? TCP itself has a keep-alive "feature" that can be used to ensure that the system at the other end is alive. So you don't need anything else to ensure that the "target is alive". However, we could use it as an opportunity to add another feature in the protocol and reinvent TCP twice. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Ayman Ghanem > Sent: Thursday, October 25, 2001 8:29 PM > To: ips@ece.cmu.edu > Subject: iSCSI: NOPs on discovery session > > > Julian, > > I am not sure if this came up before, but we also need to include > NOP-OUT to > the set of commands allowed on the discovery session. An > initiator may keep > the discovery session active, and send NOP-OUT to ping the target, or in > response to a target ping. > > -Ayman > > From owner-ips@ece.cmu.edu Sat Oct 27 04:59: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 EAA10878 for ; Sat, 27 Oct 2001 04:00:52 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9R2E2t28510 for ips-outgoing; Fri, 26 Oct 2001 22:14:02 -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 f9R2E1l28506 for ; Fri, 26 Oct 2001 22:14:01 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel1.hp.com (Postfix) with ESMTP id 0F9E051A; Fri, 26 Oct 2001 22:14:00 -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 TAA26775; Fri, 26 Oct 2001 19:15:25 -0700 (PDT) Message-Id: <200110270215.TAA26775@core.rose.hp.com> Date: Fri, 26 Oct 2001 19:26:04 -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: Sandeep Joshi , ips Subject: Re: iSCSI - Change Proposal X bit References: <200110270108.VAA09228@aura.research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sandeep, >because we allow the maxCmdSN to increase > unbounded in the presence of unacked statSNs. That's true! Two concerns - - We have been using CmdSN at the target only for reordering of commands, and it becomes irrelevant once a SCSI task is instantiated (section 2.2.2.1). Your suggestion doesn't appear to conform to this idea - in fact it seems to require CmdSN association beyond the task conclusion. - CmdSN credit management is an iSCSI session activity, and tying session level credit management with StatSN ACKs that happen at a connection level doesn't seem to enable a clean "session manager" separation spanning multiple NICs. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Sandeep Joshi wrote: > > Mallikarjun, > > This problem can be solved _without_ introducing > any additional I/O activity. Notice that it > occurs because we allow the maxCmdSN to increase > unbounded in the presence of unacked statSNs. > > The target can prevent this from happening. > > Imagine some connection A at the target : > > (1) Everytime the target sends a new statSN out, it > records the cmdSN for that statSN > (say Connection_A.cmdSN_of_last_statSN = 200) > > (2) While growing maxCmdSN at target, ensure that > (maxCmdSN - Connection_A.cmdSN_of_last_statSN < 2^31-1) > > This is stricter than current condition > (maxCmdSN - expCmdSN) < 2^31-1 > > If there are N connections, use least value of > cmdSN_of_last_statSN. > > (3) All retried commands will always fall outside > the window. They will be on the "dark side". > > (4) If the target cant grow maxCmdSN, it closes the > offending connection, or sends out NOPs. > > Works ..? > > -Sandeep > > > In helping others walk through your scenario here in HP, > > we all realized that the core solution to the problem > > is to mandate a complete execution of a numbered command > > (some I/O activity that is trackable) on each connection > > once at least every (2^32 -1) commands. It may be a NOP, > > or any regular command. So, here is my suggestion - > > > > An initiator MUST send at least one non-immediate command > > on each of the connections participating in the session, > > for every (2^31 -1) numbered commands. > > > > Comments? > > -- > > Mallikarjun From owner-ips@ece.cmu.edu Sat Oct 27 05:45: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 FAA11388 for ; Sat, 27 Oct 2001 05:45:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9R8x1L29304 for ips-outgoing; Sat, 27 Oct 2001 04:59: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 f9R8wxl29233 for ; Sat, 27 Oct 2001 04:58:59 -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 KAA121924 for ; Sat, 27 Oct 2001 10:58: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.98) with ESMTP id f9R8wqN27076 for ; Sat, 27 Oct 2001 10:58:52 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - Change proposal Removing the X bit X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 27 Oct 2001 11:58:47 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/10/2001 11:58:52, Serialize complete at 27/10/2001 11:58:52 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Sandeep, I the scenario I have forwarded we C2 & C3 could have sent the status on the pipe and the ExpStatSN carried in an immediate one-way nop. Julo Sandeep Joshi Sent by: owner-ips@ece.cmu.edu 26-10-01 23:46 Please respond to Sandeep Joshi To: Julian Satran/Haifa/IBM@IBMIL cc: ips@ece.cmu.edu Subject: Re: iSCSI - Change proposal Removing the X bit Julian When would the initiator decide to issue the cleaning NOP ? Would this be done on a sequence wraparound ? My one concern is that this puts the onus of doing things correctly on the initiator, and the target susceptible to initiator bugs. Here's an alternate idea.. It seems that for this scenario to occur the following condition must also be valid : A target MUST have a positive (expStatSN-statSN) for connection c1 when it receives c2&c3 in a new window on the same connection c1 - since the status acks are pending in-order after the retried c2&c3. If this is correct.. then would the following condition detect a connection which has gone stale ? A target MUST NOT allow a new CmdSN which is 2^31-1 greater than the unacknowledged status PDU for the last cmdSN sent on all connections. This would involve maintaining an additional counter per connection. (e.g. Connection->cmdSN_of_last_unacknowledged_statSN) In other words, if connection C1 sent status PDU for (c3) which has not yet been acked thru expStatSN, then the target will not allow a new command (Cn) which is 2^31-1 greater than c3. This must hold for all connections. This ensures that sequence wraparound does not cause old commands to reappear. Either the connection is closed or the target issues a NOP-IN which flushes that connection. If this is true, there is no need to issue the cleaning NOP since the target ensures that stale connections dont exist. Note that currently, we have a very loose requirement Sec 2.2.2.2 "A large difference between StatSN and ExpStatSN may indicate a failed connection." If we can strengthen this condition, we can ensure that the target as well as the initiator detect the sequence wrap-around without relying on one end too much. Comments ? -Sandeep Julian Satran wrote: > > Dear colleagues, > > We intend to publish very soon version 09 of the draft in its current > format (not many changes) and postpone the editorial changes (already under > way) for 10. > > One of the latest change proposal involves removing the X bit. > > The X bit has been used in several types of restart/replay but is somewhat > made redundant by the removal > of the command replay. > > This involves removing the X bit from request byte 0 and either making it > reserved or "shifting left" the rest of the general-use bits (I and the > direction bit). > > It also involves mandating a cleaning NOP. > > The cleaning NOP is needed in order to "flush out" old command PDU that can > be left over by simple sequences like the one in the following scenario: > > 2 connections > > On connection 1 I->T c1,c2,c3 > On connection 2 I->T c4,c5,c6 > > Targets receives everything and acts on commands but responses are sluggish > and initiators sees only an ack for > c1. It then retransmits c2, and c3 while there answer are in flight back > after which the connection is almost dead and not used by initiator. > > After a complete wrap around, involving only connection 2, the target > suddenly gets c2, c3 in a correct window and acts on them. > > The need to clean-up old PDUs is common to all protocols that use a > sequence that wraps and we suggested cleaning up using a NOP. We will > mandate a cleaning NOP only on connections that had at least one "retry". > > It looks like we might e able also to abandon the task management - > reassign function and do it with a reissue (with the same NOP cleanout > implication) since retiring the replay function makes the reassign > unambiguous (reissuing a command, after logout, on a new connection - > implies reassign). > > Please comment - I need your input urgently. > > Julo From owner-ips@ece.cmu.edu Sat Oct 27 05:49: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 FAA11407 for ; Sat, 27 Oct 2001 05:49:12 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9R9CtQ02147 for ips-outgoing; Sat, 27 Oct 2001 05:12:55 -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 f9R9Crl02142 for ; Sat, 27 Oct 2001 05:12:53 -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 LAA102206 for ; Sat, 27 Oct 2001 11:12: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.98) with ESMTP id f9R9Ck8151378 for ; Sat, 27 Oct 2001 11:12:46 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - Change Proposal X bit X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 27 Oct 2001 12:12:37 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/10/2001 12:12:46, Serialize complete at 27/10/2001 12:12:46 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, It is not clear to me what your response to the change proposal is. Restricting the command retries only on same connection is not strictly necessary. If we explicitly say that sending it on another connection can be done only after a logout (and I think we say that) than we could get rid of the task management reassign. As for executing a non-immediate command in 2^31-1 that could be an acceptable cleanup solution. Julo "Mallikarjun C." Sent by: cbm@core.rose.hp.com 25-10-01 21:50 Please respond to cbm To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: Re: iSCSI - Change Proposal X bit Julian, We need to call out that all (X-bit) retries should go out on the same connection, and I will make that explicit in the error recovery section. In effect, the "connection allegiance" should exist once the first copy of a command is sent. In helping others walk through your scenario here in HP, we all realized that the core solution to the problem is to mandate a complete execution of a numbered command (some I/O activity that is trackable) on each connection once at least every (2^32 -1) commands. It may be a NOP, or any regular command. So, here is my suggestion - An initiator MUST send at least one non-immediate command on each of the connections participating in the session, for every (2^31 -1) numbered commands. Comments? -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Julian Satran wrote: > > Santosh, > > The draft DOES NOT ALLOW commands to be reissued on another connection > without an intervening logout. > > Julo > > Santosh Rao > Sent by: santoshr@cup.hp.com > 25-10-01 01:44 > Please respond to Santosh Rao > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: Re: iSCSI - Change Proposal X bit > > > > Julian, > > The one scenario where I do see stale CmdSNs creating a problem is the > following : > > - 2 connections. > - CmdSN 3 issued on connection 1. > - Initiator does not get CmdSN ack for 1 and re-issues CmdSN 1 on > connection 2. > - CmdSN ack for 1 received on connection 2. All further I/O traffic on > connection 2 only (nothing on connection 1) and CmdSN sequence wraps > around. > - Finally, connection 1 clears up and CmdSN 1 is delivered on connection > 1. > > In the above situation, the stale CmdSN 1 is a problem. However, the > problem only occurs if the draft allows previously issued commands to be > re-issued on a different connection without first logging out the > previous connection. > > Why is it not possible to disallow commands to be re-issued on a > different connection unless the original connection used for that > command was first logged out successfully ? > > This would avoid this stale CmdSN on wrap around problem, as well as > avoid sporadic ULP timeout of I/Os due to race condition b/n initiator > re-issuing command on another connection and target sending CmdSN update > on the first connection. > > Thanks, > Santosh > > ps : I still don't see how your scenario below holds good. When the > target ack's CmdSNs upto 8 on connection 3, it has received all CmdSNs. > Hence, there can be no stalled commands on connection 2. However, a > different scenario which does cause a problem is the one I describe > above. > > Julian Satran wrote: > > > > Santosh, > > > > There is nothing in a command that arrives late on a link (as in the > > example in which it was sent redundantly) to distinguish it from a new > > (valid) command. > > > > This wraparound problem exists in all protocols - even in TCP, and we > use > > the CmdSN per session in the same fashion TCP uses sequence numbers per > > connection - and it is solved in different ways (TCP uses time-stamps). > > > > The NOP is meant to solve that wrap-around problem. > > > > I am sure that when rereading the example you will see the issue. > > > > Julo > > > > Santosh Rao > > Sent by: santoshr@cup.hp.com > > 24-10-01 18:29 > > Please respond to Santosh Rao > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI - Change Proposal X bit > > > > > > > > Julian, > > > > Some comments on the below quoted scenarios : > > > > > session has 3 connections > > > on connection 1 I->T c1,c2,c3,C6 > > > on connection 2 I->T c4,c5,c7,c8 > > > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > > > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 > and > > 6 > > > on connection 3 > > > target receives all and starts executing and acks 8 on connection 3 > > but > > > connection 2 stalls after c3 for a LONG TIME > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > delivers c4,c5 etc (that are now valid) > > > > When the target acks CmdSN 8 on connection 3, it has, in effect, sent > > CmdSN ack's for CMdSNs 3,4,5,6,7,8. This implies that the commands with > > CmdSN 3, 4, 5, 7, & 8 were received by the target on connection 2 and > > their processing was commenced. > > > > Hence, the following does not make sense : > > > > > connection 2 stalls after c3 for a LONG TIME > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > delivers c4,c5 etc (that are now valid) > > > > c4, c5, etc were already delivered to the target and are not being > > re-delivered. There is no problem in this case. (??). > > > > Take the next scenario : > > > 2 connections: > > > > > > connection1 I->T c3,c4,c5 > > > status of 3 contains ack up to 6 and it and all other statuses > are > > > lost > > > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > > > Since the initiator got CmdSN ack's upto 6, the initiator should not be > > re-issuing these I/Os ?? > > > > I still don't see justification to require that initiators send a > > immediate NOP-OUT in the manner being advocated. > > > > On a more fundamental note, I see some issues with the initiator being > > allowed to re-issue the commands on a different connection without > > having first logged out the previous connection successfully. I see > > nothing in the draft that suggests such behaviour, while at the same > > time, it is not forbidden. > > > > By resorting to command retries on a different connection in an attempt > > to plug the hole, without first logging out the previous connection, the > > initiator is susceptible to encountering I/O failure of that I/O due to > > ULP timeout. > > > > Here's the scenario why such recovery should not be allowed : > > - Initiator sends CmdSN 3 on connection 1. > > - No CmdSN updates for a while and initiator re-sends CmdSn 3 on > > connection 2. > > - At the same time, target has sent CmdSN ack's for CmdSN 3 on > > connection 1. > > > > - Initiator has transferred the command allegiance on its side from > > connection 1 to connection 2 and is attempting the command on connection > > 2. However, the command does not go through, since the (ExpCmdSN, > > MaxCmdSN) window has advanced and the trget discards the command. > > > > - Target sends in data and/or R2T and/or status for CmdSN 3 on > > connection 1. Since the initiator is not expecting any traffic for that > > I/O on connection 1, it discards any PDUs received on that connection 1 > > for which no I/O state existed. > > > > In the above scenario, initiator will never get a CmdSN ack on > > connection 2 and will never be able to plug the hole despite repeated > > retries, finally, causing a ULP timeout, followed by session recovery. > > > > Given the above scenario, I suggest that the initiator must only > > re-issue commands on the same connection, and can re-issue them on > > another connection only following a successful logout. > > > > Comments ? > > > > Thanks, > > Santosh > > > > Julian Satran wrote: > > > > > > Santosh, > > > > > > The scenarios I am talking about are all derivatives of an initiator > > trying > > > to plug-in holes and switching connections. > > > As the initiator does know the "extent" of a hole it can send-out > > commands > > > that he did not have to. > > > I have sent the attached not to Mallikarjun a while ago. I think > that > > > there might be many of this kind. I am also aware that X bit by > itself > > > might have some bad scenarios but the new proposal fixes them all. > > > > > > Julo > > > > > > _____________________________ > > > > > > Mallikarjun, > > > > > > Take the following sequence scenario: > > > > > > session has 3 connections > > > on connection 1 I->T c1,c2,c3,C6 > > > on connection 2 I->T c4,c5,c7,c8 > > > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > > > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 > and > > 6 > > > on connection 3 > > > target receives all and starts executing and acks 8 on connection 3 > > but > > > connection 2 stalls after c3 for a LONG TIME > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > delivers c4,c5 etc (that are now valid) > > > > > > That is not a very likely scenario, I admit, but it is possible. > > > With X bit I could not find any such scenario since an X either > follows > > a > > > good one on the same connection or can be safely discarded. > > > I suspect that there are some more scenarios that involve immediate > > > commands or commands that carry their own ack in the status and are > > acked > > > like: > > > > > > 2 connections: > > > > > > connection1 I->T c3,c4,c5 > > > status of 3 contains ack up to 6 and it and all other statuses > are > > > lost > > > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > > > > > I think we can avoid those be requiring a NOP exchange before > reissuing > > a > > > command on a new connection or reissue the command with a task > > management > > > (that has an implied ordering) but why do it if X is an obvious and > safe > > > solution. > > > > > > Julo > > > > > > Regards, > > > Julo > > > > > > > > > "Mallikarjun > > > C." To: Julian > > Satran/Haifa/IBM@IBMIL > > > > > om> Subject: Re: iscsi : X > bit > > in SCSI Command PDU. > > > > > > 08-10-01 21:45 > > > Please respond > > > to cbm > > > > > > > > > > > > Julian, > > > > > > We currently have the following specified in section 2.2.2.1 - > > > > > > "The target MUST NOT transmit a MaxCmdSN that is more than > > > 2**31 - 1 above the last ExpCmdSN." > > > > > > It appears to me that the above is sufficient to ward off the > > > accidents of the sort you describe. Do you think otherwise? > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > MS 5668 Hewlett-Packard, Roseville. > > > cbm@rose.hp.com > > > > > > Julian Satran wrote: > > > > > > > > Mallikarjun, > > > > > > > > There is at least one theoretical scenario in which an "old" command > > > > may appear in a "new window" and be reinstantiated. > > > > At 10Gbs and several connection that does not take months. With X > the > > > > probability is far lower (not 0). I have no other strong arguments > > > > but I am still thinking. Matt Wakeley that insisted on it (against > > > > me) had some other argument that I am trying to find (I am note > > > > remembering). > > > > > > > > Julo > > > > > > > > "Mallikarjun C." > > > > To: Julian > > > > Satran/Haifa/IBM@IBMIL > > > > 08-10-01 20:39 cc: > > > > Please respond to cbm Subject: Re: iscsi : X > > > > bit in SCSI Command PDU. > > > > > > > > > > > > > > > > Julian, > > > > > > > > Now that you put me on the spot, :-), my response - > > > > > > > > Santosh argued with me privately that X-bit no longer serves a > > > > useful purpose after the advent of task management commands to > > > > reassign. My response was that it never was a requirement per se, > > > > but always a "courtesy" extended by the initiator to help the > > > > target. I also suggested that X-bit may be considered for its > > > > usefulness in debugging. > > > > > > > > He still had some (very reasonable) comments for simplification > > > > - the most appealing of which (to me) was the opportunity to do > > > > away with the X-bit checking for *every* command PDU that the target > > > > has to endure now. > > > > > > > > If I missed a legitimate use of X-bit, please comment. Do you > > > > think it is a protocol requirement per se? I couldn't justify > > > > to myself so far (except the Login). > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions Organization > > > > MS 5668 Hewlett-Packard, Roseville. > > > > cbm@rose.hp.com > > > > > > > > > > > > > > > > Julian Satran wrote: > > > > > > > > > > Santosh, > > > > > > > > > > I am not sure you went through all scenarios. A conversation with > > > > your > > > > > colleague - Mallikarjun - and getting through the state table may > go > > > > a > > > > > long way to clarify the need for X. > > > > > > > > > > And I am sure that by now you found yourself several . > > > > > > > > > > Julo > > > > > > > > > > Santosh Rao > > > > > To: IPS Reflector > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > cc: > > > > > 06-10-01 01:56 Subject: iscsi : > X > > > > > Please respond to Santosh Rao bit in SCSI Command PDU. > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > With the elimination of command relay from iscsi [in the interests > > > > of > > > > > simplification ?], I believe that the X bit in the SCSI Command > PDU > > > > > can > > > > > also be removed. As it exists today, the X bit is only being used > > > > for > > > > > command restart, which is at attempt by the initiator to plug a > > > > > potential hole in the CmdSN sequence at the target. It does this > on > > > > > failing to get an ExpCmdSN ack for a previously sent command > within > > > > > some > > > > > timeout period. > > > > > > > > > > Given the above usage of command restart, no X bit is required to > be > > > > > set > > > > > in the SCSI Command PDU when command re-start is done. > > > > > > > > > > Either : > > > > > (a) the target had dropped the command earlier due to a digest > > > > error, > > > > > in > > > > > which case, the command restart plugs the CmdSN hole in the > target. > > > > > > > > > > [OR] > > > > > > > > > > (b) the target had received the command and was working on it, > when > > > > > the > > > > > initiator timed out too soon and attempted a command restart to > plug > > > > > [what it thought was] a possible hole in the CmdSN sequence. > > > > > > > > > > In case (a), no X bit was required, since the target knows nothing > > > > of > > > > > the original command. In case (b), no X bit is required again, > since > > > > > the > > > > > (ExpCmdSN, MaxCmdSN) window would have advanced and the target can > > > > > silently discard the received retry and continue working on the > > > > > original > > > > > command received. > > > > > > > > > > Removal of the X bit in the SCSI Command PDU has the following > > > > > benefits > > > > > : > > > > > > > > > > a) The CmdSN rules at the target are simplified. No need to look > at > > > > X > > > > > bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) > window. > > > > > > > > > > b) The reject reason code "command already in progress" can be > > > > > removed. > > > > > There's no need for this reject reason code anymore, since X bit > > > > > itself > > > > > is not required, and the targets can silently discard commands > > > > outside > > > > > the command window and continue to work on the original instance > of > > > > > the > > > > > command already being processed at the target. > > > > > > > > > > c) Less work for the target and less resources consumed since it > no > > > > > longer needs to generate a Reject PDU of type "command in > progress". > > > > > It > > > > > can just silently discard any command PDU outside the (ExpCmdSN, > > > > > MaxCmdSN) window. > > > > > > > > > > d) Less code for the target, since it does not need : > > > > > - any Reject code paths when it receives X bit command PDUs that > are > > > > > already in progress. > > > > > - No special casing of CmdSN checking rules. > > > > > - No overheads of verifying a received command based on its > > > > initiator > > > > > task tag, to check if the task is currently active, prior to > sending > > > > a > > > > > Reject response with "command in progress". > > > > > > > > > > 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 > > > > > ################################## > > > > > > > > > Santosh Rao > > > > > > > hp.com> cc: > > > Sent by: Subject: Re: iSCSI - > Change > > Proposal X bit > > > owner-ips@ece. > > > cmu.edu > > > > > > > > > 23-10-01 22:50 > > > Please respond > > > to Santosh Rao > > > > > > > > > > > > Julian Satran wrote: > > > > > > > > However in order to drop "old" commands that might in the pipe on a > > > > sluggish connection - removing the X bit will require the initiator > to > > > > issue an immediate NOP requiring a NOP response on every open > > connection > > > > whenever CmdSN wraps around (becomes equal to InitCmdSN). > > > > > > Julian, > > > > > > Can you please explain further the corner case you are describing > above > > > ? Are you suggesting that special action should be taken every time > > > CmdSN wraps around, in case there were holes in the CmdSN sequence at > > > the wrap time ? Why is that ? > > > > > > Here's my understanding of how this plays out : > > > > > > Rule 1) > > > The CmdSN management rules at the target should be handling CmdSN wrap > > > case and the initiator cannot issue more than 2^32 -1 commands beyond > > > the last ExpCmdSN update it has received from the target, since the > > > target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 above > > > the last ExpCmdSN. (per Section 2.2.2.1) > > > > > > Rule 2) > > > Any holes that occur in the CmdSN sequence are attempted to be plugged > > > by the initiator by re-issuing the original command. If the CmdSN > never > > > got acknowledged and the I/O's ULP timeout expired, the initiator MUST > > > perform session recovery. (per Section 8.6) > > > > > > Thus, going by the above 2 rules, if the CmdSN sequence wraps upto > > > ExpCmdSN, the initiator will not be able to issue further commands, > > > since the target will keep the CmdSN window closed. The window can > only > > > re-open when the CmdSN holes are plugged allowing ExpCmdSN and > thereby, > > > MaxCmdSN to advance. (rule 1 above). > > > > > > Under the above circumstances, the initiator will possibly try to plug > > > the CmdSN hole by re-issuing the original command. It may do this 1 or > > > more times before its ULP timeout expires. Either the holes get > plugged > > > and the windoe re-opens, or ULP timeout occurs without the > corresponding > > > CmdSN for that I/O having been acknowledged, resulting in session > > > logout. (rule 2 above). > > > > > > What is required over and beyond the above ? Why does removal of X-bit > > > require an immediate NOP to be issued every time CmdSN wraps and a > hole > > > exists in the CmdSN sequence (??). > > > > > > 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 Oct 27 06:25: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 GAA11616 for ; Sat, 27 Oct 2001 06:25:56 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9R9f1903580 for ips-outgoing; Sat, 27 Oct 2001 05:41:01 -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 f9R9exl03574 for ; Sat, 27 Oct 2001 05:40:59 -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 LAA242516 for ; Sat, 27 Oct 2001 11:40: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.98) with ESMTP id f9R9eqN91912 for ; Sat, 27 Oct 2001 11:40:52 +0200 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI: NOPs on discovery session X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 27 Oct 2001 12:40:48 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/10/2001 12:40:52, Serialize complete at 27/10/2001 12:40:52 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Somesh, NOPs are used for more than keep alive. They carry number acknowledgements and are done by the iSCSI layer while TCPs keep alive being kept at the TCP level does not say anything about the layers above (usually works between brain-dead machines). In general the higher the level of a "keep-alive" the more functional it is. Julo "Somesh Gupta" Sent by: owner-ips@ece.cmu.edu 27-10-01 03:31 Please respond to somesh_gupta To: "Ayman Ghanem" , cc: Subject: RE: iSCSI: NOPs on discovery session Ayman, It is not completely clear what the objective of the NOP command is? TCP itself has a keep-alive "feature" that can be used to ensure that the system at the other end is alive. So you don't need anything else to ensure that the "target is alive". However, we could use it as an opportunity to add another feature in the protocol and reinvent TCP twice. Somesh > -----Original Message----- > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of > Ayman Ghanem > Sent: Thursday, October 25, 2001 8:29 PM > To: ips@ece.cmu.edu > Subject: iSCSI: NOPs on discovery session > > > Julian, > > I am not sure if this came up before, but we also need to include > NOP-OUT to > the set of commands allowed on the discovery session. An > initiator may keep > the discovery session active, and send NOP-OUT to ping the target, or in > response to a target ping. > > -Ayman > > From owner-ips@ece.cmu.edu Sat Oct 27 13:34: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 NAA15260 for ; Sat, 27 Oct 2001 13:34:57 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9RGqDI26342 for ips-outgoing; Sat, 27 Oct 2001 12:52:13 -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 f9RGqCl26337 for ; Sat, 27 Oct 2001 12:52:12 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Sat Oct 27 12:46:31 EDT 2001 Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id f9RGodk07452; Sat, 27 Oct 2001 12:50:39 -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 MAA02821; Sat, 27 Oct 2001 12:50:35 -0400 (EDT) Message-ID: <3BDAE5DB.7699C52E@research.bell-labs.com> Date: Sat, 27 Oct 2001 12:50:35 -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: cbm@rose.hp.com CC: ips Subject: Re: iSCSI - Change Proposal X bit References: <200110270108.VAA09228@aura.research.bell-labs.com> <200110270215.TAA26775@core.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 Your 2nd argument make sense..the first seems like a issue of changing the cmdSN definition. That said, I'd rather have preventive measures to make the target protect itself rather than assume the initiator sends out certain periodic messages. -Sandeep "Mallikarjun C." wrote: > > Sandeep, > > >because we allow the maxCmdSN to increase > > unbounded in the presence of unacked statSNs. > > That's true! Two concerns - > > - We have been using CmdSN at the target only > for reordering of commands, and it becomes irrelevant > once a SCSI task is instantiated (section 2.2.2.1). > Your suggestion doesn't appear to conform to this > idea - in fact it seems to require CmdSN association > beyond the task conclusion. > > - CmdSN credit management is an iSCSI session activity, > and tying session level credit management with StatSN > ACKs that happen at a connection level doesn't seem to > enable a clean "session manager" separation spanning > multiple NICs. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Sandeep Joshi wrote: > > > > Mallikarjun, > > > > This problem can be solved _without_ introducing > > any additional I/O activity. Notice that it > > occurs because we allow the maxCmdSN to increase > > unbounded in the presence of unacked statSNs. > > > > The target can prevent this from happening. > > > > Imagine some connection A at the target : > > > > (1) Everytime the target sends a new statSN out, it > > records the cmdSN for that statSN > > (say Connection_A.cmdSN_of_last_statSN = 200) > > > > (2) While growing maxCmdSN at target, ensure that > > (maxCmdSN - Connection_A.cmdSN_of_last_statSN < 2^31-1) > > > > This is stricter than current condition > > (maxCmdSN - expCmdSN) < 2^31-1 > > > > If there are N connections, use least value of > > cmdSN_of_last_statSN. > > > > (3) All retried commands will always fall outside > > the window. They will be on the "dark side". > > > > (4) If the target cant grow maxCmdSN, it closes the > > offending connection, or sends out NOPs. > > > > Works ..? > > > > -Sandeep > > > > > In helping others walk through your scenario here in HP, > > > we all realized that the core solution to the problem > > > is to mandate a complete execution of a numbered command > > > (some I/O activity that is trackable) on each connection > > > once at least every (2^32 -1) commands. It may be a NOP, > > > or any regular command. So, here is my suggestion - > > > > > > An initiator MUST send at least one non-immediate command > > > on each of the connections participating in the session, > > > for every (2^31 -1) numbered commands. > > > > > > Comments? > > > -- > > > Mallikarjun From owner-ips@ece.cmu.edu Sat Oct 27 13:36: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 NAA15288 for ; Sat, 27 Oct 2001 13:36:21 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9RGgDk25783 for ips-outgoing; Sat, 27 Oct 2001 12:42:13 -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 f9RGgBl25778 for ; Sat, 27 Oct 2001 12:42:11 -0400 (EDT) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Sat Oct 27 12:37:52 EDT 2001 Received: from aura.research.bell-labs.com (aura.research.bell-labs.com [135.104.46.10]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id f9RGfvk07325 for ; Sat, 27 Oct 2001 12:42:01 -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 MAA02140 for ; Sat, 27 Oct 2001 12:41:57 -0400 (EDT) Message-ID: <3BDAE3D4.99027706@research.bell-labs.com> Date: Sat, 27 Oct 2001 12:41:56 -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 - Change proposal Removing the X bit 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 Satran wrote: > > Sandeep, > > I the scenario I have forwarded we C2 & C3 could have sent the status on > the pipe and the ExpStatSN carried in an immediate one-way nop. > > Julo Dont believe so..If that were the case, the retried C2 & C3 must be _ahead_ of that one-way NOP issued by the initiator, since the initiator cannot see the status PDUs before retrying commands. If the target cant read C2&C3 in the pipe, it cant see the updated expStatSN either -Sandeep > > Sandeep Joshi > Sent by: owner-ips@ece.cmu.edu > 26-10-01 23:46 > Please respond to Sandeep Joshi > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: ips@ece.cmu.edu > Subject: Re: iSCSI - Change proposal Removing the X bit > > > > Julian > > When would the initiator decide to issue the cleaning NOP ? > Would this be done on a sequence wraparound ? > My one concern is that this puts the onus of doing things > correctly on the initiator, and the target susceptible to > initiator bugs. > > Here's an alternate idea.. > > It seems that for this scenario to occur the following > condition must also be valid : > > A target MUST have a positive (expStatSN-statSN) for > connection c1 when it receives c2&c3 in a new window > on the same connection c1 - since the status acks > are pending in-order after the retried c2&c3. > > If this is correct.. then would the following condition > detect a connection which has gone stale ? > > A target MUST NOT allow a new CmdSN which is 2^31-1 greater > than the unacknowledged status PDU for the last cmdSN sent > on all connections. > > This would involve maintaining an additional counter per > connection. (e.g. Connection->cmdSN_of_last_unacknowledged_statSN) > > In other words, if connection C1 sent status PDU for (c3) which > has not yet been acked thru expStatSN, then the target will not > allow a new command (Cn) which is 2^31-1 greater than c3. > This must hold for all connections. > > This ensures that sequence wraparound does not cause old commands > to reappear. Either the connection is closed or the target > issues a NOP-IN which flushes that connection. > > If this is true, there is no need to issue the cleaning NOP > since the target ensures that stale connections dont exist. > > Note that currently, we have a very loose requirement Sec 2.2.2.2 > "A large difference between StatSN and ExpStatSN may > indicate a failed connection." > > If we can strengthen this condition, we can ensure that the target > as well as the initiator detect the sequence wrap-around without > relying on one end too much. > > Comments ? > > -Sandeep > > Julian Satran wrote: > > > > Dear colleagues, > > > > We intend to publish very soon version 09 of the draft in its current > > format (not many changes) and postpone the editorial changes (already > under > > way) for 10. > > > > One of the latest change proposal involves removing the X bit. > > > > The X bit has been used in several types of restart/replay but is > somewhat > > made redundant by the removal > > of the command replay. > > > > This involves removing the X bit from request byte 0 and either making > it > > reserved or "shifting left" the rest of the general-use bits (I and the > > direction bit). > > > > It also involves mandating a cleaning NOP. > > > > The cleaning NOP is needed in order to "flush out" old command PDU that > can > > be left over by simple sequences like the one in the following scenario: > > > > 2 connections > > > > On connection 1 I->T c1,c2,c3 > > On connection 2 I->T c4,c5,c6 > > > > Targets receives everything and acts on commands but responses are > sluggish > > and initiators sees only an ack for > > c1. It then retransmits c2, and c3 while there answer are in flight > back > > after which the connection is almost dead and not used by initiator. > > > > After a complete wrap around, involving only connection 2, the target > > suddenly gets c2, c3 in a correct window and acts on them. > > > > The need to clean-up old PDUs is common to all protocols that use a > > sequence that wraps and we suggested cleaning up using a NOP. We will > > mandate a cleaning NOP only on connections that had at least one > "retry". > > > > It looks like we might e able also to abandon the task management - > > reassign function and do it with a reissue (with the same NOP cleanout > > implication) since retiring the replay function makes the reassign > > unambiguous (reissuing a command, after logout, on a new connection - > > implies reassign). > > > > Please comment - I need your input urgently. > > > > Julo From owner-ips@ece.cmu.edu Sat Oct 27 16:36: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 QAA16539 for ; Sat, 27 Oct 2001 16:36:26 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9RJl4606081 for ips-outgoing; Sat, 27 Oct 2001 15:47:04 -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 f9RJl3l06076 for ; Sat, 27 Oct 2001 15:47:03 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 5C0271F58D; Sat, 27 Oct 2001 15:46:57 -0400 (EDT) Received: from swathi (pal1nai160168.nsr.hp.com [15.244.160.168]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id MAA03056; Sat, 27 Oct 2001 12:48:22 -0700 (PDT) Message-ID: <002e01c15f20$21e78de0$a8a0f40f@rose.hp.com> From: "Mallikarjun C." To: "Sandeep Joshi" Cc: "ips" References: <200110270108.VAA09228@aura.research.bell-labs.com> <200110270215.TAA26775@core.rose.hp.com> <3BDAE5DB.7699C52E@research.bell-labs.com> Subject: Re: iSCSI - Change Proposal X bit Date: Sat, 27 Oct 2001 12:46:54 -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 Sandeep, Okay, it seems we are beginning to agree with each other. Please note that my suggestion to mandate at least one non-immediate command every 2^31 -1 commands does not preclude a double-check by a target in an implementation. It would be no different from an initiator implementation double-checking that a target is giving no more than a (mandatory limit of) 2^31 -1 credit (both are protocol violations). That said, I tend to differ on your idea of who the "victim" would be if this proposed protocol requirement is not adhered to. If initiator does not follow the proposed stipulation, it gets what it deserves - a possible data corruption. But perhaps this view is slightly subjective. Finally, CmdSN as the name indicates is a sequencing mechanism. We have studiously avoided so far to use CmdSN beyond sequencing, and relied on ITT as the identifier for (an instantiated) task. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com ----- Original Message ----- From: "Sandeep Joshi" To: Cc: "ips" Sent: Saturday, October 27, 2001 9:50 AM Subject: Re: iSCSI - Change Proposal X bit > > > Your 2nd argument make sense..the first seems like a > issue of changing the cmdSN definition. That said, > I'd rather have preventive measures to make the target > protect itself rather than assume the initiator sends > out certain periodic messages. > > -Sandeep > > "Mallikarjun C." wrote: > > > > Sandeep, > > > > >because we allow the maxCmdSN to increase > > > unbounded in the presence of unacked statSNs. > > > > That's true! Two concerns - > > > > - We have been using CmdSN at the target only > > for reordering of commands, and it becomes irrelevant > > once a SCSI task is instantiated (section 2.2.2.1). > > Your suggestion doesn't appear to conform to this > > idea - in fact it seems to require CmdSN association > > beyond the task conclusion. > > > > - CmdSN credit management is an iSCSI session activity, > > and tying session level credit management with StatSN > > ACKs that happen at a connection level doesn't seem to > > enable a clean "session manager" separation spanning > > multiple NICs. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > Sandeep Joshi wrote: > > > > > > Mallikarjun, > > > > > > This problem can be solved _without_ introducing > > > any additional I/O activity. Notice that it > > > occurs because we allow the maxCmdSN to increase > > > unbounded in the presence of unacked statSNs. > > > > > > The target can prevent this from happening. > > > > > > Imagine some connection A at the target : > > > > > > (1) Everytime the target sends a new statSN out, it > > > records the cmdSN for that statSN > > > (say Connection_A.cmdSN_of_last_statSN = 200) > > > > > > (2) While growing maxCmdSN at target, ensure that > > > (maxCmdSN - Connection_A.cmdSN_of_last_statSN < 2^31-1) > > > > > > This is stricter than current condition > > > (maxCmdSN - expCmdSN) < 2^31-1 > > > > > > If there are N connections, use least value of > > > cmdSN_of_last_statSN. > > > > > > (3) All retried commands will always fall outside > > > the window. They will be on the "dark side". > > > > > > (4) If the target cant grow maxCmdSN, it closes the > > > offending connection, or sends out NOPs. > > > > > > Works ..? > > > > > > -Sandeep > > > > > > > In helping others walk through your scenario here in HP, > > > > we all realized that the core solution to the problem > > > > is to mandate a complete execution of a numbered command > > > > (some I/O activity that is trackable) on each connection > > > > once at least every (2^32 -1) commands. It may be a NOP, > > > > or any regular command. So, here is my suggestion - > > > > > > > > An initiator MUST send at least one non-immediate command > > > > on each of the connections participating in the session, > > > > for every (2^31 -1) numbered commands. > > > > > > > > Comments? > > > > -- > > > > Mallikarjun > From owner-ips@ece.cmu.edu Sat Oct 27 16:37: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 QAA16550 for ; Sat, 27 Oct 2001 16:37:02 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9RKEbj07639 for ips-outgoing; Sat, 27 Oct 2001 16:14:37 -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 f9RKEZl07634 for ; Sat, 27 Oct 2001 16:14:35 -0400 (EDT) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel2.hp.com (Postfix) with ESMTP id BD63D81F for ; Sat, 27 Oct 2001 13:14:34 -0700 (PDT) Received: from swathi (pal1nai160168.nsr.hp.com [15.244.160.168]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id NAA07221 for ; Sat, 27 Oct 2001 13:15:58 -0700 (PDT) Message-ID: <003f01c15f23$fd294940$a8a0f40f@rose.hp.com> From: "Mallikarjun C." To: "ips" Subject: Re: iSCSI - Change Proposal X bit Date: Sat, 27 Oct 2001 13:14:31 -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 Julian, Perhaps I wasn't clear, but what I meant by "command retries" is what iSCSI allows to plug holes (duplicate copies, currently indicated by X-bit). I agree that a successful Logout should enable the reassignment to a different connection, so also would any Rejects of *command* PDUs from the target on a given connection (the latter indicates that the task is not instantiated on the target, as on an immediate command for ex.). I IRC, one of the reasons we came up with "task reassign" TMF was to ensure that only the ITT is relied on for allegiance reassignment - so one does not have to either fill in the (old) CmdSN/flags/CDB/LUN etc., or reconfirm them on the target. I wasn't sure if you meant to continue that idea. One possibility is to use the X-bit as the "reassign" bit now - as a protocol by both the parties that only the ITT is valid and the rest can be ignored if the reassign-bit is set. Other obvious possibility is ofcourse to stay with the task reassign TMF (which we mandate as immediate today). Please comment. Thanks for the agreement on the suggestion to require any non-immediate command every (2^31 -1) commands, in stead of only NOPs. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com ----- Original Message ----- From: "Julian Satran" To: Sent: Saturday, October 27, 2001 2:12 AM Subject: Re: iSCSI - Change Proposal X bit > Mallikarjun, > > It is not clear to me what your response to the change proposal is. > Restricting the command retries only on same connection is not strictly > necessary. > If we explicitly say that sending it on another connection can be done > only after a logout (and I think we say that) than > we could get rid of the task management reassign. > > As for executing a non-immediate command in 2^31-1 that could be an > acceptable cleanup solution. > > Julo > > > > > > > > "Mallikarjun C." > Sent by: cbm@core.rose.hp.com > 25-10-01 21:50 > Please respond to cbm > > > To: Julian Satran/Haifa/IBM@IBMIL > cc: > Subject: Re: iSCSI - Change Proposal X bit > > > > Julian, > > We need to call out that all (X-bit) retries should > go out on the same connection, and I will make that > explicit in the error recovery section. In effect, > the "connection allegiance" should exist once the > first copy of a command is sent. > > In helping others walk through your scenario here in HP, > we all realized that the core solution to the problem > is to mandate a complete execution of a numbered command > (some I/O activity that is trackable) on each connection > once at least every (2^32 -1) commands. It may be a NOP, > or any regular command. So, here is my suggestion - > > An initiator MUST send at least one non-immediate command > on each of the connections participating in the session, > for every (2^31 -1) numbered commands. > > Comments? > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Julian Satran wrote: > > > > Santosh, > > > > The draft DOES NOT ALLOW commands to be reissued on another connection > > without an intervening logout. > > > > Julo > > > > Santosh Rao > > Sent by: santoshr@cup.hp.com > > 25-10-01 01:44 > > Please respond to Santosh Rao > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > cc: > > Subject: Re: iSCSI - Change Proposal X bit > > > > > > > > Julian, > > > > The one scenario where I do see stale CmdSNs creating a problem is the > > following : > > > > - 2 connections. > > - CmdSN 3 issued on connection 1. > > - Initiator does not get CmdSN ack for 1 and re-issues CmdSN 1 on > > connection 2. > > - CmdSN ack for 1 received on connection 2. All further I/O traffic on > > connection 2 only (nothing on connection 1) and CmdSN sequence wraps > > around. > > - Finally, connection 1 clears up and CmdSN 1 is delivered on connection > > 1. > > > > In the above situation, the stale CmdSN 1 is a problem. However, the > > problem only occurs if the draft allows previously issued commands to be > > re-issued on a different connection without first logging out the > > previous connection. > > > > Why is it not possible to disallow commands to be re-issued on a > > different connection unless the original connection used for that > > command was first logged out successfully ? > > > > This would avoid this stale CmdSN on wrap around problem, as well as > > avoid sporadic ULP timeout of I/Os due to race condition b/n initiator > > re-issuing command on another connection and target sending CmdSN update > > on the first connection. > > > > Thanks, > > Santosh > > > > ps : I still don't see how your scenario below holds good. When the > > target ack's CmdSNs upto 8 on connection 3, it has received all CmdSNs. > > Hence, there can be no stalled commands on connection 2. However, a > > different scenario which does cause a problem is the one I describe > > above. > > > > Julian Satran wrote: > > > > > > Santosh, > > > > > > There is nothing in a command that arrives late on a link (as in the > > > example in which it was sent redundantly) to distinguish it from a > new > > > (valid) command. > > > > > > This wraparound problem exists in all protocols - even in TCP, and we > > use > > > the CmdSN per session in the same fashion TCP uses sequence numbers > per > > > connection - and it is solved in different ways (TCP uses > time-stamps). > > > > > > The NOP is meant to solve that wrap-around problem. > > > > > > I am sure that when rereading the example you will see the issue. > > > > > > Julo > > > > > > Santosh Rao > > > Sent by: santoshr@cup.hp.com > > > 24-10-01 18:29 > > > Please respond to Santosh Rao > > > > > > > > > To: Julian Satran/Haifa/IBM@IBMIL > > > cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI - Change Proposal X bit > > > > > > > > > > > > Julian, > > > > > > Some comments on the below quoted scenarios : > > > > > > > session has 3 connections > > > > on connection 1 I->T c1,c2,c3,C6 > > > > on connection 2 I->T c4,c5,c7,c8 > > > > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > > > > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 > > and > > > 6 > > > > on connection 3 > > > > target receives all and starts executing and acks 8 on connection > 3 > > > but > > > > connection 2 stalls after c3 for a LONG TIME > > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > > delivers c4,c5 etc (that are now valid) > > > > > > When the target acks CmdSN 8 on connection 3, it has, in effect, sent > > > CmdSN ack's for CMdSNs 3,4,5,6,7,8. This implies that the commands > with > > > CmdSN 3, 4, 5, 7, & 8 were received by the target on connection 2 and > > > their processing was commenced. > > > > > > Hence, the following does not make sense : > > > > > > > connection 2 stalls after c3 for a LONG TIME > > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > > delivers c4,c5 etc (that are now valid) > > > > > > c4, c5, etc were already delivered to the target and are not being > > > re-delivered. There is no problem in this case. (??). > > > > > > Take the next scenario : > > > > 2 connections: > > > > > > > > connection1 I->T c3,c4,c5 > > > > status of 3 contains ack up to 6 and it and all other statuses > > are > > > > lost > > > > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > > > > > Since the initiator got CmdSN ack's upto 6, the initiator should not > be > > > re-issuing these I/Os ?? > > > > > > I still don't see justification to require that initiators send a > > > immediate NOP-OUT in the manner being advocated. > > > > > > On a more fundamental note, I see some issues with the initiator being > > > allowed to re-issue the commands on a different connection without > > > having first logged out the previous connection successfully. I see > > > nothing in the draft that suggests such behaviour, while at the same > > > time, it is not forbidden. > > > > > > By resorting to command retries on a different connection in an > attempt > > > to plug the hole, without first logging out the previous connection, > the > > > initiator is susceptible to encountering I/O failure of that I/O due > to > > > ULP timeout. > > > > > > Here's the scenario why such recovery should not be allowed : > > > - Initiator sends CmdSN 3 on connection 1. > > > - No CmdSN updates for a while and initiator re-sends CmdSn 3 on > > > connection 2. > > > - At the same time, target has sent CmdSN ack's for CmdSN 3 on > > > connection 1. > > > > > > - Initiator has transferred the command allegiance on its side from > > > connection 1 to connection 2 and is attempting the command on > connection > > > 2. However, the command does not go through, since the (ExpCmdSN, > > > MaxCmdSN) window has advanced and the trget discards the command. > > > > > > - Target sends in data and/or R2T and/or status for CmdSN 3 on > > > connection 1. Since the initiator is not expecting any traffic for > that > > > I/O on connection 1, it discards any PDUs received on that connection > 1 > > > for which no I/O state existed. > > > > > > In the above scenario, initiator will never get a CmdSN ack on > > > connection 2 and will never be able to plug the hole despite repeated > > > retries, finally, causing a ULP timeout, followed by session recovery. > > > > > > Given the above scenario, I suggest that the initiator must only > > > re-issue commands on the same connection, and can re-issue them on > > > another connection only following a successful logout. > > > > > > Comments ? > > > > > > Thanks, > > > Santosh > > > > > > Julian Satran wrote: > > > > > > > > Santosh, > > > > > > > > The scenarios I am talking about are all derivatives of an initiator > > > trying > > > > to plug-in holes and switching connections. > > > > As the initiator does know the "extent" of a hole it can send-out > > > commands > > > > that he did not have to. > > > > I have sent the attached not to Mallikarjun a while ago. I think > > that > > > > there might be many of this kind. I am also aware that X bit by > > itself > > > > might have some bad scenarios but the new proposal fixes them all. > > > > > > > > Julo > > > > > > > > _____________________________ > > > > > > > > Mallikarjun, > > > > > > > > Take the following sequence scenario: > > > > > > > > session has 3 connections > > > > on connection 1 I->T c1,c2,c3,C6 > > > > on connection 2 I->T c4,c5,c7,c8 > > > > Target receives 1,2,4,5,7,8 (miss 3 and 6) and acks 1 & 2 > > > > Initiator closes 1 and resends c3, c4, c5,c7,c8 on connection 2 > > and > > > 6 > > > > on connection 3 > > > > target receives all and starts executing and acks 8 on connection > 3 > > > but > > > > connection 2 stalls after c3 for a LONG TIME > > > > then (after 2 full sequence wraps) connection 2 is gets alive and > > > > delivers c4,c5 etc (that are now valid) > > > > > > > > That is not a very likely scenario, I admit, but it is possible. > > > > With X bit I could not find any such scenario since an X either > > follows > > > a > > > > good one on the same connection or can be safely discarded. > > > > I suspect that there are some more scenarios that involve immediate > > > > commands or commands that carry their own ack in the status and are > > > acked > > > > like: > > > > > > > > 2 connections: > > > > > > > > connection1 I->T c3,c4,c5 > > > > status of 3 contains ack up to 6 and it and all other statuses > > are > > > > lost > > > > connection2 resend c3, c4 & c5 (no logout) and those are executed! > > > > > > > > I think we can avoid those be requiring a NOP exchange before > > reissuing > > > a > > > > command on a new connection or reissue the command with a task > > > management > > > > (that has an implied ordering) but why do it if X is an obvious and > > safe > > > > solution. > > > > > > > > Julo > > > > > > > > Regards, > > > > Julo > > > > > > > > > > > > "Mallikarjun > > > > C." To: Julian > > > Satran/Haifa/IBM@IBMIL > > > > > > > om> Subject: Re: iscsi : X > > bit > > > in SCSI Command PDU. > > > > > > > > 08-10-01 21:45 > > > > Please respond > > > > to cbm > > > > > > > > > > > > > > > > Julian, > > > > > > > > We currently have the following specified in section 2.2.2.1 - > > > > > > > > "The target MUST NOT transmit a MaxCmdSN that is more than > > > > 2**31 - 1 above the last ExpCmdSN." > > > > > > > > It appears to me that the above is sufficient to ward off the > > > > accidents of the sort you describe. Do you think otherwise? > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions Organization > > > > MS 5668 Hewlett-Packard, Roseville. > > > > cbm@rose.hp.com > > > > > > > > Julian Satran wrote: > > > > > > > > > > Mallikarjun, > > > > > > > > > > There is at least one theoretical scenario in which an "old" > command > > > > > may appear in a "new window" and be reinstantiated. > > > > > At 10Gbs and several connection that does not take months. With X > > the > > > > > probability is far lower (not 0). I have no other strong > arguments > > > > > but I am still thinking. Matt Wakeley that insisted on it > (against > > > > > me) had some other argument that I am trying to find (I am note > > > > > remembering). > > > > > > > > > > Julo > > > > > > > > > > "Mallikarjun C." > > > > > To: Julian > > > > > Satran/Haifa/IBM@IBMIL > > > > > 08-10-01 20:39 cc: > > > > > Please respond to cbm Subject: Re: iscsi : X > > > > > bit in SCSI Command PDU. > > > > > > > > > > > > > > > > > > > > Julian, > > > > > > > > > > Now that you put me on the spot, :-), my response - > > > > > > > > > > Santosh argued with me privately that X-bit no longer serves a > > > > > useful purpose after the advent of task management commands to > > > > > reassign. My response was that it never was a requirement per se, > > > > > but always a "courtesy" extended by the initiator to help the > > > > > target. I also suggested that X-bit may be considered for its > > > > > usefulness in debugging. > > > > > > > > > > He still had some (very reasonable) comments for simplification > > > > > - the most appealing of which (to me) was the opportunity to do > > > > > away with the X-bit checking for *every* command PDU that the > target > > > > > has to endure now. > > > > > > > > > > If I missed a legitimate use of X-bit, please comment. Do you > > > > > think it is a protocol requirement per se? I couldn't justify > > > > > to myself so far (except the Login). > > > > > > > > > > Regards. > > > > > -- > > > > > Mallikarjun > > > > > > > > > > Mallikarjun Chadalapaka > > > > > Networked Storage Architecture > > > > > Network Storage Solutions Organization > > > > > MS 5668 Hewlett-Packard, Roseville. > > > > > cbm@rose.hp.com > > > > > > > > > > > > > > > > > > > > Julian Satran wrote: > > > > > > > > > > > > Santosh, > > > > > > > > > > > > I am not sure you went through all scenarios. A conversation > with > > > > > your > > > > > > colleague - Mallikarjun - and getting through the state table > may > > go > > > > > a > > > > > > long way to clarify the need for X. > > > > > > > > > > > > And I am sure that by now you found yourself several . > > > > > > > > > > > > Julo > > > > > > > > > > > > Santosh Rao > > > > > > To: IPS > Reflector > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > cc: > > > > > > 06-10-01 01:56 Subject: iscsi > : > > X > > > > > > Please respond to Santosh Rao bit in SCSI Command PDU. > > > > > > > > > > > > > > > > > > > > > > > > All, > > > > > > > > > > > > With the elimination of command relay from iscsi [in the > interests > > > > > of > > > > > > simplification ?], I believe that the X bit in the SCSI Command > > PDU > > > > > > can > > > > > > also be removed. As it exists today, the X bit is only being > used > > > > > for > > > > > > command restart, which is at attempt by the initiator to plug a > > > > > > potential hole in the CmdSN sequence at the target. It does this > > on > > > > > > failing to get an ExpCmdSN ack for a previously sent command > > within > > > > > > some > > > > > > timeout period. > > > > > > > > > > > > Given the above usage of command restart, no X bit is required > to > > be > > > > > > set > > > > > > in the SCSI Command PDU when command re-start is done. > > > > > > > > > > > > Either : > > > > > > (a) the target had dropped the command earlier due to a digest > > > > > error, > > > > > > in > > > > > > which case, the command restart plugs the CmdSN hole in the > > target. > > > > > > > > > > > > [OR] > > > > > > > > > > > > (b) the target had received the command and was working on it, > > when > > > > > > the > > > > > > initiator timed out too soon and attempted a command restart to > > plug > > > > > > [what it thought was] a possible hole in the CmdSN sequence. > > > > > > > > > > > > In case (a), no X bit was required, since the target knows > nothing > > > > > of > > > > > > the original command. In case (b), no X bit is required again, > > since > > > > > > the > > > > > > (ExpCmdSN, MaxCmdSN) window would have advanced and the target > can > > > > > > silently discard the received retry and continue working on the > > > > > > original > > > > > > command received. > > > > > > > > > > > > Removal of the X bit in the SCSI Command PDU has the following > > > > > > benefits > > > > > > : > > > > > > > > > > > > a) The CmdSN rules at the target are simplified. No need to look > > at > > > > > X > > > > > > bit, only validate received CmdSN with (ExpCmdSN, MaxCmdSN) > > window. > > > > > > > > > > > > b) The reject reason code "command already in progress" can be > > > > > > removed. > > > > > > There's no need for this reject reason code anymore, since X bit > > > > > > itself > > > > > > is not required, and the targets can silently discard commands > > > > > outside > > > > > > the command window and continue to work on the original instance > > of > > > > > > the > > > > > > command already being processed at the target. > > > > > > > > > > > > c) Less work for the target and less resources consumed since it > > no > > > > > > longer needs to generate a Reject PDU of type "command in > > progress". > > > > > > It > > > > > > can just silently discard any command PDU outside the (ExpCmdSN, > > > > > > MaxCmdSN) window. > > > > > > > > > > > > d) Less code for the target, since it does not need : > > > > > > - any Reject code paths when it receives X bit command PDUs that > > are > > > > > > already in progress. > > > > > > - No special casing of CmdSN checking rules. > > > > > > - No overheads of verifying a received command based on its > > > > > initiator > > > > > > task tag, to check if the task is currently active, prior to > > sending > > > > > a > > > > > > Reject response with "command in progress". > > > > > > > > > > > > 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 > > > > > > ################################## > > > > > > > > > > > > Santosh Rao > > > > > > > > > > hp.com> cc: > > > > Sent by: Subject: Re: iSCSI - > > Change > > > Proposal X bit > > > > owner-ips@ece. > > > > cmu.edu > > > > > > > > > > > > 23-10-01 22:50 > > > > Please respond > > > > to Santosh Rao > > > > > > > > > > > > > > > > Julian Satran wrote: > > > > > > > > > > However in order to drop "old" commands that might in the pipe on > a > > > > > sluggish connection - removing the X bit will require the > initiator > > to > > > > > issue an immediate NOP requiring a NOP response on every open > > > connection > > > > > whenever CmdSN wraps around (becomes equal to InitCmdSN). > > > > > > > > Julian, > > > > > > > > Can you please explain further the corner case you are describing > > above > > > > ? Are you suggesting that special action should be taken every time > > > > CmdSN wraps around, in case there were holes in the CmdSN sequence > at > > > > the wrap time ? Why is that ? > > > > > > > > Here's my understanding of how this plays out : > > > > > > > > Rule 1) > > > > The CmdSN management rules at the target should be handling CmdSN > wrap > > > > case and the initiator cannot issue more than 2^32 -1 commands > beyond > > > > the last ExpCmdSN update it has received from the target, since the > > > > target MUST NOT transmit a MaxCmdSN that is more than 2**31 - 1 > above > > > > the last ExpCmdSN. (per Section 2.2.2.1) > > > > > > > > Rule 2) > > > > Any holes that occur in the CmdSN sequence are attempted to be > plugged > > > > by the initiator by re-issuing the original command. If the CmdSN > > never > > > > got acknowledged and the I/O's ULP timeout expired, the initiator > MUST > > > > perform session recovery. (per Section 8.6) > > > > > > > > Thus, going by the above 2 rules, if the CmdSN sequence wraps upto > > > > ExpCmdSN, the initiator will not be able to issue further commands, > > > > since the target will keep the CmdSN window closed. The window can > > only > > > > re-open when the CmdSN holes are plugged allowing ExpCmdSN and > > thereby, > > > > MaxCmdSN to advance. (rule 1 above). > > > > > > > > Under the above circumstances, the initiator will possibly try to > plug > > > > the CmdSN hole by re-issuing the original command. It may do this 1 > or > > > > more times before its ULP timeout expires. Either the holes get > > plugged > > > > and the windoe re-opens, or ULP timeout occurs without the > > corresponding > > > > CmdSN for that I/O having been acknowledged, resulting in session > > > > logout. (rule 2 above). > > > > > > > > What is required over and beyond the above ? Why does removal of > X-bit > > > > require an immediate NOP to be issued every time CmdSN wraps and a > > hole > > > > exists in the CmdSN sequence (??). > > > > > > > > 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 Oct 27 18:37: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 SAA17017 for ; Sat, 27 Oct 2001 18:37:35 -0400 (EDT) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9RLPVL11760 for ips-outgoing; Sat, 27 Oct 2001 17:25: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 f9RLPTl11755 for ; Sat, 27 Oct 2001 17:25: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 RAA54616; Sat, 27 Oct 2001 17:22: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.98) with ESMTP id f9RLPRI251246; Sat, 27 Oct 2001 15:25:28 -0600 X-Priority: 1 (High) Importance: Normal Subject: RE: iSCSI: proposal to solve the ISID issues To: Michael Schoberg Cc: "IPS Reflector (E-mail)" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Sat, 27 Oct 2001 14:24:30 -0700 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/27/2001 03:25:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk First lets understand that the real name that is part of the I-T Nexus is InitiatorName+ISID as the Initiator part of the Nexus and the TargetName+PortalGroupTag as the Target Part of the Nexus. This is somewhat independent of Authentication. There are several levels that are part of the Authentication. We are attempting to not make the same mistake that we did in Fibre Channel, by making the Authentication based on a Network "Nozzle". We want to Authenticate on something larger -- the Initiator Node Name (InitiatorName) and its approved relationship to a Target Node Name (SCSI Device). To do this we have several things we need to worry about with security. 1. Is the link secure and able to handle secure traffic 2. Is the "User" who he says he is 3. Is the "User" permitted to use the specified Initiator 4. Is the Initiator permitted to use the specified Target Item 1 is the IPSec stuff to secure the link Item 2 is the iSCSI Authentication Items 3 and 4 deal with Access Control List (ACLs). With regards to Item 3 the user should be bound to a set of Initiators that he is permitted to use, if any, and whether this Login is claiming to be from one of them. This is needed because the user maybe permitted to move from one system to another Item 4 determines whether the specified Initiator is permitted to access this target. In some implementations I expect the vendor code will check if the User, when on the specified Initiator, is permitted to access this target (a more restrictive test). In None of the Points above (1-4) did we even talk about the ISID, TSID or SSID. These are Items that have to do with either the Nexus or the Session Management . Note that the Authentication and Security Process cares not at all about the SIDs. Also the Nexus cares only about the session end points and how the ISID, and PortalGroup_Tags qualify the names of the Initiator Node and Target Node so that the Session end points (SCSI Ports) TOTAL name is unique in the world. (That is the Initiator Node Name qualified by the ISID, and the Target Node Name when qualified by the PortalGroup_Tag is unique in the World.) The ISID and TSID when combined together give a unique handle to the session (SSID), and the SSID can be used bind the various connections together. That is its purpose, I think, that is its only purpose. The ISID has a dual purpose. It uniquely qualifies the Initiator Node Name, and is a part of the SSID. But it is important to understand that the SSID is not unique in the world, it is only Unique within the context of the Initiator SCSI Port and the Target SCSI Port Nexus. Your example of Controller 1, Controller 2 is somewhat confusing, I think you mean Host, or Initiator. Most of us think of Controller as Storage Controllers and they are usually Targets. However, please see comments below. Any way, It maybe the case that when you look at what I have said above, and what you have described, you might find that what you said is either addressed or not a problem in the way you said it. Also I have included Comments in your attached text. (Between [Huff/] and [/Huff].) . . . 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 10/26/2001 04:02:00 PM Sent by: owner-ips@ece.cmu.edu To: "IPS Reflector (E-mail)" cc: Subject: RE: iSCSI: proposal to solve the ISID issues I don't want to pour gas on this. I know a lot has gone into resolving this issue, and at one point I thought I understood it. After all the online debate I'm convinced I must be missing something. At this point I'm not even sure why SSID is useful. ISID // iSCSI initiator defined session ID + TSID // iSCSI target defined session ID ---- SSID // iSCSI Session ID == I_T NEXUS [Huff/] This is NOT correct, please see the above. [/Huff] Is SSID used to establish an I_T nexus? [/Huff] NO it is Not The Spec. Explicitly states that the SSID is NOT Equal to the I-T Nexus. [/Huff] But iSCSI uses login authentication to identify the initiator (InitiatorName=) & target (TargetName=). What extra information is being gained through SSID? [Huff/] SSID is used to identify the Sessions from the same Initiator Node to the same Target Node Combo. Please Note, This is NOT the same as Initiator SCSI Port to Target SCSI Port Nexus (Since, there is only one Session that is valid between the same two SCSI Ports.) [/Huff] [Login] InitiatorName=MyInitiator TargetName=YourTarget NexusID=controller_1 [Huff/] Where did you get the Syntax of NexusID??? That is not in the Spec. But in case you meant it only as a comment, that comment is Wrong! The Nexi are between Initiator and Target SCSI Ports, Not Initiator and Target Node Names (which is what the InitiatorName and TargetName are.) [/Huff] SSID use in LOGIN: 1) An unknown initiator sends an iSCSI login request to an iSCSI target address/port. 2) The target gathers the ISID, TSID, CID, X-Bit fields from the login request. This tells who the initiator is and what it's requesting. The target takes in all of this is with a grain of salt, because it's not yet sure the initiator is who it says it is. 3) Mutual security authentication takes place between the target and initiator. This may be as simple as "AuthMode=none", but in any case InitiatorName= and TargetName= have been stated and authenticated to the satisfaction of both. 4) The target looks back at ISID/TSID/CID/X-bits passed in the first login. Now it must decide whether or not it can continue or drop the connection. [Huff/] SSID (ISID/TSID) is only unique within the InitiatorName & TargetName Pair. And CID is only unique within a specific SSID. [/Huff] On TSID: How can a target determine this value such that each I-T nexus can be reformed consistently? The target must assign a TSID value each unique I-T nexus it can identify. It could use this new unique 6-byte ISID field, but an initiator could still masquerade as someone else: Controller A & B have valid logins to target X. Controller B knows controller A's ISID. Controller B specifies controller A's ISID in login. Controller B uses its InitiatorName= to pass authentication. Unless X knows the valid ISID values for login A/B, it will assign A's SSID to B. [Huff/] Please see my comments above on Authentication and ACLs. If steps 1-4 are done correctly, this is NOT an issue. [/Huff] This mistake can be avoided by using (TSID ~> InitiatorName). Each InitiatorName= allowed by the target is assigned a unique TID. Taking over someone's SSID now becomes a pure administration issue not a fault in the protocol. [Huff/] I think you created a problem that did not exist and then solved it. See comments above. [/Huff] On ISID: It's configured by the initiator. Whether it be a 16-bit or 48-bit value, the idea is to allow each vendor multiple controller instances (I of I_T nexus) if desired. This value is expected to be assigned and permanent with each I_T (portal group) nexus. [Huff/] That is what the proposal permits. That is, it permits the vendor, without worrying about other vendors or OS support which is not there, and may be implemented differently on different OSs, to Identify in a stable way their end of the I-T Nexi. [/Huff] So why does iSCSI use two methods of identification? [Huff/] They are different things, the ISID is only unique within an iSCSI Initiator Node. [/Huff] InitiatorName/TargetName requires super encryption algorithms for verification while ISID/TSID uses cleartext with the motto, "we trust you'll play nice." Why does iSCSI need SSID to describe the session at all? Why not roll it into the authentication parameters? [Huff/] The ISID is only a qualifier in the SCSI Port Name which is actually InitiatorName+ISID. And the TSID is not even used in the I-T Nexus. It is only part of the SSID. And the SSID is itself a Handle which only needs to be unique within an Initiator Node and Target Node pair. An implementation may decide to allocate the TSIDs such that they are unique within the iSCSI Target Node, thereby making all its SSIDs unique within the iSCSI Target Node, but that would limit the Target Node to 64k Sessions, which maybe fine for some, but that is NOT a requirement of the Protocol. [/Huff] Wrapping ISIDs into a new naming authority seems excessive for a local issue (SSIDs are local to each target)? Or is there a future iSCSI going to make SSIDs unique so they can be inherited along iSCSI networks? [Huff/] See answers above. [/Huff] : -----Original Message----- : From: Jim Hafner [mailto:hafner@almaden.ibm.com] : Sent: Friday, October 26, 2001 12:02 PM : To: ips@ece.cmu.edu : Subject: iSCSI: proposal to solve the ISID issues : : : Folks, (David Black in particular). : : Apologies for the long note, but the issue is complicated. : : The NDTeam have a proposal to resolve the concerns surrounding use of : ISIDs as essential components (along with iSCSI Initiator Name) of : SCSI Initiator Portname. (This was rooted in private discussions : between John Hufferd, Julian and myself -- and came about as a result : of the lengthy (and boring) discussions mostly myself and David : Black.) : : There are two somewhat orthogonal issues involved in this discussion: : : 1) How to coordinate ISIDs in the initiator to minimize the risk of : accidentally breaking the ISID RULE (no parallel nexus) when : independent vendors co-exist in the same OS. : : 2) What ISID "reuse" rules should be specified to facilitate current : and future (soon?) SCSI reservation semantics (and also internal OS : views of SCSI Initiator Ports). : : To address these two issues, we (NDT) propose the following: : : 1) Enlarge the ISID field in the Login Request and Response to 6bytes : and structure it with a component that corresponds to a "naming : authority" (essentially the vendor generating the ISID). So vendors : each have a piece of the ISID namespace to work with their own : components (HBAs, SW, etc). More details below. : : 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used as : conservatively as possible ("conservative reuse"). What this means is : that a given ISID should be reused for as many sessions (across : multiple target portal groups) as possible (but never to the same : target portal group twice -- that's the ISID RULE). : : NOTES and ADVANTAGES: : : (1-a) Each vendor owns his own piece of the ISID namespace, so in : effect, at the vendor-level, this provides a "partitioning" of that : namespace. : : (1-b) We don't need to specify an OS infrastructure requirement for : configuration of ISIDs -- each vendor can do it any way it chooses : (within its naming authority). : : (1-c) Breaking of the ISID RULE will only occur if a vendor messes up : its own implementation. : : (1-d) This is not fundamentally different from David Black's : suggestion for a "key"; it just (a) defines it precisely and (b) : embeds it in an already defined (but enlarged) field. : : (1-e) Looking towards the future, as common ISID coordination : mechanisms are implemented between vendors (say, SNIA banding together : to define a precise API), this "naming authority" can be elevated to : the coordinating entity or even the OS vendor. : : (1-f) ISIDs have no global uniqueness property. They need only be : unique between a named iSCSI initiator and iSCSI target portal group. : That means that a vendor implementation can use the same algorithm to : generate ISIDs (under its naming authority) in every machine (OS). : : (2-a) If a SCSI target (or logical unit) is holding state (say : persistent reservation) for a SCSI Initiator Port (named by iSCSI Name : and ISID), and the associated nexus/session is dropped for some : reason, "reuse" by that initiator of that ISID will restore to the : resulting new session that state (with no other action on the part of : the upper SCSI layers). : : (2-b) "Reuse" of an ISID on different sessions to (necessarily) : different SCSI Target Ports (iSCSI Target portal groups), will enable : the SCSI target/logical unit to recognize a common SCSI Initiator Port : for those two paths. This facilitates future changes to SCSI : reservations (at least). : : (2-c) An initiator driver implementated with "conservative reuse" can : present to the OS a stable and fairly static view of the SCSI : Initiator Ports (one for each ISID). Current OS driver stacks : (including current wedge drivers) that are built on the presumption of : such a stable view, will not need modification to handle the more : dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence of : a SCSI Initiator Port presented to the OS does not *require* that this : port discover all possible targets; what the initiator builds sessions : to using a specific ISID will determine what is presented to the OS as : "devices" and LUs visible to that SCSI Initiator Port (could be none : if that ISID is never actually used!).] : : (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator : Port is as simple as configuring another ISID! : : (2-e) Its debatable whether "conservative reuse" is a MUST or a : SHOULD. My personal opinion is "SHOULD", because many systems, : particularly low-end that don't use reservations, can function more or : less OK without it. This is an open question. : : DETAILS: : : 1) ISID Structure: : The 6byte ISID structure would be split into three parts: : "type" field (1byte) -- identifies the format of the naming : authority field : "naming authority" field (3bytes) -- identifies the vendor (or : group of vendors) generating this ISID : "qualifier" (2bytes) -- the free-space for ISID uniqueness : : The type field takes on three defined values with all other values : reserved: : Type naming authority format : 00h IEEE OUI : 01h IANA Enterprise Number (EN) : 02h "Random" : : The first types two provide a mechanism to uniquely (world wide) : identify the naming authority. A vendor with one or more OUIs and : possibly also Enterprise number MUST use at least one of these numbers : when it generates ISIDs. : : The "Random" type is for the case where the ISID generator (SW or HW) : is provided by an entity that has no OUI or EN. This includes, for : example, : -- a user-written program that builds sessions (and has access to the : system level iSCSI Name) : -- a university or other organization providing the component : -- a testing tool : : For the "Random" type, the naming authority field should be a random : or pseudo-random number. (See below on how this affects "conservative : reuse"). : : [Note: the "type" field needn't be this big, but NDT felt that (a) : 2bits was insufficient for the future, (b) the "type" field should be : first, and (c) the "naming authority" field should be byte-aligned.] : : 2) Conservative Reuse : : The "conservative reuse" principle of this proposal just says that : SCSI Initiator Portnames should be viewed as static things (as much as : possible) and reused (when feasible) to give the most stable : presentation of SCSI Initiator Ports to both the OS above and to SCSU : targets across the wire. : : Whereas the current draft says "The ISID RULE does not preclude the : use of the same ISID to different Target portal groups", the : "conservative reuse" requirement would say that such reuse (using the : same ISID to many target portal groups) is a SHOULD (or is that : MUST?). So, in one implementation, each iSCSI Initiator Portal group : would get configured with iSCSI Name, and a (small) set of ISIDs. The : portal group might take this set of ISIDs as an ordered list. The : first session to a Target portal group would use the first ISID, the : second to the *same* target portal group would use the second in the : list, etc. The number of ISIDs would then define a configuration : parameter that can be interpreted as the maximum number of sessions : that can be built to a given target portal group. : : To facilitate "conservative reuse", the "qualifier" field of a set of : ISIDs SHOULD be generated using either a repeatable algorithm : (non-random or pseudo-random but based on a fixed seed) or any : algorithm and stored in a persistent location (e.g., registry or /etc : file). : : For the "Random" type, "conservative reuse" may not be an issue (say, : user application that doesn't care about reservations, etc.). When it : is, the "naming authority" field SHOULD also be generated by a : mechanism similar to that for the "qualifier" field as specified above : (e.g., defined in the SW at compilation time.) : : : DOCUMENTATING CHANGES: : : The iscsi drafts would need the following minor changes to support : this proposal: : : NDT doc : (a) define the structure of the ISID field (as described above) : (b) add some notes about implementation in the presense of : "conservative reuse" (e.g., that ISID should be configured once, say : at install time, then reused on subsequent reboots, even for "Random" : type). : : iSCSI MAIN doc: : (a) move the CID field in Login Request to another reserved field. : (b) expand the ISID field in Login Request and Response to encompass : the previous 4 bytes. : (c) add a sentence where the ISID field is defined indicating that : this field is a structured value, showing the structure (as above) and : point to the NDT document. : (d) add some text to "Note to Implementors" on "conservative reuse". : : Comments? : : : Jim Hafner : From owner-ips@ece.cmu.edu Sun Oct 28 02:32: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 CAA08884 for ; Sun, 28 Oct 2001 02:32:07 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9S6pwT11368 for ips-outgoing; Sun, 28 Oct 2001 01:51:58 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9S6pul11360 for ; Sun, 28 Oct 2001 01:51:57 -0500 (EST) Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id GAA111324 for ; Sun, 28 Oct 2001 06:31:14 GMT Received: from d10hubm1.telaviv.ibm.com ([9.148.216.55]) by d06relay02_en0 (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA16454 for ; Sat, 27 Oct 2001 21:10:54 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI minimum PDU length X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 27 Oct 2001 19:57:01 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/10/2001 23:10:55, Serialize complete at 27/10/2001 23:10:55 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Steph, 512 is a good number for full feature phase if we stay with the current 8k during login (you have no framing anyhow during login - don't you?). The large binaries used by the security negotiation can become an issue otherwise. Julo Stephen Bailey Sent by: owner-ips@ece.cmu.edu 25-10-01 17:33 Please respond to Stephen Bailey To: ips@ece.cmu.edu cc: Subject: Re: iSCSI minimum PDU length > The minimum MSS is under 300 bytes. As I understand it, the minimum MSS is 8 bytes. Yes, this is a pathological case. What you really seem to be talking about here is the minimum allowable maximum PDU length, NOT, as the subject indicates, and JohnH points out, the true `minimum PDU length'. One number relevant to this discussion is the one below which you would not expect (or desire) good performance anyway. When MSS shrinks below this performance limit you may have to fall back to a slow path (e.g. reassembly & copying instead of on-the-fly direct placement) in your implementation, but you won't feel bad because you know there's no way performance could be good at that MSS under ANY circumstances. The minimum allowable maximum PDU length should be NO LARGER than this number. I personally think that you will want to maintain performance at an EMSS smaller than 1024. I agree with Dave that 512 is certainly headed in the right direction. Looking at it from the other direction, the minimum allowable maximum PDU could definitely be smaller than this performance target number. The lower limit is a result of the protocol design---what is the smallest limit larger than fixed sized PDUs which also allows variable sized PDUs to carry a minimum amount of data. There's no reason why the minimum allowable maximum PDU size could not be chosen to exactly fit the current iSCSI PDUs (or, within a power-of-two stones throw). Just because the protocol allows you to scale PDUs down to a minimum of xxx bytes and still operate does not mean that implementations won't chose a larger value for the limit of their performance design point. Implementations care about bounding the maximum PDU size. They must handle the smallest PDUs the protocol can create already anyway. In other words, nobody is going to say `ok, you mean I can make all the PDUs I send carry only 1 byte of data, GREAT! I'm going to do that'. Where you're headed, it really comes down to ensuring that all variably sized data can be chunked, which means you have to solve the chunking problem for text in one way or another. Steph From owner-ips@ece.cmu.edu Sun Oct 28 02: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 CAA08903 for ; Sun, 28 Oct 2001 02:32:10 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9S6pxw11373 for ips-outgoing; Sun, 28 Oct 2001 01:51:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from d06lmsgate.uk.ibm.COM (d06lmsgate.uk.ibm.com [195.212.29.1]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9S6pwl11367 for ; Sun, 28 Oct 2001 01:51:58 -0500 (EST) Received: from d06relay02.portsmouth.uk.ibm.com (d06relay02.portsmouth.uk.ibm.com [9.166.84.148]) by d06lmsgate.uk.ibm.COM (1.0.0) with ESMTP id GAA102600 for ; Sun, 28 Oct 2001 06:31:11 GMT Received: from d10hubm1.telaviv.ibm.com ([9.148.216.55]) by d06relay02_en0 (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA08890 for ; Sat, 27 Oct 2001 21:10:49 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI - Change Proposal X bit X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Sat, 27 Oct 2001 18:25:05 +0300 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 27/10/2001 23:10:50, Serialize complete at 27/10/2001 23:10:50 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk That is an interesting proposal. However since it won't work in face of an initiator that does not actively use the connection (your two prameters are per/session values determined by the initiator. I read Mallikarjun's proposal to add a stricter requirement on activity and thus avoid cleaning NOPs - as "send some non-immediate request that requires a response on every connection at least once in 2^31-1 CmdSN to include anything sent (no additional traffic). I intended to something close to your rule at the target to avoid increasing the window into the "dangerous zone" while not requiring a synchronous barrier at the initiator. Julo sandeepj@research.bell-labs.com (Sandeep Joshi) Sent by: owner-ips@ece.cmu.edu 27-10-01 03:08 Please respond to sandeepj To: cbm@rose.hp.com, ips@ece.cmu.edu cc: Subject: Re: iSCSI - Change Proposal X bit Mallikarjun, This problem can be solved _without_ introducing any additional I/O activity. Notice that it occurs because we allow the maxCmdSN to increase unbounded in the presence of unacked statSNs. The target can prevent this from happening. Imagine some connection A at the target : (1) Everytime the target sends a new statSN out, it records the cmdSN for that statSN (say Connection_A.cmdSN_of_last_statSN = 200) (2) While growing maxCmdSN at target, ensure that (maxCmdSN - Connection_A.cmdSN_of_last_statSN < 2^31-1) This is stricter than current condition (maxCmdSN - expCmdSN) < 2^31-1 If there are N connections, use least value of cmdSN_of_last_statSN. (3) All retried commands will always fall outside the window. They will be on the "dark side". (4) If the target cant grow maxCmdSN, it closes the offending connection, or sends out NOPs. Works ..? -Sandeep > In helping others walk through your scenario here in HP, > we all realized that the core solution to the problem > is to mandate a complete execution of a numbered command > (some I/O activity that is trackable) on each connection > once at least every (2^32 -1) commands. It may be a NOP, > or any regular command. So, here is my suggestion - > > An initiator MUST send at least one non-immediate command > on each of the connections participating in the session, > for every (2^31 -1) numbered commands. > > Comments? > -- > Mallikarjun From owner-ips@ece.cmu.edu Sun Oct 28 16:25: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 QAA16090 for ; Sun, 28 Oct 2001 16:25:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9SKZQR02448 for ips-outgoing; Sun, 28 Oct 2001 15:35:26 -0500 (EST) 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 f9SKZPl02444 for ; Sun, 28 Oct 2001 15:35:25 -0500 (EST) Received: from scummy.research.bell-labs.com ([135.104.2.10]) by dirty; Sun Oct 28 15:35:41 EST 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 f9SKZ4l03742; Sun, 28 Oct 2001 15:35:04 -0500 (EST) 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 PAA14214; Sun, 28 Oct 2001 15:35:03 -0500 (EST) Message-ID: <3BDC6BF7.1FF0D256@research.bell-labs.com> Date: Sun, 28 Oct 2001 15:35:03 -0500 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 - Change Proposal X bit References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit comments in text.. Julian Satran wrote: > > That is an interesting proposal. However since it won't work in face of an > initiator that does not actively use the connection (your two prameters > are per/session values determined by the initiator. I am not sure if I am catching this one..I think the problem you are referring to is as follows : When there is no difference between (expStatSN, statSN), the target must ignore "cmdSN_of_last_statSN" and _only_ use "expCmdSN" when growing the maxCmdSN. This involves some form of upcalls from the connection to the session manager. Then this scheme would work, but it gets architecturally complicated, as Mallikarjun already pointed out. Is this what you are also saying ? > > I read Mallikarjun's proposal to add a stricter requirement on activity > and thus avoid cleaning NOPs - as "send some non-immediate request that > requires a response on every connection at least once in 2^31-1 CmdSN to > include anything sent (no additional traffic). > > I intended to something close to your rule at the target to avoid > increasing the window into the "dangerous zone" while not requiring a > synchronous barrier at the initiator. Curious minds, interested in details .. -Sandeep > > Julo > > sandeepj@research.bell-labs.com (Sandeep Joshi) > Sent by: owner-ips@ece.cmu.edu > 27-10-01 03:08 > Please respond to sandeepj > > > To: cbm@rose.hp.com, ips@ece.cmu.edu > cc: > Subject: Re: iSCSI - Change Proposal X bit > > > > Mallikarjun, > > This problem can be solved _without_ introducing > any additional I/O activity. Notice that it > occurs because we allow the maxCmdSN to increase > unbounded in the presence of unacked statSNs. > > The target can prevent this from happening. > > Imagine some connection A at the target : > > (1) Everytime the target sends a new statSN out, it > records the cmdSN for that statSN > (say Connection_A.cmdSN_of_last_statSN = 200) > > (2) While growing maxCmdSN at target, ensure that > (maxCmdSN - Connection_A.cmdSN_of_last_statSN < 2^31-1) > > This is stricter than current condition > (maxCmdSN - expCmdSN) < 2^31-1 > > If there are N connections, use least value of > cmdSN_of_last_statSN. > > (3) All retried commands will always fall outside > the window. They will be on the "dark side". > > (4) If the target cant grow maxCmdSN, it closes the > offending connection, or sends out NOPs. > > Works ..? > > -Sandeep > > > In helping others walk through your scenario here in HP, > > we all realized that the core solution to the problem > > is to mandate a complete execution of a numbered command > > (some I/O activity that is trackable) on each connection > > once at least every (2^32 -1) commands. It may be a NOP, > > or any regular command. So, here is my suggestion - > > > > An initiator MUST send at least one non-immediate command > > on each of the connections participating in the session, > > for every (2^31 -1) numbered commands. > > > > Comments? > > -- > > Mallikarjun From owner-ips@ece.cmu.edu Mon Oct 29 03:06: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 DAA07123 for ; Mon, 29 Oct 2001 03:06:55 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9T79ac06529 for ips-outgoing; Mon, 29 Oct 2001 02:09:36 -0500 (EST) 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 f9T79Xl06521 for ; Mon, 29 Oct 2001 02:09:33 -0500 (EST) Received: by INTENS2 with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Oct 2001 09:11:30 +0200 Message-ID: <8B578C8302B3D411811200D0B7B64CD105E5CD@INTENS2> From: Ron Grinfeld To: ips@ece.cmu.edu Subject: iSCSI framing using TCP options Date: Mon, 29 Oct 2001 09:11:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Sender: owner-ips@ece.cmu.edu Precedence: bulk iSCSI framing using TCP options was raised and noted in an unofficial document (Jul/5/2000). Was this issue ever concluded ? If so what is the resolution ? __________________________________ Best regards, Ron Grinfeld Siliquent Technologies Ltd. Yigal Alon 126 St. Tel Aviv, Israel, 67443 Tel. +972 3 6948671 Fax. +972 3 6953736 From owner-ips@ece.cmu.edu Mon Oct 29 09:09: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 JAA13386 for ; Mon, 29 Oct 2001 09:09:01 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9TD9SS08477 for ips-outgoing; Mon, 29 Oct 2001 08:09:28 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from web14510.mail.yahoo.com (web14510.mail.yahoo.com [216.136.224.169]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f9TD9Rl08472 for ; Mon, 29 Oct 2001 08:09:27 -0500 (EST) Message-ID: <20011029130926.86753.qmail@web14510.mail.yahoo.com> Received: from [192.9.25.22] by web14510.mail.yahoo.com via HTTP; Mon, 29 Oct 2001 05:09:26 PST Date: Mon, 29 Oct 2001 05:09:26 -0800 (PST) From: S T Subject: remove To: ips@ece.cmu.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk remove __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com From owner-ips@ece.cmu.edu Mon Oct 29 16:25: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 QAA27517 for ; Mon, 29 Oct 2001 16:25:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9TK5qS12610 for ips-outgoing; Mon, 29 Oct 2001 15:05:52 -0500 (EST) 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 f9TK5ml12603 for ; Mon, 29 Oct 2001 15:05:48 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel13.hp.com (Postfix) with ESMTP id 968881FA84; Mon, 29 Oct 2001 12:05:41 -0800 (PST) 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 MAA09856; Mon, 29 Oct 2001 12:07:07 -0800 (PST) Message-Id: <200110292007.MAA09856@core.rose.hp.com> Date: Mon, 29 Oct 2001 12:17:49 -0800 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: Jim Hafner Cc: ips@ece.cmu.edu Subject: Re: iSCSI: proposal to solve the ISID issues 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, Thanks for the excellent summary. Some questions/comments - - I assume that the NICs must enable the configuration of iSCSI Node name even in this proposal. If it is so, please call this out as a hard requirement in the main modelling discussion. - In the case of multiple NICs from the same vendor operating in an end node, it appears to me that the proposal implicitly assumes an ISID-range to be configurable among those NICs (perhaps in vendor-unique ways, which is always what I expected). If this is a correct inference, there is again a hard requirement on the NICs to make the ISID range configurable. Please comment on any subtle qualitative change from the earlier situation that I may be missing. > (2-e) Its debatable whether "conservative reuse" is a MUST or a > SHOULD. My personal opinion is "SHOULD", because many systems, > particularly low-end that don't use reservations, can function more or > less OK without it. It seems we're attempting to set ourselves up for future in discussing the above requirement. Some questions - - It appears to me that the "conservative reuse" can not be enforced for initiators hosting NICs from different vendors (since the proposal allows ISID namespaces to be totally non-overlapping between non-homogenous NICs). Is this a fair assessment? - Do you see a particular disadvantage for low-end systems if it's mandated (aside from the fact that they may be able to live without it)? - Do you see any corner cases not being met (for future) if we don't make it a MUST (since you said "more or less OK")? Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Jim Hafner wrote: > > Folks, (David Black in particular). > > Apologies for the long note, but the issue is complicated. > > The NDTeam have a proposal to resolve the concerns surrounding use of > ISIDs as essential components (along with iSCSI Initiator Name) of > SCSI Initiator Portname. (This was rooted in private discussions > between John Hufferd, Julian and myself -- and came about as a result > of the lengthy (and boring) discussions mostly myself and David > Black.) > > There are two somewhat orthogonal issues involved in this discussion: > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > accidentally breaking the ISID RULE (no parallel nexus) when > independent vendors co-exist in the same OS. > > 2) What ISID "reuse" rules should be specified to facilitate current > and future (soon?) SCSI reservation semantics (and also internal OS > views of SCSI Initiator Ports). > > To address these two issues, we (NDT) propose the following: > > 1) Enlarge the ISID field in the Login Request and Response to 6bytes > and structure it with a component that corresponds to a "naming > authority" (essentially the vendor generating the ISID). So vendors > each have a piece of the ISID namespace to work with their own > components (HBAs, SW, etc). More details below. > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used as > conservatively as possible ("conservative reuse"). What this means is > that a given ISID should be reused for as many sessions (across > multiple target portal groups) as possible (but never to the same > target portal group twice -- that's the ISID RULE). > > NOTES and ADVANTAGES: > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > effect, at the vendor-level, this provides a "partitioning" of that > namespace. > > (1-b) We don't need to specify an OS infrastructure requirement for > configuration of ISIDs -- each vendor can do it any way it chooses > (within its naming authority). > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes up > its own implementation. > > (1-d) This is not fundamentally different from David Black's > suggestion for a "key"; it just (a) defines it precisely and (b) > embeds it in an already defined (but enlarged) field. > > (1-e) Looking towards the future, as common ISID coordination > mechanisms are implemented between vendors (say, SNIA banding together > to define a precise API), this "naming authority" can be elevated to > the coordinating entity or even the OS vendor. > > (1-f) ISIDs have no global uniqueness property. They need only be > unique between a named iSCSI initiator and iSCSI target portal group. > That means that a vendor implementation can use the same algorithm to > generate ISIDs (under its naming authority) in every machine (OS). > > (2-a) If a SCSI target (or logical unit) is holding state (say > persistent reservation) for a SCSI Initiator Port (named by iSCSI Name > and ISID), and the associated nexus/session is dropped for some > reason, "reuse" by that initiator of that ISID will restore to the > resulting new session that state (with no other action on the part of > the upper SCSI layers). > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > different SCSI Target Ports (iSCSI Target portal groups), will enable > the SCSI target/logical unit to recognize a common SCSI Initiator Port > for those two paths. This facilitates future changes to SCSI > reservations (at least). > > (2-c) An initiator driver implementated with "conservative reuse" can > present to the OS a stable and fairly static view of the SCSI > Initiator Ports (one for each ISID). Current OS driver stacks > (including current wedge drivers) that are built on the presumption of > such a stable view, will not need modification to handle the more > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence of > a SCSI Initiator Port presented to the OS does not *require* that this > port discover all possible targets; what the initiator builds sessions > to using a specific ISID will determine what is presented to the OS as > "devices" and LUs visible to that SCSI Initiator Port (could be none > if that ISID is never actually used!).] > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator > Port is as simple as configuring another ISID! > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > SHOULD. My personal opinion is "SHOULD", because many systems, > particularly low-end that don't use reservations, can function more or > less OK without it. This is an open question. > > DETAILS: > > 1) ISID Structure: > The 6byte ISID structure would be split into three parts: > "type" field (1byte) -- identifies the format of the naming > authority field > "naming authority" field (3bytes) -- identifies the vendor (or > group of vendors) generating this ISID > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > The type field takes on three defined values with all other values > reserved: > Type naming authority format > 00h IEEE OUI > 01h IANA Enterprise Number (EN) > 02h "Random" > > The first types two provide a mechanism to uniquely (world wide) > identify the naming authority. A vendor with one or more OUIs and > possibly also Enterprise number MUST use at least one of these numbers > when it generates ISIDs. > > The "Random" type is for the case where the ISID generator (SW or HW) > is provided by an entity that has no OUI or EN. This includes, for > example, > -- a user-written program that builds sessions (and has access to the > system level iSCSI Name) > -- a university or other organization providing the component > -- a testing tool > > For the "Random" type, the naming authority field should be a random > or pseudo-random number. (See below on how this affects "conservative > reuse"). > > [Note: the "type" field needn't be this big, but NDT felt that (a) > 2bits was insufficient for the future, (b) the "type" field should be > first, and (c) the "naming authority" field should be byte-aligned.] > > 2) Conservative Reuse > > The "conservative reuse" principle of this proposal just says that > SCSI Initiator Portnames should be viewed as static things (as much as > possible) and reused (when feasible) to give the most stable > presentation of SCSI Initiator Ports to both the OS above and to SCSU > targets across the wire. > > Whereas the current draft says "The ISID RULE does not preclude the > use of the same ISID to different Target portal groups", the > "conservative reuse" requirement would say that such reuse (using the > same ISID to many target portal groups) is a SHOULD (or is that > MUST?). So, in one implementation, each iSCSI Initiator Portal group > would get configured with iSCSI Name, and a (small) set of ISIDs. The > portal group might take this set of ISIDs as an ordered list. The > first session to a Target portal group would use the first ISID, the > second to the *same* target portal group would use the second in the > list, etc. The number of ISIDs would then define a configuration > parameter that can be interpreted as the maximum number of sessions > that can be built to a given target portal group. > > To facilitate "conservative reuse", the "qualifier" field of a set of > ISIDs SHOULD be generated using either a repeatable algorithm > (non-random or pseudo-random but based on a fixed seed) or any > algorithm and stored in a persistent location (e.g., registry or /etc > file). > > For the "Random" type, "conservative reuse" may not be an issue (say, > user application that doesn't care about reservations, etc.). When it > is, the "naming authority" field SHOULD also be generated by a > mechanism similar to that for the "qualifier" field as specified above > (e.g., defined in the SW at compilation time.) > > DOCUMENTATING CHANGES: > > The iscsi drafts would need the following minor changes to support > this proposal: > > NDT doc > (a) define the structure of the ISID field (as described above) > (b) add some notes about implementation in the presense of > "conservative reuse" (e.g., that ISID should be configured once, say > at install time, then reused on subsequent reboots, even for "Random" > type). > > iSCSI MAIN doc: > (a) move the CID field in Login Request to another reserved field. > (b) expand the ISID field in Login Request and Response to encompass > the previous 4 bytes. > (c) add a sentence where the ISID field is defined indicating that > this field is a structured value, showing the structure (as above) and > point to the NDT document. > (d) add some text to "Note to Implementors" on "conservative reuse". > > Comments? > > Jim Hafner From owner-ips@ece.cmu.edu Mon Oct 29 16:28: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 QAA27585 for ; Mon, 29 Oct 2001 16:28:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9TKnhr16319 for ips-outgoing; Mon, 29 Oct 2001 15:49:43 -0500 (EST) 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 f9TKngl16315 for ; Mon, 29 Oct 2001 15:49:42 -0500 (EST) 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 PAA66054; Mon, 29 Oct 2001 15:47:08 -0500 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9TKmNp252884; Mon, 29 Oct 2001 13:48:24 -0700 Importance: Normal Subject: Re: iSCSI: proposal to solve the ISID issues To: cbm@rose.hp.com Cc: ips@ece.cmu.edu From: "Jim Hafner" Date: Mon, 29 Oct 2001 12:48:21 -0800 Message-ID: X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/29/2001 12:48:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, Comments in line below Jim Hafner "Mallikarjun C." @core.rose.hp.com on 10/29/2001 12:17:49 pm Please respond to cbm@rose.hp.com Sent by: cbm@core.rose.hp.com To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: proposal to solve the ISID issues Jim, Thanks for the excellent summary. Some questions/comments - - I assume that the NICs must enable the configuration of iSCSI Node name even in this proposal. If it is so, please call this out as a hard requirement in the main modelling discussion. This requirement doesn't change from before (but how it gets written into the spec may differ -- and we've had this discussion before). If a vendor doesn't allow configuration of his NIC's iSCSI Node name, then his NICs will be acting as their own iSCSI Node (that is, not representing the system they live in). One can argue that this is a legitimate implementation (just as writing user-level code that uses its own iSCSI Node name). So a "hard requirement" may be a bit too strong. However, I will go with the will of the group on this point. What words do you suggest? - In the case of multiple NICs from the same vendor operating in an end node, it appears to me that the proposal implicitly assumes an ISID-range to be configurable among those NICs (perhaps in vendor-unique ways, which is always what I expected). If this is a correct inference, there is again a hard requirement on the NICs to make the ISID range configurable. Please comment on any subtle qualitative change from the earlier situation that I may be missing. Well, the point is that the vendor can manage his own namespace for his NICs anyway he/she/it wants to. Making them configurable (at initialization time, e.g., as a range of values) or making them dynamic (the driver generates them on demand) both fit the mold. So, I don't think this one is a hard requirement (though that is probably how most vendors will implement their NICs). In effect, the proposal gives vendors more flexibility in their own space, without causing heterogenous interoperability problems within the host. And a lot depends on how functional the NICs are: (a) just network nics, (b) protocol nics, but not session coordinating nics (c) full session coordination nics (with driver assist) (d) fully autonomous session nics. How do we make a requirement that fits all the cases correctly? You clearly have in mind a specific level of implementation within the NICs, but that may not be everybody's model. > (2-e) Its debatable whether "conservative reuse" is a MUST or a > SHOULD. My personal opinion is "SHOULD", because many systems, > particularly low-end that don't use reservations, can function more or > less OK without it. It seems we're attempting to set ourselves up for future in discussing the above requirement. Some questions - - It appears to me that the "conservative reuse" can not be enforced for initiators hosting NICs from different vendors (since the proposal allows ISID namespaces to be totally non-overlapping between non-homogenous NICs). Is this a fair assessment? Well, I don't think so. If each vendor implements "conservative reuse" within their own ISID namespace on their own NICs, then you get this property system wide. As before, by owning their own piece of the ISID namespace, they can implement what they want. So, you may have a situation where some of your installed nics have this property and some don't. You'll find out (if your environment really needs conservative reuse) that you haven't got it, and it becomes a marketing/purchase spec requirement. - Do you see a particular disadvantage for low-end systems if it's mandated (aside from the fact that they may be able to live without it)? No, but I don't see any way to really enforce it (or even really test it). It's not a requirement of the protocol, per se. - Do you see any corner cases not being met (for future) if we don't make it a MUST (since you said "more or less OK")? No, I can't see that far into the future! :-{). One reason I'm being cagey here is that I'm finding it difficult to find the right words to specify this as a hard requirement (but I'm no technical writer either!). Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Jim Hafner wrote: > > Folks, (David Black in particular). > > Apologies for the long note, but the issue is complicated. > > The NDTeam have a proposal to resolve the concerns surrounding use of > ISIDs as essential components (along with iSCSI Initiator Name) of > SCSI Initiator Portname. (This was rooted in private discussions > between John Hufferd, Julian and myself -- and came about as a result > of the lengthy (and boring) discussions mostly myself and David > Black.) > > There are two somewhat orthogonal issues involved in this discussion: > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > accidentally breaking the ISID RULE (no parallel nexus) when > independent vendors co-exist in the same OS. > > 2) What ISID "reuse" rules should be specified to facilitate current > and future (soon?) SCSI reservation semantics (and also internal OS > views of SCSI Initiator Ports). > > To address these two issues, we (NDT) propose the following: > > 1) Enlarge the ISID field in the Login Request and Response to 6bytes > and structure it with a component that corresponds to a "naming > authority" (essentially the vendor generating the ISID). So vendors > each have a piece of the ISID namespace to work with their own > components (HBAs, SW, etc). More details below. > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used as > conservatively as possible ("conservative reuse"). What this means is > that a given ISID should be reused for as many sessions (across > multiple target portal groups) as possible (but never to the same > target portal group twice -- that's the ISID RULE). > > NOTES and ADVANTAGES: > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > effect, at the vendor-level, this provides a "partitioning" of that > namespace. > > (1-b) We don't need to specify an OS infrastructure requirement for > configuration of ISIDs -- each vendor can do it any way it chooses > (within its naming authority). > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes up > its own implementation. > > (1-d) This is not fundamentally different from David Black's > suggestion for a "key"; it just (a) defines it precisely and (b) > embeds it in an already defined (but enlarged) field. > > (1-e) Looking towards the future, as common ISID coordination > mechanisms are implemented between vendors (say, SNIA banding together > to define a precise API), this "naming authority" can be elevated to > the coordinating entity or even the OS vendor. > > (1-f) ISIDs have no global uniqueness property. They need only be > unique between a named iSCSI initiator and iSCSI target portal group. > That means that a vendor implementation can use the same algorithm to > generate ISIDs (under its naming authority) in every machine (OS). > > (2-a) If a SCSI target (or logical unit) is holding state (say > persistent reservation) for a SCSI Initiator Port (named by iSCSI Name > and ISID), and the associated nexus/session is dropped for some > reason, "reuse" by that initiator of that ISID will restore to the > resulting new session that state (with no other action on the part of > the upper SCSI layers). > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > different SCSI Target Ports (iSCSI Target portal groups), will enable > the SCSI target/logical unit to recognize a common SCSI Initiator Port > for those two paths. This facilitates future changes to SCSI > reservations (at least). > > (2-c) An initiator driver implementated with "conservative reuse" can > present to the OS a stable and fairly static view of the SCSI > Initiator Ports (one for each ISID). Current OS driver stacks > (including current wedge drivers) that are built on the presumption of > such a stable view, will not need modification to handle the more > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence of > a SCSI Initiator Port presented to the OS does not *require* that this > port discover all possible targets; what the initiator builds sessions > to using a specific ISID will determine what is presented to the OS as > "devices" and LUs visible to that SCSI Initiator Port (could be none > if that ISID is never actually used!).] > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator > Port is as simple as configuring another ISID! > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > SHOULD. My personal opinion is "SHOULD", because many systems, > particularly low-end that don't use reservations, can function more or > less OK without it. This is an open question. > > DETAILS: > > 1) ISID Structure: > The 6byte ISID structure would be split into three parts: > "type" field (1byte) -- identifies the format of the naming > authority field > "naming authority" field (3bytes) -- identifies the vendor (or > group of vendors) generating this ISID > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > The type field takes on three defined values with all other values > reserved: > Type naming authority format > 00h IEEE OUI > 01h IANA Enterprise Number (EN) > 02h "Random" > > The first types two provide a mechanism to uniquely (world wide) > identify the naming authority. A vendor with one or more OUIs and > possibly also Enterprise number MUST use at least one of these numbers > when it generates ISIDs. > > The "Random" type is for the case where the ISID generator (SW or HW) > is provided by an entity that has no OUI or EN. This includes, for > example, > -- a user-written program that builds sessions (and has access to the > system level iSCSI Name) > -- a university or other organization providing the component > -- a testing tool > > For the "Random" type, the naming authority field should be a random > or pseudo-random number. (See below on how this affects "conservative > reuse"). > > [Note: the "type" field needn't be this big, but NDT felt that (a) > 2bits was insufficient for the future, (b) the "type" field should be > first, and (c) the "naming authority" field should be byte-aligned.] > > 2) Conservative Reuse > > The "conservative reuse" principle of this proposal just says that > SCSI Initiator Portnames should be viewed as static things (as much as > possible) and reused (when feasible) to give the most stable > presentation of SCSI Initiator Ports to both the OS above and to SCSU > targets across the wire. > > Whereas the current draft says "The ISID RULE does not preclude the > use of the same ISID to different Target portal groups", the > "conservative reuse" requirement would say that such reuse (using the > same ISID to many target portal groups) is a SHOULD (or is that > MUST?). So, in one implementation, each iSCSI Initiator Portal group > would get configured with iSCSI Name, and a (small) set of ISIDs. The > portal group might take this set of ISIDs as an ordered list. The > first session to a Target portal group would use the first ISID, the > second to the *same* target portal group would use the second in the > list, etc. The number of ISIDs would then define a configuration > parameter that can be interpreted as the maximum number of sessions > that can be built to a given target portal group. > > To facilitate "conservative reuse", the "qualifier" field of a set of > ISIDs SHOULD be generated using either a repeatable algorithm > (non-random or pseudo-random but based on a fixed seed) or any > algorithm and stored in a persistent location (e.g., registry or /etc > file). > > For the "Random" type, "conservative reuse" may not be an issue (say, > user application that doesn't care about reservations, etc.). When it > is, the "naming authority" field SHOULD also be generated by a > mechanism similar to that for the "qualifier" field as specified above > (e.g., defined in the SW at compilation time.) > > DOCUMENTATING CHANGES: > > The iscsi drafts would need the following minor changes to support > this proposal: > > NDT doc > (a) define the structure of the ISID field (as described above) > (b) add some notes about implementation in the presense of > "conservative reuse" (e.g., that ISID should be configured once, say > at install time, then reused on subsequent reboots, even for "Random" > type). > > iSCSI MAIN doc: > (a) move the CID field in Login Request to another reserved field. > (b) expand the ISID field in Login Request and Response to encompass > the previous 4 bytes. > (c) add a sentence where the ISID field is defined indicating that > this field is a structured value, showing the structure (as above) and > point to the NDT document. > (d) add some text to "Note to Implementors" on "conservative reuse". > > Comments? > > Jim Hafner From owner-ips@ece.cmu.edu Mon Oct 29 19:30: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 TAA00845 for ; Mon, 29 Oct 2001 19:30:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9TNSdV28960 for ips-outgoing; Mon, 29 Oct 2001 18:28:39 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sheffield.xo.com (sheffield.xo.com [207.155.252.71]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9TNSal28947 for ; Mon, 29 Oct 2001 18:28:37 -0500 (EST) Received: from blekinge ([66.89.96.162]) by sheffield.xo.com id SAA17250; Mon, 29 Oct 2001 18:28:35 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <002101c160d1$55626e30$1001010a@blekinge> From: "Peter Mellquist" To: Subject: Re: iSCSI: NOPs on discovery session Date: Mon, 29 Oct 2001 15:27:53 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C1608E.46CFA380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C1608E.46CFA380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Changes to targets/LUNs should be announced via unsolicited SLP. Since = we are already pushing SLP, it makes sense to use it. A target server = utilizing SLP in this manner would not need a long lived discovery session around. = As far as 'pinging' the target via a NOP-OUT I'm not sure of the intent?? = If one would like to determine if the target server is up and running, this = can also be accomplished via standard protocols such as SNMP. Is there = currently an iSCSI MIB object to determine the health/status of a target server? = MIB objects=20 could be used to monitor the status / health of each session as well. -peter Peter Mellquist Seven-Systems ----- Original Message ----- From: "Julian Satran" To: Sent: Friday, October 26, 2001 12:38 AM Subject: Re: iSCSI: NOPs on discovery session > Ron, > > We are defining a wire protocol so that we should not be concerned if > closing is mandatary or not. > An open discovery session could be used (with proprietary exchanges) = to > announce new LUN and target creation. > > Julo > > > > > "Ron Cohen" > Sent by: owner-ips@ece.cmu.edu > 26-10-01 08:16 > Please respond to "Ron Cohen" > > > To: "ips" > cc: > Subject: Re: iSCSI: NOPs on discovery session > > > > This brings up an interesting point: > > Is it intended that discovery sessions remain open? > Should an initiator close a discovery session after the SendTargets > command > has completed? > Should a target request a logout and session closure if an initiator = does > not close the session? > What would the application of leaving a discovery session open be? > > Ron > > > ----- Original Message ----- > From: "Ayman Ghanem" > To: > Sent: Friday, October 26, 2001 4:29 AM > Subject: iSCSI: NOPs on discovery session > > > > Julian, > > > > I am not sure if this came up before, but we also need to include > NOP-OUT > to > > the set of commands allowed on the discovery session. An initiator = may > keep > > the discovery session active, and send NOP-OUT to ping the target, = or in > > response to a target ping. > > > > -Ayman > > > > > > > > > ------=_NextPart_000_001E_01C1608E.46CFA380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Changes to targets/LUNs should be = announced via=20 unsolicited SLP. Since we
are already pushing SLP, it makes sense to = use it.=20 A target server utilizing
SLP in this manner would not need a long = lived=20 discovery session around. As
far as 'pinging' the target via a = NOP-OUT I'm=20 not sure of the intent?? If
one would like to determine if the target = server=20 is up and running, this can
also be accomplished via standard = protocols such=20 as SNMP. Is there currently
an iSCSI MIB object to determine the=20 health/status of a target server? MIB objects
could be used to=20 monitor the status / health of each session as=20 well.


-peter

Peter = Mellquist
Seven-Systems


-----=20 Original Message -----
From: "Julian Satran" <Julian_Satran@il.ibm.com>=
To:=20 <ips@ece.cmu.edu>
Sent: = Friday,=20 October 26, 2001 12:38 AM
Subject: Re: iSCSI: NOPs on discovery=20 session


> Ron,
>
> We are defining a wire = protocol so=20 that we should not be concerned if
> closing is mandatary or = not.
>=20 An open discovery session could be used (with proprietary exchanges) = to
>=20 announce new LUN and target creation.
>
>=20 Julo
>
>
>
>
> "Ron Cohen" <rcohen@eurologic.com>
>= Sent by:=20 owner-ips@ece.cmu.edu
>=20 26-10-01 08:16
> Please respond to "Ron=20 Cohen"
>
>
>       &= nbsp;=20 To:     "ips" <ips@ece.cmu.edu>
> &nbs= p;      =20 cc:
>        =20 Subject:        Re: iSCSI: NOPs on = discovery=20 session
>
>
>
> This brings up an interesting=20 point:
>
> Is it intended that discovery sessions remain=20 open?
> Should an initiator close a discovery session after the=20 SendTargets
> command
> has completed?
> Should a = target=20 request a logout and session closure if an initiator does
> not = close the=20 session?
> What would the application of leaving a discovery = session open=20 be?
>
> Ron
>
>
> ----- Original Message=20 -----
> From: "Ayman Ghanem" <aghanem@cisco.com>
> To: = <ips@ece.cmu.edu>
> Sent: = Friday,=20 October 26, 2001 4:29 AM
> Subject: iSCSI: NOPs on discovery=20 session
>
>
> > Julian,
> >
> > I = am not=20 sure if this came up before, but we also need to include
> = NOP-OUT
>=20 to
> > the set of commands allowed on the discovery session. An = initiator may
> keep
> > the discovery session active, = and send=20 NOP-OUT to ping the target, or in
> > response to a target=20 ping.
> >
> > -Ayman
> >
>=20 >
>
>
>
>
>
------=_NextPart_000_001E_01C1608E.46CFA380-- From owner-ips@ece.cmu.edu Mon Oct 29 20: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 UAA01928 for ; Mon, 29 Oct 2001 20:51:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9U1CJ505989 for ips-outgoing; Mon, 29 Oct 2001 20:12:19 -0500 (EST) 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 f9U1CIl05984 for ; Mon, 29 Oct 2001 20:12:18 -0500 (EST) Received: from core.rose.hp.com (unknown [15.43.208.100]) by atlrel6.hp.com (Postfix) with ESMTP id 67C0A1F518; Mon, 29 Oct 2001 20:12:12 -0500 (EST) 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 RAA16013; Mon, 29 Oct 2001 17:13:37 -0800 (PST) Message-Id: <200110300113.RAA16013@core.rose.hp.com> Date: Mon, 29 Oct 2001 17:24:20 -0800 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: Jim Hafner Cc: ips@ece.cmu.edu Subject: Re: iSCSI: proposal to solve the ISID issues 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, Thanks for the quick response. As much as I would like to avoid consuming more bandwidth on this topic, let me make one last strawman for wording below. > What words do you suggest? ... > And a lot depends on how > functional the NICs are: (a) just network nics, (b) protocol nics, but not > session coordinating nics (c) full session coordination nics (with driver > assist) (d) fully autonomous session nics. How do we make a requirement > that fits all the cases correctly? I have been implying iSCSI NICs in all my postings so far - sorry, may be that wasn't very clear. "iSCSI Node name" comment obviously wasn't targeted at simple network NICs. So clearly (a) is out of discussion. But you are right - I wasn't very precise. Here's a strawman - All iSCSI hardware implementations (as in NICs) MUST allow the iSCSI Node Name to be externally configurable. All iSCSI initiator hardware implementations MUST in addition also support the the operational ISID values to be (either statically or dynamically) externally configurable. > Making them configurable (at > initialization time, e.g., as a range of values) or making them dynamic > (the driver generates them on demand) both fit the mold. So, I don't think > this one is a hard requirement. I agree that my earlier "range" wording was too constraining. My point though is that by banning a duplicate nexus (that an inadvertently re-used ISID allows), we are making the ISID (dynamic/static) distribution an imminent hard requirement for all NICs in a given iSCSI initiator Node - except it is not sufficiently explicit. Please consider the above proposed wording. > Well, I don't think so. If each vendor implements "conservative reuse" > within their own ISID namespace on their own NICs, then you get this > property system wide. You are right, I guess I briefly overlooked the fact that ISID includes the vendor identifier within, per the new proposal. I am personally okay with making "conservative reuse" a SHOULD. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Jim Hafner wrote: > > Mallikarjun, > > Comments in line below > > Jim Hafner > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 12:17:49 > pm > > Please respond to cbm@rose.hp.com > > Sent by: cbm@core.rose.hp.com > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > Jim, > > Thanks for the excellent summary. Some questions/comments - > > - I assume that the NICs must enable the configuration of > iSCSI Node name even in this proposal. If it is so, please > call this out as a hard requirement in the main modelling > discussion. > > > This requirement doesn't change from before (but how it gets written into > the spec may differ -- and we've had this discussion before). If a vendor > doesn't allow configuration of his NIC's iSCSI Node name, then his NICs > will be acting as their own iSCSI Node (that is, not representing the > system they live in). One can argue that this is a legitimate > implementation (just as writing user-level code that uses its own iSCSI > Node name). So a "hard requirement" may be a bit too strong. However, I > will go with the will of the group on this point. > > What words do you suggest? > > - In the case of multiple NICs from the same vendor operating > in an end node, it appears to me that the proposal implicitly > assumes an ISID-range to be configurable among those NICs > (perhaps in vendor-unique ways, which is always what I expected). > If this is a correct inference, there is again a hard > requirement on the NICs to make the ISID range configurable. > Please comment on any subtle qualitative change from the > earlier situation that I may be missing. > > > Well, the point is that the vendor can manage his own namespace for his > NICs anyway he/she/it wants to. Making them configurable (at > initialization time, e.g., as a range of values) or making them dynamic > (the driver generates them on demand) both fit the mold. So, I don't think > this one is a hard requirement (though that is probably how most vendors > will implement their NICs). In effect, the proposal gives vendors more > flexibility in their own space, without causing heterogenous > interoperability problems within the host. And a lot depends on how > functional the NICs are: (a) just network nics, (b) protocol nics, but not > session coordinating nics (c) full session coordination nics (with driver > assist) (d) fully autonomous session nics. How do we make a requirement > that fits all the cases correctly? You clearly have in mind a specific > level of implementation within the NICs, but that may not be everybody's > model. > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > SHOULD. My personal opinion is "SHOULD", because many systems, > > particularly low-end that don't use reservations, can function more or > > less OK without it. > > It seems we're attempting to set ourselves up for future in > discussing the above requirement. Some questions - > - It appears to me that the "conservative reuse" can not > be enforced for initiators hosting NICs from different > vendors (since the proposal allows ISID namespaces to > be totally non-overlapping between non-homogenous NICs). > Is this a fair assessment? > > Well, I don't think so. If each vendor implements "conservative reuse" > within their own ISID namespace on their own NICs, then you get this > property system wide. As before, by owning their own piece of the ISID > namespace, they can implement what they want. So, you may have a situation > where some of your installed nics have this property and some don't. > You'll find out (if your environment really needs conservative reuse) that > you haven't got it, and it becomes a marketing/purchase spec requirement. > > - Do you see a particular disadvantage for low-end systems > if it's mandated (aside from the fact that they may be able > to live without it)? > > No, but I don't see any way to really enforce it (or even really test it). > It's not a requirement of the protocol, per se. > > - Do you see any corner cases not being met (for future) > if we don't make it a MUST (since you said "more or less OK")? > > No, I can't see that far into the future! :-{). One reason I'm being cagey > here is that I'm finding it difficult to find the right words to specify > this as a hard requirement (but I'm no technical writer either!). > > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Jim Hafner wrote: > > > > Folks, (David Black in particular). > > > > Apologies for the long note, but the issue is complicated. > > > > The NDTeam have a proposal to resolve the concerns surrounding use of > > ISIDs as essential components (along with iSCSI Initiator Name) of > > SCSI Initiator Portname. (This was rooted in private discussions > > between John Hufferd, Julian and myself -- and came about as a result > > of the lengthy (and boring) discussions mostly myself and David > > Black.) > > > > There are two somewhat orthogonal issues involved in this discussion: > > > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > > accidentally breaking the ISID RULE (no parallel nexus) when > > independent vendors co-exist in the same OS. > > > > 2) What ISID "reuse" rules should be specified to facilitate current > > and future (soon?) SCSI reservation semantics (and also internal OS > > views of SCSI Initiator Ports). > > > > To address these two issues, we (NDT) propose the following: > > > > 1) Enlarge the ISID field in the Login Request and Response to 6bytes > > and structure it with a component that corresponds to a "naming > > authority" (essentially the vendor generating the ISID). So vendors > > each have a piece of the ISID namespace to work with their own > > components (HBAs, SW, etc). More details below. > > > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used as > > conservatively as possible ("conservative reuse"). What this means is > > that a given ISID should be reused for as many sessions (across > > multiple target portal groups) as possible (but never to the same > > target portal group twice -- that's the ISID RULE). > > > > NOTES and ADVANTAGES: > > > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > > effect, at the vendor-level, this provides a "partitioning" of that > > namespace. > > > > (1-b) We don't need to specify an OS infrastructure requirement for > > configuration of ISIDs -- each vendor can do it any way it chooses > > (within its naming authority). > > > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes up > > its own implementation. > > > > (1-d) This is not fundamentally different from David Black's > > suggestion for a "key"; it just (a) defines it precisely and (b) > > embeds it in an already defined (but enlarged) field. > > > > (1-e) Looking towards the future, as common ISID coordination > > mechanisms are implemented between vendors (say, SNIA banding together > > to define a precise API), this "naming authority" can be elevated to > > the coordinating entity or even the OS vendor. > > > > (1-f) ISIDs have no global uniqueness property. They need only be > > unique between a named iSCSI initiator and iSCSI target portal group. > > That means that a vendor implementation can use the same algorithm to > > generate ISIDs (under its naming authority) in every machine (OS). > > > > (2-a) If a SCSI target (or logical unit) is holding state (say > > persistent reservation) for a SCSI Initiator Port (named by iSCSI Name > > and ISID), and the associated nexus/session is dropped for some > > reason, "reuse" by that initiator of that ISID will restore to the > > resulting new session that state (with no other action on the part of > > the upper SCSI layers). > > > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > > different SCSI Target Ports (iSCSI Target portal groups), will enable > > the SCSI target/logical unit to recognize a common SCSI Initiator Port > > for those two paths. This facilitates future changes to SCSI > > reservations (at least). > > > > (2-c) An initiator driver implementated with "conservative reuse" can > > present to the OS a stable and fairly static view of the SCSI > > Initiator Ports (one for each ISID). Current OS driver stacks > > (including current wedge drivers) that are built on the presumption of > > such a stable view, will not need modification to handle the more > > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence of > > a SCSI Initiator Port presented to the OS does not *require* that this > > port discover all possible targets; what the initiator builds sessions > > to using a specific ISID will determine what is presented to the OS as > > "devices" and LUs visible to that SCSI Initiator Port (could be none > > if that ISID is never actually used!).] > > > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator > > Port is as simple as configuring another ISID! > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > SHOULD. My personal opinion is "SHOULD", because many systems, > > particularly low-end that don't use reservations, can function more or > > less OK without it. This is an open question. > > > > DETAILS: > > > > 1) ISID Structure: > > The 6byte ISID structure would be split into three parts: > > "type" field (1byte) -- identifies the format of the naming > > authority field > > "naming authority" field (3bytes) -- identifies the vendor (or > > group of vendors) generating this ISID > > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > > > The type field takes on three defined values with all other values > > reserved: > > Type naming authority format > > 00h IEEE OUI > > 01h IANA Enterprise Number (EN) > > 02h "Random" > > > > The first types two provide a mechanism to uniquely (world wide) > > identify the naming authority. A vendor with one or more OUIs and > > possibly also Enterprise number MUST use at least one of these numbers > > when it generates ISIDs. > > > > The "Random" type is for the case where the ISID generator (SW or HW) > > is provided by an entity that has no OUI or EN. This includes, for > > example, > > -- a user-written program that builds sessions (and has access to the > > system level iSCSI Name) > > -- a university or other organization providing the component > > -- a testing tool > > > > For the "Random" type, the naming authority field should be a random > > or pseudo-random number. (See below on how this affects "conservative > > reuse"). > > > > [Note: the "type" field needn't be this big, but NDT felt that (a) > > 2bits was insufficient for the future, (b) the "type" field should be > > first, and (c) the "naming authority" field should be byte-aligned.] > > > > 2) Conservative Reuse > > > > The "conservative reuse" principle of this proposal just says that > > SCSI Initiator Portnames should be viewed as static things (as much as > > possible) and reused (when feasible) to give the most stable > > presentation of SCSI Initiator Ports to both the OS above and to SCSU > > targets across the wire. > > > > Whereas the current draft says "The ISID RULE does not preclude the > > use of the same ISID to different Target portal groups", the > > "conservative reuse" requirement would say that such reuse (using the > > same ISID to many target portal groups) is a SHOULD (or is that > > MUST?). So, in one implementation, each iSCSI Initiator Portal group > > would get configured with iSCSI Name, and a (small) set of ISIDs. The > > portal group might take this set of ISIDs as an ordered list. The > > first session to a Target portal group would use the first ISID, the > > second to the *same* target portal group would use the second in the > > list, etc. The number of ISIDs would then define a configuration > > parameter that can be interpreted as the maximum number of sessions > > that can be built to a given target portal group. > > > > To facilitate "conservative reuse", the "qualifier" field of a set of > > ISIDs SHOULD be generated using either a repeatable algorithm > > (non-random or pseudo-random but based on a fixed seed) or any > > algorithm and stored in a persistent location (e.g., registry or /etc > > file). > > > > For the "Random" type, "conservative reuse" may not be an issue (say, > > user application that doesn't care about reservations, etc.). When it > > is, the "naming authority" field SHOULD also be generated by a > > mechanism similar to that for the "qualifier" field as specified above > > (e.g., defined in the SW at compilation time.) > > > > DOCUMENTATING CHANGES: > > > > The iscsi drafts would need the following minor changes to support > > this proposal: > > > > NDT doc > > (a) define the structure of the ISID field (as described above) > > (b) add some notes about implementation in the presense of > > "conservative reuse" (e.g., that ISID should be configured once, say > > at install time, then reused on subsequent reboots, even for "Random" > > type). > > > > iSCSI MAIN doc: > > (a) move the CID field in Login Request to another reserved field. > > (b) expand the ISID field in Login Request and Response to encompass > > the previous 4 bytes. > > (c) add a sentence where the ISID field is defined indicating that > > this field is a structured value, showing the structure (as above) and > > point to the NDT document. > > (d) add some text to "Note to Implementors" on "conservative reuse". > > > > Comments? > > > > Jim Hafner From owner-ips@ece.cmu.edu Mon Oct 29 20:56: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 UAA02015 for ; Mon, 29 Oct 2001 20:56:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9U0iG104141 for ips-outgoing; Mon, 29 Oct 2001 19:44:16 -0500 (EST) 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 f9U0iDl04135 for ; Mon, 29 Oct 2001 19:44:13 -0500 (EST) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id TAA15624 for ; Mon, 29 Oct 2001 19:44:13 -0500 (EST) Date: Mon, 29 Oct 2001 19:44:12 -0500 From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: iSCSI: current UNH Plugfest Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Attached are some of the issues that arose during the first day of the iSCSI plugfest at UNH on Monday 29-Oct-2001. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 ---------------------------------------------------------------------------- 1. Situation: the very first command sent on a new connection is a login. However, the I bit is not set. What should the target do? Interpretation 1: According to section 8.3 page 127 of draft 8, "Explicit violations of the PDU layout rules stated in this document are format errors." "When a target or an initiator receives an iSCSI PDU with a format error, it MUST reset all transport connections in the session immediately ..." This is a format error so section 8.3 applies. Therefore, the target should simply close the connection without sending anything to the initiator. Interpretation 2: This is a login command that contains an error caused by the initiator. Therefore, the target should send back a login response with a status code of 0x0200 and then close the TCP connection. 2. Situation: on the first login command in operational parameter negotiation stage, the initiator sends the keys InitialR2T=yes and ImmediateData=no and the target agrees with these values. Therefore, according to the table on page 182 of draft 8, both sides agree that unsolicited data is disallowed. These keys are then followed, either later in the keys associated with this same login command or in a subsequent login command belonging to the same login phase, with the key FirstBurstSize=6. What should the target do? Interpretation 1: FirstBurstSize indicates "the maximum amount of unsolicited data an iSCSI initiator may send to the target during the execution of a single SCSI command, in units of 512 bytes." However unsolicited data is now disallowed, so FirstBurstSize is irrelevant. Therefore, no response is necessary -- the key is just ignored. Interpretation 2: In section 2.2.4 on page 30 of draft 8 it says "For numerical negotiations, the responding party MUST respond with the required key." Since FirstBurstSize is a numerical key, the target MUST respond with a numeric value ("reject" is not allowed for numerical keys), even if the value is irrelevant and will not be used. 3. Situation: As the first command on a new connection the initiator sends a valid login command with SessionType=discovery, CSG=0, NSG=3, and T=1. The target responds with CSG=0, NSG=1 and T=1. So both sides are now in the operational parameter negotiation stage. Question: what parameters can they negotiate in this stage for a discovery session, and what should be done if other, irrelevant, parameters are negotiated? Interpretation 1: The only relevant operational parameters in a discovery session seem to be those related to markers (FMarker, RFMarkInt, SFMarkInt), error recovery (ErrorRecoveryLevel) and vendor specific keys. If this is true, what should one side do when the other side attempts to negotiate other operational parameters in a discovery session? Interpretation 2: Even the relevant operational parameters in a discovery session given above have very marginal utility. It would be easier to just disallow all operational parameter negotiation in a discovery session. 4. Contradiction in draft 8. In section 3.13.5 on page 92 it says that in a login response: "for a non-zero Status-Class the T, CSG & NSG fields MUST be 0." In section 5.1 on page 112 it says that in a login response with login reject (i.e., Status-Class non-zero): "The T bit of the response MUST be set to 1 and the CSG and NSG are ignored." One of these has to be changed. Note also that the second statement just given (from page 112) is inconsistent with the statement in section 3.12.4 on page 87 that for login requests: "the next stage value is valid only when the T bit is 1 and is reserved otherwise." One would expect the standard to have the same rule for the way the T, NSG and CSG fields are handled in both login request and login response. 5. Clarification suggested: In section 3.13.4 on page 91 of draft 8 it says: "For the first Login Response (the response to the first Login Request) this is the starting status Sequence Number for the connection (the next response of any kind will carry this number + 1)." If the login phase requires more than one login-request/login-response exchange, this rule implies that the second (third, fourth, ...) login-response should be incrementing StatSN. Nobody was doing this, although it seems clear that the standard requires it. Perhaps there needs to be a slight addition to the wording of this section so it reads: "For the first Login Response (the response to the first Login Request) this is the starting status Sequence Number for the connection (the next response of any kind, including the next login response if any in the same login phase, will carry this number + 1)." 6. Situations where frequent errors or misunderstandings occured, although the draft seems clear: 1. - StatSN must be incremented in Login Phase (point 5 above) 2. - CmdSN must not be incremented CmdSN in Login Phase 3. - it is okay to transmit the first command of the Login Phase with the CSG set to 1. It is also okay for the target to reject it and to close the connection. 4. - If the Initiator transmits its first command of the Login Phase with the T bit set, its okay for the target to transmit a response with T = 0, even though there is no example in the draft demonstrating it. 5. - Stage Transitions from 0 to 3 are valid according to the spec although this is not specifically stated in the draft. From owner-ips@ece.cmu.edu Mon Oct 29 21:58: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 VAA03653 for ; Mon, 29 Oct 2001 21:58:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9U1knF08219 for ips-outgoing; Mon, 29 Oct 2001 20:46:49 -0500 (EST) 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 f9U1kll08215 for ; Mon, 29 Oct 2001 20:46:47 -0500 (EST) 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 UAA65432; Mon, 29 Oct 2001 20:44:10 -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 f9U1kgp227528; Mon, 29 Oct 2001 18:46:42 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: proposal to solve the ISID issues To: cbm@rose.hp.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: Mon, 29 Oct 2001 17:45:59 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/29/2001 06:46:42 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, I do not understand the purpose for your proposed wordage "All iSCSIinitiator hardware implementations MUST in addition also support the operational ISID values to be (either statically or dynamically) externally configurable." Why is this so important that it is a MUST. The purpose of the proposal is to eliminate the need for the above. At most it should only apply to the vendors (Probably Software and at Universities and IT shops) that use the RANDOM ISID type code. I do not see the need elsewhere. At most it could be "MAY". . . . 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 "Mallikarjun C." @ece.cmu.edu on 10/29/2001 05:24:20 PM Please respond to cbm@rose.hp.com Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: proposal to solve the ISID issues Jim, Thanks for the quick response. As much as I would like to avoid consuming more bandwidth on this topic, let me make one last strawman for wording below. > What words do you suggest? ... > And a lot depends on how > functional the NICs are: (a) just network nics, (b) protocol nics, but not > session coordinating nics (c) full session coordination nics (with driver > assist) (d) fully autonomous session nics. How do we make a requirement > that fits all the cases correctly? I have been implying iSCSI NICs in all my postings so far - sorry, may be that wasn't very clear. "iSCSI Node name" comment obviously wasn't targeted at simple network NICs. So clearly (a) is out of discussion. But you are right - I wasn't very precise. Here's a strawman - All iSCSI hardware implementations (as in NICs) MUST allow the iSCSI Node Name to be externally configurable. All iSCSI initiator hardware implementations MUST in addition also support the the operational ISID values to be (either statically or dynamically) externally configurable. > Making them configurable (at > initialization time, e.g., as a range of values) or making them dynamic > (the driver generates them on demand) both fit the mold. So, I don't think > this one is a hard requirement. I agree that my earlier "range" wording was too constraining. My point though is that by banning a duplicate nexus (that an inadvertently re-used ISID allows), we are making the ISID (dynamic/static) distribution an imminent hard requirement for all NICs in a given iSCSI initiator Node - except it is not sufficiently explicit. Please consider the above proposed wording. > Well, I don't think so. If each vendor implements "conservative reuse" > within their own ISID namespace on their own NICs, then you get this > property system wide. You are right, I guess I briefly overlooked the fact that ISID includes the vendor identifier within, per the new proposal. I am personally okay with making "conservative reuse" a SHOULD. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Jim Hafner wrote: > > Mallikarjun, > > Comments in line below > > Jim Hafner > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 12:17:49 > pm > > Please respond to cbm@rose.hp.com > > Sent by: cbm@core.rose.hp.com > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > Jim, > > Thanks for the excellent summary. Some questions/comments - > > - I assume that the NICs must enable the configuration of > iSCSI Node name even in this proposal. If it is so, please > call this out as a hard requirement in the main modelling > discussion. > > > This requirement doesn't change from before (but how it gets written into > the spec may differ -- and we've had this discussion before). If a vendor > doesn't allow configuration of his NIC's iSCSI Node name, then his NICs > will be acting as their own iSCSI Node (that is, not representing the > system they live in). One can argue that this is a legitimate > implementation (just as writing user-level code that uses its own iSCSI > Node name). So a "hard requirement" may be a bit too strong. However, I > will go with the will of the group on this point. > > What words do you suggest? > > - In the case of multiple NICs from the same vendor operating > in an end node, it appears to me that the proposal implicitly > assumes an ISID-range to be configurable among those NICs > (perhaps in vendor-unique ways, which is always what I expected). > If this is a correct inference, there is again a hard > requirement on the NICs to make the ISID range configurable. > Please comment on any subtle qualitative change from the > earlier situation that I may be missing. > > > Well, the point is that the vendor can manage his own namespace for his > NICs anyway he/she/it wants to. Making them configurable (at > initialization time, e.g., as a range of values) or making them dynamic > (the driver generates them on demand) both fit the mold. So, I don't think > this one is a hard requirement (though that is probably how most vendors > will implement their NICs). In effect, the proposal gives vendors more > flexibility in their own space, without causing heterogenous > interoperability problems within the host. And a lot depends on how > functional the NICs are: (a) just network nics, (b) protocol nics, but not > session coordinating nics (c) full session coordination nics (with driver > assist) (d) fully autonomous session nics. How do we make a requirement > that fits all the cases correctly? You clearly have in mind a specific > level of implementation within the NICs, but that may not be everybody's > model. > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > SHOULD. My personal opinion is "SHOULD", because many systems, > > particularly low-end that don't use reservations, can function more or > > less OK without it. > > It seems we're attempting to set ourselves up for future in > discussing the above requirement. Some questions - > - It appears to me that the "conservative reuse" can not > be enforced for initiators hosting NICs from different > vendors (since the proposal allows ISID namespaces to > be totally non-overlapping between non-homogenous NICs). > Is this a fair assessment? > > Well, I don't think so. If each vendor implements "conservative reuse" > within their own ISID namespace on their own NICs, then you get this > property system wide. As before, by owning their own piece of the ISID > namespace, they can implement what they want. So, you may have a situation > where some of your installed nics have this property and some don't. > You'll find out (if your environment really needs conservative reuse) that > you haven't got it, and it becomes a marketing/purchase spec requirement. > > - Do you see a particular disadvantage for low-end systems > if it's mandated (aside from the fact that they may be able > to live without it)? > > No, but I don't see any way to really enforce it (or even really test it). > It's not a requirement of the protocol, per se. > > - Do you see any corner cases not being met (for future) > if we don't make it a MUST (since you said "more or less OK")? > > No, I can't see that far into the future! :-{). One reason I'm being cagey > here is that I'm finding it difficult to find the right words to specify > this as a hard requirement (but I'm no technical writer either!). > > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Jim Hafner wrote: > > > > Folks, (David Black in particular). > > > > Apologies for the long note, but the issue is complicated. > > > > The NDTeam have a proposal to resolve the concerns surrounding use of > > ISIDs as essential components (along with iSCSI Initiator Name) of > > SCSI Initiator Portname. (This was rooted in private discussions > > between John Hufferd, Julian and myself -- and came about as a result > > of the lengthy (and boring) discussions mostly myself and David > > Black.) > > > > There are two somewhat orthogonal issues involved in this discussion: > > > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > > accidentally breaking the ISID RULE (no parallel nexus) when > > independent vendors co-exist in the same OS. > > > > 2) What ISID "reuse" rules should be specified to facilitate current > > and future (soon?) SCSI reservation semantics (and also internal OS > > views of SCSI Initiator Ports). > > > > To address these two issues, we (NDT) propose the following: > > > > 1) Enlarge the ISID field in the Login Request and Response to 6bytes > > and structure it with a component that corresponds to a "naming > > authority" (essentially the vendor generating the ISID). So vendors > > each have a piece of the ISID namespace to work with their own > > components (HBAs, SW, etc). More details below. > > > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used as > > conservatively as possible ("conservative reuse"). What this means is > > that a given ISID should be reused for as many sessions (across > > multiple target portal groups) as possible (but never to the same > > target portal group twice -- that's the ISID RULE). > > > > NOTES and ADVANTAGES: > > > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > > effect, at the vendor-level, this provides a "partitioning" of that > > namespace. > > > > (1-b) We don't need to specify an OS infrastructure requirement for > > configuration of ISIDs -- each vendor can do it any way it chooses > > (within its naming authority). > > > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes up > > its own implementation. > > > > (1-d) This is not fundamentally different from David Black's > > suggestion for a "key"; it just (a) defines it precisely and (b) > > embeds it in an already defined (but enlarged) field. > > > > (1-e) Looking towards the future, as common ISID coordination > > mechanisms are implemented between vendors (say, SNIA banding together > > to define a precise API), this "naming authority" can be elevated to > > the coordinating entity or even the OS vendor. > > > > (1-f) ISIDs have no global uniqueness property. They need only be > > unique between a named iSCSI initiator and iSCSI target portal group. > > That means that a vendor implementation can use the same algorithm to > > generate ISIDs (under its naming authority) in every machine (OS). > > > > (2-a) If a SCSI target (or logical unit) is holding state (say > > persistent reservation) for a SCSI Initiator Port (named by iSCSI Name > > and ISID), and the associated nexus/session is dropped for some > > reason, "reuse" by that initiator of that ISID will restore to the > > resulting new session that state (with no other action on the part of > > the upper SCSI layers). > > > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > > different SCSI Target Ports (iSCSI Target portal groups), will enable > > the SCSI target/logical unit to recognize a common SCSI Initiator Port > > for those two paths. This facilitates future changes to SCSI > > reservations (at least). > > > > (2-c) An initiator driver implementated with "conservative reuse" can > > present to the OS a stable and fairly static view of the SCSI > > Initiator Ports (one for each ISID). Current OS driver stacks > > (including current wedge drivers) that are built on the presumption of > > such a stable view, will not need modification to handle the more > > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence of > > a SCSI Initiator Port presented to the OS does not *require* that this > > port discover all possible targets; what the initiator builds sessions > > to using a specific ISID will determine what is presented to the OS as > > "devices" and LUs visible to that SCSI Initiator Port (could be none > > if that ISID is never actually used!).] > > > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator > > Port is as simple as configuring another ISID! > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > SHOULD. My personal opinion is "SHOULD", because many systems, > > particularly low-end that don't use reservations, can function more or > > less OK without it. This is an open question. > > > > DETAILS: > > > > 1) ISID Structure: > > The 6byte ISID structure would be split into three parts: > > "type" field (1byte) -- identifies the format of the naming > > authority field > > "naming authority" field (3bytes) -- identifies the vendor (or > > group of vendors) generating this ISID > > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > > > The type field takes on three defined values with all other values > > reserved: > > Type naming authority format > > 00h IEEE OUI > > 01h IANA Enterprise Number (EN) > > 02h "Random" > > > > The first types two provide a mechanism to uniquely (world wide) > > identify the naming authority. A vendor with one or more OUIs and > > possibly also Enterprise number MUST use at least one of these numbers > > when it generates ISIDs. > > > > The "Random" type is for the case where the ISID generator (SW or HW) > > is provided by an entity that has no OUI or EN. This includes, for > > example, > > -- a user-written program that builds sessions (and has access to the > > system level iSCSI Name) > > -- a university or other organization providing the component > > -- a testing tool > > > > For the "Random" type, the naming authority field should be a random > > or pseudo-random number. (See below on how this affects "conservative > > reuse"). > > > > [Note: the "type" field needn't be this big, but NDT felt that (a) > > 2bits was insufficient for the future, (b) the "type" field should be > > first, and (c) the "naming authority" field should be byte-aligned.] > > > > 2) Conservative Reuse > > > > The "conservative reuse" principle of this proposal just says that > > SCSI Initiator Portnames should be viewed as static things (as much as > > possible) and reused (when feasible) to give the most stable > > presentation of SCSI Initiator Ports to both the OS above and to SCSU > > targets across the wire. > > > > Whereas the current draft says "The ISID RULE does not preclude the > > use of the same ISID to different Target portal groups", the > > "conservative reuse" requirement would say that such reuse (using the > > same ISID to many target portal groups) is a SHOULD (or is that > > MUST?). So, in one implementation, each iSCSI Initiator Portal group > > would get configured with iSCSI Name, and a (small) set of ISIDs. The > > portal group might take this set of ISIDs as an ordered list. The > > first session to a Target portal group would use the first ISID, the > > second to the *same* target portal group would use the second in the > > list, etc. The number of ISIDs would then define a configuration > > parameter that can be interpreted as the maximum number of sessions > > that can be built to a given target portal group. > > > > To facilitate "conservative reuse", the "qualifier" field of a set of > > ISIDs SHOULD be generated using either a repeatable algorithm > > (non-random or pseudo-random but based on a fixed seed) or any > > algorithm and stored in a persistent location (e.g., registry or /etc > > file). > > > > For the "Random" type, "conservative reuse" may not be an issue (say, > > user application that doesn't care about reservations, etc.). When it > > is, the "naming authority" field SHOULD also be generated by a > > mechanism similar to that for the "qualifier" field as specified above > > (e.g., defined in the SW at compilation time.) > > > > DOCUMENTATING CHANGES: > > > > The iscsi drafts would need the following minor changes to support > > this proposal: > > > > NDT doc > > (a) define the structure of the ISID field (as described above) > > (b) add some notes about implementation in the presense of > > "conservative reuse" (e.g., that ISID should be configured once, say > > at install time, then reused on subsequent reboots, even for "Random" > > type). > > > > iSCSI MAIN doc: > > (a) move the CID field in Login Request to another reserved field. > > (b) expand the ISID field in Login Request and Response to encompass > > the previous 4 bytes. > > (c) add a sentence where the ISID field is defined indicating that > > this field is a structured value, showing the structure (as above) and > > point to the NDT document. > > (d) add some text to "Note to Implementors" on "conservative reuse". > > > > Comments? > > > > Jim Hafner From owner-ips@ece.cmu.edu Mon Oct 29 22: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 WAA04306 for ; Mon, 29 Oct 2001 22:31:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9U2mHd12092 for ips-outgoing; Mon, 29 Oct 2001 21:48:17 -0500 (EST) 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 f9U2mFl12087 for ; Mon, 29 Oct 2001 21:48:15 -0500 (EST) 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 VAA94478; Mon, 29 Oct 2001 21:45:42 -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 f9U2mEp158076; Mon, 29 Oct 2001 19:48:14 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: proposal to solve the ISID issues To: cbm@rose.hp.com Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Mon, 29 Oct 2001 18:47:31 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/29/2001 07:48:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I have no problem with the Must have a way to have the Node name set. However, I do not grasp the problem you state here: "I don't believe the type of the ISID matters, nor does the NIC capability (coordinating vs not). If two initiator NICs share the same node name, they better not re-use the same ISID to a given target portal group. I was trying to capture the consequences of this reality." If the ISID includes the Vendor ID, I do not see the problem, unless the vendor can not assign the rest of the ISID. And I would say that it is the vendors problem to work out. If you are saying that with NICs (not HBAs) that the SW Drivers will have a problem coming up with the ISID, I do not understand that either since most software is built by a Vendor, and if not the Random type should work. Now in case you are saying something about the creation of a second Session from the Initiator, which is to access the same Target Node. Then by definition, the ISID must be unique. (and it will probably need a Wedge Driver to operate correctly). I would think that a vendor should be able to come up with a unique qualifier for the session since they have 64K numbers to chose from. Remember the vendor only needs to coordinate the lower 2 bytes of the new ISID, with itself. So if they can not do that, ... Oh well ... Are we on the same page yet? . . . 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 "Mallikarjun C." @core.rose.hp.com on 10/29/2001 06:35:55 PM Please respond to cbm@rose.hp.com Sent by: cbm@core.rose.hp.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: proposal to solve the ISID issues John, I take it that you don't have an issue with the Node Name part of the wording. I thought I answered your question by saying - "My point though is that by banning a duplicate nexus (that an inadvertently re-used ISID allows), we are making the ISID (dynamic/static) distribution an imminent hard requirement for all NICs in a given iSCSI initiator Node" The unspoken assumption above is that we would want to allow multiple sessions between an initiator node and a target portal group. I don't believe the type of the ISID matters, nor does the NIC capability (coordinating vs not). If two initiator NICs share the same node name, they better not re-use the same ISID to a given target portal group. I was trying to capture the consequences of this reality. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com John Hufferd wrote: > > Mallikarjun, > I do not understand the purpose for your proposed wordage > > "All iSCSIinitiator hardware implementations MUST in addition also support > the operational ISID values to be (either statically or dynamically) > externally configurable." > > Why is this so important that it is a MUST. The purpose of the proposal is > to eliminate the need for the above. At most it should only apply to the > vendors (Probably Software and at Universities and IT shops) that use the > RANDOM ISID type code. > > I do not see the need elsewhere. At most it could be "MAY". > > . > . > . > 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 > > "Mallikarjun C." @ece.cmu.edu on 10/29/2001 05:24:20 PM > > Please respond to cbm@rose.hp.com > > Sent by: owner-ips@ece.cmu.edu > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > Jim, > > Thanks for the quick response. > > As much as I would like to avoid consuming more bandwidth > on this topic, let me make one last strawman for wording below. > > > What words do you suggest? > ... > > And a lot depends on how > > functional the NICs are: (a) just network nics, (b) protocol nics, but > not > > session coordinating nics (c) full session coordination nics (with driver > > assist) (d) fully autonomous session nics. How do we make a requirement > > that fits all the cases correctly? > > I have been implying iSCSI NICs in all my postings so far - > sorry, may be that wasn't very clear. "iSCSI Node name" comment > obviously wasn't targeted at simple network NICs. So clearly (a) > is out of discussion. But you are right - I wasn't very precise. > Here's a strawman - > > All iSCSI hardware implementations (as in NICs) MUST allow > the iSCSI Node Name to be externally configurable. All iSCSI > initiator hardware implementations MUST in addition also > support the the operational ISID values to be (either statically > or dynamically) externally configurable. > > > Making them configurable (at > > initialization time, e.g., as a range of values) or making them dynamic > > (the driver generates them on demand) both fit the mold. So, I don't > think > > this one is a hard requirement. > > I agree that my earlier "range" wording was too constraining. > My point though is that by banning a duplicate nexus (that an > inadvertently re-used ISID allows), we are making the ISID > (dynamic/static) distribution an imminent hard requirement > for all NICs in a given iSCSI initiator Node - except it is > not sufficiently explicit. Please consider the above proposed > wording. > > > Well, I don't think so. If each vendor implements "conservative reuse" > > within their own ISID namespace on their own NICs, then you get this > > property system wide. > > You are right, I guess I briefly overlooked the fact that ISID > includes the vendor identifier within, per the new proposal. > > I am personally okay with making "conservative reuse" a > SHOULD. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Jim Hafner wrote: > > > > Mallikarjun, > > > > Comments in line below > > > > Jim Hafner > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > 12:17:49 > > pm > > > > Please respond to cbm@rose.hp.com > > > > Sent by: cbm@core.rose.hp.com > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > Jim, > > > > Thanks for the excellent summary. Some questions/comments - > > > > - I assume that the NICs must enable the configuration of > > iSCSI Node name even in this proposal. If it is so, please > > call this out as a hard requirement in the main modelling > > discussion. > > > > > > This requirement doesn't change from before (but how it gets written into > > the spec may differ -- and we've had this discussion before). If a > vendor > > doesn't allow configuration of his NIC's iSCSI Node name, then his NICs > > will be acting as their own iSCSI Node (that is, not representing the > > system they live in). One can argue that this is a legitimate > > implementation (just as writing user-level code that uses its own iSCSI > > Node name). So a "hard requirement" may be a bit too strong. However, I > > will go with the will of the group on this point. > > > > What words do you suggest? > > > > - In the case of multiple NICs from the same vendor operating > > in an end node, it appears to me that the proposal implicitly > > assumes an ISID-range to be configurable among those NICs > > (perhaps in vendor-unique ways, which is always what I expected). > > If this is a correct inference, there is again a hard > > requirement on the NICs to make the ISID range configurable. > > Please comment on any subtle qualitative change from the > > earlier situation that I may be missing. > > > > > > Well, the point is that the vendor can manage his own namespace for his > > NICs anyway he/she/it wants to. Making them configurable (at > > initialization time, e.g., as a range of values) or making them dynamic > > (the driver generates them on demand) both fit the mold. So, I don't > think > > this one is a hard requirement (though that is probably how most vendors > > will implement their NICs). In effect, the proposal gives vendors more > > flexibility in their own space, without causing heterogenous > > interoperability problems within the host. And a lot depends on how > > functional the NICs are: (a) just network nics, (b) protocol nics, but > not > > session coordinating nics (c) full session coordination nics (with driver > > assist) (d) fully autonomous session nics. How do we make a requirement > > that fits all the cases correctly? You clearly have in mind a specific > > level of implementation within the NICs, but that may not be everybody's > > model. > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > particularly low-end that don't use reservations, can function more or > > > less OK without it. > > > > It seems we're attempting to set ourselves up for future in > > discussing the above requirement. Some questions - > > - It appears to me that the "conservative reuse" can not > > be enforced for initiators hosting NICs from different > > vendors (since the proposal allows ISID namespaces to > > be totally non-overlapping between non-homogenous NICs). > > Is this a fair assessment? > > > > Well, I don't think so. If each vendor implements "conservative reuse" > > within their own ISID namespace on their own NICs, then you get this > > property system wide. As before, by owning their own piece of the ISID > > namespace, they can implement what they want. So, you may have a > situation > > where some of your installed nics have this property and some don't. > > You'll find out (if your environment really needs conservative reuse) > that > > you haven't got it, and it becomes a marketing/purchase spec requirement. > > > > - Do you see a particular disadvantage for low-end systems > > if it's mandated (aside from the fact that they may be able > > to live without it)? > > > > No, but I don't see any way to really enforce it (or even really test > it). > > It's not a requirement of the protocol, per se. > > > > - Do you see any corner cases not being met (for future) > > if we don't make it a MUST (since you said "more or less OK")? > > > > No, I can't see that far into the future! :-{). One reason I'm being > cagey > > here is that I'm finding it difficult to find the right words to specify > > this as a hard requirement (but I'm no technical writer either!). > > > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > Jim Hafner wrote: > > > > > > Folks, (David Black in particular). > > > > > > Apologies for the long note, but the issue is complicated. > > > > > > The NDTeam have a proposal to resolve the concerns surrounding use of > > > ISIDs as essential components (along with iSCSI Initiator Name) of > > > SCSI Initiator Portname. (This was rooted in private discussions > > > between John Hufferd, Julian and myself -- and came about as a result > > > of the lengthy (and boring) discussions mostly myself and David > > > Black.) > > > > > > There are two somewhat orthogonal issues involved in this discussion: > > > > > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > > > accidentally breaking the ISID RULE (no parallel nexus) when > > > independent vendors co-exist in the same OS. > > > > > > 2) What ISID "reuse" rules should be specified to facilitate current > > > and future (soon?) SCSI reservation semantics (and also internal OS > > > views of SCSI Initiator Ports). > > > > > > To address these two issues, we (NDT) propose the following: > > > > > > 1) Enlarge the ISID field in the Login Request and Response to 6bytes > > > and structure it with a component that corresponds to a "naming > > > authority" (essentially the vendor generating the ISID). So vendors > > > each have a piece of the ISID namespace to work with their own > > > components (HBAs, SW, etc). More details below. > > > > > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used as > > > conservatively as possible ("conservative reuse"). What this means is > > > that a given ISID should be reused for as many sessions (across > > > multiple target portal groups) as possible (but never to the same > > > target portal group twice -- that's the ISID RULE). > > > > > > NOTES and ADVANTAGES: > > > > > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > > > effect, at the vendor-level, this provides a "partitioning" of that > > > namespace. > > > > > > (1-b) We don't need to specify an OS infrastructure requirement for > > > configuration of ISIDs -- each vendor can do it any way it chooses > > > (within its naming authority). > > > > > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes up > > > its own implementation. > > > > > > (1-d) This is not fundamentally different from David Black's > > > suggestion for a "key"; it just (a) defines it precisely and (b) > > > embeds it in an already defined (but enlarged) field. > > > > > > (1-e) Looking towards the future, as common ISID coordination > > > mechanisms are implemented between vendors (say, SNIA banding together > > > to define a precise API), this "naming authority" can be elevated to > > > the coordinating entity or even the OS vendor. > > > > > > (1-f) ISIDs have no global uniqueness property. They need only be > > > unique between a named iSCSI initiator and iSCSI target portal group. > > > That means that a vendor implementation can use the same algorithm to > > > generate ISIDs (under its naming authority) in every machine (OS). > > > > > > (2-a) If a SCSI target (or logical unit) is holding state (say > > > persistent reservation) for a SCSI Initiator Port (named by iSCSI Name > > > and ISID), and the associated nexus/session is dropped for some > > > reason, "reuse" by that initiator of that ISID will restore to the > > > resulting new session that state (with no other action on the part of > > > the upper SCSI layers). > > > > > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > > > different SCSI Target Ports (iSCSI Target portal groups), will enable > > > the SCSI target/logical unit to recognize a common SCSI Initiator Port > > > for those two paths. This facilitates future changes to SCSI > > > reservations (at least). > > > > > > (2-c) An initiator driver implementated with "conservative reuse" can > > > present to the OS a stable and fairly static view of the SCSI > > > Initiator Ports (one for each ISID). Current OS driver stacks > > > (including current wedge drivers) that are built on the presumption of > > > such a stable view, will not need modification to handle the more > > > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence of > > > a SCSI Initiator Port presented to the OS does not *require* that this > > > port discover all possible targets; what the initiator builds sessions > > > to using a specific ISID will determine what is presented to the OS as > > > "devices" and LUs visible to that SCSI Initiator Port (could be none > > > if that ISID is never actually used!).] > > > > > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator > > > Port is as simple as configuring another ISID! > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > particularly low-end that don't use reservations, can function more or > > > less OK without it. This is an open question. > > > > > > DETAILS: > > > > > > 1) ISID Structure: > > > The 6byte ISID structure would be split into three parts: > > > "type" field (1byte) -- identifies the format of the naming > > > authority field > > > "naming authority" field (3bytes) -- identifies the vendor (or > > > group of vendors) generating this ISID > > > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > > > > > The type field takes on three defined values with all other values > > > reserved: > > > Type naming authority format > > > 00h IEEE OUI > > > 01h IANA Enterprise Number (EN) > > > 02h "Random" > > > > > > The first types two provide a mechanism to uniquely (world wide) > > > identify the naming authority. A vendor with one or more OUIs and > > > possibly also Enterprise number MUST use at least one of these numbers > > > when it generates ISIDs. > > > > > > The "Random" type is for the case where the ISID generator (SW or HW) > > > is provided by an entity that has no OUI or EN. This includes, for > > > example, > > > -- a user-written program that builds sessions (and has access to the > > > system level iSCSI Name) > > > -- a university or other organization providing the component > > > -- a testing tool > > > > > > For the "Random" type, the naming authority field should be a random > > > or pseudo-random number. (See below on how this affects "conservative > > > reuse"). > > > > > > [Note: the "type" field needn't be this big, but NDT felt that (a) > > > 2bits was insufficient for the future, (b) the "type" field should be > > > first, and (c) the "naming authority" field should be byte-aligned.] > > > > > > 2) Conservative Reuse > > > > > > The "conservative reuse" principle of this proposal just says that > > > SCSI Initiator Portnames should be viewed as static things (as much as > > > possible) and reused (when feasible) to give the most stable > > > presentation of SCSI Initiator Ports to both the OS above and to SCSU > > > targets across the wire. > > > > > > Whereas the current draft says "The ISID RULE does not preclude the > > > use of the same ISID to different Target portal groups", the > > > "conservative reuse" requirement would say that such reuse (using the > > > same ISID to many target portal groups) is a SHOULD (or is that > > > MUST?). So, in one implementation, each iSCSI Initiator Portal group > > > would get configured with iSCSI Name, and a (small) set of ISIDs. The > > > portal group might take this set of ISIDs as an ordered list. The > > > first session to a Target portal group would use the first ISID, the > > > second to the *same* target portal group would use the second in the > > > list, etc. The number of ISIDs would then define a configuration > > > parameter that can be interpreted as the maximum number of sessions > > > that can be built to a given target portal group. > > > > > > To facilitate "conservative reuse", the "qualifier" field of a set of > > > ISIDs SHOULD be generated using either a repeatable algorithm > > > (non-random or pseudo-random but based on a fixed seed) or any > > > algorithm and stored in a persistent location (e.g., registry or /etc > > > file). > > > > > > For the "Random" type, "conservative reuse" may not be an issue (say, > > > user application that doesn't care about reservations, etc.). When it > > > is, the "naming authority" field SHOULD also be generated by a > > > mechanism similar to that for the "qualifier" field as specified above > > > (e.g., defined in the SW at compilation time.) > > > > > > DOCUMENTATING CHANGES: > > > > > > The iscsi drafts would need the following minor changes to support > > > this proposal: > > > > > > NDT doc > > > (a) define the structure of the ISID field (as described above) > > > (b) add some notes about implementation in the presense of > > > "conservative reuse" (e.g., that ISID should be configured once, say > > > at install time, then reused on subsequent reboots, even for "Random" > > > type). > > > > > > iSCSI MAIN doc: > > > (a) move the CID field in Login Request to another reserved field. > > > (b) expand the ISID field in Login Request and Response to encompass > > > the previous 4 bytes. > > > (c) add a sentence where the ISID field is defined indicating that > > > this field is a structured value, showing the structure (as above) and > > > point to the NDT document. > > > (d) add some text to "Note to Implementors" on "conservative reuse". > > > > > > Comments? > > > > > > Jim Hafner -- 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 Mon Oct 29 22:31: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 WAA04394 for ; Mon, 29 Oct 2001 22:31:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9U2NoF10586 for ips-outgoing; Mon, 29 Oct 2001 21:23:50 -0500 (EST) 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 f9U2Nml10579 for ; Mon, 29 Oct 2001 21:23:48 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel1.hp.com (Postfix) with ESMTP id 445611BD; Mon, 29 Oct 2001 21:23:47 -0500 (EST) 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 SAA28978; Mon, 29 Oct 2001 18:25:12 -0800 (PST) Message-Id: <200110300225.SAA28978@core.rose.hp.com> Date: Mon, 29 Oct 2001 18:35:55 -0800 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: John Hufferd Cc: ips@ece.cmu.edu Subject: Re: iSCSI: proposal to solve the ISID issues 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 take it that you don't have an issue with the Node Name part of the wording. I thought I answered your question by saying - "My point though is that by banning a duplicate nexus (that an inadvertently re-used ISID allows), we are making the ISID (dynamic/static) distribution an imminent hard requirement for all NICs in a given iSCSI initiator Node" The unspoken assumption above is that we would want to allow multiple sessions between an initiator node and a target portal group. I don't believe the type of the ISID matters, nor does the NIC capability (coordinating vs not). If two initiator NICs share the same node name, they better not re-use the same ISID to a given target portal group. I was trying to capture the consequences of this reality. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com John Hufferd wrote: > > Mallikarjun, > I do not understand the purpose for your proposed wordage > > "All iSCSIinitiator hardware implementations MUST in addition also support > the operational ISID values to be (either statically or dynamically) > externally configurable." > > Why is this so important that it is a MUST. The purpose of the proposal is > to eliminate the need for the above. At most it should only apply to the > vendors (Probably Software and at Universities and IT shops) that use the > RANDOM ISID type code. > > I do not see the need elsewhere. At most it could be "MAY". > > . > . > . > 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 > > "Mallikarjun C." @ece.cmu.edu on 10/29/2001 05:24:20 PM > > Please respond to cbm@rose.hp.com > > Sent by: owner-ips@ece.cmu.edu > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > Jim, > > Thanks for the quick response. > > As much as I would like to avoid consuming more bandwidth > on this topic, let me make one last strawman for wording below. > > > What words do you suggest? > ... > > And a lot depends on how > > functional the NICs are: (a) just network nics, (b) protocol nics, but > not > > session coordinating nics (c) full session coordination nics (with driver > > assist) (d) fully autonomous session nics. How do we make a requirement > > that fits all the cases correctly? > > I have been implying iSCSI NICs in all my postings so far - > sorry, may be that wasn't very clear. "iSCSI Node name" comment > obviously wasn't targeted at simple network NICs. So clearly (a) > is out of discussion. But you are right - I wasn't very precise. > Here's a strawman - > > All iSCSI hardware implementations (as in NICs) MUST allow > the iSCSI Node Name to be externally configurable. All iSCSI > initiator hardware implementations MUST in addition also > support the the operational ISID values to be (either statically > or dynamically) externally configurable. > > > Making them configurable (at > > initialization time, e.g., as a range of values) or making them dynamic > > (the driver generates them on demand) both fit the mold. So, I don't > think > > this one is a hard requirement. > > I agree that my earlier "range" wording was too constraining. > My point though is that by banning a duplicate nexus (that an > inadvertently re-used ISID allows), we are making the ISID > (dynamic/static) distribution an imminent hard requirement > for all NICs in a given iSCSI initiator Node - except it is > not sufficiently explicit. Please consider the above proposed > wording. > > > Well, I don't think so. If each vendor implements "conservative reuse" > > within their own ISID namespace on their own NICs, then you get this > > property system wide. > > You are right, I guess I briefly overlooked the fact that ISID > includes the vendor identifier within, per the new proposal. > > I am personally okay with making "conservative reuse" a > SHOULD. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Jim Hafner wrote: > > > > Mallikarjun, > > > > Comments in line below > > > > Jim Hafner > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > 12:17:49 > > pm > > > > Please respond to cbm@rose.hp.com > > > > Sent by: cbm@core.rose.hp.com > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > Jim, > > > > Thanks for the excellent summary. Some questions/comments - > > > > - I assume that the NICs must enable the configuration of > > iSCSI Node name even in this proposal. If it is so, please > > call this out as a hard requirement in the main modelling > > discussion. > > > > > > This requirement doesn't change from before (but how it gets written into > > the spec may differ -- and we've had this discussion before). If a > vendor > > doesn't allow configuration of his NIC's iSCSI Node name, then his NICs > > will be acting as their own iSCSI Node (that is, not representing the > > system they live in). One can argue that this is a legitimate > > implementation (just as writing user-level code that uses its own iSCSI > > Node name). So a "hard requirement" may be a bit too strong. However, I > > will go with the will of the group on this point. > > > > What words do you suggest? > > > > - In the case of multiple NICs from the same vendor operating > > in an end node, it appears to me that the proposal implicitly > > assumes an ISID-range to be configurable among those NICs > > (perhaps in vendor-unique ways, which is always what I expected). > > If this is a correct inference, there is again a hard > > requirement on the NICs to make the ISID range configurable. > > Please comment on any subtle qualitative change from the > > earlier situation that I may be missing. > > > > > > Well, the point is that the vendor can manage his own namespace for his > > NICs anyway he/she/it wants to. Making them configurable (at > > initialization time, e.g., as a range of values) or making them dynamic > > (the driver generates them on demand) both fit the mold. So, I don't > think > > this one is a hard requirement (though that is probably how most vendors > > will implement their NICs). In effect, the proposal gives vendors more > > flexibility in their own space, without causing heterogenous > > interoperability problems within the host. And a lot depends on how > > functional the NICs are: (a) just network nics, (b) protocol nics, but > not > > session coordinating nics (c) full session coordination nics (with driver > > assist) (d) fully autonomous session nics. How do we make a requirement > > that fits all the cases correctly? You clearly have in mind a specific > > level of implementation within the NICs, but that may not be everybody's > > model. > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > particularly low-end that don't use reservations, can function more or > > > less OK without it. > > > > It seems we're attempting to set ourselves up for future in > > discussing the above requirement. Some questions - > > - It appears to me that the "conservative reuse" can not > > be enforced for initiators hosting NICs from different > > vendors (since the proposal allows ISID namespaces to > > be totally non-overlapping between non-homogenous NICs). > > Is this a fair assessment? > > > > Well, I don't think so. If each vendor implements "conservative reuse" > > within their own ISID namespace on their own NICs, then you get this > > property system wide. As before, by owning their own piece of the ISID > > namespace, they can implement what they want. So, you may have a > situation > > where some of your installed nics have this property and some don't. > > You'll find out (if your environment really needs conservative reuse) > that > > you haven't got it, and it becomes a marketing/purchase spec requirement. > > > > - Do you see a particular disadvantage for low-end systems > > if it's mandated (aside from the fact that they may be able > > to live without it)? > > > > No, but I don't see any way to really enforce it (or even really test > it). > > It's not a requirement of the protocol, per se. > > > > - Do you see any corner cases not being met (for future) > > if we don't make it a MUST (since you said "more or less OK")? > > > > No, I can't see that far into the future! :-{). One reason I'm being > cagey > > here is that I'm finding it difficult to find the right words to specify > > this as a hard requirement (but I'm no technical writer either!). > > > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > Jim Hafner wrote: > > > > > > Folks, (David Black in particular). > > > > > > Apologies for the long note, but the issue is complicated. > > > > > > The NDTeam have a proposal to resolve the concerns surrounding use of > > > ISIDs as essential components (along with iSCSI Initiator Name) of > > > SCSI Initiator Portname. (This was rooted in private discussions > > > between John Hufferd, Julian and myself -- and came about as a result > > > of the lengthy (and boring) discussions mostly myself and David > > > Black.) > > > > > > There are two somewhat orthogonal issues involved in this discussion: > > > > > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > > > accidentally breaking the ISID RULE (no parallel nexus) when > > > independent vendors co-exist in the same OS. > > > > > > 2) What ISID "reuse" rules should be specified to facilitate current > > > and future (soon?) SCSI reservation semantics (and also internal OS > > > views of SCSI Initiator Ports). > > > > > > To address these two issues, we (NDT) propose the following: > > > > > > 1) Enlarge the ISID field in the Login Request and Response to 6bytes > > > and structure it with a component that corresponds to a "naming > > > authority" (essentially the vendor generating the ISID). So vendors > > > each have a piece of the ISID namespace to work with their own > > > components (HBAs, SW, etc). More details below. > > > > > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used as > > > conservatively as possible ("conservative reuse"). What this means is > > > that a given ISID should be reused for as many sessions (across > > > multiple target portal groups) as possible (but never to the same > > > target portal group twice -- that's the ISID RULE). > > > > > > NOTES and ADVANTAGES: > > > > > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > > > effect, at the vendor-level, this provides a "partitioning" of that > > > namespace. > > > > > > (1-b) We don't need to specify an OS infrastructure requirement for > > > configuration of ISIDs -- each vendor can do it any way it chooses > > > (within its naming authority). > > > > > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes up > > > its own implementation. > > > > > > (1-d) This is not fundamentally different from David Black's > > > suggestion for a "key"; it just (a) defines it precisely and (b) > > > embeds it in an already defined (but enlarged) field. > > > > > > (1-e) Looking towards the future, as common ISID coordination > > > mechanisms are implemented between vendors (say, SNIA banding together > > > to define a precise API), this "naming authority" can be elevated to > > > the coordinating entity or even the OS vendor. > > > > > > (1-f) ISIDs have no global uniqueness property. They need only be > > > unique between a named iSCSI initiator and iSCSI target portal group. > > > That means that a vendor implementation can use the same algorithm to > > > generate ISIDs (under its naming authority) in every machine (OS). > > > > > > (2-a) If a SCSI target (or logical unit) is holding state (say > > > persistent reservation) for a SCSI Initiator Port (named by iSCSI Name > > > and ISID), and the associated nexus/session is dropped for some > > > reason, "reuse" by that initiator of that ISID will restore to the > > > resulting new session that state (with no other action on the part of > > > the upper SCSI layers). > > > > > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > > > different SCSI Target Ports (iSCSI Target portal groups), will enable > > > the SCSI target/logical unit to recognize a common SCSI Initiator Port > > > for those two paths. This facilitates future changes to SCSI > > > reservations (at least). > > > > > > (2-c) An initiator driver implementated with "conservative reuse" can > > > present to the OS a stable and fairly static view of the SCSI > > > Initiator Ports (one for each ISID). Current OS driver stacks > > > (including current wedge drivers) that are built on the presumption of > > > such a stable view, will not need modification to handle the more > > > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence of > > > a SCSI Initiator Port presented to the OS does not *require* that this > > > port discover all possible targets; what the initiator builds sessions > > > to using a specific ISID will determine what is presented to the OS as > > > "devices" and LUs visible to that SCSI Initiator Port (could be none > > > if that ISID is never actually used!).] > > > > > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator > > > Port is as simple as configuring another ISID! > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > particularly low-end that don't use reservations, can function more or > > > less OK without it. This is an open question. > > > > > > DETAILS: > > > > > > 1) ISID Structure: > > > The 6byte ISID structure would be split into three parts: > > > "type" field (1byte) -- identifies the format of the naming > > > authority field > > > "naming authority" field (3bytes) -- identifies the vendor (or > > > group of vendors) generating this ISID > > > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > > > > > The type field takes on three defined values with all other values > > > reserved: > > > Type naming authority format > > > 00h IEEE OUI > > > 01h IANA Enterprise Number (EN) > > > 02h "Random" > > > > > > The first types two provide a mechanism to uniquely (world wide) > > > identify the naming authority. A vendor with one or more OUIs and > > > possibly also Enterprise number MUST use at least one of these numbers > > > when it generates ISIDs. > > > > > > The "Random" type is for the case where the ISID generator (SW or HW) > > > is provided by an entity that has no OUI or EN. This includes, for > > > example, > > > -- a user-written program that builds sessions (and has access to the > > > system level iSCSI Name) > > > -- a university or other organization providing the component > > > -- a testing tool > > > > > > For the "Random" type, the naming authority field should be a random > > > or pseudo-random number. (See below on how this affects "conservative > > > reuse"). > > > > > > [Note: the "type" field needn't be this big, but NDT felt that (a) > > > 2bits was insufficient for the future, (b) the "type" field should be > > > first, and (c) the "naming authority" field should be byte-aligned.] > > > > > > 2) Conservative Reuse > > > > > > The "conservative reuse" principle of this proposal just says that > > > SCSI Initiator Portnames should be viewed as static things (as much as > > > possible) and reused (when feasible) to give the most stable > > > presentation of SCSI Initiator Ports to both the OS above and to SCSU > > > targets across the wire. > > > > > > Whereas the current draft says "The ISID RULE does not preclude the > > > use of the same ISID to different Target portal groups", the > > > "conservative reuse" requirement would say that such reuse (using the > > > same ISID to many target portal groups) is a SHOULD (or is that > > > MUST?). So, in one implementation, each iSCSI Initiator Portal group > > > would get configured with iSCSI Name, and a (small) set of ISIDs. The > > > portal group might take this set of ISIDs as an ordered list. The > > > first session to a Target portal group would use the first ISID, the > > > second to the *same* target portal group would use the second in the > > > list, etc. The number of ISIDs would then define a configuration > > > parameter that can be interpreted as the maximum number of sessions > > > that can be built to a given target portal group. > > > > > > To facilitate "conservative reuse", the "qualifier" field of a set of > > > ISIDs SHOULD be generated using either a repeatable algorithm > > > (non-random or pseudo-random but based on a fixed seed) or any > > > algorithm and stored in a persistent location (e.g., registry or /etc > > > file). > > > > > > For the "Random" type, "conservative reuse" may not be an issue (say, > > > user application that doesn't care about reservations, etc.). When it > > > is, the "naming authority" field SHOULD also be generated by a > > > mechanism similar to that for the "qualifier" field as specified above > > > (e.g., defined in the SW at compilation time.) > > > > > > DOCUMENTATING CHANGES: > > > > > > The iscsi drafts would need the following minor changes to support > > > this proposal: > > > > > > NDT doc > > > (a) define the structure of the ISID field (as described above) > > > (b) add some notes about implementation in the presense of > > > "conservative reuse" (e.g., that ISID should be configured once, say > > > at install time, then reused on subsequent reboots, even for "Random" > > > type). > > > > > > iSCSI MAIN doc: > > > (a) move the CID field in Login Request to another reserved field. > > > (b) expand the ISID field in Login Request and Response to encompass > > > the previous 4 bytes. > > > (c) add a sentence where the ISID field is defined indicating that > > > this field is a structured value, showing the structure (as above) and > > > point to the NDT document. > > > (d) add some text to "Note to Implementors" on "conservative reuse". > > > > > > Comments? > > > > > > Jim Hafner -- 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 Tue Oct 30 09:05: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 JAA00043 for ; Tue, 30 Oct 2001 09:05:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9UDCJA29065 for ips-outgoing; Tue, 30 Oct 2001 08:12:19 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from mailnpd.hcltech.com ([203.197.145.76]) by ece.cmu.edu (8.11.0/8.10.2) with SMTP id f9UDCEl29051 for ; Tue, 30 Oct 2001 08:12:15 -0500 (EST) Received: from nramamurpc (nramamur-pc.hcltech.com [192.168.100.98]) by mailnpd.hcltech.com (8.11.0/8.11.0) with SMTP id f9UDAqe05012 for ; Tue, 30 Oct 2001 18:40:57 +0530 Message-ID: <020301c16144$86e79980$6264a8c0@hcltech.com> From: "Nandakumar Ramamurthy" To: Subject: iSCSI: Connection establishment criteria Date: Tue, 30 Oct 2001 18:42:24 +0530 Organization: HCL Technologies Ltd. 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 All, Consider the following : An initiator and a target have established a session ( Leading login has been successful ). Thus, we have one connection between the initiator and target (the leading connection). Also assume MaxConnections has been agreed upon by both ends as X ( 2 or more ). My question is : What situations/conditions/events make the initiator to establish subsequent connections ? From my understanding, one definite event is when the leading connection goes down, thus, making the initiator to establish a new connection (for continuing the session ) which holds true even if MaxConnections = 1. Are the second and later connection(s) attempted immediately after the first connection is successful ? A seemingly related question on the alias earlier (from the mailing archives) suggests that connection establishment/selection is done by an iSCSI initiator to improve bandwidth/availability. Does this mean that "when to spawn consecutive connections" is purely implementation dependent ? Does any section of the draft clarify my question ? Please clarify. Thanks, Nandakumar. From owner-ips@ece.cmu.edu Tue Oct 30 09:07: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 JAA00213 for ; Tue, 30 Oct 2001 09:07:04 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9UD5PT28599 for ips-outgoing; Tue, 30 Oct 2001 08:05:25 -0500 (EST) 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 f9UD5Ml28594 for ; Tue, 30 Oct 2001 08:05:22 -0500 (EST) Received: from COORS (coors.eurologic.com [192.168.7.111] (may be forged)) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id NAA13500 for ; Tue, 30 Oct 2001 13:01:58 GMT Message-ID: <008901c16143$9d537500$6f07a8c0@COORS> From: "Ron Cohen" To: "ips" Subject: iSCSI: Third Party Copy Date: Tue, 30 Oct 2001 13:05:53 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01C16143.9AD22150" 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_0086_01C16143.9AD22150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was looking through the Extended Copy command in SPC-2 and came across = the problem of the format of a Target Descriptor for an iSCSI device. = The current format for a Target Descriptor is 32-bytes which does not = provide much in the way of possibilities for identifying a source or = destination device in terms of its iSCSI name. If this has been handled = already, can anyone direct me to the references which discuss the = implementation of the Extended Copy command in an iSCSI SAN.=20 Ronald Cohen E-mail: rcohen@Eurologic.com Telephone: +44 (0) 117 930 9615 ------=_NextPart_000_0086_01C16143.9AD22150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I was looking through the Extended Copy = command in=20 SPC-2 and came across the problem of the format of a Target Descriptor = for an=20 iSCSI device.  The current format for a Target Descriptor is = 32-bytes which=20 does not provide much in the way of possibilities for identifying a = source=20 or destination device in terms of its iSCSI name.  If this has = been=20 handled already, can anyone direct me to the references which discuss = the=20 implementation of the Extended Copy command in an iSCSI SAN. =
 
Ronald Cohen
E-mail:  rcohen@Eurologic.com
Telephon= e: =20 +44 (0) 117 930 9615
------=_NextPart_000_0086_01C16143.9AD22150-- From owner-ips@ece.cmu.edu Tue Oct 30 09:22: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 JAA01093 for ; Tue, 30 Oct 2001 09:22:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9UDkK001346 for ips-outgoing; Tue, 30 Oct 2001 08:46:20 -0500 (EST) 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 f9UDkIl01342 for ; Tue, 30 Oct 2001 08:46:18 -0500 (EST) 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 OAA315588 for ; Tue, 30 Oct 2001 14:46:09 +0100 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 f9UDk8D83920 for ; Tue, 30 Oct 2001 14:46:08 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: Connection establishment criteria X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 30 Oct 2001 15:46:02 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/10/2001 15:46:08, Serialize complete at 30/10/2001 15:46:08 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Nandakumar, Once a session is established, when to create additional connections is entirely implementation dependent. One caveat is that if the last or only connection remaining goes down you have to establish a new one and reassign tasks if you have some within the bounds of an explicit or session default Time2Retain. Julo "Nandakumar Ramamurthy" Sent by: owner-ips@ece.cmu.edu 30-10-01 15:12 Please respond to "Nandakumar Ramamurthy" To: cc: Subject: iSCSI: Connection establishment criteria Hi All, Consider the following : An initiator and a target have established a session ( Leading login has been successful ). Thus, we have one connection between the initiator and target (the leading connection). Also assume MaxConnections has been agreed upon by both ends as X ( 2 or more ). My question is : What situations/conditions/events make the initiator to establish subsequent connections ? From my understanding, one definite event is when the leading connection goes down, thus, making the initiator to establish a new connection (for continuing the session ) which holds true even if MaxConnections = 1. Are the second and later connection(s) attempted immediately after the first connection is successful ? A seemingly related question on the alias earlier (from the mailing archives) suggests that connection establishment/selection is done by an iSCSI initiator to improve bandwidth/availability. Does this mean that "when to spawn consecutive connections" is purely implementation dependent ? Does any section of the draft clarify my question ? Please clarify. Thanks, Nandakumar. From owner-ips@ece.cmu.edu Tue Oct 30 10:02: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 KAA03162 for ; Tue, 30 Oct 2001 10:02:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9UEKdD03724 for ips-outgoing; Tue, 30 Oct 2001 09:20:39 -0500 (EST) 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 f9UEKcl03719 for ; Tue, 30 Oct 2001 09:20:38 -0500 (EST) Received: by LMOXCH04 with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Oct 2001 09:16:40 -0500 Message-ID: <8BE017CC8923D511A00A0008C78605EE7A8132@LMOXCH04> From: David Dillard To: "'Ron Cohen'" Cc: ips Subject: RE: iSCSI: Third Party Copy Date: Tue, 30 Oct 2001 09:16:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1614D.7C56E490" 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_01C1614D.7C56E490 Content-Type: text/plain; charset="iso-8859-1" Ron, Take a look at section 2.3 and appendix F. These areas discuss using the CHANGE ALIASES and REPORT ALIASES commands to handle this issue. David -----Original Message----- From: Ron Cohen [mailto:rcohen@eurologic.com] Sent: Tuesday, October 30, 2001 8:06 AM To: ips Subject: iSCSI: Third Party Copy I was looking through the Extended Copy command in SPC-2 and came across the problem of the format of a Target Descriptor for an iSCSI device. The current format for a Target Descriptor is 32-bytes which does not provide much in the way of possibilities for identifying a source or destination device in terms of its iSCSI name. If this has been handled already, can anyone direct me to the references which discuss the implementation of the Extended Copy command in an iSCSI SAN. Ronald Cohen E-mail: rcohen@Eurologic.com Telephone: +44 (0) 117 930 9615 ------_=_NextPart_001_01C1614D.7C56E490 Content-Type: text/html; charset="iso-8859-1"
Ron,
 
Take a look at section 2.3 and appendix F.  These areas discuss using the CHANGE ALIASES and REPORT ALIASES commands to handle this issue.
 
 
David
 
-----Original Message-----
From: Ron Cohen [mailto:rcohen@eurologic.com]
Sent: Tuesday, October 30, 2001 8:06 AM
To: ips
Subject: iSCSI: Third Party Copy

I was looking through the Extended Copy command in SPC-2 and came across the problem of the format of a Target Descriptor for an iSCSI device.  The current format for a Target Descriptor is 32-bytes which does not provide much in the way of possibilities for identifying a source or destination device in terms of its iSCSI name.  If this has been handled already, can anyone direct me to the references which discuss the implementation of the Extended Copy command in an iSCSI SAN.
 
Ronald Cohen
E-mail:  rcohen@Eurologic.com
Telephone:  +44 (0) 117 930 9615
------_=_NextPart_001_01C1614D.7C56E490-- From owner-ips@ece.cmu.edu Tue Oct 30 10: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 KAA04781 for ; Tue, 30 Oct 2001 10:52:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9UEmme05996 for ips-outgoing; Tue, 30 Oct 2001 09:48:48 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9UEmkl05992 for ; Tue, 30 Oct 2001 09:48:46 -0500 (EST) To: ips@ece.cmu.edu Subject: Re: iSCSI framing using TCP options In-Reply-To: Message from Ron Grinfeld of "Mon, 29 Oct 2001 09:11:29 +0200." <8B578C8302B3D411811200D0B7B64CD105E5CD@INTENS2> References: <8B578C8302B3D411811200D0B7B64CD105E5CD@INTENS2> Date: Tue, 30 Oct 2001 09:46:49 -0500 From: Stephen Bailey Message-Id: <20011030144829.932404E7A@sandmail.sandburst.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Ron, > iSCSI framing using TCP options was raised and noted in an > unofficial document (Jul/5/2000). Was this issue ever concluded ? > If so what is the resolution ? The TCP option approach was roundly rejected by the IETF transport community. The descendent of that effort, which takes the approach of delivering framing information in-band (in the TCP stream) is still active. The authors of that draft are actively working on a new version in response to many comments on draft-ietf-tsvwg-tcp-ulp-frame-00.txt. One likely change in the next revision of the draft (which I'm sure will go straight to last call, and win the hearts and minds of all who read it :^), is that it will only define what is called PDU alignment mode in -00. The other primary client of TCP framing is RDMA, and that community seems to have no interest in marker mode. Therefore, I would propose that iSCSI will continue with its own definition of marker mode as it currently does, and additionally call out a negotiation for ULP framing for TCP. However, I don't think any specific action is called for until draft-*-01.txt is released in the next few weeks. Steph From owner-ips@ece.cmu.edu Tue Oct 30 13:43: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 NAA10903 for ; Tue, 30 Oct 2001 13:43:23 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9UHbU120316 for ips-outgoing; Tue, 30 Oct 2001 12:37:30 -0500 (EST) 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 f9UHbRl20304 for ; Tue, 30 Oct 2001 12:37:28 -0500 (EST) 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 MAA07911 for ; Tue, 30 Oct 2001 12:37:21 -0500 (EST) Message-ID: <3BDEE304.B89C3782@cisco.com> Date: Tue, 30 Oct 2001 11:27:32 -0600 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: New iSCSI MIB draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit We have submitted a new iSCSI MIB draft to the repository. Until it becomes available, it may be retrieved as either a gzipped or text version from: ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt.gz ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt A matching UML drawing is available at: ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-uml-model-03.pdf The table hierarchy has been significantly flattened. This does not change the object model, but does reduce the number of redundant levels of OIDs when address individual objects. I will send a new table structure drawing soon. We will send a list of open issues to the IPS list shortly. Thanks, -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 From owner-ips@ece.cmu.edu Tue Oct 30 13:45: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 NAA11028 for ; Tue, 30 Oct 2001 13:45:47 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9UHL3318935 for ips-outgoing; Tue, 30 Oct 2001 12:21:03 -0500 (EST) 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 f9UHKhl18920 for ; Tue, 30 Oct 2001 12:20:43 -0500 (EST) 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 LAA31948; Tue, 30 Oct 2001 11:18:06 -0600 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9UHJ2f221768; Tue, 30 Oct 2001 10:19:21 -0700 Importance: Normal Subject: Re: iSCSI: proposal to solve the ISID issues To: "John Hufferd" , cbm@rose.hp.com Cc: ips@ece.cmu.edu From: "Jim Hafner" Date: Tue, 30 Oct 2001 09:19:00 -0800 Message-ID: X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/30/2001 09:19:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John and Mallikarjun, I appreciate where Mallikarjun wants to go here. There is a requirement that vendor NICs (managed by the same vendor driver) be configurable in their ISIDs. However, that requirement is more a derivative conclusion of the rules (for a good and correct implementation) than it is a protocol requirement. A vendor that doesn't do this only steps on his own toes when more than one of his cards is in a system! Perhaps we compromise and make this a big NOTE: NOTE: For correct behavior (in particular with respect to the ISID rule), a vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must provide either driver software or external and public APIs to allow for configuration and coordination of ISIDs for all sessions managed by multiple instances of that hardware within a given iSCSI Node. Such configuration might be either static (e.g., partitioned across all the NICs at initialization) or dynamic (e.g., on-line allocator). We can make the iSCSI Node Name a stronger requirement (that is, outside of a NOTE). Does that help? Jim Hafner John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 10/29/2001 06:47:31 pm Sent by: owner-ips@ece.cmu.edu To: cbm@rose.hp.com cc: ips@ece.cmu.edu Subject: Re: iSCSI: proposal to solve the ISID issues I have no problem with the Must have a way to have the Node name set. However, I do not grasp the problem you state here: "I don't believe the type of the ISID matters, nor does the NIC capability (coordinating vs not). If two initiator NICs share the same node name, they better not re-use the same ISID to a given target portal group. I was trying to capture the consequences of this reality." If the ISID includes the Vendor ID, I do not see the problem, unless the vendor can not assign the rest of the ISID. And I would say that it is the vendors problem to work out. If you are saying that with NICs (not HBAs) that the SW Drivers will have a problem coming up with the ISID, I do not understand that either since most software is built by a Vendor, and if not the Random type should work. Now in case you are saying something about the creation of a second Session from the Initiator, which is to access the same Target Node. Then by definition, the ISID must be unique. (and it will probably need a Wedge Driver to operate correctly). I would think that a vendor should be able to come up with a unique qualifier for the session since they have 64K numbers to chose from. Remember the vendor only needs to coordinate the lower 2 bytes of the new ISID, with itself. So if they can not do that, ... Oh well ... Are we on the same page yet? . . . 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 "Mallikarjun C." @core.rose.hp.com on 10/29/2001 06:35:55 PM Please respond to cbm@rose.hp.com Sent by: cbm@core.rose.hp.com To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: proposal to solve the ISID issues John, I take it that you don't have an issue with the Node Name part of the wording. I thought I answered your question by saying - "My point though is that by banning a duplicate nexus (that an inadvertently re-used ISID allows), we are making the ISID (dynamic/static) distribution an imminent hard requirement for all NICs in a given iSCSI initiator Node" The unspoken assumption above is that we would want to allow multiple sessions between an initiator node and a target portal group. I don't believe the type of the ISID matters, nor does the NIC capability (coordinating vs not). If two initiator NICs share the same node name, they better not re-use the same ISID to a given target portal group. I was trying to capture the consequences of this reality. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com John Hufferd wrote: > > Mallikarjun, > I do not understand the purpose for your proposed wordage > > "All iSCSIinitiator hardware implementations MUST in addition also support > the operational ISID values to be (either statically or dynamically) > externally configurable." > > Why is this so important that it is a MUST. The purpose of the proposal is > to eliminate the need for the above. At most it should only apply to the > vendors (Probably Software and at Universities and IT shops) that use the > RANDOM ISID type code. > > I do not see the need elsewhere. At most it could be "MAY". > > . > . > . > 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 > > "Mallikarjun C." @ece.cmu.edu on 10/29/2001 05:24:20 PM > > Please respond to cbm@rose.hp.com > > Sent by: owner-ips@ece.cmu.edu > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > Jim, > > Thanks for the quick response. > > As much as I would like to avoid consuming more bandwidth > on this topic, let me make one last strawman for wording below. > > > What words do you suggest? > ... > > And a lot depends on how > > functional the NICs are: (a) just network nics, (b) protocol nics, but > not > > session coordinating nics (c) full session coordination nics (with driver > > assist) (d) fully autonomous session nics. How do we make a requirement > > that fits all the cases correctly? > > I have been implying iSCSI NICs in all my postings so far - > sorry, may be that wasn't very clear. "iSCSI Node name" comment > obviously wasn't targeted at simple network NICs. So clearly (a) > is out of discussion. But you are right - I wasn't very precise. > Here's a strawman - > > All iSCSI hardware implementations (as in NICs) MUST allow > the iSCSI Node Name to be externally configurable. All iSCSI > initiator hardware implementations MUST in addition also > support the the operational ISID values to be (either statically > or dynamically) externally configurable. > > > Making them configurable (at > > initialization time, e.g., as a range of values) or making them dynamic > > (the driver generates them on demand) both fit the mold. So, I don't > think > > this one is a hard requirement. > > I agree that my earlier "range" wording was too constraining. > My point though is that by banning a duplicate nexus (that an > inadvertently re-used ISID allows), we are making the ISID > (dynamic/static) distribution an imminent hard requirement > for all NICs in a given iSCSI initiator Node - except it is > not sufficiently explicit. Please consider the above proposed > wording. > > > Well, I don't think so. If each vendor implements "conservative reuse" > > within their own ISID namespace on their own NICs, then you get this > > property system wide. > > You are right, I guess I briefly overlooked the fact that ISID > includes the vendor identifier within, per the new proposal. > > I am personally okay with making "conservative reuse" a > SHOULD. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > Jim Hafner wrote: > > > > Mallikarjun, > > > > Comments in line below > > > > Jim Hafner > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > 12:17:49 > > pm > > > > Please respond to cbm@rose.hp.com > > > > Sent by: cbm@core.rose.hp.com > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > Jim, > > > > Thanks for the excellent summary. Some questions/comments - > > > > - I assume that the NICs must enable the configuration of > > iSCSI Node name even in this proposal. If it is so, please > > call this out as a hard requirement in the main modelling > > discussion. > > > > > > This requirement doesn't change from before (but how it gets written into > > the spec may differ -- and we've had this discussion before). If a > vendor > > doesn't allow configuration of his NIC's iSCSI Node name, then his NICs > > will be acting as their own iSCSI Node (that is, not representing the > > system they live in). One can argue that this is a legitimate > > implementation (just as writing user-level code that uses its own iSCSI > > Node name). So a "hard requirement" may be a bit too strong. However, I > > will go with the will of the group on this point. > > > > What words do you suggest? > > > > - In the case of multiple NICs from the same vendor operating > > in an end node, it appears to me that the proposal implicitly > > assumes an ISID-range to be configurable among those NICs > > (perhaps in vendor-unique ways, which is always what I expected). > > If this is a correct inference, there is again a hard > > requirement on the NICs to make the ISID range configurable. > > Please comment on any subtle qualitative change from the > > earlier situation that I may be missing. > > > > > > Well, the point is that the vendor can manage his own namespace for his > > NICs anyway he/she/it wants to. Making them configurable (at > > initialization time, e.g., as a range of values) or making them dynamic > > (the driver generates them on demand) both fit the mold. So, I don't > think > > this one is a hard requirement (though that is probably how most vendors > > will implement their NICs). In effect, the proposal gives vendors more > > flexibility in their own space, without causing heterogenous > > interoperability problems within the host. And a lot depends on how > > functional the NICs are: (a) just network nics, (b) protocol nics, but > not > > session coordinating nics (c) full session coordination nics (with driver > > assist) (d) fully autonomous session nics. How do we make a requirement > > that fits all the cases correctly? You clearly have in mind a specific > > level of implementation within the NICs, but that may not be everybody's > > model. > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > particularly low-end that don't use reservations, can function more or > > > less OK without it. > > > > It seems we're attempting to set ourselves up for future in > > discussing the above requirement. Some questions - > > - It appears to me that the "conservative reuse" can not > > be enforced for initiators hosting NICs from different > > vendors (since the proposal allows ISID namespaces to > > be totally non-overlapping between non-homogenous NICs). > > Is this a fair assessment? > > > > Well, I don't think so. If each vendor implements "conservative reuse" > > within their own ISID namespace on their own NICs, then you get this > > property system wide. As before, by owning their own piece of the ISID > > namespace, they can implement what they want. So, you may have a > situation > > where some of your installed nics have this property and some don't. > > You'll find out (if your environment really needs conservative reuse) > that > > you haven't got it, and it becomes a marketing/purchase spec requirement. > > > > - Do you see a particular disadvantage for low-end systems > > if it's mandated (aside from the fact that they may be able > > to live without it)? > > > > No, but I don't see any way to really enforce it (or even really test > it). > > It's not a requirement of the protocol, per se. > > > > - Do you see any corner cases not being met (for future) > > if we don't make it a MUST (since you said "more or less OK")? > > > > No, I can't see that far into the future! :-{). One reason I'm being > cagey > > here is that I'm finding it difficult to find the right words to specify > > this as a hard requirement (but I'm no technical writer either!). > > > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > Jim Hafner wrote: > > > > > > Folks, (David Black in particular). > > > > > > Apologies for the long note, but the issue is complicated. > > > > > > The NDTeam have a proposal to resolve the concerns surrounding use of > > > ISIDs as essential components (along with iSCSI Initiator Name) of > > > SCSI Initiator Portname. (This was rooted in private discussions > > > between John Hufferd, Julian and myself -- and came about as a result > > > of the lengthy (and boring) discussions mostly myself and David > > > Black.) > > > > > > There are two somewhat orthogonal issues involved in this discussion: > > > > > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > > > accidentally breaking the ISID RULE (no parallel nexus) when > > > independent vendors co-exist in the same OS. > > > > > > 2) What ISID "reuse" rules should be specified to facilitate current > > > and future (soon?) SCSI reservation semantics (and also internal OS > > > views of SCSI Initiator Ports). > > > > > > To address these two issues, we (NDT) propose the following: > > > > > > 1) Enlarge the ISID field in the Login Request and Response to 6bytes > > > and structure it with a component that corresponds to a "naming > > > authority" (essentially the vendor generating the ISID). So vendors > > > each have a piece of the ISID namespace to work with their own > > > components (HBAs, SW, etc). More details below. > > > > > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used as > > > conservatively as possible ("conservative reuse"). What this means is > > > that a given ISID should be reused for as many sessions (across > > > multiple target portal groups) as possible (but never to the same > > > target portal group twice -- that's the ISID RULE). > > > > > > NOTES and ADVANTAGES: > > > > > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > > > effect, at the vendor-level, this provides a "partitioning" of that > > > namespace. > > > > > > (1-b) We don't need to specify an OS infrastructure requirement for > > > configuration of ISIDs -- each vendor can do it any way it chooses > > > (within its naming authority). > > > > > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes up > > > its own implementation. > > > > > > (1-d) This is not fundamentally different from David Black's > > > suggestion for a "key"; it just (a) defines it precisely and (b) > > > embeds it in an already defined (but enlarged) field. > > > > > > (1-e) Looking towards the future, as common ISID coordination > > > mechanisms are implemented between vendors (say, SNIA banding together > > > to define a precise API), this "naming authority" can be elevated to > > > the coordinating entity or even the OS vendor. > > > > > > (1-f) ISIDs have no global uniqueness property. They need only be > > > unique between a named iSCSI initiator and iSCSI target portal group. > > > That means that a vendor implementation can use the same algorithm to > > > generate ISIDs (under its naming authority) in every machine (OS). > > > > > > (2-a) If a SCSI target (or logical unit) is holding state (say > > > persistent reservation) for a SCSI Initiator Port (named by iSCSI Name > > > and ISID), and the associated nexus/session is dropped for some > > > reason, "reuse" by that initiator of that ISID will restore to the > > > resulting new session that state (with no other action on the part of > > > the upper SCSI layers). > > > > > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > > > different SCSI Target Ports (iSCSI Target portal groups), will enable > > > the SCSI target/logical unit to recognize a common SCSI Initiator Port > > > for those two paths. This facilitates future changes to SCSI > > > reservations (at least). > > > > > > (2-c) An initiator driver implementated with "conservative reuse" can > > > present to the OS a stable and fairly static view of the SCSI > > > Initiator Ports (one for each ISID). Current OS driver stacks > > > (including current wedge drivers) that are built on the presumption of > > > such a stable view, will not need modification to handle the more > > > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence of > > > a SCSI Initiator Port presented to the OS does not *require* that this > > > port discover all possible targets; what the initiator builds sessions > > > to using a specific ISID will determine what is presented to the OS as > > > "devices" and LUs visible to that SCSI Initiator Port (could be none > > > if that ISID is never actually used!).] > > > > > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator > > > Port is as simple as configuring another ISID! > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > particularly low-end that don't use reservations, can function more or > > > less OK without it. This is an open question. > > > > > > DETAILS: > > > > > > 1) ISID Structure: > > > The 6byte ISID structure would be split into three parts: > > > "type" field (1byte) -- identifies the format of the naming > > > authority field > > > "naming authority" field (3bytes) -- identifies the vendor (or > > > group of vendors) generating this ISID > > > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > > > > > The type field takes on three defined values with all other values > > > reserved: > > > Type naming authority format > > > 00h IEEE OUI > > > 01h IANA Enterprise Number (EN) > > > 02h "Random" > > > > > > The first types two provide a mechanism to uniquely (world wide) > > > identify the naming authority. A vendor with one or more OUIs and > > > possibly also Enterprise number MUST use at least one of these numbers > > > when it generates ISIDs. > > > > > > The "Random" type is for the case where the ISID generator (SW or HW) > > > is provided by an entity that has no OUI or EN. This includes, for > > > example, > > > -- a user-written program that builds sessions (and has access to the > > > system level iSCSI Name) > > > -- a university or other organization providing the component > > > -- a testing tool > > > > > > For the "Random" type, the naming authority field should be a random > > > or pseudo-random number. (See below on how this affects "conservative > > > reuse"). > > > > > > [Note: the "type" field needn't be this big, but NDT felt that (a) > > > 2bits was insufficient for the future, (b) the "type" field should be > > > first, and (c) the "naming authority" field should be byte-aligned.] > > > > > > 2) Conservative Reuse > > > > > > The "conservative reuse" principle of this proposal just says that > > > SCSI Initiator Portnames should be viewed as static things (as much as > > > possible) and reused (when feasible) to give the most stable > > > presentation of SCSI Initiator Ports to both the OS above and to SCSU > > > targets across the wire. > > > > > > Whereas the current draft says "The ISID RULE does not preclude the > > > use of the same ISID to different Target portal groups", the > > > "conservative reuse" requirement would say that such reuse (using the > > > same ISID to many target portal groups) is a SHOULD (or is that > > > MUST?). So, in one implementation, each iSCSI Initiator Portal group > > > would get configured with iSCSI Name, and a (small) set of ISIDs. The > > > portal group might take this set of ISIDs as an ordered list. The > > > first session to a Target portal group would use the first ISID, the > > > second to the *same* target portal group would use the second in the > > > list, etc. The number of ISIDs would then define a configuration > > > parameter that can be interpreted as the maximum number of sessions > > > that can be built to a given target portal group. > > > > > > To facilitate "conservative reuse", the "qualifier" field of a set of > > > ISIDs SHOULD be generated using either a repeatable algorithm > > > (non-random or pseudo-random but based on a fixed seed) or any > > > algorithm and stored in a persistent location (e.g., registry or /etc > > > file). > > > > > > For the "Random" type, "conservative reuse" may not be an issue (say, > > > user application that doesn't care about reservations, etc.). When it > > > is, the "naming authority" field SHOULD also be generated by a > > > mechanism similar to that for the "qualifier" field as specified above > > > (e.g., defined in the SW at compilation time.) > > > > > > DOCUMENTATING CHANGES: > > > > > > The iscsi drafts would need the following minor changes to support > > > this proposal: > > > > > > NDT doc > > > (a) define the structure of the ISID field (as described above) > > > (b) add some notes about implementation in the presense of > > > "conservative reuse" (e.g., that ISID should be configured once, say > > > at install time, then reused on subsequent reboots, even for "Random" > > > type). > > > > > > iSCSI MAIN doc: > > > (a) move the CID field in Login Request to another reserved field. > > > (b) expand the ISID field in Login Request and Response to encompass > > > the previous 4 bytes. > > > (c) add a sentence where the ISID field is defined indicating that > > > this field is a structured value, showing the structure (as above) and > > > point to the NDT document. > > > (d) add some text to "Note to Implementors" on "conservative reuse". > > > > > > Comments? > > > > > > Jim Hafner -- 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 Tue Oct 30 14:48: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 OAA12864 for ; Tue, 30 Oct 2001 14:48:39 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9UJ6Lr28241 for ips-outgoing; Tue, 30 Oct 2001 14:06:21 -0500 (EST) 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 f9UJ6Il28233 for ; Tue, 30 Oct 2001 14:06:18 -0500 (EST) Received: from cisco.com (dhcp-161-44-68-189.cisco.com [161.44.68.189]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA14294 for ; Tue, 30 Oct 2001 14:06:13 -0500 (EST) Message-ID: <3BDEFA15.2529EFAB@cisco.com> Date: Tue, 30 Oct 2001 13:05:57 -0600 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI: current UNH Plugfest 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: > For numerical and single literal negotiations, the responding party MUST > respond with the required key and the value it selects, based on the > selection rule specific to the key, becomes the negotiation result. If a > key is irrelevant in the current negotiation, the responder may use the > special numeric constant 0r. > Selection of a value not admissible under the selection rules is > considered a protocol error and handled accordingly. I don't see the point or using '0r' instead of 'irrelevant' like the list and boolean types do. Even numeric types have to check for 'NotUnderstood', a decidedly non numeric value. Steve Senum From owner-ips@ece.cmu.edu Tue Oct 30 14:53: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 OAA13037 for ; Tue, 30 Oct 2001 14:53:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9UIgRV26192 for ips-outgoing; Tue, 30 Oct 2001 13:42:27 -0500 (EST) 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 f9UIgOl26187 for ; Tue, 30 Oct 2001 13:42:25 -0500 (EST) 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 TAA177194 for ; Tue, 30 Oct 2001 19:42:18 +0100 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 f9UIgHD65194 for ; Tue, 30 Oct 2001 19:42:17 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: current UNH Plugfest X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Tue, 30 Oct 2001 20:42:15 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 30/10/2001 20:42:16, Serialize complete at 30/10/2001 20:42:16 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Bob, Good work. My comment in text. Regards, Julo "Robert D. Russell" Sent by: owner-ips@ece.cmu.edu 30-10-01 02:44 Please respond to "Robert D. Russell" To: ips@ece.cmu.edu cc: Subject: iSCSI: current UNH Plugfest Attached are some of the issues that arose during the first day of the iSCSI plugfest at UNH on Monday 29-Oct-2001. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 ---------------------------------------------------------------------------- 1. Situation: the very first command sent on a new connection is a login. However, the I bit is not set. What should the target do? Interpretation 1: According to section 8.3 page 127 of draft 8, "Explicit violations of the PDU layout rules stated in this document are format errors." "When a target or an initiator receives an iSCSI PDU with a format error, it MUST reset all transport connections in the session immediately ..." This is a format error so section 8.3 applies. Therefore, the target should simply close the connection without sending anything to the initiator. Interpretation 2: This is a login command that contains an error caused by the initiator. Therefore, the target should send back a login response with a status code of 0x0200 and then close the TCP connection. +++ I will change 3.13.5 to explicitly say that class 2 does not cover format errors). 2 - Initiator Error (not a format 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. ++++ 2. Situation: on the first login command in operational parameter negotiation stage, the initiator sends the keys InitialR2T=yes and ImmediateData=no and the target agrees with these values. Therefore, according to the table on page 182 of draft 8, both sides agree that unsolicited data is disallowed. These keys are then followed, either later in the keys associated with this same login command or in a subsequent login command belonging to the same login phase, with the key FirstBurstSize=6. What should the target do? Interpretation 1: FirstBurstSize indicates "the maximum amount of unsolicited data an iSCSI initiator may send to the target during the execution of a single SCSI command, in units of 512 bytes." However unsolicited data is now disallowed, so FirstBurstSize is irrelevant. Therefore, no response is necessary -- the key is just ignored. Interpretation 2: In section 2.2.4 on page 30 of draft 8 it says "For numerical negotiations, the responding party MUST respond with the required key." Since FirstBurstSize is a numerical key, the target MUST respond with a numeric value ("reject" is not allowed for numerical keys), even if the value is irrelevant and will not be used. ++++ I suggest adding the "irrelevant" and 0r constants to 2.2.4 as follows: During login and thereafter some session or connection parameters are negotiated through an exchange of textual information. The initiator starts the negotiation through a Text/Login request and indicates when it is ready for completion (by setting to 1 and keeping to 1 the F bit in a Text/Login request). All negotiations are stateless - i.e. the result MUST be based only on newly exchanged values. The general format of text negotiation is: Originator-> = Responder-> =|NotUnderstood The value can be a number, a single literal constant a Boolean value (yes or no) or a list of comma separated literal constant values. In literal list negotiation, the originator sends for each key a list of options (literal constants which may include "none") in its order of preference. The responding party answers with the first value from the list it supports and is allowed to use for the specific originator. The constant "none" MUST always be used to indicate a missing function. However, none is a valid selection only if it is explicitly offered. If a responder is not supporting, or not allowed to use with a specific originator, any of the offered options, it may use the constant "reject". If a specific key is not relevant for the current text negotiation the responder may answer with the constant "irrelevant". The constants "none", "reject" and "irrelevant" are reserved and must be used only as described here. For numerical and single literal negotiations, the responding party MUST respond with the required key and the value it selects, based on the selection rule specific to the key, becomes the negotiation result. If a key is irrelevant in the current negotiation, the responder may use the special numeric constant 0r. Selection of a value not admissible under the selection rules is considered a protocol error and handled accordingly. For Boolean negotiations (keys taking the values yes or no), the responding party MUST respond with the required key and the result of the negotiation when the received value does not determine that result by itself. The last value transmitted becomes the negotiation result. The rules for selecting the value to respond with are expressed as Boolean functions of the value received and the value that the responding party would select in the absence of knowledge of the received value. Specifically, the two cases in which responses are OPTIONAL are: - The Boolean function is "AND" and the value "no" is received. The outcome of the negotiation is "no". - The Boolean function is "OR" and the value "yes" is received. The outcome of the negotiation is "yes". Responses are REQUIRED in all other cases, and the value chosen and sent by the responder becomes the outcome of the negotiation. If a specific key is not relevant for the current Boolean negotiation the responder may answer with the constant "irrelevant". Any key not understood is answered with "NotUnderstood". The value "?" with any key has the meaning of enquiry and should be answered with the current value or "NotUnderstood". Target requests are not limited to respond to key=value pairs as offered by the initiator. The target may offer key=value pairs of its own. +++++ 3. Situation: As the first command on a new connection the initiator sends a valid login command with SessionType=discovery, CSG=0, NSG=3, and T=1. The target responds with CSG=0, NSG=1 and T=1. So both sides are now in the operational parameter negotiation stage. Question: what parameters can they negotiate in this stage for a discovery session, and what should be done if other, irrelevant, parameters are negotiated? Interpretation 1: The only relevant operational parameters in a discovery session seem to be those related to markers (FMarker, RFMarkInt, SFMarkInt), error recovery (ErrorRecoveryLevel) and vendor specific keys. If this is true, what should one side do when the other side attempts to negotiate other operational parameters in a discovery session? Interpretation 2: Even the relevant operational parameters in a discovery session given above have very marginal utility. It would be easier to just disallow all operational parameter negotiation in a discovery session. +++ I assume that the "irrelevant" item solves this issue as well. +++ 4. Contradiction in draft 8. In section 3.13.5 on page 92 it says that in a login response: "for a non-zero Status-Class the T, CSG & NSG fields MUST be 0." +++ That has been removed - it was a a residue from an intermediate proposal +++ In section 5.1 on page 112 it says that in a login response with login reject (i.e., Status-Class non-zero): "The T bit of the response MUST be set to 1 and the CSG and NSG are ignored." ++++ I will change ignored to reserved +++ One of these has to be changed. Note also that the second statement just given (from page 112) is inconsistent with the statement in section 3.12.4 on page 87 that for login requests: "the next stage value is valid only when the T bit is 1 and is reserved otherwise." One would expect the standard to have the same rule for the way the T, NSG and CSG fields are handled in both login request and login response. +++ The reject is peculiar - there is no present nor future in it :-) +++ 5. Clarification suggested: In section 3.13.4 on page 91 of draft 8 it says: "For the first Login Response (the response to the first Login Request) this is the starting status Sequence Number for the connection (the next response of any kind will carry this number + 1)." If the login phase requires more than one login-request/login-response exchange, this rule implies that the second (third, fourth, ...) login-response should be incrementing StatSN. Nobody was doing this, although it seems clear that the standard requires it. Perhaps there needs to be a slight addition to the wording of this section so it reads: "For the first Login Response (the response to the first Login Request) this is the starting status Sequence Number for the connection (the next response of any kind, including the next login response if any in the same login phase, will carry this number + 1)." +++ I will add the text. +++ 6. Situations where frequent errors or misunderstandings occured, although the draft seems clear: 1. - StatSN must be incremented in Login Phase (point 5 above) 2. - CmdSN must not be incremented CmdSN in Login Phase 3. - it is okay to transmit the first command of the Login Phase with the CSG set to 1. It is also okay for the target to reject it and to close the connection. 4. - If the Initiator transmits its first command of the Login Phase with the T bit set, its okay for the target to transmit a response with T = 0, even though there is no example in the draft demonstrating it. 5. - Stage Transitions from 0 to 3 are valid according to the spec although this is not specifically stated in the draft. +++ Stage transition 0-3 is enabled specifically by the table in 5 pg 114 +++ From owner-ips@ece.cmu.edu Tue Oct 30 15:48: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 PAA14030 for ; Tue, 30 Oct 2001 15:48:17 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9UJfPJ01295 for ips-outgoing; Tue, 30 Oct 2001 14:41:25 -0500 (EST) 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 f9UJfCl01272 for ; Tue, 30 Oct 2001 14:41:22 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel2.hp.com (Postfix) with ESMTP id 617B97C6; Tue, 30 Oct 2001 14:41:11 -0500 (EST) 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 LAA17470; Tue, 30 Oct 2001 11:42:36 -0800 (PST) Message-Id: <200110301942.LAA17470@core.rose.hp.com> Date: Tue, 30 Oct 2001 11:53:20 -0800 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: Jim Hafner Cc: ips@ece.cmu.edu Subject: Re: iSCSI: proposal to solve the ISID issues 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, I am in broad agreement with you on your suggestion, and I agree that the ISID-configurability is a derivative requirement - but my argument is that it's nevertheless a crucial one to warrant making it explicit, but I can live with the proposed compromise of making it a NOTE. Some comments - >There is a requirement > that vendor NICs (managed by the same vendor driver) be configurable in > their ISIDs. I am kind of perplexed on this underlying assumption that a vendor NICs are "managed by the same vendor driver". As you know, this is not always true. IMHO, regardless of vendor and driver affiliations, an iSCSI initiator NIC MUST have external ISID-configurability - that's a design constraint on a NIC vendor (from the ISID rule)! [ Note that I am NOT suggesting that the API be "public", it's upto the NIC vendor on allowing third-party drivers - and I believe most would. ] With that, I would suggest the following wordsmithing, but I will not press it any further... NOTE: For correct behavior (in particular with respect to the ISID rule), a vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must allow for configuration and coordination of ISIDs for all sessions managed by multiple instances of that hardware within a given iSCSI Node. Such configuration might be either static (e.g., partitioned across all the NICs at initialization) or dynamic (e.g., on-line allocator). I hope the suggested wording (or something close to it) on the Node name would make its way in. Finally, thanks for so patiently driving this issue! -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Jim Hafner wrote: > > John and Mallikarjun, > > I appreciate where Mallikarjun wants to go here. There is a requirement > that vendor NICs (managed by the same vendor driver) be configurable in > their ISIDs. However, that requirement is more a derivative conclusion of > the rules (for a good and correct implementation) than it is a protocol > requirement. A vendor that doesn't do this only steps on his own toes when > more than one of his cards is in a system! > > Perhaps we compromise and make this a big NOTE: > > NOTE: For correct behavior (in particular with respect to the ISID rule), a > vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must provide > either driver software or external and public APIs to allow for > configuration and coordination of ISIDs for all sessions managed by > multiple instances of that hardware within a given iSCSI Node. Such > configuration might be either static (e.g., partitioned across all the NICs > at initialization) or dynamic (e.g., on-line allocator). > > We can make the iSCSI Node Name a stronger requirement (that is, outside of > a NOTE). > > Does that help? > > Jim Hafner > > John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 10/29/2001 06:47:31 pm > > Sent by: owner-ips@ece.cmu.edu > > To: cbm@rose.hp.com > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > I have no problem with the Must have a way to have the Node name set. > However, I do not grasp the problem you state here: > > "I don't believe the type of the ISID matters, nor does > the NIC capability (coordinating vs not). If two initiator > NICs share the same node name, they better not re-use the > same ISID to a given target portal group. I was trying > to capture the consequences of this reality." > > If the ISID includes the Vendor ID, I do not see the problem, unless the > vendor can not assign the rest of the ISID. And I would say that it is the > vendors problem to work out. If you are saying that with NICs (not HBAs) > that the SW Drivers will have a problem coming up with the ISID, I do not > understand that either since most software is built by a Vendor, and if not > the Random type should work. > > Now in case you are saying something about the creation of a second Session > from the Initiator, which is to access the same Target Node. Then by > definition, the ISID must be unique. (and it will probably need a Wedge > Driver to operate correctly). I would think that a vendor should be able > to come up with a unique qualifier for the session since they have 64K > numbers to chose from. Remember the vendor only needs to coordinate the > lower 2 bytes of the new ISID, with itself. So if they can not do that, > ... Oh well ... > > Are we on the same page yet? > > . > . > . > 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 > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 06:35:55 > PM > > Please respond to cbm@rose.hp.com > > Sent by: cbm@core.rose.hp.com > > To: John Hufferd/San Jose/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > John, > > I take it that you don't have an issue with the > Node Name part of the wording. > > I thought I answered your question by saying - > > "My point though is that by banning a duplicate nexus (that an > inadvertently re-used ISID allows), we are making the ISID > (dynamic/static) distribution an imminent hard requirement > for all NICs in a given iSCSI initiator Node" > > The unspoken assumption above is that we would want to > allow multiple sessions between an initiator node and > a target portal group. > > I don't believe the type of the ISID matters, nor does > the NIC capability (coordinating vs not). If two initiator > NICs share the same node name, they better not re-use the > same ISID to a given target portal group. I was trying > to capture the consequences of this reality. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > John Hufferd wrote: > > > > Mallikarjun, > > I do not understand the purpose for your proposed wordage > > > > "All iSCSIinitiator hardware implementations MUST in addition also > support > > the operational ISID values to be (either statically or dynamically) > > externally configurable." > > > > Why is this so important that it is a MUST. The purpose of the proposal > is > > to eliminate the need for the above. At most it should only apply to the > > vendors (Probably Software and at Universities and IT shops) that use the > > RANDOM ISID type code. > > > > I do not see the need elsewhere. At most it could be "MAY". > > > > . > > . > > . > > 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 > > > > "Mallikarjun C." @ece.cmu.edu on 10/29/2001 05:24:20 PM > > > > Please respond to cbm@rose.hp.com > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > Jim, > > > > Thanks for the quick response. > > > > As much as I would like to avoid consuming more bandwidth > > on this topic, let me make one last strawman for wording below. > > > > > What words do you suggest? > > ... > > > And a lot depends on how > > > functional the NICs are: (a) just network nics, (b) protocol nics, but > > not > > > session coordinating nics (c) full session coordination nics (with > driver > > > assist) (d) fully autonomous session nics. How do we make a > requirement > > > that fits all the cases correctly? > > > > I have been implying iSCSI NICs in all my postings so far - > > sorry, may be that wasn't very clear. "iSCSI Node name" comment > > obviously wasn't targeted at simple network NICs. So clearly (a) > > is out of discussion. But you are right - I wasn't very precise. > > Here's a strawman - > > > > All iSCSI hardware implementations (as in NICs) MUST allow > > the iSCSI Node Name to be externally configurable. All iSCSI > > initiator hardware implementations MUST in addition also > > support the the operational ISID values to be (either statically > > or dynamically) externally configurable. > > > > > Making them configurable (at > > > initialization time, e.g., as a range of values) or making them dynamic > > > (the driver generates them on demand) both fit the mold. So, I don't > > think > > > this one is a hard requirement. > > > > I agree that my earlier "range" wording was too constraining. > > My point though is that by banning a duplicate nexus (that an > > inadvertently re-used ISID allows), we are making the ISID > > (dynamic/static) distribution an imminent hard requirement > > for all NICs in a given iSCSI initiator Node - except it is > > not sufficiently explicit. Please consider the above proposed > > wording. > > > > > Well, I don't think so. If each vendor implements "conservative reuse" > > > within their own ISID namespace on their own NICs, then you get this > > > property system wide. > > > > You are right, I guess I briefly overlooked the fact that ISID > > includes the vendor identifier within, per the new proposal. > > > > I am personally okay with making "conservative reuse" a > > SHOULD. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > Jim Hafner wrote: > > > > > > Mallikarjun, > > > > > > Comments in line below > > > > > > Jim Hafner > > > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > > 12:17:49 > > > pm > > > > > > Please respond to cbm@rose.hp.com > > > > > > Sent by: cbm@core.rose.hp.com > > > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > > cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > Jim, > > > > > > Thanks for the excellent summary. Some questions/comments - > > > > > > - I assume that the NICs must enable the configuration of > > > iSCSI Node name even in this proposal. If it is so, please > > > call this out as a hard requirement in the main modelling > > > discussion. > > > > > > > > > This requirement doesn't change from before (but how it gets written > into > > > the spec may differ -- and we've had this discussion before). If a > > vendor > > > doesn't allow configuration of his NIC's iSCSI Node name, then his NICs > > > will be acting as their own iSCSI Node (that is, not representing the > > > system they live in). One can argue that this is a legitimate > > > implementation (just as writing user-level code that uses its own iSCSI > > > Node name). So a "hard requirement" may be a bit too strong. However, > I > > > will go with the will of the group on this point. > > > > > > What words do you suggest? > > > > > > - In the case of multiple NICs from the same vendor operating > > > in an end node, it appears to me that the proposal implicitly > > > assumes an ISID-range to be configurable among those NICs > > > (perhaps in vendor-unique ways, which is always what I expected). > > > If this is a correct inference, there is again a hard > > > requirement on the NICs to make the ISID range configurable. > > > Please comment on any subtle qualitative change from the > > > earlier situation that I may be missing. > > > > > > > > > Well, the point is that the vendor can manage his own namespace for his > > > NICs anyway he/she/it wants to. Making them configurable (at > > > initialization time, e.g., as a range of values) or making them dynamic > > > (the driver generates them on demand) both fit the mold. So, I don't > > think > > > this one is a hard requirement (though that is probably how most > vendors > > > will implement their NICs). In effect, the proposal gives vendors more > > > flexibility in their own space, without causing heterogenous > > > interoperability problems within the host. And a lot depends on how > > > functional the NICs are: (a) just network nics, (b) protocol nics, but > > not > > > session coordinating nics (c) full session coordination nics (with > driver > > > assist) (d) fully autonomous session nics. How do we make a > requirement > > > that fits all the cases correctly? You clearly have in mind a specific > > > level of implementation within the NICs, but that may not be > everybody's > > > model. > > > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > particularly low-end that don't use reservations, can function more > or > > > > less OK without it. > > > > > > It seems we're attempting to set ourselves up for future in > > > discussing the above requirement. Some questions - > > > - It appears to me that the "conservative reuse" can not > > > be enforced for initiators hosting NICs from different > > > vendors (since the proposal allows ISID namespaces to > > > be totally non-overlapping between non-homogenous NICs). > > > Is this a fair assessment? > > > > > > Well, I don't think so. If each vendor implements "conservative reuse" > > > within their own ISID namespace on their own NICs, then you get this > > > property system wide. As before, by owning their own piece of the ISID > > > namespace, they can implement what they want. So, you may have a > > situation > > > where some of your installed nics have this property and some don't. > > > You'll find out (if your environment really needs conservative reuse) > > that > > > you haven't got it, and it becomes a marketing/purchase spec > requirement. > > > > > > - Do you see a particular disadvantage for low-end systems > > > if it's mandated (aside from the fact that they may be able > > > to live without it)? > > > > > > No, but I don't see any way to really enforce it (or even really test > > it). > > > It's not a requirement of the protocol, per se. > > > > > > - Do you see any corner cases not being met (for future) > > > if we don't make it a MUST (since you said "more or less > OK")? > > > > > > No, I can't see that far into the future! :-{). One reason I'm being > > cagey > > > here is that I'm finding it difficult to find the right words to > specify > > > this as a hard requirement (but I'm no technical writer either!). > > > > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > MS 5668 Hewlett-Packard, Roseville. > > > cbm@rose.hp.com > > > > > > Jim Hafner wrote: > > > > > > > > Folks, (David Black in particular). > > > > > > > > Apologies for the long note, but the issue is complicated. > > > > > > > > The NDTeam have a proposal to resolve the concerns surrounding use of > > > > ISIDs as essential components (along with iSCSI Initiator Name) of > > > > SCSI Initiator Portname. (This was rooted in private discussions > > > > between John Hufferd, Julian and myself -- and came about as a result > > > > of the lengthy (and boring) discussions mostly myself and David > > > > Black.) > > > > > > > > There are two somewhat orthogonal issues involved in this discussion: > > > > > > > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > > > > accidentally breaking the ISID RULE (no parallel nexus) when > > > > independent vendors co-exist in the same OS. > > > > > > > > 2) What ISID "reuse" rules should be specified to facilitate current > > > > and future (soon?) SCSI reservation semantics (and also internal OS > > > > views of SCSI Initiator Ports). > > > > > > > > To address these two issues, we (NDT) propose the following: > > > > > > > > 1) Enlarge the ISID field in the Login Request and Response to 6bytes > > > > and structure it with a component that corresponds to a "naming > > > > authority" (essentially the vendor generating the ISID). So vendors > > > > each have a piece of the ISID namespace to work with their own > > > > components (HBAs, SW, etc). More details below. > > > > > > > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used > as > > > > conservatively as possible ("conservative reuse"). What this means > is > > > > that a given ISID should be reused for as many sessions (across > > > > multiple target portal groups) as possible (but never to the same > > > > target portal group twice -- that's the ISID RULE). > > > > > > > > NOTES and ADVANTAGES: > > > > > > > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > > > > effect, at the vendor-level, this provides a "partitioning" of that > > > > namespace. > > > > > > > > (1-b) We don't need to specify an OS infrastructure requirement for > > > > configuration of ISIDs -- each vendor can do it any way it chooses > > > > (within its naming authority). > > > > > > > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes up > > > > its own implementation. > > > > > > > > (1-d) This is not fundamentally different from David Black's > > > > suggestion for a "key"; it just (a) defines it precisely and (b) > > > > embeds it in an already defined (but enlarged) field. > > > > > > > > (1-e) Looking towards the future, as common ISID coordination > > > > mechanisms are implemented between vendors (say, SNIA banding > together > > > > to define a precise API), this "naming authority" can be elevated to > > > > the coordinating entity or even the OS vendor. > > > > > > > > (1-f) ISIDs have no global uniqueness property. They need only be > > > > unique between a named iSCSI initiator and iSCSI target portal group. > > > > That means that a vendor implementation can use the same algorithm to > > > > generate ISIDs (under its naming authority) in every machine (OS). > > > > > > > > (2-a) If a SCSI target (or logical unit) is holding state (say > > > > persistent reservation) for a SCSI Initiator Port (named by iSCSI > Name > > > > and ISID), and the associated nexus/session is dropped for some > > > > reason, "reuse" by that initiator of that ISID will restore to the > > > > resulting new session that state (with no other action on the part of > > > > the upper SCSI layers). > > > > > > > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > > > > different SCSI Target Ports (iSCSI Target portal groups), will enable > > > > the SCSI target/logical unit to recognize a common SCSI Initiator > Port > > > > for those two paths. This facilitates future changes to SCSI > > > > reservations (at least). > > > > > > > > (2-c) An initiator driver implementated with "conservative reuse" can > > > > present to the OS a stable and fairly static view of the SCSI > > > > Initiator Ports (one for each ISID). Current OS driver stacks > > > > (including current wedge drivers) that are built on the presumption > of > > > > such a stable view, will not need modification to handle the more > > > > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence > of > > > > a SCSI Initiator Port presented to the OS does not *require* that > this > > > > port discover all possible targets; what the initiator builds > sessions > > > > to using a specific ISID will determine what is presented to the OS > as > > > > "devices" and LUs visible to that SCSI Initiator Port (could be none > > > > if that ISID is never actually used!).] > > > > > > > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator > > > > Port is as simple as configuring another ISID! > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > particularly low-end that don't use reservations, can function more > or > > > > less OK without it. This is an open question. > > > > > > > > DETAILS: > > > > > > > > 1) ISID Structure: > > > > The 6byte ISID structure would be split into three parts: > > > > "type" field (1byte) -- identifies the format of the naming > > > > authority field > > > > "naming authority" field (3bytes) -- identifies the vendor (or > > > > group of vendors) generating this ISID > > > > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > > > > > > > The type field takes on three defined values with all other values > > > > reserved: > > > > Type naming authority format > > > > 00h IEEE OUI > > > > 01h IANA Enterprise Number (EN) > > > > 02h "Random" > > > > > > > > The first types two provide a mechanism to uniquely (world wide) > > > > identify the naming authority. A vendor with one or more OUIs and > > > > possibly also Enterprise number MUST use at least one of these > numbers > > > > when it generates ISIDs. > > > > > > > > The "Random" type is for the case where the ISID generator (SW or HW) > > > > is provided by an entity that has no OUI or EN. This includes, for > > > > example, > > > > -- a user-written program that builds sessions (and has access to the > > > > system level iSCSI Name) > > > > -- a university or other organization providing the component > > > > -- a testing tool > > > > > > > > For the "Random" type, the naming authority field should be a random > > > > or pseudo-random number. (See below on how this affects "conservative > > > > reuse"). > > > > > > > > [Note: the "type" field needn't be this big, but NDT felt that (a) > > > > 2bits was insufficient for the future, (b) the "type" field should be > > > > first, and (c) the "naming authority" field should be byte-aligned.] > > > > > > > > 2) Conservative Reuse > > > > > > > > The "conservative reuse" principle of this proposal just says that > > > > SCSI Initiator Portnames should be viewed as static things (as much > as > > > > possible) and reused (when feasible) to give the most stable > > > > presentation of SCSI Initiator Ports to both the OS above and to SCSU > > > > targets across the wire. > > > > > > > > Whereas the current draft says "The ISID RULE does not preclude the > > > > use of the same ISID to different Target portal groups", the > > > > "conservative reuse" requirement would say that such reuse (using the > > > > same ISID to many target portal groups) is a SHOULD (or is that > > > > MUST?). So, in one implementation, each iSCSI Initiator Portal group > > > > would get configured with iSCSI Name, and a (small) set of ISIDs. > The > > > > portal group might take this set of ISIDs as an ordered list. The > > > > first session to a Target portal group would use the first ISID, the > > > > second to the *same* target portal group would use the second in the > > > > list, etc. The number of ISIDs would then define a configuration > > > > parameter that can be interpreted as the maximum number of sessions > > > > that can be built to a given target portal group. > > > > > > > > To facilitate "conservative reuse", the "qualifier" field of a set of > > > > ISIDs SHOULD be generated using either a repeatable algorithm > > > > (non-random or pseudo-random but based on a fixed seed) or any > > > > algorithm and stored in a persistent location (e.g., registry or /etc > > > > file). > > > > > > > > For the "Random" type, "conservative reuse" may not be an issue (say, > > > > user application that doesn't care about reservations, etc.). When > it > > > > is, the "naming authority" field SHOULD also be generated by a > > > > mechanism similar to that for the "qualifier" field as specified > above > > > > (e.g., defined in the SW at compilation time.) > > > > > > > > DOCUMENTATING CHANGES: > > > > > > > > The iscsi drafts would need the following minor changes to support > > > > this proposal: > > > > > > > > NDT doc > > > > (a) define the structure of the ISID field (as described above) > > > > (b) add some notes about implementation in the presense of > > > > "conservative reuse" (e.g., that ISID should be configured once, say > > > > at install time, then reused on subsequent reboots, even for "Random" > > > > type). > > > > > > > > iSCSI MAIN doc: > > > > (a) move the CID field in Login Request to another reserved field. > > > > (b) expand the ISID field in Login Request and Response to encompass > > > > the previous 4 bytes. > > > > (c) add a sentence where the ISID field is defined indicating that > > > > this field is a structured value, showing the structure (as above) > and > > > > point to the NDT document. > > > > (d) add some text to "Note to Implementors" on "conservative reuse". > > > > > > > > Comments? > > > > > > > > Jim Hafner > > -- > 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 Tue Oct 30 17:58: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 RAA16703 for ; Tue, 30 Oct 2001 17:58:02 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9UM8sl12766 for ips-outgoing; Tue, 30 Oct 2001 17:08:54 -0500 (EST) 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 f9UM8ol12761 for ; Tue, 30 Oct 2001 17:08:50 -0500 (EST) 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 OAA09314; Tue, 30 Oct 2001 14:08:26 -0800 (PST) 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 NAA18760; Tue, 30 Oct 2001 13:54:10 -0800 (PST) Received: by aimexc03.corp.adaptec.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Oct 2001 14:08:25 -0800 Message-ID: <268DBFF7D2A3D411A37400D0B72E345F0113A95F@aimexc03.corp.adaptec.com> From: "De, Tandra" To: "Julian Satran (E-mail)" Cc: "'ips@ece.cmu.edu'" , "De, Tandra" Subject: iSCSI CRC check clarification Date: Tue, 30 Oct 2001 14:08:24 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1618F.64C22FF0" 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_01C1618F.64C22FF0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1618F.64C22FF0" ------_=_NextPart_001_01C1618F.64C22FF0 Content-Type: text/plain; charset="iso-8859-1" Julian, I followed few iSCSI CRC checking example threads and the thread file://www.pdl.cmu.edu/mailinglists/ips/mail/msg05931.html says that "Before transmission, the CRC bits must be reflected and complemented"; whereas, the iscsi- 08 draft only mentions about complementing the CRC before transmission. So attached you will find two software implementation code examples: crc_reflect.cpp and crc_no_reflect.cpp. I ran few test cases with the attached example code and when I do reflect bits I get 0: ff ff ff ff 4: ff ff ff ff 8: ff ff ff ff 12: ff ff ff ff 16: ff ff ff ff 20: ff ff ff ff 24: ff ff ff ff 28: ff ff ff ff 32: 43 ab a8 62 in the transmission side, and the reception side I get 0x1c2d19ed. But when I do not bit flip I get 0: ff ff ff ff 4: ff ff ff ff 8: ff ff ff ff 12: ff ff ff ff 16: ff ff ff ff 20: ff ff ff ff 24: ff ff ff ff 28: ff ff ff ff 32: 46 15 d5 c2 in the transmission side, and the reception side I do get 0x1c2d19ed though. I like to clarify which implementation we should use so that both Initiator and Target will be in sync. validating the CRC. I appreciate if you could verify the attached files to see I am missing anytbing. Also I think that it would help everyone who are dealing with iSCSI CRC if you could put up the finalized version of the code in the reflector. Thanks, Tandra ( tde@corp.adaptec.com ) ------_=_NextPart_001_01C1618F.64C22FF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Julian,
 
I = followed few iSCSI=20 CRC checking example threads and the thread file= ://www.pdl.cmu.edu/mailinglists/ips/mail/msg05931.html says=20 that "Before transmission, the CRC bits must be reflected and = complemented";=20 whereas, the iscsi- 08 draft only mentions about complementing the CRC = before=20 transmission. So attached you will find two software implementation = code=20 examples: crc_reflect.cpp and crc_no_reflect.cpp.
I ran = few test cases=20 with the attached example code and when I do reflect bits I=20 get
       &nb= sp;           &nb= sp;           =20 0:        ff ff ff=20 ff
           =             =         =20 4:        ff ff ff=20 ff
           =             =         =20 8:        ff ff ff=20 ff
           =             =        =20 12:        ff ff ff=20 ff
           =             =        =20 16:        ff ff ff=20 ff
           =             =        =20 20:        ff ff ff=20 ff
           =             =        =20 24:        ff ff ff=20 ff
           =             =        =20 28:        ff ff ff = ff
 
       &nb= sp;           &nb= sp;          =20 32:        43 ab a8 = 62
in = the transmission=20 side, and the reception side I get 0x1c2d19ed.
 
But = when I do not=20 bit flip I get
       &nb= sp;           &nb= sp;           =20 0:        ff ff ff=20 ff
           =             =         =20 4:        ff ff ff=20 ff
           =             =         =20 8:        ff ff ff=20 ff
           =             =        =20 12:        ff ff ff=20 ff
           =             =        =20 16:        ff ff ff=20 ff
           =             =        =20 20:        ff ff ff=20 ff
           =             =        =20 24:        ff ff ff=20 ff
           =             =        =20 28:        ff ff ff = ff
 
       &nb= sp;           &nb= sp;          =20 32:        46 15 d5 = c2
in = the transmission=20 side, and the reception side I do get 0x1c2d19ed though. =
 
I = like to clarify=20 which implementation we should use so that both Initiator and Target = will be in=20 sync. validating the CRC. I appreciate if you could verify the attached = files to=20 see I am missing anytbing. Also I think that it would help = everyone who are=20 dealing with iSCSI CRC if you could put up the finalized version of the = code in=20 the reflector.
 
Thanks,
Tandra (tde@corp.adaptec.com)
------_=_NextPart_001_01C1618F.64C22FF0-- ------_=_NextPart_000_01C1618F.64C22FF0 Content-Type: application/octet-stream; name="crc_no_reflect.cpp" Content-Disposition: attachment; filename="crc_no_reflect.cpp" #include #include #define CRC_KEY 0x11edc6f41L #define OUTPUT_FILE "opcrc32_tab.h" unsigned long table[256]; unsigned long crc_register; FILE *tf; void Init_CRC_Table() { int i, j; printf ("\nGenerating CRC32 Table file <%s>\n", OUTPUT_FILE); if ((tf = fopen (OUTPUT_FILE, "w")) == NULL) { printf ("Unable to open %s\n", OUTPUT_FILE); exit (1); } fprintf (tf, "#ifndef __opcrc32_table_h__\n"); fprintf (tf, "#define __opcrc32_table_h__\n\n"); fprintf (tf, "#define CRC_KEY 0x%08lX\n", CRC_KEY); printf("CRC_KEY = %x\n", (__int64)CRC_KEY); fprintf (tf, "\nunsigned long table[256] =\n{\n"); for (i = 0; i < 256; ++i) { // put this byte at the top of the register unsigned long reg = i << 24; // for all bits in a byte for (j = 0; j < 8; ++j) { bool topBit = (reg & 0x80000000) != 0; reg <<= 1; if (topBit) reg ^= CRC_KEY; } table [i] = reg; fprintf (tf, "0x%08lXL, ", table[i]); if ((i & 3) == 3) fprintf (tf, "\n"); } fprintf (tf, "};\n\n#endif\n"); if (fclose (tf) != 0) printf ("Unable to close <%s>." OUTPUT_FILE); else printf ("\nThe CRC32 table has been written to <%s>.\n", OUTPUT_FILE); } void PutByte (unsigned byte) { unsigned top = crc_register >> 24; top ^= byte; crc_register = (crc_register << 8) ^ table[top]; } void main () { unsigned char msg[32 + 4]; int i; for (i = 0; i < 32; i++) { msg[i] = 0xff; } Init_CRC_Table(); /* Transmission */ crc_register = 0xffffffff; for (i = 0; i < 32; ++i) { PutByte (msg [i]); } printf("Transmission crc = %x\n", crc_register); crc_register = ~crc_register; printf("Transmission crc after complement = %x\n", crc_register); /* Reception */ int shift = 32; for (i = 0; i < 4; ++i) { shift -= 8; msg [32 + i] = (unsigned char)(crc_register >> shift); } crc_register = 0xffffffff; for (i = 0; i < 36; ++i) { PutByte (msg [i]); } printf("Reception crc = %x\n", crc_register); } ------_=_NextPart_000_01C1618F.64C22FF0 Content-Type: application/octet-stream; name="crc_reflect.cpp" Content-Disposition: attachment; filename="crc_reflect.cpp" #include #include #define CRC_KEY 0x11edc6f41L #define OUTPUT_FILE "opcrc32_tab.h" unsigned long table[256]; unsigned long crc_register; FILE *tf; void Init_CRC_Table() { int i, j; printf ("\nGenerating CRC32 Table file <%s>\n", OUTPUT_FILE); if ((tf = fopen (OUTPUT_FILE, "w")) == NULL) { printf ("Unable to open %s\n", OUTPUT_FILE); exit (1); } fprintf (tf, "#ifndef __opcrc32_table_h__\n"); fprintf (tf, "#define __opcrc32_table_h__\n\n"); fprintf (tf, "#define CRC_KEY 0x%08lX\n", CRC_KEY); printf("CRC_KEY = %x\n", (__int64)CRC_KEY); fprintf (tf, "\nunsigned long table[256] =\n{\n"); for (i = 0; i < 256; ++i) { // put this byte at the top of the register unsigned long reg = i << 24; // for all bits in a byte for (j = 0; j < 8; ++j) { bool topBit = (reg & 0x80000000) != 0; reg <<= 1; if (topBit) reg ^= CRC_KEY; } table [i] = reg; fprintf (tf, "0x%08lXL, ", table[i]); if ((i & 3) == 3) fprintf (tf, "\n"); } fprintf (tf, "};\n\n#endif\n"); if (fclose (tf) != 0) printf ("Unable to close <%s>." OUTPUT_FILE); else printf ("\nThe CRC32 table has been written to <%s>.\n", OUTPUT_FILE); } unsigned long bit_swap_long(unsigned long val) { unsigned long rval = 0; int i; for (i = 0; i < 32; i++) { if (val & 1) rval |= 1 << (31 - i); val >>= 1; } return rval; } unsigned char bit_swap_byte(unsigned char byte) { unsigned char rbyte = 0; if (byte & 0x01) rbyte |= 0x80; if (byte & 0x02) rbyte |= 0x40; if (byte & 0x04) rbyte |= 0x20; if (byte & 0x08) rbyte |= 0x10; if (byte & 0x10) rbyte |= 0x08; if (byte & 0x20) rbyte |= 0x04; if (byte & 0x40) rbyte |= 0x02; if (byte & 0x80) rbyte |= 0x01; return rbyte; } void PutByte (unsigned byte) { unsigned top = crc_register >> 24; unsigned char rbyte; rbyte = bit_swap_byte(byte); top ^= rbyte; crc_register = (crc_register << 8) ^ table [top]; } void main () { unsigned char msg[32 + 4]; int i; for (i = 0; i < 32; i++) { msg[i] = 0xff; } Init_CRC_Table(); /* Transmission */ crc_register = 0xffffffff; for (i = 0; i < 32; ++i) { PutByte (msg [i]); } crc_register = bit_swap_long(crc_register); printf("Transmission crc = %x\n", crc_register); crc_register = ~crc_register; printf("Transmission crc after complement = %x\n", crc_register); /* Reception */ int shift = 0; for (i = 0; i < 4; ++i) { msg [32 + i] = (unsigned char)(crc_register >> shift); shift += 8; } crc_register = 0xffffffff; for (i = 0; i < 36; ++i) { PutByte (msg [i]); } printf("Reception crc = %x\n", crc_register); } ------_=_NextPart_000_01C1618F.64C22FF0-- From owner-ips@ece.cmu.edu Tue Oct 30 17:58: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 RAA16714 for ; Tue, 30 Oct 2001 17:58:20 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9ULnqU11489 for ips-outgoing; Tue, 30 Oct 2001 16:49:52 -0500 (EST) 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 f9ULnUl11457 for ; Tue, 30 Oct 2001 16:49:30 -0500 (EST) 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 QAA47884; Tue, 30 Oct 2001 16:46:52 -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 f9ULnOf173238; Tue, 30 Oct 2001 14:49:24 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: proposal to solve the ISID issues To: cbm@rose.hp.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: Tue, 30 Oct 2001 13:48:40 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/30/2001 02:49:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk I do not like the word must even if it is in lower case. This is an Implementation decision! and many/most will not need Admin help. If you were to say "Should allow for configuration and coordination of ISIDs, by the iSCSI/HBA Driver,to allow for configuration and coordination of ISIDs for...." I could go along with that. How that driver gets the information is its business. . . . 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 "Mallikarjun C." @ece.cmu.edu on 10/30/2001 11:53:20 AM Please respond to cbm@rose.hp.com Sent by: owner-ips@ece.cmu.edu To: Jim Hafner/Almaden/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: iSCSI: proposal to solve the ISID issues Jim, I am in broad agreement with you on your suggestion, and I agree that the ISID-configurability is a derivative requirement - but my argument is that it's nevertheless a crucial one to warrant making it explicit, but I can live with the proposed compromise of making it a NOTE. Some comments - >There is a requirement > that vendor NICs (managed by the same vendor driver) be configurable in > their ISIDs. I am kind of perplexed on this underlying assumption that a vendor NICs are "managed by the same vendor driver". As you know, this is not always true. IMHO, regardless of vendor and driver affiliations, an iSCSI initiator NIC MUST have external ISID-configurability - that's a design constraint on a NIC vendor (from the ISID rule)! [ Note that I am NOT suggesting that the API be "public", it's upto the NIC vendor on allowing third-party drivers - and I believe most would. ] With that, I would suggest the following wordsmithing, but I will not press it any further... NOTE: For correct behavior (in particular with respect to the ISID rule), a vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must allow for configuration and coordination of ISIDs for all sessions managed by multiple instances of that hardware within a given iSCSI Node. Such configuration might be either static (e.g., partitioned across all the NICs at initialization) or dynamic (e.g., on-line allocator). I hope the suggested wording (or something close to it) on the Node name would make its way in. Finally, thanks for so patiently driving this issue! -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization MS 5668 Hewlett-Packard, Roseville. cbm@rose.hp.com Jim Hafner wrote: > > John and Mallikarjun, > > I appreciate where Mallikarjun wants to go here. There is a requirement > that vendor NICs (managed by the same vendor driver) be configurable in > their ISIDs. However, that requirement is more a derivative conclusion of > the rules (for a good and correct implementation) than it is a protocol > requirement. A vendor that doesn't do this only steps on his own toes when > more than one of his cards is in a system! > > Perhaps we compromise and make this a big NOTE: > > NOTE: For correct behavior (in particular with respect to the ISID rule), a > vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must provide > either driver software or external and public APIs to allow for > configuration and coordination of ISIDs for all sessions managed by > multiple instances of that hardware within a given iSCSI Node. Such > configuration might be either static (e.g., partitioned across all the NICs > at initialization) or dynamic (e.g., on-line allocator). > > We can make the iSCSI Node Name a stronger requirement (that is, outside of > a NOTE). > > Does that help? > > Jim Hafner > > John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 10/29/2001 06:47:31 pm > > Sent by: owner-ips@ece.cmu.edu > > To: cbm@rose.hp.com > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > I have no problem with the Must have a way to have the Node name set. > However, I do not grasp the problem you state here: > > "I don't believe the type of the ISID matters, nor does > the NIC capability (coordinating vs not). If two initiator > NICs share the same node name, they better not re-use the > same ISID to a given target portal group. I was trying > to capture the consequences of this reality." > > If the ISID includes the Vendor ID, I do not see the problem, unless the > vendor can not assign the rest of the ISID. And I would say that it is the > vendors problem to work out. If you are saying that with NICs (not HBAs) > that the SW Drivers will have a problem coming up with the ISID, I do not > understand that either since most software is built by a Vendor, and if not > the Random type should work. > > Now in case you are saying something about the creation of a second Session > from the Initiator, which is to access the same Target Node. Then by > definition, the ISID must be unique. (and it will probably need a Wedge > Driver to operate correctly). I would think that a vendor should be able > to come up with a unique qualifier for the session since they have 64K > numbers to chose from. Remember the vendor only needs to coordinate the > lower 2 bytes of the new ISID, with itself. So if they can not do that, > ... Oh well ... > > Are we on the same page yet? > > . > . > . > 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 > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 06:35:55 > PM > > Please respond to cbm@rose.hp.com > > Sent by: cbm@core.rose.hp.com > > To: John Hufferd/San Jose/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > John, > > I take it that you don't have an issue with the > Node Name part of the wording. > > I thought I answered your question by saying - > > "My point though is that by banning a duplicate nexus (that an > inadvertently re-used ISID allows), we are making the ISID > (dynamic/static) distribution an imminent hard requirement > for all NICs in a given iSCSI initiator Node" > > The unspoken assumption above is that we would want to > allow multiple sessions between an initiator node and > a target portal group. > > I don't believe the type of the ISID matters, nor does > the NIC capability (coordinating vs not). If two initiator > NICs share the same node name, they better not re-use the > same ISID to a given target portal group. I was trying > to capture the consequences of this reality. > > Regards. > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > John Hufferd wrote: > > > > Mallikarjun, > > I do not understand the purpose for your proposed wordage > > > > "All iSCSIinitiator hardware implementations MUST in addition also > support > > the operational ISID values to be (either statically or dynamically) > > externally configurable." > > > > Why is this so important that it is a MUST. The purpose of the proposal > is > > to eliminate the need for the above. At most it should only apply to the > > vendors (Probably Software and at Universities and IT shops) that use the > > RANDOM ISID type code. > > > > I do not see the need elsewhere. At most it could be "MAY". > > > > . > > . > > . > > 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 > > > > "Mallikarjun C." @ece.cmu.edu on 10/29/2001 05:24:20 PM > > > > Please respond to cbm@rose.hp.com > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > Jim, > > > > Thanks for the quick response. > > > > As much as I would like to avoid consuming more bandwidth > > on this topic, let me make one last strawman for wording below. > > > > > What words do you suggest? > > ... > > > And a lot depends on how > > > functional the NICs are: (a) just network nics, (b) protocol nics, but > > not > > > session coordinating nics (c) full session coordination nics (with > driver > > > assist) (d) fully autonomous session nics. How do we make a > requirement > > > that fits all the cases correctly? > > > > I have been implying iSCSI NICs in all my postings so far - > > sorry, may be that wasn't very clear. "iSCSI Node name" comment > > obviously wasn't targeted at simple network NICs. So clearly (a) > > is out of discussion. But you are right - I wasn't very precise. > > Here's a strawman - > > > > All iSCSI hardware implementations (as in NICs) MUST allow > > the iSCSI Node Name to be externally configurable. All iSCSI > > initiator hardware implementations MUST in addition also > > support the the operational ISID values to be (either statically > > or dynamically) externally configurable. > > > > > Making them configurable (at > > > initialization time, e.g., as a range of values) or making them dynamic > > > (the driver generates them on demand) both fit the mold. So, I don't > > think > > > this one is a hard requirement. > > > > I agree that my earlier "range" wording was too constraining. > > My point though is that by banning a duplicate nexus (that an > > inadvertently re-used ISID allows), we are making the ISID > > (dynamic/static) distribution an imminent hard requirement > > for all NICs in a given iSCSI initiator Node - except it is > > not sufficiently explicit. Please consider the above proposed > > wording. > > > > > Well, I don't think so. If each vendor implements "conservative reuse" > > > within their own ISID namespace on their own NICs, then you get this > > > property system wide. > > > > You are right, I guess I briefly overlooked the fact that ISID > > includes the vendor identifier within, per the new proposal. > > > > I am personally okay with making "conservative reuse" a > > SHOULD. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > Jim Hafner wrote: > > > > > > Mallikarjun, > > > > > > Comments in line below > > > > > > Jim Hafner > > > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > > 12:17:49 > > > pm > > > > > > Please respond to cbm@rose.hp.com > > > > > > Sent by: cbm@core.rose.hp.com > > > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > > cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > Jim, > > > > > > Thanks for the excellent summary. Some questions/comments - > > > > > > - I assume that the NICs must enable the configuration of > > > iSCSI Node name even in this proposal. If it is so, please > > > call this out as a hard requirement in the main modelling > > > discussion. > > > > > > > > > This requirement doesn't change from before (but how it gets written > into > > > the spec may differ -- and we've had this discussion before). If a > > vendor > > > doesn't allow configuration of his NIC's iSCSI Node name, then his NICs > > > will be acting as their own iSCSI Node (that is, not representing the > > > system they live in). One can argue that this is a legitimate > > > implementation (just as writing user-level code that uses its own iSCSI > > > Node name). So a "hard requirement" may be a bit too strong. However, > I > > > will go with the will of the group on this point. > > > > > > What words do you suggest? > > > > > > - In the case of multiple NICs from the same vendor operating > > > in an end node, it appears to me that the proposal implicitly > > > assumes an ISID-range to be configurable among those NICs > > > (perhaps in vendor-unique ways, which is always what I expected). > > > If this is a correct inference, there is again a hard > > > requirement on the NICs to make the ISID range configurable. > > > Please comment on any subtle qualitative change from the > > > earlier situation that I may be missing. > > > > > > > > > Well, the point is that the vendor can manage his own namespace for his > > > NICs anyway he/she/it wants to. Making them configurable (at > > > initialization time, e.g., as a range of values) or making them dynamic > > > (the driver generates them on demand) both fit the mold. So, I don't > > think > > > this one is a hard requirement (though that is probably how most > vendors > > > will implement their NICs). In effect, the proposal gives vendors more > > > flexibility in their own space, without causing heterogenous > > > interoperability problems within the host. And a lot depends on how > > > functional the NICs are: (a) just network nics, (b) protocol nics, but > > not > > > session coordinating nics (c) full session coordination nics (with > driver > > > assist) (d) fully autonomous session nics. How do we make a > requirement > > > that fits all the cases correctly? You clearly have in mind a specific > > > level of implementation within the NICs, but that may not be > everybody's > > > model. > > > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > particularly low-end that don't use reservations, can function more > or > > > > less OK without it. > > > > > > It seems we're attempting to set ourselves up for future in > > > discussing the above requirement. Some questions - > > > - It appears to me that the "conservative reuse" can not > > > be enforced for initiators hosting NICs from different > > > vendors (since the proposal allows ISID namespaces to > > > be totally non-overlapping between non-homogenous NICs). > > > Is this a fair assessment? > > > > > > Well, I don't think so. If each vendor implements "conservative reuse" > > > within their own ISID namespace on their own NICs, then you get this > > > property system wide. As before, by owning their own piece of the ISID > > > namespace, they can implement what they want. So, you may have a > > situation > > > where some of your installed nics have this property and some don't. > > > You'll find out (if your environment really needs conservative reuse) > > that > > > you haven't got it, and it becomes a marketing/purchase spec > requirement. > > > > > > - Do you see a particular disadvantage for low-end systems > > > if it's mandated (aside from the fact that they may be able > > > to live without it)? > > > > > > No, but I don't see any way to really enforce it (or even really test > > it). > > > It's not a requirement of the protocol, per se. > > > > > > - Do you see any corner cases not being met (for future) > > > if we don't make it a MUST (since you said "more or less > OK")? > > > > > > No, I can't see that far into the future! :-{). One reason I'm being > > cagey > > > here is that I'm finding it difficult to find the right words to > specify > > > this as a hard requirement (but I'm no technical writer either!). > > > > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > MS 5668 Hewlett-Packard, Roseville. > > > cbm@rose.hp.com > > > > > > Jim Hafner wrote: > > > > > > > > Folks, (David Black in particular). > > > > > > > > Apologies for the long note, but the issue is complicated. > > > > > > > > The NDTeam have a proposal to resolve the concerns surrounding use of > > > > ISIDs as essential components (along with iSCSI Initiator Name) of > > > > SCSI Initiator Portname. (This was rooted in private discussions > > > > between John Hufferd, Julian and myself -- and came about as a result > > > > of the lengthy (and boring) discussions mostly myself and David > > > > Black.) > > > > > > > > There are two somewhat orthogonal issues involved in this discussion: > > > > > > > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > > > > accidentally breaking the ISID RULE (no parallel nexus) when > > > > independent vendors co-exist in the same OS. > > > > > > > > 2) What ISID "reuse" rules should be specified to facilitate current > > > > and future (soon?) SCSI reservation semantics (and also internal OS > > > > views of SCSI Initiator Ports). > > > > > > > > To address these two issues, we (NDT) propose the following: > > > > > > > > 1) Enlarge the ISID field in the Login Request and Response to 6bytes > > > > and structure it with a component that corresponds to a "naming > > > > authority" (essentially the vendor generating the ISID). So vendors > > > > each have a piece of the ISID namespace to work with their own > > > > components (HBAs, SW, etc). More details below. > > > > > > > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used > as > > > > conservatively as possible ("conservative reuse"). What this means > is > > > > that a given ISID should be reused for as many sessions (across > > > > multiple target portal groups) as possible (but never to the same > > > > target portal group twice -- that's the ISID RULE). > > > > > > > > NOTES and ADVANTAGES: > > > > > > > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > > > > effect, at the vendor-level, this provides a "partitioning" of that > > > > namespace. > > > > > > > > (1-b) We don't need to specify an OS infrastructure requirement for > > > > configuration of ISIDs -- each vendor can do it any way it chooses > > > > (within its naming authority). > > > > > > > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes up > > > > its own implementation. > > > > > > > > (1-d) This is not fundamentally different from David Black's > > > > suggestion for a "key"; it just (a) defines it precisely and (b) > > > > embeds it in an already defined (but enlarged) field. > > > > > > > > (1-e) Looking towards the future, as common ISID coordination > > > > mechanisms are implemented between vendors (say, SNIA banding > together > > > > to define a precise API), this "naming authority" can be elevated to > > > > the coordinating entity or even the OS vendor. > > > > > > > > (1-f) ISIDs have no global uniqueness property. They need only be > > > > unique between a named iSCSI initiator and iSCSI target portal group. > > > > That means that a vendor implementation can use the same algorithm to > > > > generate ISIDs (under its naming authority) in every machine (OS). > > > > > > > > (2-a) If a SCSI target (or logical unit) is holding state (say > > > > persistent reservation) for a SCSI Initiator Port (named by iSCSI > Name > > > > and ISID), and the associated nexus/session is dropped for some > > > > reason, "reuse" by that initiator of that ISID will restore to the > > > > resulting new session that state (with no other action on the part of > > > > the upper SCSI layers). > > > > > > > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > > > > different SCSI Target Ports (iSCSI Target portal groups), will enable > > > > the SCSI target/logical unit to recognize a common SCSI Initiator > Port > > > > for those two paths. This facilitates future changes to SCSI > > > > reservations (at least). > > > > > > > > (2-c) An initiator driver implementated with "conservative reuse" can > > > > present to the OS a stable and fairly static view of the SCSI > > > > Initiator Ports (one for each ISID). Current OS driver stacks > > > > (including current wedge drivers) that are built on the presumption > of > > > > such a stable view, will not need modification to handle the more > > > > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence > of > > > > a SCSI Initiator Port presented to the OS does not *require* that > this > > > > port discover all possible targets; what the initiator builds > sessions > > > > to using a specific ISID will determine what is presented to the OS > as > > > > "devices" and LUs visible to that SCSI Initiator Port (could be none > > > > if that ISID is never actually used!).] > > > > > > > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI Initiator > > > > Port is as simple as configuring another ISID! > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > particularly low-end that don't use reservations, can function more > or > > > > less OK without it. This is an open question. > > > > > > > > DETAILS: > > > > > > > > 1) ISID Structure: > > > > The 6byte ISID structure would be split into three parts: > > > > "type" field (1byte) -- identifies the format of the naming > > > > authority field > > > > "naming authority" field (3bytes) -- identifies the vendor (or > > > > group of vendors) generating this ISID > > > > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > > > > > > > The type field takes on three defined values with all other values > > > > reserved: > > > > Type naming authority format > > > > 00h IEEE OUI > > > > 01h IANA Enterprise Number (EN) > > > > 02h "Random" > > > > > > > > The first types two provide a mechanism to uniquely (world wide) > > > > identify the naming authority. A vendor with one or more OUIs and > > > > possibly also Enterprise number MUST use at least one of these > numbers > > > > when it generates ISIDs. > > > > > > > > The "Random" type is for the case where the ISID generator (SW or HW) > > > > is provided by an entity that has no OUI or EN. This includes, for > > > > example, > > > > -- a user-written program that builds sessions (and has access to the > > > > system level iSCSI Name) > > > > -- a university or other organization providing the component > > > > -- a testing tool > > > > > > > > For the "Random" type, the naming authority field should be a random > > > > or pseudo-random number. (See below on how this affects "conservative > > > > reuse"). > > > > > > > > [Note: the "type" field needn't be this big, but NDT felt that (a) > > > > 2bits was insufficient for the future, (b) the "type" field should be > > > > first, and (c) the "naming authority" field should be byte-aligned.] > > > > > > > > 2) Conservative Reuse > > > > > > > > The "conservative reuse" principle of this proposal just says that > > > > SCSI Initiator Portnames should be viewed as static things (as much > as > > > > possible) and reused (when feasible) to give the most stable > > > > presentation of SCSI Initiator Ports to both the OS above and to SCSU > > > > targets across the wire. > > > > > > > > Whereas the current draft says "The ISID RULE does not preclude the > > > > use of the same ISID to different Target portal groups", the > > > > "conservative reuse" requirement would say that such reuse (using the > > > > same ISID to many target portal groups) is a SHOULD (or is that > > > > MUST?). So, in one implementation, each iSCSI Initiator Portal group > > > > would get configured with iSCSI Name, and a (small) set of ISIDs. > The > > > > portal group might take this set of ISIDs as an ordered list. The > > > > first session to a Target portal group would use the first ISID, the > > > > second to the *same* target portal group would use the second in the > > > > list, etc. The number of ISIDs would then define a configuration > > > > parameter that can be interpreted as the maximum number of sessions > > > > that can be built to a given target portal group. > > > > > > > > To facilitate "conservative reuse", the "qualifier" field of a set of > > > > ISIDs SHOULD be generated using either a repeatable algorithm > > > > (non-random or pseudo-random but based on a fixed seed) or any > > > > algorithm and stored in a persistent location (e.g., registry or /etc > > > > file). > > > > > > > > For the "Random" type, "conservative reuse" may not be an issue (say, > > > > user application that doesn't care about reservations, etc.). When > it > > > > is, the "naming authority" field SHOULD also be generated by a > > > > mechanism similar to that for the "qualifier" field as specified > above > > > > (e.g., defined in the SW at compilation time.) > > > > > > > > DOCUMENTATING CHANGES: > > > > > > > > The iscsi drafts would need the following minor changes to support > > > > this proposal: > > > > > > > > NDT doc > > > > (a) define the structure of the ISID field (as described above) > > > > (b) add some notes about implementation in the presense of > > > > "conservative reuse" (e.g., that ISID should be configured once, say > > > > at install time, then reused on subsequent reboots, even for "Random" > > > > type). > > > > > > > > iSCSI MAIN doc: > > > > (a) move the CID field in Login Request to another reserved field. > > > > (b) expand the ISID field in Login Request and Response to encompass > > > > the previous 4 bytes. > > > > (c) add a sentence where the ISID field is defined indicating that > > > > this field is a structured value, showing the structure (as above) > and > > > > point to the NDT document. > > > > (d) add some text to "Note to Implementors" on "conservative reuse". > > > > > > > > Comments? > > > > > > > > Jim Hafner > > -- > 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 Tue Oct 30 19:51: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 TAA17873 for ; Tue, 30 Oct 2001 19:51:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9V08Rj21123 for ips-outgoing; Tue, 30 Oct 2001 19:08:27 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9V08Ml21115 for ; Tue, 30 Oct 2001 19:08:22 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA126708 for ; Tue, 30 Oct 2001 18:05:18 -0600 Received: from d04nms41.raleigh.ibm.com (d04nms41.raleigh.ibm.com [9.67.228.19]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id f9V07fj51306 for ; Tue, 30 Oct 2001 19:07:41 -0500 Subject: is TargetName always mandatory or not? To: "IPS Reflector (E-mail)" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andre Asselin" Date: Tue, 30 Oct 2001 19:08:42 -0500 X-MIMETrack: Serialize by Router on D04NMS41/04/M/IBM(Release 5.0.8 |June 18, 2001) at 10/30/2001 07:07:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk In section 5 of the spec, it says "If the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName.". However, in Appendix D, the description for TargetName says it is Leading Only. Should TargetName not be Leading Only, or should the text in section 5 say that TargetName must be in the initial Login Request of a leading connection? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC From owner-ips@ece.cmu.edu Tue Oct 30 19:53: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 TAA17903 for ; Tue, 30 Oct 2001 19:53:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9V065b20966 for ips-outgoing; Tue, 30 Oct 2001 19:06:05 -0500 (EST) 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 f9V064l20960 for ; Tue, 30 Oct 2001 19:06:04 -0500 (EST) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id TAA17188 for ; Tue, 30 Oct 2001 19:06:03 -0500 (EST) Date: Tue, 30 Oct 2001 19:06:03 -0500 From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: Re: iSCSI: current UNH Plugfest Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Attached are some new issues that arose during the iSCSI plugfest at UNH on Tuesday 29-Oct-2001. (Note: these issues do not take into account any modifications or clarifications that occured in the standard due to the issues raised on Monday.) Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 ----------------------------------------------------------------------------- 1. Situation: as the first command on a new TCP connection, the initiator sends a login with T=1, CSG=1, NSG=3, and valid InitiatorName, TargetName, and SessionType keys. However, there is also a valid key having an invalid value, such as MaxConnections=abcd (i.e., not a number after the '=') or MaxConnections4 (i.e., missing the '='). What should the target do? Interpretation 1: According to section 3.10.4 page 82 of draft 8 (page 83 of draft 8a), "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." Two things have to be clarified: 1. Does this section also apply to keys received in a login? 2. Can "NotUnderstood" also apply to "values of keys" that are not understood, even if the key word itself is understood? If the answer to these 2 of these questions is "yes", then the appropriate response would seem to be for the target to just ignore the key and send back MaxConnections=NotUnderstood as part of its next login response. Interpratation 2: According to section 8.7 page 129 of draft 8 (page 130 of draft 8a), "A negotiation failure is considered one or both of the following: - None of the choices or the stated value is acceptable to one negotiating side. ..." Clearly this stated value ("abcd") is not acceptable to the target. Therefore, the following rule on page 129, draft 8 (page 130, draft 8a) applies: "- During Login, any failure in negotiation MUST be considered as the login process failure and the connection must be dropped." Therefore, the target should just drop the connection without sending any login response back to the initiator. Interpretation 3: This is a login command that contains an error caused by the initiator. Therefore, the target should send back a login response with a status code of 0x0200 and then close the TCP connection. 2. Situation: on the first login command in operational parameter negotiation stage, the initiator sends no operational keys, thereby telling the target that it accepts all the default values for these keys. However, the target wants to negotiate the value of MaxConnections, so in the login response it sends back "MaxConnections=3" (for example). Should the initiator send a response to this key or not? The statement in section 2.2.4 on page 30 of draft 8 and 8a: "For numerical (and single literal) negotiations, the responding party MUST respond with the required key.(...)" makes it clear that the responding party MUST respond. However, in this situation, it is not clear who the responding party is. Interpretation 1: By not explicitly sending this key in the login command, the initiator is implicitly offering the default value and therefore is the offering party and the target is the responding party. The conclusion is that the initiator does not have to send a response to this key from the target. Interpretation 2: The target is the offering party because it is the party that explicitly stated the key for the first time during these negotiations. The conclusion is that the initiator MUST send a response to this key from the target. NOTE 1: If interpretation 1 is correct, it would seem to imply that the target MUST respond to every key whether or not it is present in the login from the initiator, even if it does not want to change the default value. The reason is that a missing key is an implicit offer of the default value, and the responding party MUST respond. Is this a correct interpretation? NOTE 2: The following statements in section 2.2.4 page 29 of draft 8a: Originator-> = Responder-> =|NOtUnderstood seem to imply that the originator is the party (initiator or target) that explicitly offers a key, and that omitting a key is not an implicit offer of that key with the default value. However, even in the revised draft 8a there is no definition of "Originator" and/or "Responder" that would make this clear. Adding to the standard these definitions, and an explicit statement that "a missing key does not constitute an implicit offer of the default" would help eliminate misunderstandings. In addition, including an example of this situation (where an initiator omits a key and the target offers the key) would be a big help. 3. Some of the login phase examples given in Appendix A of both draft 8 and 8a do not follow the rule in section 3.12.4 page 87 of draft 8 (page 88 of draft 8a): "The next stage value is valid only when the T bit is 1 and is reserved otherwise." and the rule in section 3 page 48 of draft 8 (page 49 of draft 8a): "Any reserved fields and values MUST be 0 unless specified otherwise." If these rules are applied, all examples having T=0 should also have NSG=0. Presently all of them with T=0 also have NSG=1 or NSG=3. 4. Situation: The initiator and target have successfully completed the login phase for a discovery session and are now in full feature phase. The initiator sends a text command containing the single key: "SendTargets=". What response is expected from the target? Interpretation 1: According to the explanation on page 188 of draft 8 (page 189 of draft 8a): "If no target name is specified, the session should respond with addresses only for the target to which the session is logged in. This MUST be supported on operational sessions, and MAY NOT return targets other than the one to which the session is logged in." However, for a discovery session there is no target per se (the initiator does not specify a TargetName= during login), so the target therefore follows the rule on page 188 of draft 8 (page 189 of draft 8a): "A SendTargets response MAY contain no target names, if there are no targets for the requesting initiator to access." and sends back a Text Response with no keys in it. Interpretation 2: In a discovery session, the key "SendTargets=" makes no sense and should be treated by the target in the same manner as the key "SendTargets=all". 5. Some common error situations: 1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02), some targets are not including the SenseLength as the first 2 bytes in the data segment. Although the format of the data segment is clear from the diagram in section 3.4.6 on page 62 of draft 8 (page 63 of draft 8a), the last entry in the diagram for the SCSI Response PDU on page 58 of draft 8 (page 59 of draft 8a) is misleading because it mentions only the Sense Data and Response Data and omits the Sense Length. It would therefore be helpful if the last entry in the diagram on page 58 were changed to explicitly reference the diagram on page 62, as in: Data Segment -- see section 3.4.6 (optional) 2) - after sending a CmdSN on an initial login, some initiators are incrementing it before sending their first non-immediate command. (i.e., if the initial login contains CmdSN=123, they are sending CmdSN=124 on the first non-immediate command after the login phase). Section 3.12.10 on page 89 of draft 8 (page 90 of draft 8a) is clear that in this example the first non-immediate command should carry CmdSN=123, not 124. This was an issue at the July plugfest and apparently some implementations have not been updated to conform to the draft 8 standard in their handling of CmdSN. From owner-ips@ece.cmu.edu Tue Oct 30 19:53: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 TAA17914 for ; Tue, 30 Oct 2001 19:53:41 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9V0KT821885 for ips-outgoing; Tue, 30 Oct 2001 19:20:29 -0500 (EST) 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 f9V0KSl21880 for ; Tue, 30 Oct 2001 19:20:28 -0500 (EST) Received: from muralipc ([192.168.2.58]) by lightsand.com (8.9.3+Sun/8.9.1) with SMTP id QAA27565; Tue, 30 Oct 2001 16:20:20 -0800 (PST) From: "Murali Rajagopal" To: , "IPS Reflector" Subject: RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting) Date: Tue, 30 Oct 2001 16:21:25 -0800 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 In-Reply-To: <3BD73607.75972C10@compuserve.com> Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Few minor comments regarding the write up. See embedded comments in the snipped version of this email from Ralph: -----Original Message----- From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of Ralph Weber Sent: Wednesday, October 24, 2001 2:44 PM To: IPS Reflector Subject: FCIP: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting) ..... An FCIP Entity that receives a TCP Connect request SHALL use the contents of the FC Fabric Entity World Wide Name and FC/FCIP Identifier fields to determine the FCIP_LEP to which the FCIP_DE associated with the TCP connection is assigned. This may be an existing FCIP_LEP or a new FCIP_LEP, depending on whether the FCIP Entity has received the same FC Fabric Entity World Wide Name and FC/FCIP Identifier field values before. If an FCIP Short Frame is received on a TCP connection that has already been assigned to an FCIP_LEP, the FC Fabric Entity World Wide Name and FC/FCIP Identifier fields SHALL be ignored. The above last sentence needs some more elaboration as to how a SF can arrive on an existing FCIP_LEP. The Connection Usage Flags field identifies the types of SOF values [FC Encapsulation] to be carried on the connection as shown in figure z. |------------------------------Bit------------------------------| | | | 31 30 29 28 27 26 25 24 | +---------------------------------------------------------------+ | SOFf | SOF?2 | SOF?3 | Reserved | +---------------------------------------------------------------+ Fig. z - Connection Usage Flags Field Format If the SOFf bit is one, then frames containing SOFf are intended to be carried on the connection. If the SOF?2 bit is one, then frames containing SOFi2 and SOFn2 are intended to be carried on the connection. If the SOF?3 bit is one, then frames containing SOFi3 and SOFn3 are intended to be carried on the connection. All or none of the SOFf, SOF?2, and SOF?3 bits MAY be set to one. If all of the SOFf, SOF?2, and SOF?3 bits are zero, then the types of FC Frames intended to be carried on the connection has no specific relationship to SOF code. The FCIP Entity SHALL NOT enforce the SOF usage described by the Connection Usage Flags field and SHALL only use the contents of the field as described below. The Connection Usage Code field contains Fibre Channel defined information regarding the intended usage of the connection as specified in FC-BB-2. The FCIP Entity SHALL use the contents of the Connection Usage Flags and Connection Usage Code fields to locate appropriate QoS settings in the "shared" database of TCP connection information (see 8.1.1) and apply those settings to a newly formed connection. If an FCIP Short Frame is received after QOS settings have been established, the Connection Usage Flags and Connection Usage Code fields SHOULD be ignored. Use of Connection Usage Flags and Code Fields need some explanation For each new incoming TCP Connect request received, the FCIP Entity SHALL send the contents of the FC Fabric Entity World Wide Name, FC/FCIP Identifier, Connection Usage Flags and Connection Usage Code fields to the FC Entity along with the other new connection information. [Change 2] In 5.6.1, add the pFlags field definition and require all FCIP Encapsulated Frames except Short Frames to have SF equal to zero. Note: Some part of the pFlags description above will go in 5.6.1 not in the new section but the description above is structured for easier reading in this proposal. [Change 3] Some place in 5.6 (the description of the FCIP_DE), require the FCIP_DE to pass all FCIP Short Frames to the Control & Services Module. [Change 4] In 7.1.3 and 7.1.4 (the two sections where TCP Connect requests are generated), require the FCIP Entity to: 1) Acquire the Connection Usage and other information from the "shared" database (see section 7.1.1); 2) Send a FCIP Short Frame as the first bytes passing through the Encapsulated Frame Transmitter Portal following establishment of a TCP connection; May be a good idea to describe the echo protocol a little more clearly stating its purpose and capabilities and any possible future extensions. 3) Compare the first bytes received through the Encapsulated Frame Receiver Portal to the FCIP Short Frame sent and close the TCP connection if the bytes are not an FCIP Short Frame whose contents (words 7 through 13 inclusive) exactly match the FCIP Short Frame passed through the Encapsulated Frame Transmitter Portal. ..... From owner-ips@ece.cmu.edu Tue Oct 30 20:49: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 UAA18483 for ; Tue, 30 Oct 2001 20:49:32 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9V0qxo24018 for ips-outgoing; Tue, 30 Oct 2001 19:52:59 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from smtppop3pub.verizon.net (smtppop3pub.gte.net [206.46.170.22]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9V0qvl24011 for ; Tue, 30 Oct 2001 19:52:57 -0500 (EST) Received: from bas7175b (lsanca1-ar11-056-214.lsanca1.dsl.gtei.net [4.40.56.214]) by smtppop3pub.verizon.net with SMTP for ; id SAA43083283 Tue, 30 Oct 2001 18:52:35 -0600 (CST) Message-ID: <009201c161a6$814a9a60$6401a8c0@bas7175b> From: "res059xq" To: Subject: remove Date: Tue, 30 Oct 2001 16:53:49 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008F_01C16163.7288A960" 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_008F_01C16163.7288A960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable remove ------=_NextPart_000_008F_01C16163.7288A960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
remove
------=_NextPart_000_008F_01C16163.7288A960-- From owner-ips@ece.cmu.edu Tue Oct 30 21:07: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 VAA18664 for ; Tue, 30 Oct 2001 21:07:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9V1Nlv26040 for ips-outgoing; Tue, 30 Oct 2001 20:23:47 -0500 (EST) 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 f9V1Njl26036 for ; Tue, 30 Oct 2001 20:23:45 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by palrel10.hp.com (Postfix) with ESMTP id 5A6011F7E3; Tue, 30 Oct 2001 17:23:38 -0800 (PST) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id RAA06606; Tue, 30 Oct 2001 17:25:03 -0800 (PST) Message-ID: <006401c161aa$a9b99150$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "John Hufferd" Cc: References: Subject: Re: iSCSI: proposal to solve the ISID issues Date: Tue, 30 Oct 2001 17:23:35 -0800 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 John, >This is an > Implementation decision! I have been trying to point out that it is *not* an implementation decision *whether* to require ISID-configurability (Note below). OTOH, *how* to configure the ISIDs is an implementation decision (as Jim pointed out earlier), so also the decision of *if* it should be made a public API. Note: And I say this based on three factors - - multiple NICs in the Node sharing the same Node Name - stated objective of allowing multiple sessions between a given initiator node and a target portal group. - ISID RULE, which forbids parallel nexus As a final note, Jim alluded to the possibility of "this naming authority can be elevated to the (SNIA-defined) coordinating entity or even the OS vendor" in future. That possibility requires external ISID-configurability as well, AND requires the API to be public. I see that Jim and Julian had already appreciated where I am coming from. I hope I did a better job of convincing you this time..... -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "John Hufferd" To: Cc: "Jim Hafner" ; Sent: Tuesday, October 30, 2001 1:48 PM Subject: Re: iSCSI: proposal to solve the ISID issues > > I do not like the word must even if it is in lower case. This is an > Implementation decision! and many/most will not need Admin help. > If you were to say "Should allow for configuration and coordination of > ISIDs, by the iSCSI/HBA Driver,to allow for configuration and coordination > of ISIDs for...." I could go along with that. How that driver gets the > information is its business. > > > > > > . > . > . > 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 > > > "Mallikarjun C." @ece.cmu.edu on 10/30/2001 11:53:20 AM > > Please respond to cbm@rose.hp.com > > Sent by: owner-ips@ece.cmu.edu > > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > Jim, > > I am in broad agreement with you on your suggestion, > and I agree that the ISID-configurability is a derivative > requirement - but my argument is that it's nevertheless > a crucial one to warrant making it explicit, but I can > live with the proposed compromise of making it a NOTE. > > Some comments - > > >There is a requirement > > that vendor NICs (managed by the same vendor driver) be configurable in > > their ISIDs. > > I am kind of perplexed on this underlying assumption that > a vendor NICs are "managed by the same vendor driver". As > you know, this is not always true. IMHO, regardless of > vendor and driver affiliations, an iSCSI initiator NIC MUST > have external ISID-configurability - that's a design constraint > on a NIC vendor (from the ISID rule)! [ Note that I am NOT > suggesting that the API be "public", it's upto the NIC vendor > on allowing third-party drivers - and I believe most would. ] > > With that, I would suggest the following wordsmithing, but > I will not press it any further... > > NOTE: For correct behavior (in particular with respect to the ISID > rule), a > vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must > allow > for configuration and coordination of ISIDs for all sessions managed > by > multiple instances of that hardware within a given iSCSI Node. Such > configuration might be either static (e.g., partitioned across all the > NICs > at initialization) or dynamic (e.g., on-line allocator). > > I hope the suggested wording (or something close to it) on the > Node name would make its way in. > > Finally, thanks for so patiently driving this issue! > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Jim Hafner wrote: > > > > John and Mallikarjun, > > > > I appreciate where Mallikarjun wants to go here. There is a requirement > > that vendor NICs (managed by the same vendor driver) be configurable in > > their ISIDs. However, that requirement is more a derivative conclusion > of > > the rules (for a good and correct implementation) than it is a protocol > > requirement. A vendor that doesn't do this only steps on his own toes > when > > more than one of his cards is in a system! > > > > Perhaps we compromise and make this a big NOTE: > > > > NOTE: For correct behavior (in particular with respect to the ISID rule), > a > > vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must > provide > > either driver software or external and public APIs to allow for > > configuration and coordination of ISIDs for all sessions managed by > > multiple instances of that hardware within a given iSCSI Node. Such > > configuration might be either static (e.g., partitioned across all the > NICs > > at initialization) or dynamic (e.g., on-line allocator). > > > > We can make the iSCSI Node Name a stronger requirement (that is, outside > of > > a NOTE). > > > > Does that help? > > > > Jim Hafner > > > > John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 10/29/2001 06:47:31 pm > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: cbm@rose.hp.com > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > I have no problem with the Must have a way to have the Node name set. > > However, I do not grasp the problem you state here: > > > > "I don't believe the type of the ISID matters, nor does > > the NIC capability (coordinating vs not). If two initiator > > NICs share the same node name, they better not re-use the > > same ISID to a given target portal group. I was trying > > to capture the consequences of this reality." > > > > If the ISID includes the Vendor ID, I do not see the problem, unless the > > vendor can not assign the rest of the ISID. And I would say that it is > the > > vendors problem to work out. If you are saying that with NICs (not HBAs) > > that the SW Drivers will have a problem coming up with the ISID, I do not > > understand that either since most software is built by a Vendor, and if > not > > the Random type should work. > > > > Now in case you are saying something about the creation of a second > Session > > from the Initiator, which is to access the same Target Node. Then by > > definition, the ISID must be unique. (and it will probably need a Wedge > > Driver to operate correctly). I would think that a vendor should be able > > to come up with a unique qualifier for the session since they have 64K > > numbers to chose from. Remember the vendor only needs to coordinate the > > lower 2 bytes of the new ISID, with itself. So if they can not do that, > > ... Oh well ... > > > > Are we on the same page yet? > > > > . > > . > > . > > 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 > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > 06:35:55 > > PM > > > > Please respond to cbm@rose.hp.com > > > > Sent by: cbm@core.rose.hp.com > > > > To: John Hufferd/San Jose/IBM@IBMUS > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > John, > > > > I take it that you don't have an issue with the > > Node Name part of the wording. > > > > I thought I answered your question by saying - > > > > "My point though is that by banning a duplicate nexus (that an > > inadvertently re-used ISID allows), we are making the ISID > > (dynamic/static) distribution an imminent hard requirement > > for all NICs in a given iSCSI initiator Node" > > > > The unspoken assumption above is that we would want to > > allow multiple sessions between an initiator node and > > a target portal group. > > > > I don't believe the type of the ISID matters, nor does > > the NIC capability (coordinating vs not). If two initiator > > NICs share the same node name, they better not re-use the > > same ISID to a given target portal group. I was trying > > to capture the consequences of this reality. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > John Hufferd wrote: > > > > > > Mallikarjun, > > > I do not understand the purpose for your proposed wordage > > > > > > "All iSCSIinitiator hardware implementations MUST in addition also > > support > > > the operational ISID values to be (either statically or dynamically) > > > externally configurable." > > > > > > Why is this so important that it is a MUST. The purpose of the > proposal > > is > > > to eliminate the need for the above. At most it should only apply to > the > > > vendors (Probably Software and at Universities and IT shops) that use > the > > > RANDOM ISID type code. > > > > > > I do not see the need elsewhere. At most it could be "MAY". > > > > > > . > > > . > > > . > > > 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 > > > > > > "Mallikarjun C." @ece.cmu.edu on 10/29/2001 05:24:20 > PM > > > > > > Please respond to cbm@rose.hp.com > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > > cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > Jim, > > > > > > Thanks for the quick response. > > > > > > As much as I would like to avoid consuming more bandwidth > > > on this topic, let me make one last strawman for wording below. > > > > > > > What words do you suggest? > > > ... > > > > And a lot depends on how > > > > functional the NICs are: (a) just network nics, (b) protocol nics, > but > > > not > > > > session coordinating nics (c) full session coordination nics (with > > driver > > > > assist) (d) fully autonomous session nics. How do we make a > > requirement > > > > that fits all the cases correctly? > > > > > > I have been implying iSCSI NICs in all my postings so far - > > > sorry, may be that wasn't very clear. "iSCSI Node name" comment > > > obviously wasn't targeted at simple network NICs. So clearly (a) > > > is out of discussion. But you are right - I wasn't very precise. > > > Here's a strawman - > > > > > > All iSCSI hardware implementations (as in NICs) MUST allow > > > the iSCSI Node Name to be externally configurable. All iSCSI > > > initiator hardware implementations MUST in addition also > > > support the the operational ISID values to be (either statically > > > or dynamically) externally configurable. > > > > > > > Making them configurable (at > > > > initialization time, e.g., as a range of values) or making them > dynamic > > > > (the driver generates them on demand) both fit the mold. So, I don't > > > think > > > > this one is a hard requirement. > > > > > > I agree that my earlier "range" wording was too constraining. > > > My point though is that by banning a duplicate nexus (that an > > > inadvertently re-used ISID allows), we are making the ISID > > > (dynamic/static) distribution an imminent hard requirement > > > for all NICs in a given iSCSI initiator Node - except it is > > > not sufficiently explicit. Please consider the above proposed > > > wording. > > > > > > > Well, I don't think so. If each vendor implements "conservative > reuse" > > > > within their own ISID namespace on their own NICs, then you get this > > > > property system wide. > > > > > > You are right, I guess I briefly overlooked the fact that ISID > > > includes the vendor identifier within, per the new proposal. > > > > > > I am personally okay with making "conservative reuse" a > > > SHOULD. > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > MS 5668 Hewlett-Packard, Roseville. > > > cbm@rose.hp.com > > > > > > Jim Hafner wrote: > > > > > > > > Mallikarjun, > > > > > > > > Comments in line below > > > > > > > > Jim Hafner > > > > > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > > > 12:17:49 > > > > pm > > > > > > > > Please respond to cbm@rose.hp.com > > > > > > > > Sent by: cbm@core.rose.hp.com > > > > > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > > > cc: ips@ece.cmu.edu > > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > > > Jim, > > > > > > > > Thanks for the excellent summary. Some questions/comments - > > > > > > > > - I assume that the NICs must enable the configuration of > > > > iSCSI Node name even in this proposal. If it is so, please > > > > call this out as a hard requirement in the main modelling > > > > discussion. > > > > > > > > > > > > This requirement doesn't change from before (but how it gets written > > into > > > > the spec may differ -- and we've had this discussion before). If a > > > vendor > > > > doesn't allow configuration of his NIC's iSCSI Node name, then his > NICs > > > > will be acting as their own iSCSI Node (that is, not representing the > > > > system they live in). One can argue that this is a legitimate > > > > implementation (just as writing user-level code that uses its own > iSCSI > > > > Node name). So a "hard requirement" may be a bit too strong. > However, > > I > > > > will go with the will of the group on this point. > > > > > > > > What words do you suggest? > > > > > > > > - In the case of multiple NICs from the same vendor operating > > > > in an end node, it appears to me that the proposal implicitly > > > > assumes an ISID-range to be configurable among those NICs > > > > (perhaps in vendor-unique ways, which is always what I expected). > > > > If this is a correct inference, there is again a hard > > > > requirement on the NICs to make the ISID range configurable. > > > > Please comment on any subtle qualitative change from the > > > > earlier situation that I may be missing. > > > > > > > > > > > > Well, the point is that the vendor can manage his own namespace for > his > > > > NICs anyway he/she/it wants to. Making them configurable (at > > > > initialization time, e.g., as a range of values) or making them > dynamic > > > > (the driver generates them on demand) both fit the mold. So, I don't > > > think > > > > this one is a hard requirement (though that is probably how most > > vendors > > > > will implement their NICs). In effect, the proposal gives vendors > more > > > > flexibility in their own space, without causing heterogenous > > > > interoperability problems within the host. And a lot depends on how > > > > functional the NICs are: (a) just network nics, (b) protocol nics, > but > > > not > > > > session coordinating nics (c) full session coordination nics (with > > driver > > > > assist) (d) fully autonomous session nics. How do we make a > > requirement > > > > that fits all the cases correctly? You clearly have in mind a > specific > > > > level of implementation within the NICs, but that may not be > > everybody's > > > > model. > > > > > > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > > particularly low-end that don't use reservations, can function more > > or > > > > > less OK without it. > > > > > > > > It seems we're attempting to set ourselves up for future in > > > > discussing the above requirement. Some questions - > > > > - It appears to me that the "conservative reuse" can not > > > > be enforced for initiators hosting NICs from different > > > > vendors (since the proposal allows ISID namespaces to > > > > be totally non-overlapping between non-homogenous NICs). > > > > Is this a fair assessment? > > > > > > > > Well, I don't think so. If each vendor implements "conservative > reuse" > > > > within their own ISID namespace on their own NICs, then you get this > > > > property system wide. As before, by owning their own piece of the > ISID > > > > namespace, they can implement what they want. So, you may have a > > > situation > > > > where some of your installed nics have this property and some don't. > > > > You'll find out (if your environment really needs conservative reuse) > > > that > > > > you haven't got it, and it becomes a marketing/purchase spec > > requirement. > > > > > > > > - Do you see a particular disadvantage for low-end systems > > > > if it's mandated (aside from the fact that they may be able > > > > to live without it)? > > > > > > > > No, but I don't see any way to really enforce it (or even really test > > > it). > > > > It's not a requirement of the protocol, per se. > > > > > > > > - Do you see any corner cases not being met (for future) > > > > if we don't make it a MUST (since you said "more or less > > OK")? > > > > > > > > No, I can't see that far into the future! :-{). One reason I'm being > > > cagey > > > > here is that I'm finding it difficult to find the right words to > > specify > > > > this as a hard requirement (but I'm no technical writer either!). > > > > > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions Organization > > > > MS 5668 Hewlett-Packard, Roseville. > > > > cbm@rose.hp.com > > > > > > > > Jim Hafner wrote: > > > > > > > > > > Folks, (David Black in particular). > > > > > > > > > > Apologies for the long note, but the issue is complicated. > > > > > > > > > > The NDTeam have a proposal to resolve the concerns surrounding use > of > > > > > ISIDs as essential components (along with iSCSI Initiator Name) of > > > > > SCSI Initiator Portname. (This was rooted in private discussions > > > > > between John Hufferd, Julian and myself -- and came about as a > result > > > > > of the lengthy (and boring) discussions mostly myself and David > > > > > Black.) > > > > > > > > > > There are two somewhat orthogonal issues involved in this > discussion: > > > > > > > > > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > > > > > accidentally breaking the ISID RULE (no parallel nexus) when > > > > > independent vendors co-exist in the same OS. > > > > > > > > > > 2) What ISID "reuse" rules should be specified to facilitate > current > > > > > and future (soon?) SCSI reservation semantics (and also internal OS > > > > > views of SCSI Initiator Ports). > > > > > > > > > > To address these two issues, we (NDT) propose the following: > > > > > > > > > > 1) Enlarge the ISID field in the Login Request and Response to > 6bytes > > > > > and structure it with a component that corresponds to a "naming > > > > > authority" (essentially the vendor generating the ISID). So > vendors > > > > > each have a piece of the ISID namespace to work with their own > > > > > components (HBAs, SW, etc). More details below. > > > > > > > > > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used > > as > > > > > conservatively as possible ("conservative reuse"). What this means > > is > > > > > that a given ISID should be reused for as many sessions (across > > > > > multiple target portal groups) as possible (but never to the same > > > > > target portal group twice -- that's the ISID RULE). > > > > > > > > > > NOTES and ADVANTAGES: > > > > > > > > > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > > > > > effect, at the vendor-level, this provides a "partitioning" of that > > > > > namespace. > > > > > > > > > > (1-b) We don't need to specify an OS infrastructure requirement for > > > > > configuration of ISIDs -- each vendor can do it any way it chooses > > > > > (within its naming authority). > > > > > > > > > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes > up > > > > > its own implementation. > > > > > > > > > > (1-d) This is not fundamentally different from David Black's > > > > > suggestion for a "key"; it just (a) defines it precisely and (b) > > > > > embeds it in an already defined (but enlarged) field. > > > > > > > > > > (1-e) Looking towards the future, as common ISID coordination > > > > > mechanisms are implemented between vendors (say, SNIA banding > > together > > > > > to define a precise API), this "naming authority" can be elevated > to > > > > > the coordinating entity or even the OS vendor. > > > > > > > > > > (1-f) ISIDs have no global uniqueness property. They need only be > > > > > unique between a named iSCSI initiator and iSCSI target portal > group. > > > > > That means that a vendor implementation can use the same algorithm > to > > > > > generate ISIDs (under its naming authority) in every machine (OS). > > > > > > > > > > (2-a) If a SCSI target (or logical unit) is holding state (say > > > > > persistent reservation) for a SCSI Initiator Port (named by iSCSI > > Name > > > > > and ISID), and the associated nexus/session is dropped for some > > > > > reason, "reuse" by that initiator of that ISID will restore to the > > > > > resulting new session that state (with no other action on the part > of > > > > > the upper SCSI layers). > > > > > > > > > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > > > > > different SCSI Target Ports (iSCSI Target portal groups), will > enable > > > > > the SCSI target/logical unit to recognize a common SCSI Initiator > > Port > > > > > for those two paths. This facilitates future changes to SCSI > > > > > reservations (at least). > > > > > > > > > > (2-c) An initiator driver implementated with "conservative reuse" > can > > > > > present to the OS a stable and fairly static view of the SCSI > > > > > Initiator Ports (one for each ISID). Current OS driver stacks > > > > > (including current wedge drivers) that are built on the presumption > > of > > > > > such a stable view, will not need modification to handle the more > > > > > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence > > of > > > > > a SCSI Initiator Port presented to the OS does not *require* that > > this > > > > > port discover all possible targets; what the initiator builds > > sessions > > > > > to using a specific ISID will determine what is presented to the OS > > as > > > > > "devices" and LUs visible to that SCSI Initiator Port (could be > none > > > > > if that ISID is never actually used!).] > > > > > > > > > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI > Initiator > > > > > Port is as simple as configuring another ISID! > > > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > > particularly low-end that don't use reservations, can function more > > or > > > > > less OK without it. This is an open question. > > > > > > > > > > DETAILS: > > > > > > > > > > 1) ISID Structure: > > > > > The 6byte ISID structure would be split into three parts: > > > > > "type" field (1byte) -- identifies the format of the naming > > > > > authority field > > > > > "naming authority" field (3bytes) -- identifies the vendor (or > > > > > group of vendors) generating this ISID > > > > > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > > > > > > > > > The type field takes on three defined values with all other values > > > > > reserved: > > > > > Type naming authority format > > > > > 00h IEEE OUI > > > > > 01h IANA Enterprise Number (EN) > > > > > 02h "Random" > > > > > > > > > > The first types two provide a mechanism to uniquely (world wide) > > > > > identify the naming authority. A vendor with one or more OUIs and > > > > > possibly also Enterprise number MUST use at least one of these > > numbers > > > > > when it generates ISIDs. > > > > > > > > > > The "Random" type is for the case where the ISID generator (SW or > HW) > > > > > is provided by an entity that has no OUI or EN. This includes, for > > > > > example, > > > > > -- a user-written program that builds sessions (and has access to > the > > > > > system level iSCSI Name) > > > > > -- a university or other organization providing the component > > > > > -- a testing tool > > > > > > > > > > For the "Random" type, the naming authority field should be a > random > > > > > or pseudo-random number. (See below on how this affects > "conservative > > > > > reuse"). > > > > > > > > > > [Note: the "type" field needn't be this big, but NDT felt that (a) > > > > > 2bits was insufficient for the future, (b) the "type" field should > be > > > > > first, and (c) the "naming authority" field should be > byte-aligned.] > > > > > > > > > > 2) Conservative Reuse > > > > > > > > > > The "conservative reuse" principle of this proposal just says that > > > > > SCSI Initiator Portnames should be viewed as static things (as much > > as > > > > > possible) and reused (when feasible) to give the most stable > > > > > presentation of SCSI Initiator Ports to both the OS above and to > SCSU > > > > > targets across the wire. > > > > > > > > > > Whereas the current draft says "The ISID RULE does not preclude the > > > > > use of the same ISID to different Target portal groups", the > > > > > "conservative reuse" requirement would say that such reuse (using > the > > > > > same ISID to many target portal groups) is a SHOULD (or is that > > > > > MUST?). So, in one implementation, each iSCSI Initiator Portal > group > > > > > would get configured with iSCSI Name, and a (small) set of ISIDs. > > The > > > > > portal group might take this set of ISIDs as an ordered list. The > > > > > first session to a Target portal group would use the first ISID, > the > > > > > second to the *same* target portal group would use the second in > the > > > > > list, etc. The number of ISIDs would then define a configuration > > > > > parameter that can be interpreted as the maximum number of sessions > > > > > that can be built to a given target portal group. > > > > > > > > > > To facilitate "conservative reuse", the "qualifier" field of a set > of > > > > > ISIDs SHOULD be generated using either a repeatable algorithm > > > > > (non-random or pseudo-random but based on a fixed seed) or any > > > > > algorithm and stored in a persistent location (e.g., registry or > /etc > > > > > file). > > > > > > > > > > For the "Random" type, "conservative reuse" may not be an issue > (say, > > > > > user application that doesn't care about reservations, etc.). When > > it > > > > > is, the "naming authority" field SHOULD also be generated by a > > > > > mechanism similar to that for the "qualifier" field as specified > > above > > > > > (e.g., defined in the SW at compilation time.) > > > > > > > > > > DOCUMENTATING CHANGES: > > > > > > > > > > The iscsi drafts would need the following minor changes to support > > > > > this proposal: > > > > > > > > > > NDT doc > > > > > (a) define the structure of the ISID field (as described above) > > > > > (b) add some notes about implementation in the presense of > > > > > "conservative reuse" (e.g., that ISID should be configured once, > say > > > > > at install time, then reused on subsequent reboots, even for > "Random" > > > > > type). > > > > > > > > > > iSCSI MAIN doc: > > > > > (a) move the CID field in Login Request to another reserved field. > > > > > (b) expand the ISID field in Login Request and Response to > encompass > > > > > the previous 4 bytes. > > > > > (c) add a sentence where the ISID field is defined indicating that > > > > > this field is a structured value, showing the structure (as above) > > and > > > > > point to the NDT document. > > > > > (d) add some text to "Note to Implementors" on "conservative > reuse". > > > > > > > > > > Comments? > > > > > > > > > > Jim Hafner > > > > -- > > 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 Oct 31 02:38: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 CAA08453 for ; Wed, 31 Oct 2001 02:38:14 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9V6ss217365 for ips-outgoing; Wed, 31 Oct 2001 01:54:54 -0500 (EST) 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 f9V6srl17360 for ; Wed, 31 Oct 2001 01:54:53 -0500 (EST) 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 HAA280196 for ; Wed, 31 Oct 2001 07:54:47 +0100 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 f9V6skc57268 for ; Wed, 31 Oct 2001 07:54:46 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI CRC check clarification X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 31 Oct 2001 08:54:46 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 31/10/2001 08:54:45, Serialize complete at 31/10/2001 08:54:45 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Tandra, I am not sure I understand what you are talking about. The spec clearly states how the CRC should be calculated and what the bit order on the wire is. Perhaps by "reflecting" you are talking about the later. The examples where checked independently by me and at least 2 other persons. Regards, Julo "De, Tandra" 31-10-01 00:08 Please respond to "De, Tandra" To: Julian Satran/Haifa/IBM@IBMIL cc: "'ips@ece.cmu.edu'" , "De, Tandra" Subject: iSCSI CRC check clarification Julian, I followed few iSCSI CRC checking example threads and the thread file://www.pdl.cmu.edu/mailinglists/ips/mail/msg05931.html says that "Before transmission, the CRC bits must be reflected and complemented"; whereas, the iscsi- 08 draft only mentions about complementing the CRC before transmission. So attached you will find two software implementation code examples: crc_reflect.cpp and crc_no_reflect.cpp. I ran few test cases with the attached example code and when I do reflect bits I get 0: ff ff ff ff 4: ff ff ff ff 8: ff ff ff ff 12: ff ff ff ff 16: ff ff ff ff 20: ff ff ff ff 24: ff ff ff ff 28: ff ff ff ff 32: 43 ab a8 62 in the transmission side, and the reception side I get 0x1c2d19ed. But when I do not bit flip I get 0: ff ff ff ff 4: ff ff ff ff 8: ff ff ff ff 12: ff ff ff ff 16: ff ff ff ff 20: ff ff ff ff 24: ff ff ff ff 28: ff ff ff ff 32: 46 15 d5 c2 in the transmission side, and the reception side I do get 0x1c2d19ed though. I like to clarify which implementation we should use so that both Initiator and Target will be in sync. validating the CRC. I appreciate if you could verify the attached files to see I am missing anytbing. Also I think that it would help everyone who are dealing with iSCSI CRC if you could put up the finalized version of the code in the reflector. Thanks, Tandra (tde@corp.adaptec.com) #### crc_no_reflect.cpp has been removed from this note on October 31 2001 by Julian Satran #### crc_reflect.cpp has been removed from this note on October 31 2001 by Julian Satran From owner-ips@ece.cmu.edu Wed Oct 31 03:26: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 DAA08833 for ; Wed, 31 Oct 2001 03:26:16 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9V7Y1U19659 for ips-outgoing; Wed, 31 Oct 2001 02:34:01 -0500 (EST) 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 f9V7Xvl19650 for ; Wed, 31 Oct 2001 02:33:57 -0500 (EST) 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 IAA187360 for ; Wed, 31 Oct 2001 08:33:51 +0100 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 f9V7Xoc65614 for ; Wed, 31 Oct 2001 08:33:50 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: is TargetName always mandatory or not? X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 31 Oct 2001 09:33:50 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 31/10/2001 09:33:50, Serialize complete at 31/10/2001 09:33:50 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk It is the leading login: The section 5 paragraph will read: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The leading Login request MAY also include the SessionType key=value pair in which case if the SessionType is not "discovery" then the leading Login Request MUST also include the key=value pair TargetName. Julo Andre Asselin/Raleigh/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 31-10-01 02:08 Please respond to Andre Asselin To: "IPS Reflector (E-mail)" cc: Subject: is TargetName always mandatory or not? In section 5 of the spec, it says "If the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName.". However, in Appendix D, the description for TargetName says it is Leading Only. Should TargetName not be Leading Only, or should the text in section 5 say that TargetName must be in the initial Login Request of a leading connection? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 04:29: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 EAA09253 for ; Wed, 31 Oct 2001 04:29:29 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9V8fHL23394 for ips-outgoing; Wed, 31 Oct 2001 03:41:17 -0500 (EST) 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 f9V8fFl23389 for ; Wed, 31 Oct 2001 03:41:16 -0500 (EST) 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 JAA15474 for ; Wed, 31 Oct 2001 09:41:08 +0100 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 f9V8f8c32528 for ; Wed, 31 Oct 2001 09:41:08 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: iSCSI: current UNH Plugfest X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 31 Oct 2001 10:41:08 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 31/10/2001 10:41:07, Serialize complete at 31/10/2001 10:41:07 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Good point - Julo Steve Senum Sent by: owner-ips@ece.cmu.edu 30-10-01 21:05 Please respond to Steve Senum To: ietf-ips cc: Subject: Re: iSCSI: current UNH Plugfest Julian, Julian Satran wrote: > For numerical and single literal negotiations, the responding party MUST > respond with the required key and the value it selects, based on the > selection rule specific to the key, becomes the negotiation result. If a > key is irrelevant in the current negotiation, the responder may use the > special numeric constant 0r. > Selection of a value not admissible under the selection rules is > considered a protocol error and handled accordingly. I don't see the point or using '0r' instead of 'irrelevant' like the list and boolean types do. Even numeric types have to check for 'NotUnderstood', a decidedly non numeric value. Steve Senum From owner-ips@ece.cmu.edu Wed Oct 31 04:31: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 EAA09287 for ; Wed, 31 Oct 2001 04:31:00 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9V8exP23377 for ips-outgoing; Wed, 31 Oct 2001 03:40:59 -0500 (EST) 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 f9V8eul23372 for ; Wed, 31 Oct 2001 03:40:57 -0500 (EST) 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 DAA25320; Wed, 31 Oct 2001 03:38:22 -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 f9V8et9192584; Wed, 31 Oct 2001 01:40:55 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: iSCSI: proposal to solve the ISID issues To: "Mallikarjun C." Cc: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 31 Oct 2001 00:39:57 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/31/2001 01:40:55 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Mallikarjun, I think you are not making things clearer. We have said that the new Extended ISID can be determined independent of any other outside interference. Period!!! And that includes multiple Sessions from the same Manufactures HBAs or Set of HBAs. By definition if a different vendor's HBA is placed in the NODE, that vendor's ID should be part of its Extended ISID, and a new session can be created independent of the other ones. And there maybe NO Admin interface, yet it still works! Even if a HBA is supported by a Device Driver that is not owned by the HBA manufacture, it does not matter, since there should be a vendor ID for the vendor that IS creating the Device Driver. NO one is saying where the Vendor ID comes from. Hence still no problem and still no Admin Interface. So if you want an outside interference, it should NOT be a "must". If SNIA or anyone else wants to come up with a API, wonderful for them. It is still not a must. If the SNIA group wants to pick a common value for the Vendor ID in the Extended ISID they can do that. Still no problem and no Admin Interface. This picking of a common value was part of the proposal. But that is not what I call an API. Therefore, since the original issue I stated was -- I did not like your use of the word "must", I think that point is still valid, "must" is not approprate. . . . 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 "Mallikarjun C." @ece.cmu.edu on 10/30/2001 05:23:35 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: Re: iSCSI: proposal to solve the ISID issues John, >This is an > Implementation decision! I have been trying to point out that it is *not* an implementation decision *whether* to require ISID-configurability (Note below). OTOH, *how* to configure the ISIDs is an implementation decision (as Jim pointed out earlier), so also the decision of *if* it should be made a public API. Note: And I say this based on three factors - - multiple NICs in the Node sharing the same Node Name - stated objective of allowing multiple sessions between a given initiator node and a target portal group. - ISID RULE, which forbids parallel nexus As a final note, Jim alluded to the possibility of "this naming authority can be elevated to the (SNIA-defined) coordinating entity or even the OS vendor" in future. That possibility requires external ISID-configurability as well, AND requires the API to be public. I see that Jim and Julian had already appreciated where I am coming from. I hope I did a better job of convincing you this time..... -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "John Hufferd" To: Cc: "Jim Hafner" ; Sent: Tuesday, October 30, 2001 1:48 PM Subject: Re: iSCSI: proposal to solve the ISID issues > > I do not like the word must even if it is in lower case. This is an > Implementation decision! and many/most will not need Admin help. > If you were to say "Should allow for configuration and coordination of > ISIDs, by the iSCSI/HBA Driver,to allow for configuration and coordination > of ISIDs for...." I could go along with that. How that driver gets the > information is its business. > > > > > > . > . > . > 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 > > > "Mallikarjun C." @ece.cmu.edu on 10/30/2001 11:53:20 AM > > Please respond to cbm@rose.hp.com > > Sent by: owner-ips@ece.cmu.edu > > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > Jim, > > I am in broad agreement with you on your suggestion, > and I agree that the ISID-configurability is a derivative > requirement - but my argument is that it's nevertheless > a crucial one to warrant making it explicit, but I can > live with the proposed compromise of making it a NOTE. > > Some comments - > > >There is a requirement > > that vendor NICs (managed by the same vendor driver) be configurable in > > their ISIDs. > > I am kind of perplexed on this underlying assumption that > a vendor NICs are "managed by the same vendor driver". As > you know, this is not always true. IMHO, regardless of > vendor and driver affiliations, an iSCSI initiator NIC MUST > have external ISID-configurability - that's a design constraint > on a NIC vendor (from the ISID rule)! [ Note that I am NOT > suggesting that the API be "public", it's upto the NIC vendor > on allowing third-party drivers - and I believe most would. ] > > With that, I would suggest the following wordsmithing, but > I will not press it any further... > > NOTE: For correct behavior (in particular with respect to the ISID > rule), a > vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must > allow > for configuration and coordination of ISIDs for all sessions managed > by > multiple instances of that hardware within a given iSCSI Node. Such > configuration might be either static (e.g., partitioned across all the > NICs > at initialization) or dynamic (e.g., on-line allocator). > > I hope the suggested wording (or something close to it) on the > Node name would make its way in. > > Finally, thanks for so patiently driving this issue! > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Jim Hafner wrote: > > > > John and Mallikarjun, > > > > I appreciate where Mallikarjun wants to go here. There is a requirement > > that vendor NICs (managed by the same vendor driver) be configurable in > > their ISIDs. However, that requirement is more a derivative conclusion > of > > the rules (for a good and correct implementation) than it is a protocol > > requirement. A vendor that doesn't do this only steps on his own toes > when > > more than one of his cards is in a system! > > > > Perhaps we compromise and make this a big NOTE: > > > > NOTE: For correct behavior (in particular with respect to the ISID rule), > a > > vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must > provide > > either driver software or external and public APIs to allow for > > configuration and coordination of ISIDs for all sessions managed by > > multiple instances of that hardware within a given iSCSI Node. Such > > configuration might be either static (e.g., partitioned across all the > NICs > > at initialization) or dynamic (e.g., on-line allocator). > > > > We can make the iSCSI Node Name a stronger requirement (that is, outside > of > > a NOTE). > > > > Does that help? > > > > Jim Hafner > > > > John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 10/29/2001 06:47:31 pm > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: cbm@rose.hp.com > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > I have no problem with the Must have a way to have the Node name set. > > However, I do not grasp the problem you state here: > > > > "I don't believe the type of the ISID matters, nor does > > the NIC capability (coordinating vs not). If two initiator > > NICs share the same node name, they better not re-use the > > same ISID to a given target portal group. I was trying > > to capture the consequences of this reality." > > > > If the ISID includes the Vendor ID, I do not see the problem, unless the > > vendor can not assign the rest of the ISID. And I would say that it is > the > > vendors problem to work out. If you are saying that with NICs (not HBAs) > > that the SW Drivers will have a problem coming up with the ISID, I do not > > understand that either since most software is built by a Vendor, and if > not > > the Random type should work. > > > > Now in case you are saying something about the creation of a second > Session > > from the Initiator, which is to access the same Target Node. Then by > > definition, the ISID must be unique. (and it will probably need a Wedge > > Driver to operate correctly). I would think that a vendor should be able > > to come up with a unique qualifier for the session since they have 64K > > numbers to chose from. Remember the vendor only needs to coordinate the > > lower 2 bytes of the new ISID, with itself. So if they can not do that, > > ... Oh well ... > > > > Are we on the same page yet? > > > > . > > . > > . > > 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 > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > 06:35:55 > > PM > > > > Please respond to cbm@rose.hp.com > > > > Sent by: cbm@core.rose.hp.com > > > > To: John Hufferd/San Jose/IBM@IBMUS > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > John, > > > > I take it that you don't have an issue with the > > Node Name part of the wording. > > > > I thought I answered your question by saying - > > > > "My point though is that by banning a duplicate nexus (that an > > inadvertently re-used ISID allows), we are making the ISID > > (dynamic/static) distribution an imminent hard requirement > > for all NICs in a given iSCSI initiator Node" > > > > The unspoken assumption above is that we would want to > > allow multiple sessions between an initiator node and > > a target portal group. > > > > I don't believe the type of the ISID matters, nor does > > the NIC capability (coordinating vs not). If two initiator > > NICs share the same node name, they better not re-use the > > same ISID to a given target portal group. I was trying > > to capture the consequences of this reality. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > John Hufferd wrote: > > > > > > Mallikarjun, > > > I do not understand the purpose for your proposed wordage > > > > > > "All iSCSIinitiator hardware implementations MUST in addition also > > support > > > the operational ISID values to be (either statically or dynamically) > > > externally configurable." > > > > > > Why is this so important that it is a MUST. The purpose of the > proposal > > is > > > to eliminate the need for the above. At most it should only apply to > the > > > vendors (Probably Software and at Universities and IT shops) that use > the > > > RANDOM ISID type code. > > > > > > I do not see the need elsewhere. At most it could be "MAY". > > > > > > . > > > . > > > . > > > 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 > > > > > > "Mallikarjun C." @ece.cmu.edu on 10/29/2001 05:24:20 > PM > > > > > > Please respond to cbm@rose.hp.com > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > > cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > Jim, > > > > > > Thanks for the quick response. > > > > > > As much as I would like to avoid consuming more bandwidth > > > on this topic, let me make one last strawman for wording below. > > > > > > > What words do you suggest? > > > ... > > > > And a lot depends on how > > > > functional the NICs are: (a) just network nics, (b) protocol nics, > but > > > not > > > > session coordinating nics (c) full session coordination nics (with > > driver > > > > assist) (d) fully autonomous session nics. How do we make a > > requirement > > > > that fits all the cases correctly? > > > > > > I have been implying iSCSI NICs in all my postings so far - > > > sorry, may be that wasn't very clear. "iSCSI Node name" comment > > > obviously wasn't targeted at simple network NICs. So clearly (a) > > > is out of discussion. But you are right - I wasn't very precise. > > > Here's a strawman - > > > > > > All iSCSI hardware implementations (as in NICs) MUST allow > > > the iSCSI Node Name to be externally configurable. All iSCSI > > > initiator hardware implementations MUST in addition also > > > support the the operational ISID values to be (either statically > > > or dynamically) externally configurable. > > > > > > > Making them configurable (at > > > > initialization time, e.g., as a range of values) or making them > dynamic > > > > (the driver generates them on demand) both fit the mold. So, I don't > > > think > > > > this one is a hard requirement. > > > > > > I agree that my earlier "range" wording was too constraining. > > > My point though is that by banning a duplicate nexus (that an > > > inadvertently re-used ISID allows), we are making the ISID > > > (dynamic/static) distribution an imminent hard requirement > > > for all NICs in a given iSCSI initiator Node - except it is > > > not sufficiently explicit. Please consider the above proposed > > > wording. > > > > > > > Well, I don't think so. If each vendor implements "conservative > reuse" > > > > within their own ISID namespace on their own NICs, then you get this > > > > property system wide. > > > > > > You are right, I guess I briefly overlooked the fact that ISID > > > includes the vendor identifier within, per the new proposal. > > > > > > I am personally okay with making "conservative reuse" a > > > SHOULD. > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > MS 5668 Hewlett-Packard, Roseville. > > > cbm@rose.hp.com > > > > > > Jim Hafner wrote: > > > > > > > > Mallikarjun, > > > > > > > > Comments in line below > > > > > > > > Jim Hafner > > > > > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > > > 12:17:49 > > > > pm > > > > > > > > Please respond to cbm@rose.hp.com > > > > > > > > Sent by: cbm@core.rose.hp.com > > > > > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > > > cc: ips@ece.cmu.edu > > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > > > Jim, > > > > > > > > Thanks for the excellent summary. Some questions/comments - > > > > > > > > - I assume that the NICs must enable the configuration of > > > > iSCSI Node name even in this proposal. If it is so, please > > > > call this out as a hard requirement in the main modelling > > > > discussion. > > > > > > > > > > > > This requirement doesn't change from before (but how it gets written > > into > > > > the spec may differ -- and we've had this discussion before). If a > > > vendor > > > > doesn't allow configuration of his NIC's iSCSI Node name, then his > NICs > > > > will be acting as their own iSCSI Node (that is, not representing the > > > > system they live in). One can argue that this is a legitimate > > > > implementation (just as writing user-level code that uses its own > iSCSI > > > > Node name). So a "hard requirement" may be a bit too strong. > However, > > I > > > > will go with the will of the group on this point. > > > > > > > > What words do you suggest? > > > > > > > > - In the case of multiple NICs from the same vendor operating > > > > in an end node, it appears to me that the proposal implicitly > > > > assumes an ISID-range to be configurable among those NICs > > > > (perhaps in vendor-unique ways, which is always what I expected). > > > > If this is a correct inference, there is again a hard > > > > requirement on the NICs to make the ISID range configurable. > > > > Please comment on any subtle qualitative change from the > > > > earlier situation that I may be missing. > > > > > > > > > > > > Well, the point is that the vendor can manage his own namespace for > his > > > > NICs anyway he/she/it wants to. Making them configurable (at > > > > initialization time, e.g., as a range of values) or making them > dynamic > > > > (the driver generates them on demand) both fit the mold. So, I don't > > > think > > > > this one is a hard requirement (though that is probably how most > > vendors > > > > will implement their NICs). In effect, the proposal gives vendors > more > > > > flexibility in their own space, without causing heterogenous > > > > interoperability problems within the host. And a lot depends on how > > > > functional the NICs are: (a) just network nics, (b) protocol nics, > but > > > not > > > > session coordinating nics (c) full session coordination nics (with > > driver > > > > assist) (d) fully autonomous session nics. How do we make a > > requirement > > > > that fits all the cases correctly? You clearly have in mind a > specific > > > > level of implementation within the NICs, but that may not be > > everybody's > > > > model. > > > > > > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > > particularly low-end that don't use reservations, can function more > > or > > > > > less OK without it. > > > > > > > > It seems we're attempting to set ourselves up for future in > > > > discussing the above requirement. Some questions - > > > > - It appears to me that the "conservative reuse" can not > > > > be enforced for initiators hosting NICs from different > > > > vendors (since the proposal allows ISID namespaces to > > > > be totally non-overlapping between non-homogenous NICs). > > > > Is this a fair assessment? > > > > > > > > Well, I don't think so. If each vendor implements "conservative > reuse" > > > > within their own ISID namespace on their own NICs, then you get this > > > > property system wide. As before, by owning their own piece of the > ISID > > > > namespace, they can implement what they want. So, you may have a > > > situation > > > > where some of your installed nics have this property and some don't. > > > > You'll find out (if your environment really needs conservative reuse) > > > that > > > > you haven't got it, and it becomes a marketing/purchase spec > > requirement. > > > > > > > > - Do you see a particular disadvantage for low-end systems > > > > if it's mandated (aside from the fact that they may be able > > > > to live without it)? > > > > > > > > No, but I don't see any way to really enforce it (or even really test > > > it). > > > > It's not a requirement of the protocol, per se. > > > > > > > > - Do you see any corner cases not being met (for future) > > > > if we don't make it a MUST (since you said "more or less > > OK")? > > > > > > > > No, I can't see that far into the future! :-{). One reason I'm being > > > cagey > > > > here is that I'm finding it difficult to find the right words to > > specify > > > > this as a hard requirement (but I'm no technical writer either!). > > > > > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions Organization > > > > MS 5668 Hewlett-Packard, Roseville. > > > > cbm@rose.hp.com > > > > > > > > Jim Hafner wrote: > > > > > > > > > > Folks, (David Black in particular). > > > > > > > > > > Apologies for the long note, but the issue is complicated. > > > > > > > > > > The NDTeam have a proposal to resolve the concerns surrounding use > of > > > > > ISIDs as essential components (along with iSCSI Initiator Name) of > > > > > SCSI Initiator Portname. (This was rooted in private discussions > > > > > between John Hufferd, Julian and myself -- and came about as a > result > > > > > of the lengthy (and boring) discussions mostly myself and David > > > > > Black.) > > > > > > > > > > There are two somewhat orthogonal issues involved in this > discussion: > > > > > > > > > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > > > > > accidentally breaking the ISID RULE (no parallel nexus) when > > > > > independent vendors co-exist in the same OS. > > > > > > > > > > 2) What ISID "reuse" rules should be specified to facilitate > current > > > > > and future (soon?) SCSI reservation semantics (and also internal OS > > > > > views of SCSI Initiator Ports). > > > > > > > > > > To address these two issues, we (NDT) propose the following: > > > > > > > > > > 1) Enlarge the ISID field in the Login Request and Response to > 6bytes > > > > > and structure it with a component that corresponds to a "naming > > > > > authority" (essentially the vendor generating the ISID). So > vendors > > > > > each have a piece of the ISID namespace to work with their own > > > > > components (HBAs, SW, etc). More details below. > > > > > > > > > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used > > as > > > > > conservatively as possible ("conservative reuse"). What this means > > is > > > > > that a given ISID should be reused for as many sessions (across > > > > > multiple target portal groups) as possible (but never to the same > > > > > target portal group twice -- that's the ISID RULE). > > > > > > > > > > NOTES and ADVANTAGES: > > > > > > > > > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > > > > > effect, at the vendor-level, this provides a "partitioning" of that > > > > > namespace. > > > > > > > > > > (1-b) We don't need to specify an OS infrastructure requirement for > > > > > configuration of ISIDs -- each vendor can do it any way it chooses > > > > > (within its naming authority). > > > > > > > > > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes > up > > > > > its own implementation. > > > > > > > > > > (1-d) This is not fundamentally different from David Black's > > > > > suggestion for a "key"; it just (a) defines it precisely and (b) > > > > > embeds it in an already defined (but enlarged) field. > > > > > > > > > > (1-e) Looking towards the future, as common ISID coordination > > > > > mechanisms are implemented between vendors (say, SNIA banding > > together > > > > > to define a precise API), this "naming authority" can be elevated > to > > > > > the coordinating entity or even the OS vendor. > > > > > > > > > > (1-f) ISIDs have no global uniqueness property. They need only be > > > > > unique between a named iSCSI initiator and iSCSI target portal > group. > > > > > That means that a vendor implementation can use the same algorithm > to > > > > > generate ISIDs (under its naming authority) in every machine (OS). > > > > > > > > > > (2-a) If a SCSI target (or logical unit) is holding state (say > > > > > persistent reservation) for a SCSI Initiator Port (named by iSCSI > > Name > > > > > and ISID), and the associated nexus/session is dropped for some > > > > > reason, "reuse" by that initiator of that ISID will restore to the > > > > > resulting new session that state (with no other action on the part > of > > > > > the upper SCSI layers). > > > > > > > > > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > > > > > different SCSI Target Ports (iSCSI Target portal groups), will > enable > > > > > the SCSI target/logical unit to recognize a common SCSI Initiator > > Port > > > > > for those two paths. This facilitates future changes to SCSI > > > > > reservations (at least). > > > > > > > > > > (2-c) An initiator driver implementated with "conservative reuse" > can > > > > > present to the OS a stable and fairly static view of the SCSI > > > > > Initiator Ports (one for each ISID). Current OS driver stacks > > > > > (including current wedge drivers) that are built on the presumption > > of > > > > > such a stable view, will not need modification to handle the more > > > > > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence > > of > > > > > a SCSI Initiator Port presented to the OS does not *require* that > > this > > > > > port discover all possible targets; what the initiator builds > > sessions > > > > > to using a specific ISID will determine what is presented to the OS > > as > > > > > "devices" and LUs visible to that SCSI Initiator Port (could be > none > > > > > if that ISID is never actually used!).] > > > > > > > > > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI > Initiator > > > > > Port is as simple as configuring another ISID! > > > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > > particularly low-end that don't use reservations, can function more > > or > > > > > less OK without it. This is an open question. > > > > > > > > > > DETAILS: > > > > > > > > > > 1) ISID Structure: > > > > > The 6byte ISID structure would be split into three parts: > > > > > "type" field (1byte) -- identifies the format of the naming > > > > > authority field > > > > > "naming authority" field (3bytes) -- identifies the vendor (or > > > > > group of vendors) generating this ISID > > > > > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > > > > > > > > > The type field takes on three defined values with all other values > > > > > reserved: > > > > > Type naming authority format > > > > > 00h IEEE OUI > > > > > 01h IANA Enterprise Number (EN) > > > > > 02h "Random" > > > > > > > > > > The first types two provide a mechanism to uniquely (world wide) > > > > > identify the naming authority. A vendor with one or more OUIs and > > > > > possibly also Enterprise number MUST use at least one of these > > numbers > > > > > when it generates ISIDs. > > > > > > > > > > The "Random" type is for the case where the ISID generator (SW or > HW) > > > > > is provided by an entity that has no OUI or EN. This includes, for > > > > > example, > > > > > -- a user-written program that builds sessions (and has access to > the > > > > > system level iSCSI Name) > > > > > -- a university or other organization providing the component > > > > > -- a testing tool > > > > > > > > > > For the "Random" type, the naming authority field should be a > random > > > > > or pseudo-random number. (See below on how this affects > "conservative > > > > > reuse"). > > > > > > > > > > [Note: the "type" field needn't be this big, but NDT felt that (a) > > > > > 2bits was insufficient for the future, (b) the "type" field should > be > > > > > first, and (c) the "naming authority" field should be > byte-aligned.] > > > > > > > > > > 2) Conservative Reuse > > > > > > > > > > The "conservative reuse" principle of this proposal just says that > > > > > SCSI Initiator Portnames should be viewed as static things (as much > > as > > > > > possible) and reused (when feasible) to give the most stable > > > > > presentation of SCSI Initiator Ports to both the OS above and to > SCSU > > > > > targets across the wire. > > > > > > > > > > Whereas the current draft says "The ISID RULE does not preclude the > > > > > use of the same ISID to different Target portal groups", the > > > > > "conservative reuse" requirement would say that such reuse (using > the > > > > > same ISID to many target portal groups) is a SHOULD (or is that > > > > > MUST?). So, in one implementation, each iSCSI Initiator Portal > group > > > > > would get configured with iSCSI Name, and a (small) set of ISIDs. > > The > > > > > portal group might take this set of ISIDs as an ordered list. The > > > > > first session to a Target portal group would use the first ISID, > the > > > > > second to the *same* target portal group would use the second in > the > > > > > list, etc. The number of ISIDs would then define a configuration > > > > > parameter that can be interpreted as the maximum number of sessions > > > > > that can be built to a given target portal group. > > > > > > > > > > To facilitate "conservative reuse", the "qualifier" field of a set > of > > > > > ISIDs SHOULD be generated using either a repeatable algorithm > > > > > (non-random or pseudo-random but based on a fixed seed) or any > > > > > algorithm and stored in a persistent location (e.g., registry or > /etc > > > > > file). > > > > > > > > > > For the "Random" type, "conservative reuse" may not be an issue > (say, > > > > > user application that doesn't care about reservations, etc.). When > > it > > > > > is, the "naming authority" field SHOULD also be generated by a > > > > > mechanism similar to that for the "qualifier" field as specified > > above > > > > > (e.g., defined in the SW at compilation time.) > > > > > > > > > > DOCUMENTATING CHANGES: > > > > > > > > > > The iscsi drafts would need the following minor changes to support > > > > > this proposal: > > > > > > > > > > NDT doc > > > > > (a) define the structure of the ISID field (as described above) > > > > > (b) add some notes about implementation in the presense of > > > > > "conservative reuse" (e.g., that ISID should be configured once, > say > > > > > at install time, then reused on subsequent reboots, even for > "Random" > > > > > type). > > > > > > > > > > iSCSI MAIN doc: > > > > > (a) move the CID field in Login Request to another reserved field. > > > > > (b) expand the ISID field in Login Request and Response to > encompass > > > > > the previous 4 bytes. > > > > > (c) add a sentence where the ISID field is defined indicating that > > > > > this field is a structured value, showing the structure (as above) > > and > > > > > point to the NDT document. > > > > > (d) add some text to "Note to Implementors" on "conservative > reuse". > > > > > > > > > > Comments? > > > > > > > > > > Jim Hafner > > > > -- > > 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 Oct 31 05:12: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 FAA09559 for ; Wed, 31 Oct 2001 05:12:45 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9V9Lww25598 for ips-outgoing; Wed, 31 Oct 2001 04:21:58 -0500 (EST) 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 f9V9Lsl25591 for ; Wed, 31 Oct 2001 04:21:55 -0500 (EST) 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 EAA59744 for ; Wed, 31 Oct 2001 04:19: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 f9V9Lq9153806 for ; Wed, 31 Oct 2001 02:21:52 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: is TargetName always mandatory or not? 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: Wed, 31 Oct 2001 01:20:57 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/31/2001 02:21:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, I think the TargetName should be included on the Initial Login Request on the Leading Login. It seem strange to permit the Authentication functions to proceed if perhaps the intended Target is different then the one doing the Authentication. The way it currently is written, you could pass all the Security test and then find out just before going into Full Function Phase, that it was intended for some other Target. Seems like a waste. My I think that TargetName should also be on all connections on the Initial Login Request. Here is my thinking: The SSID (ISID+TSID) is unique only with regards to a Specific Initiator and Target Node Pair. It is therefore not clear that just knowing the SSID and InitiatorName is enough to understand what session the subsequent connections are being attached to. And it is possible that the CID could be also overlapped with another session. Therefore, I think it make since to determine all this on the initial Login on every Connection, so you know at the beginning what values can be negotiated, or that are being set to the right Session. . . . 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 10/30/2001 11:33:50 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: is TargetName always mandatory or not? It is the leading login: The section 5 paragraph will read: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The leading Login request MAY also include the SessionType key=value pair in which case if the SessionType is not "discovery" then the leading Login Request MUST also include the key=value pair TargetName. Julo Andre Asselin/Raleigh/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 31-10-01 02:08 Please respond to Andre Asselin To: "IPS Reflector (E-mail)" cc: Subject: is TargetName always mandatory or not? In section 5 of the spec, it says "If the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName.". However, in Appendix D, the description for TargetName says it is Leading Only. Should TargetName not be Leading Only, or should the text in section 5 say that TargetName must be in the initial Login Request of a leading connection? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 10:45: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 KAA22218 for ; Wed, 31 Oct 2001 10:45:27 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VEjc827969 for ips-outgoing; Wed, 31 Oct 2001 09:45:38 -0500 (EST) 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 f9VEjal27962 for ; Wed, 31 Oct 2001 09:45:36 -0500 (EST) Received: by mercury.corp.iready.com with Internet Mail Service (5.5.2653.19) id <4VFN6Y1B>; Wed, 31 Oct 2001 06:45:30 -0800 Message-ID: <034670D62D19D31180990090277A37B701B15852@mercury.corp.iready.com> From: Ken Nicholson To: "'ips@ece.cmu.edu'" Subject: Phase collapse Date: Wed, 31 Oct 2001 06:45:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1621A.AF3EE150" 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_01C1621A.AF3EE150 Content-Type: text/plain Julian and David: Could you clarify the information below? It seems to us that it should be possible for a target to phase collapse the response to an INQ in a single PDU which is both the first and last PDU of that response. If this true: >A command and its associated data may be > shipped together from initiator to target and data and responses > may be shipped together from targets." Why is this true: "...the above text makes it quite clear that data transferred by the action of a SCSI command (including Read, Inquiry, Mode Sense, and Read Capacity) cannot be put in the Response PDU. " Ken Nicholson iReady Corp. ---------------------------------------------------------------------------- ------------- To: ips@ece.cmu.edu Subject: RE: iSCSI: Inquiry, Mode Sense, Read Capacity From: "Julian Satran" Date: Wed, 3 Oct 2001 22:46:44 +0300 Content-Type: multipart/alternative; boundary="=_alternative 006CB109C2256ADA_=" Sender: owner-ips@ece.cmu.edu David is right. Response doe not contain data proper. Phase collapse is for the last DataPDU in which a target can fit a GOOD status (and thus avoid an additional response) and some residual counts (when those are not considered errors). Julo Black_David@emc.com Sent by: owner-ips@ece.cmu.edu 03-10-01 20:21 Please respond to Black_David To: lxing@Crossroads.com, ips@ece.cmu.edu cc: Subject: RE: iSCSI: Inquiry, Mode Sense, Read Capacity The governing text is the following from p.62 of -08 on the contents of the Response PDU: 3.4.6 Data Segment - Sense and Response Data Segment iSCSI targets MUST support and enable autosense. If Status is CHECK CONDITION (0x02), then the Data Segment contains sense data for the failed command. For some iSCSI responses, the response data segment MAY contain some response related information, (e.g., for a target failure it may contain a vendor specific detailed description of the failure). Julian may be able to shed more light on the intended meaning of "phase collapse" for the response case, but the above text makes it quite clear that data transferred by the action of a SCSI command (including Read, Inquiry, Mode Sense, and Read Capacity) cannot be put in the Response PDU. A target can send the Response PDU immediately following the last Data-In PDU for the associated command, which is similar to the ability of an Initiator to send unsolicited Data-Out PDUs. There is no Target analog to the Initiator's ability to send Immediate Data in the same PDU as the SCSI command. Thanks, --David ------_=_NextPart_001_01C1621A.AF3EE150 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Phase collapse

Julian and David:

Could you clarify the information below?

It seems to us that it should be possible for a = target to phase collapse the response to an INQ in a single PDU which = is both the first and last PDU of that response.

If this true:
>A command and its associated data may be
> shipped together from initiator to target and = data and responses
> may be shipped together from = targets."


Why is this true:
"...the above text makes
it quite clear that data transferred by the action = of a SCSI command
(including Read, Inquiry, Mode Sense, and Read = Capacity) cannot be put in
the Response PDU. "





Ken Nicholson
iReady Corp.

---------------------------------------------------------------= -------------
-------------
To: ips@ece.cmu.edu
Subject: RE: iSCSI: Inquiry, Mode Sense, Read = Capacity
From: "Julian Satran" = <Julian_Satran@il.ibm.com>
Date: Wed, 3 Oct 2001 22:46:44 +0300
Content-Type: multipart/alternative; = boundary=3D"=3D_alternative
006CB109C2256ADA_=3D"
Sender: owner-ips@ece.cmu.edu




David is right. Response doe not contain data = proper.
Phase collapse is for the last DataPDU in which a = target can fit a GOOD
status (and thus avoid an additional response) and = some residual counts
(when those are not considered errors).

Julo



Black_David@emc.com
Sent by: owner-ips@ece.cmu.edu
03-10-01 20:21
Please respond to Black_David

        = To:        lxing@Crossroads.com, = ips@ece.cmu.edu
        = cc:
        = Subject:        RE: iSCSI: Inquiry, = Mode Sense, Read Capacity





The governing text is the following from p.62 of -08 = on the contents of
the Response PDU:

    3.4.6 Data Segment - Sense and = Response Data Segment

       iSCSI targets = MUST support and enable autosense.  If Status is CHECK

       CONDITION = (0x02), then the Data Segment contains sense data for the
       failed = command.

       For some iSCSI = responses, the response data segment MAY contain some

       response related = information, (e.g., for a target failure it may
       contain a = vendor specific detailed description of the failure).

Julian may be able to shed more light on the intended = meaning of
"phase collapse" for the response case, = but the above text makes
it quite clear that data transferred by the action = of a SCSI command
(including Read, Inquiry, Mode Sense, and Read = Capacity) cannot be
put in the Response PDU.  A target can send the = Response PDU immediately
following the last Data-In PDU for the associated = command, which is
similar to the ability of an Initiator to send = unsolicited Data-Out
PDUs.  There is no Target analog to the = Initiator's ability to send
Immediate Data in the same PDU as the SCSI = command.

Thanks,
--David

------_=_NextPart_001_01C1621A.AF3EE150-- From owner-ips@ece.cmu.edu Wed Oct 31 12:33: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 MAA25250 for ; Wed, 31 Oct 2001 12:33:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VGOsi06168 for ips-outgoing; Wed, 31 Oct 2001 11:24:54 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9VGOql06160 for ; Wed, 31 Oct 2001 11:24:52 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA16448 for ; Wed, 31 Oct 2001 10:22:13 -0600 Received: from d04nms41.raleigh.ibm.com (d04nms41.raleigh.ibm.com [9.67.228.19]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id f9VGOi823418 for ; Wed, 31 Oct 2001 11:24:44 -0500 Subject: question on whitespace in text negotiations To: "IPS Reflector (E-mail)" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andre Asselin" Date: Wed, 31 Oct 2001 11:25:45 -0500 X-MIMETrack: Serialize by Router on D04NMS41/04/M/IBM(Release 5.0.8 |June 18, 2001) at 10/31/2001 11:24:44 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Julian, Thanks for answering my previous question. I have another one for you: Sections 2.2.4 and 3.10.4 describe the format of text requests/responses, but doesn't address whether whitespace is significant or should be thrown away. For example, is "_MaxConnections_=_2" (where _ represents a space) valid or invalid? I get the feeling that whitespace is significant, but it would be nice if the spec explicitly said so. Thanks... Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 12: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 MAA25686 for ; Wed, 31 Oct 2001 12:52:58 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VH9Yp09909 for ips-outgoing; Wed, 31 Oct 2001 12:09:34 -0500 (EST) 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 f9VH9Rl09900 for ; Wed, 31 Oct 2001 12:09:29 -0500 (EST) Received: from wombat (wombat [192.168.7.41]) by best.eurologic.com (8.9.3+Sun/8.9.3) with SMTP id RAA22191 for ; Wed, 31 Oct 2001 17:05:56 GMT Message-ID: <058001c1622e$bb403710$2907a8c0@wombat> From: "Ken Sandars" To: Subject: iSCSI:SCSI responses for iSCSI errors Date: Wed, 31 Oct 2001 17:08:57 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 Gidday all, With reference to 3.4.2, when a target detects an error does: '...MUST wait until it receives a Data PDU with the F bit set, in the last expected sequence, before sending the Response PDU' imply the target waits for the entire Expected Data Transfer Length worth to be transferred? If so, the target may have to R2T for the solicited data! Should it R2T with 'correct' values, regardless of what the initiator sent? In this case it is possible that this clean-up action actually solicits all the required data, however, the command is still going to get a response with sense data indicating an abort. Is it possible to just reject the original command PDU when validity checking picks up one of these errors? Any Data-Out PDUs in the pipeline which belong to this rejected command can be silently discarded by the target. What am I missing? Thoughts? Ken Sandars ksandars@eurologic.com Eurologic Systems +44 117 930 9616 From owner-ips@ece.cmu.edu Wed Oct 31 14:14: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 OAA28368 for ; Wed, 31 Oct 2001 14:14:08 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VIHB615603 for ips-outgoing; Wed, 31 Oct 2001 13:17:11 -0500 (EST) 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 f9VIH9l15594 for ; Wed, 31 Oct 2001 13:17:09 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel1.hp.com (Postfix) with ESMTP id B3F5D95E; Wed, 31 Oct 2001 13:17:06 -0500 (EST) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id KAA10441; Wed, 31 Oct 2001 10:18:32 -0800 (PST) Message-ID: <001601c16238$3e679170$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "John Hufferd" Cc: References: Subject: Re: iSCSI: proposal to solve the ISID issues Date: Wed, 31 Oct 2001 10:17:04 -0800 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 John, You make it sound like I am arguing for an Admin interface - which I already said I am not (two times now). At this point, I would stop reiterating and wait for other interested individuals to chime in since you seem to be the only one who has an issue with it so far. Perhaps David can call a consensus when appropriate. Regards. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "John Hufferd" To: "Mallikarjun C." Cc: Sent: Wednesday, October 31, 2001 12:39 AM Subject: Re: iSCSI: proposal to solve the ISID issues > > Mallikarjun, > I think you are not making things clearer. > > We have said that the new Extended ISID can be determined independent of > any other outside interference. Period!!! And that includes multiple > Sessions from the same Manufactures HBAs or Set of HBAs. By definition if > a different vendor's HBA is placed in the NODE, that vendor's ID should be > part of its Extended ISID, and a new session can be created independent of > the other ones. And there maybe NO Admin interface, yet it still works! > > Even if a HBA is supported by a Device Driver that is not owned by the HBA > manufacture, it does not matter, since there should be a vendor ID for the > vendor that IS creating the Device Driver. NO one is saying where the > Vendor ID comes from. Hence still no problem and still no Admin Interface. > > So if you want an outside interference, it should NOT be a "must". > > If SNIA or anyone else wants to come up with a API, wonderful for them. It > is still not a must. > > If the SNIA group wants to pick a common value for the Vendor ID in the > Extended ISID they can do that. Still no problem and no Admin Interface. > This picking of a common value was part of the proposal. But that is not > what I call an API. > > Therefore, since the original issue I stated was -- I did not like your use > of the word "must", I think that point is still valid, "must" is not > approprate. > > > . > . > . > 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 > > > "Mallikarjun C." @ece.cmu.edu on 10/30/2001 05:23:35 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: John Hufferd/San Jose/IBM@IBMUS > cc: > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > John, > > >This is an > > Implementation decision! > > I have been trying to point out that it is *not* an implementation decision > *whether* to require ISID-configurability (Note below). OTOH, *how* > to configure the ISIDs is an implementation decision (as Jim pointed out > earlier), so also the decision of *if* it should be made a public API. > > Note: And I say this based on three factors - > - multiple NICs in the Node sharing the same Node Name > - stated objective of allowing multiple sessions between a given > initiator > node and a target portal group. > - ISID RULE, which forbids parallel nexus > > As a final note, Jim alluded to the possibility of "this naming authority > can > be elevated to the (SNIA-defined) coordinating entity or even the OS > vendor" > in future. That possibility requires external ISID-configurability as > well, > AND requires the API to be public. > > I see that Jim and Julian had already appreciated where I am coming from. > I hope I did a better job of convincing you this time..... > -- > Mallikarjun > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > Hewlett-Packard MS 5668 > Roseville CA 95747 > ----- Original Message ----- > From: "John Hufferd" > To: > Cc: "Jim Hafner" ; > Sent: Tuesday, October 30, 2001 1:48 PM > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > I do not like the word must even if it is in lower case. This is an > > Implementation decision! and many/most will not need Admin help. > > If you were to say "Should allow for configuration and coordination of > > ISIDs, by the iSCSI/HBA Driver,to allow for configuration and > coordination > > of ISIDs for...." I could go along with that. How that driver gets the > > information is its business. > > > > > > > > > > > > . > > . > > . > > 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 > > > > > > "Mallikarjun C." @ece.cmu.edu on 10/30/2001 11:53:20 AM > > > > Please respond to cbm@rose.hp.com > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > > > Jim, > > > > I am in broad agreement with you on your suggestion, > > and I agree that the ISID-configurability is a derivative > > requirement - but my argument is that it's nevertheless > > a crucial one to warrant making it explicit, but I can > > live with the proposed compromise of making it a NOTE. > > > > Some comments - > > > > >There is a requirement > > > that vendor NICs (managed by the same vendor driver) be configurable in > > > their ISIDs. > > > > I am kind of perplexed on this underlying assumption that > > a vendor NICs are "managed by the same vendor driver". As > > you know, this is not always true. IMHO, regardless of > > vendor and driver affiliations, an iSCSI initiator NIC MUST > > have external ISID-configurability - that's a design constraint > > on a NIC vendor (from the ISID rule)! [ Note that I am NOT > > suggesting that the API be "public", it's upto the NIC vendor > > on allowing third-party drivers - and I believe most would. ] > > > > With that, I would suggest the following wordsmithing, but > > I will not press it any further... > > > > NOTE: For correct behavior (in particular with respect to the ISID > > rule), a > > vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must > > allow > > for configuration and coordination of ISIDs for all sessions managed > > by > > multiple instances of that hardware within a given iSCSI Node. Such > > configuration might be either static (e.g., partitioned across all the > > NICs > > at initialization) or dynamic (e.g., on-line allocator). > > > > I hope the suggested wording (or something close to it) on the > > Node name would make its way in. > > > > Finally, thanks for so patiently driving this issue! > > -- > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > > > Jim Hafner wrote: > > > > > > John and Mallikarjun, > > > > > > I appreciate where Mallikarjun wants to go here. There is a > requirement > > > that vendor NICs (managed by the same vendor driver) be configurable in > > > their ISIDs. However, that requirement is more a derivative conclusion > > of > > > the rules (for a good and correct implementation) than it is a protocol > > > requirement. A vendor that doesn't do this only steps on his own toes > > when > > > more than one of his cards is in a system! > > > > > > Perhaps we compromise and make this a big NOTE: > > > > > > NOTE: For correct behavior (in particular with respect to the ISID > rule), > > a > > > vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must > > provide > > > either driver software or external and public APIs to allow for > > > configuration and coordination of ISIDs for all sessions managed by > > > multiple instances of that hardware within a given iSCSI Node. Such > > > configuration might be either static (e.g., partitioned across all the > > NICs > > > at initialization) or dynamic (e.g., on-line allocator). > > > > > > We can make the iSCSI Node Name a stronger requirement (that is, > outside > > of > > > a NOTE). > > > > > > Does that help? > > > > > > Jim Hafner > > > > > > John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 10/29/2001 06:47:31 pm > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: cbm@rose.hp.com > > > cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > I have no problem with the Must have a way to have the Node name set. > > > However, I do not grasp the problem you state here: > > > > > > "I don't believe the type of the ISID matters, nor does > > > the NIC capability (coordinating vs not). If two initiator > > > NICs share the same node name, they better not re-use the > > > same ISID to a given target portal group. I was trying > > > to capture the consequences of this reality." > > > > > > If the ISID includes the Vendor ID, I do not see the problem, unless > the > > > vendor can not assign the rest of the ISID. And I would say that it is > > the > > > vendors problem to work out. If you are saying that with NICs (not > HBAs) > > > that the SW Drivers will have a problem coming up with the ISID, I do > not > > > understand that either since most software is built by a Vendor, and if > > not > > > the Random type should work. > > > > > > Now in case you are saying something about the creation of a second > > Session > > > from the Initiator, which is to access the same Target Node. Then by > > > definition, the ISID must be unique. (and it will probably need a Wedge > > > Driver to operate correctly). I would think that a vendor should be > able > > > to come up with a unique qualifier for the session since they have 64K > > > numbers to chose from. Remember the vendor only needs to coordinate > the > > > lower 2 bytes of the new ISID, with itself. So if they can not do > that, > > > ... Oh well ... > > > > > > Are we on the same page yet? > > > > > > . > > > . > > > . > > > 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 > > > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > > 06:35:55 > > > PM > > > > > > Please respond to cbm@rose.hp.com > > > > > > Sent by: cbm@core.rose.hp.com > > > > > > To: John Hufferd/San Jose/IBM@IBMUS > > > cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > John, > > > > > > I take it that you don't have an issue with the > > > Node Name part of the wording. > > > > > > I thought I answered your question by saying - > > > > > > "My point though is that by banning a duplicate nexus (that an > > > inadvertently re-used ISID allows), we are making the ISID > > > (dynamic/static) distribution an imminent hard requirement > > > for all NICs in a given iSCSI initiator Node" > > > > > > The unspoken assumption above is that we would want to > > > allow multiple sessions between an initiator node and > > > a target portal group. > > > > > > I don't believe the type of the ISID matters, nor does > > > the NIC capability (coordinating vs not). If two initiator > > > NICs share the same node name, they better not re-use the > > > same ISID to a given target portal group. I was trying > > > to capture the consequences of this reality. > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > MS 5668 Hewlett-Packard, Roseville. > > > cbm@rose.hp.com > > > > > > John Hufferd wrote: > > > > > > > > Mallikarjun, > > > > I do not understand the purpose for your proposed wordage > > > > > > > > "All iSCSIinitiator hardware implementations MUST in addition also > > > support > > > > the operational ISID values to be (either statically or dynamically) > > > > externally configurable." > > > > > > > > Why is this so important that it is a MUST. The purpose of the > > proposal > > > is > > > > to eliminate the need for the above. At most it should only apply to > > the > > > > vendors (Probably Software and at Universities and IT shops) that use > > the > > > > RANDOM ISID type code. > > > > > > > > I do not see the need elsewhere. At most it could be "MAY". > > > > > > > > . > > > > . > > > > . > > > > 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 > > > > > > > > "Mallikarjun C." @ece.cmu.edu on 10/29/2001 05:24:20 > > PM > > > > > > > > Please respond to cbm@rose.hp.com > > > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > > > cc: ips@ece.cmu.edu > > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > > > Jim, > > > > > > > > Thanks for the quick response. > > > > > > > > As much as I would like to avoid consuming more bandwidth > > > > on this topic, let me make one last strawman for wording below. > > > > > > > > > What words do you suggest? > > > > ... > > > > > And a lot depends on how > > > > > functional the NICs are: (a) just network nics, (b) protocol nics, > > but > > > > not > > > > > session coordinating nics (c) full session coordination nics (with > > > driver > > > > > assist) (d) fully autonomous session nics. How do we make a > > > requirement > > > > > that fits all the cases correctly? > > > > > > > > I have been implying iSCSI NICs in all my postings so far - > > > > sorry, may be that wasn't very clear. "iSCSI Node name" comment > > > > obviously wasn't targeted at simple network NICs. So clearly (a) > > > > is out of discussion. But you are right - I wasn't very precise. > > > > Here's a strawman - > > > > > > > > All iSCSI hardware implementations (as in NICs) MUST allow > > > > the iSCSI Node Name to be externally configurable. All iSCSI > > > > initiator hardware implementations MUST in addition also > > > > support the the operational ISID values to be (either statically > > > > or dynamically) externally configurable. > > > > > > > > > Making them configurable (at > > > > > initialization time, e.g., as a range of values) or making them > > dynamic > > > > > (the driver generates them on demand) both fit the mold. So, I > don't > > > > think > > > > > this one is a hard requirement. > > > > > > > > I agree that my earlier "range" wording was too constraining. > > > > My point though is that by banning a duplicate nexus (that an > > > > inadvertently re-used ISID allows), we are making the ISID > > > > (dynamic/static) distribution an imminent hard requirement > > > > for all NICs in a given iSCSI initiator Node - except it is > > > > not sufficiently explicit. Please consider the above proposed > > > > wording. > > > > > > > > > Well, I don't think so. If each vendor implements "conservative > > reuse" > > > > > within their own ISID namespace on their own NICs, then you get > this > > > > > property system wide. > > > > > > > > You are right, I guess I briefly overlooked the fact that ISID > > > > includes the vendor identifier within, per the new proposal. > > > > > > > > I am personally okay with making "conservative reuse" a > > > > SHOULD. > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions Organization > > > > MS 5668 Hewlett-Packard, Roseville. > > > > cbm@rose.hp.com > > > > > > > > Jim Hafner wrote: > > > > > > > > > > Mallikarjun, > > > > > > > > > > Comments in line below > > > > > > > > > > Jim Hafner > > > > > > > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > > > > 12:17:49 > > > > > pm > > > > > > > > > > Please respond to cbm@rose.hp.com > > > > > > > > > > Sent by: cbm@core.rose.hp.com > > > > > > > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > > > > cc: ips@ece.cmu.edu > > > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > > > > > Jim, > > > > > > > > > > Thanks for the excellent summary. Some questions/comments - > > > > > > > > > > - I assume that the NICs must enable the configuration of > > > > > iSCSI Node name even in this proposal. If it is so, please > > > > > call this out as a hard requirement in the main modelling > > > > > discussion. > > > > > > > > > > > > > > > This requirement doesn't change from before (but how it gets > written > > > into > > > > > the spec may differ -- and we've had this discussion before). If a > > > > vendor > > > > > doesn't allow configuration of his NIC's iSCSI Node name, then his > > NICs > > > > > will be acting as their own iSCSI Node (that is, not representing > the > > > > > system they live in). One can argue that this is a legitimate > > > > > implementation (just as writing user-level code that uses its own > > iSCSI > > > > > Node name). So a "hard requirement" may be a bit too strong. > > However, > > > I > > > > > will go with the will of the group on this point. > > > > > > > > > > What words do you suggest? > > > > > > > > > > - In the case of multiple NICs from the same vendor operating > > > > > in an end node, it appears to me that the proposal implicitly > > > > > assumes an ISID-range to be configurable among those NICs > > > > > (perhaps in vendor-unique ways, which is always what I expected). > > > > > If this is a correct inference, there is again a hard > > > > > requirement on the NICs to make the ISID range configurable. > > > > > Please comment on any subtle qualitative change from the > > > > > earlier situation that I may be missing. > > > > > > > > > > > > > > > Well, the point is that the vendor can manage his own namespace for > > his > > > > > NICs anyway he/she/it wants to. Making them configurable (at > > > > > initialization time, e.g., as a range of values) or making them > > dynamic > > > > > (the driver generates them on demand) both fit the mold. So, I > don't > > > > > think > > > > > this one is a hard requirement (though that is probably how most > > > vendors > > > > > will implement their NICs). In effect, the proposal gives vendors > > more > > > > > flexibility in their own space, without causing heterogenous > > > > > interoperability problems within the host. And a lot depends on > how > > > > > functional the NICs are: (a) just network nics, (b) protocol nics, > > but > > > > not > > > > > session coordinating nics (c) full session coordination nics (with > > > driver > > > > > assist) (d) fully autonomous session nics. How do we make a > > > requirement > > > > > that fits all the cases correctly? You clearly have in mind a > > specific > > > > > level of implementation within the NICs, but that may not be > > > everybody's > > > > > model. > > > > > > > > > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > > > particularly low-end that don't use reservations, can function > more > > > or > > > > > > less OK without it. > > > > > > > > > > It seems we're attempting to set ourselves up for future in > > > > > discussing the above requirement. Some questions - > > > > > - It appears to me that the "conservative reuse" can not > > > > > be enforced for initiators hosting NICs from different > > > > > vendors (since the proposal allows ISID namespaces to > > > > > be totally non-overlapping between non-homogenous NICs). > > > > > Is this a fair assessment? > > > > > > > > > > Well, I don't think so. If each vendor implements "conservative > > reuse" > > > > > within their own ISID namespace on their own NICs, then you get > this > > > > > property system wide. As before, by owning their own piece of the > > ISID > > > > > namespace, they can implement what they want. So, you may have a > > > > situation > > > > > where some of your installed nics have this property and some > don't. > > > > > You'll find out (if your environment really needs conservative > reuse) > > > > that > > > > > you haven't got it, and it becomes a marketing/purchase spec > > > requirement. > > > > > > > > > > - Do you see a particular disadvantage for low-end systems > > > > > if it's mandated (aside from the fact that they may be > able > > > > > to live without it)? > > > > > > > > > > No, but I don't see any way to really enforce it (or even really > test > > > > it). > > > > > It's not a requirement of the protocol, per se. > > > > > > > > > > - Do you see any corner cases not being met (for future) > > > > > if we don't make it a MUST (since you said "more or less > > > OK")? > > > > > > > > > > No, I can't see that far into the future! :-{). One reason I'm > being > > > > cagey > > > > > here is that I'm finding it difficult to find the right words to > > > specify > > > > > this as a hard requirement (but I'm no technical writer either!). > > > > > > > > > > > > > > > Regards. > > > > > -- > > > > > Mallikarjun > > > > > > > > > > Mallikarjun Chadalapaka > > > > > Networked Storage Architecture > > > > > Network Storage Solutions Organization > > > > > MS 5668 Hewlett-Packard, Roseville. > > > > > cbm@rose.hp.com > > > > > > > > > > Jim Hafner wrote: > > > > > > > > > > > > Folks, (David Black in particular). > > > > > > > > > > > > Apologies for the long note, but the issue is complicated. > > > > > > > > > > > > The NDTeam have a proposal to resolve the concerns surrounding > use > > of > > > > > > ISIDs as essential components (along with iSCSI Initiator Name) > of > > > > > > SCSI Initiator Portname. (This was rooted in private discussions > > > > > > between John Hufferd, Julian and myself -- and came about as a > > result > > > > > > of the lengthy (and boring) discussions mostly myself and David > > > > > > Black.) > > > > > > > > > > > > There are two somewhat orthogonal issues involved in this > > discussion: > > > > > > > > > > > > 1) How to coordinate ISIDs in the initiator to minimize the risk > of > > > > > > accidentally breaking the ISID RULE (no parallel nexus) when > > > > > > independent vendors co-exist in the same OS. > > > > > > > > > > > > 2) What ISID "reuse" rules should be specified to facilitate > > current > > > > > > and future (soon?) SCSI reservation semantics (and also internal > OS > > > > > > views of SCSI Initiator Ports). > > > > > > > > > > > > To address these two issues, we (NDT) propose the following: > > > > > > > > > > > > 1) Enlarge the ISID field in the Login Request and Response to > > 6bytes > > > > > > and structure it with a component that corresponds to a "naming > > > > > > authority" (essentially the vendor generating the ISID). So > > vendors > > > > > > each have a piece of the ISID namespace to work with their own > > > > > > components (HBAs, SW, etc). More details below. > > > > > > > > > > > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be > used > > > as > > > > > > conservatively as possible ("conservative reuse"). What this > means > > > is > > > > > > that a given ISID should be reused for as many sessions (across > > > > > > multiple target portal groups) as possible (but never to the same > > > > > > target portal group twice -- that's the ISID RULE). > > > > > > > > > > > > NOTES and ADVANTAGES: > > > > > > > > > > > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > > > > > > effect, at the vendor-level, this provides a "partitioning" of > that > > > > > > namespace. > > > > > > > > > > > > (1-b) We don't need to specify an OS infrastructure requirement > for > > > > > > configuration of ISIDs -- each vendor can do it any way it > chooses > > > > > > (within its naming authority). > > > > > > > > > > > > (1-c) Breaking of the ISID RULE will only occur if a vendor > messes > > up > > > > > > its own implementation. > > > > > > > > > > > > (1-d) This is not fundamentally different from David Black's > > > > > > suggestion for a "key"; it just (a) defines it precisely and (b) > > > > > > embeds it in an already defined (but enlarged) field. > > > > > > > > > > > > (1-e) Looking towards the future, as common ISID coordination > > > > > > mechanisms are implemented between vendors (say, SNIA banding > > > together > > > > > > to define a precise API), this "naming authority" can be elevated > > to > > > > > > the coordinating entity or even the OS vendor. > > > > > > > > > > > > (1-f) ISIDs have no global uniqueness property. They need only > be > > > > > > unique between a named iSCSI initiator and iSCSI target portal > > group. > > > > > > That means that a vendor implementation can use the same > algorithm > > to > > > > > > generate ISIDs (under its naming authority) in every machine > (OS). > > > > > > > > > > > > (2-a) If a SCSI target (or logical unit) is holding state (say > > > > > > persistent reservation) for a SCSI Initiator Port (named by iSCSI > > > Name > > > > > > and ISID), and the associated nexus/session is dropped for some > > > > > > reason, "reuse" by that initiator of that ISID will restore to > the > > > > > > resulting new session that state (with no other action on the > part > > of > > > > > > the upper SCSI layers). > > > > > > > > > > > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > > > > > > different SCSI Target Ports (iSCSI Target portal groups), will > > enable > > > > > > the SCSI target/logical unit to recognize a common SCSI Initiator > > > Port > > > > > > for those two paths. This facilitates future changes to SCSI > > > > > > reservations (at least). > > > > > > > > > > > > (2-c) An initiator driver implementated with "conservative reuse" > > can > > > > > > present to the OS a stable and fairly static view of the SCSI > > > > > > Initiator Ports (one for each ISID). Current OS driver stacks > > > > > > (including current wedge drivers) that are built on the > presumption > > > of > > > > > > such a stable view, will not need modification to handle the more > > > > > > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the > existence > > > of > > > > > > a SCSI Initiator Port presented to the OS does not *require* that > > > this > > > > > > port discover all possible targets; what the initiator builds > > > sessions > > > > > > to using a specific ISID will determine what is presented to the > OS > > > as > > > > > > "devices" and LUs visible to that SCSI Initiator Port (could be > > none > > > > > > if that ISID is never actually used!).] > > > > > > > > > > > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI > > Initiator > > > > > > Port is as simple as configuring another ISID! > > > > > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > > > particularly low-end that don't use reservations, can function > more > > > or > > > > > > less OK without it. This is an open question. > > > > > > > > > > > > DETAILS: > > > > > > > > > > > > 1) ISID Structure: > > > > > > The 6byte ISID structure would be split into three parts: > > > > > > "type" field (1byte) -- identifies the format of the naming > > > > > > authority field > > > > > > "naming authority" field (3bytes) -- identifies the vendor (or > > > > > > group of vendors) generating this ISID > > > > > > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > > > > > > > > > > > The type field takes on three defined values with all other > values > > > > > > reserved: > > > > > > Type naming authority format > > > > > > 00h IEEE OUI > > > > > > 01h IANA Enterprise Number (EN) > > > > > > 02h "Random" > > > > > > > > > > > > The first types two provide a mechanism to uniquely (world wide) > > > > > > identify the naming authority. A vendor with one or more OUIs > and > > > > > > possibly also Enterprise number MUST use at least one of these > > > numbers > > > > > > when it generates ISIDs. > > > > > > > > > > > > The "Random" type is for the case where the ISID generator (SW or > > HW) > > > > > > is provided by an entity that has no OUI or EN. This includes, > for > > > > > > example, > > > > > > -- a user-written program that builds sessions (and has access to > > the > > > > > > system level iSCSI Name) > > > > > > -- a university or other organization providing the component > > > > > > -- a testing tool > > > > > > > > > > > > For the "Random" type, the naming authority field should be a > > random > > > > > > or pseudo-random number. (See below on how this affects > > "conservative > > > > > > reuse"). > > > > > > > > > > > > [Note: the "type" field needn't be this big, but NDT felt that > (a) > > > > > > 2bits was insufficient for the future, (b) the "type" field > should > > be > > > > > > first, and (c) the "naming authority" field should be > > byte-aligned.] > > > > > > > > > > > > 2) Conservative Reuse > > > > > > > > > > > > The "conservative reuse" principle of this proposal just says > that > > > > > > SCSI Initiator Portnames should be viewed as static things (as > much > > > as > > > > > > possible) and reused (when feasible) to give the most stable > > > > > > presentation of SCSI Initiator Ports to both the OS above and to > > SCSU > > > > > > targets across the wire. > > > > > > > > > > > > Whereas the current draft says "The ISID RULE does not preclude > the > > > > > > use of the same ISID to different Target portal groups", the > > > > > > "conservative reuse" requirement would say that such reuse (using > > the > > > > > > same ISID to many target portal groups) is a SHOULD (or is that > > > > > > MUST?). So, in one implementation, each iSCSI Initiator Portal > > group > > > > > > would get configured with iSCSI Name, and a (small) set of ISIDs. > > > The > > > > > > portal group might take this set of ISIDs as an ordered list. > The > > > > > > first session to a Target portal group would use the first ISID, > > the > > > > > > second to the *same* target portal group would use the second in > > the > > > > > > list, etc. The number of ISIDs would then define a configuration > > > > > > parameter that can be interpreted as the maximum number of > sessions > > > > > > that can be built to a given target portal group. > > > > > > > > > > > > To facilitate "conservative reuse", the "qualifier" field of a > set > > of > > > > > > ISIDs SHOULD be generated using either a repeatable algorithm > > > > > > (non-random or pseudo-random but based on a fixed seed) or any > > > > > > algorithm and stored in a persistent location (e.g., registry or > > /etc > > > > > > file). > > > > > > > > > > > > For the "Random" type, "conservative reuse" may not be an issue > > (say, > > > > > > user application that doesn't care about reservations, etc.). > When > > > it > > > > > > is, the "naming authority" field SHOULD also be generated by a > > > > > > mechanism similar to that for the "qualifier" field as specified > > > above > > > > > > (e.g., defined in the SW at compilation time.) > > > > > > > > > > > > DOCUMENTATING CHANGES: > > > > > > > > > > > > The iscsi drafts would need the following minor changes to > support > > > > > > this proposal: > > > > > > > > > > > > NDT doc > > > > > > (a) define the structure of the ISID field (as described above) > > > > > > (b) add some notes about implementation in the presense of > > > > > > "conservative reuse" (e.g., that ISID should be configured once, > > say > > > > > > at install time, then reused on subsequent reboots, even for > > "Random" > > > > > > type). > > > > > > > > > > > > iSCSI MAIN doc: > > > > > > (a) move the CID field in Login Request to another reserved > field. > > > > > > (b) expand the ISID field in Login Request and Response to > > encompass > > > > > > the previous 4 bytes. > > > > > > (c) add a sentence where the ISID field is defined indicating > that > > > > > > this field is a structured value, showing the structure (as > above) > > > and > > > > > > point to the NDT document. > > > > > > (d) add some text to "Note to Implementors" on "conservative > > reuse". > > > > > > > > > > > > Comments? > > > > > > > > > > > > Jim Hafner > > > > > > -- > > > 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 Oct 31 14:15: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 OAA28436 for ; Wed, 31 Oct 2001 14:15:24 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VIBqc15127 for ips-outgoing; Wed, 31 Oct 2001 13:11:52 -0500 (EST) 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 f9VIBkl15111 for ; Wed, 31 Oct 2001 13:11:46 -0500 (EST) 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 NAA23004 for ; Wed, 31 Oct 2001 13:09:12 -0500 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9VIBev87880 for ; Wed, 31 Oct 2001 11:11:40 -0700 Importance: Normal Subject: Re: iSCSI: proposal to solve the ISID issues To: "John Hufferd" Cc: ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 31 Oct 2001 10:11:37 -0800 Message-ID: X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/31/2001 10:11:40 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, I think we're talking at cross purposes here and I think it all comes down to what constitutes "external". The difference is not so much "external" as "public" vs. "private". John, I think you're reading "public" and Mallikarjun is thinking either public or private (but "must" because that's the only way a vendor can implement even private APIs). However, we're all leaving out one other case (see below). I think we can find words that are broad enough to cover all cases and still be "must". Within the scope of Mallikarjun's "iSCSI NICs" (and not the broader possible implementations using other types of components and combinations of SW and HW), I see roughly three cases: Case 1: vendor builds HBA and exports a public API, then lets others write the driver to interface to the API (or it writes its own). Case 2: vendor builds HBA and exports a private API, then writes his own driver to interface to the API. Case 3: vendor builds HBA and exports no API, but still fits the rules. E.g. the HBA fills in the "free" two bytes of the ISID based on serial number of the HBA itself, thus providing really static configuration (independent of SW). With a broad enough brush, each of these fits in the language of the NOTE (even with a "must"). I've tweaked the words a little below, in hopes of covering this a bit better: NOTE: For correct behavior (in particular with respect to the ISID rule), a vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must allow for configuration and coordination of ISIDs for all sessions managed by multiple instances of that hardware within a given iSCSI Node. Such configuration might be either permanently preassigned at the factory (in a necessarily globally unique way), statically assigned (e.g., partitioned across all the NICs at initialization in a locally unique way) or dynamically assigned (e.g., on-line allocator, also in a locally unique way). In the latter two cases, the configuration may be via public APIs (perhaps driven by an independent vendor's SW, e.g., the OS vendor) or via private APIs driven by the vendor's own SW. Does this make everyone happy? Jim Hafner John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 10/31/2001 12:39:57 am Sent by: owner-ips@ece.cmu.edu To: "Mallikarjun C." cc: Subject: Re: iSCSI: proposal to solve the ISID issues Mallikarjun, I think you are not making things clearer. We have said that the new Extended ISID can be determined independent of any other outside interference. Period!!! And that includes multiple Sessions from the same Manufactures HBAs or Set of HBAs. By definition if a different vendor's HBA is placed in the NODE, that vendor's ID should be part of its Extended ISID, and a new session can be created independent of the other ones. And there maybe NO Admin interface, yet it still works! Even if a HBA is supported by a Device Driver that is not owned by the HBA manufacture, it does not matter, since there should be a vendor ID for the vendor that IS creating the Device Driver. NO one is saying where the Vendor ID comes from. Hence still no problem and still no Admin Interface. So if you want an outside interference, it should NOT be a "must". If SNIA or anyone else wants to come up with a API, wonderful for them. It is still not a must. If the SNIA group wants to pick a common value for the Vendor ID in the Extended ISID they can do that. Still no problem and no Admin Interface. This picking of a common value was part of the proposal. But that is not what I call an API. Therefore, since the original issue I stated was -- I did not like your use of the word "must", I think that point is still valid, "must" is not approprate. . . . 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 "Mallikarjun C." @ece.cmu.edu on 10/30/2001 05:23:35 PM Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: Subject: Re: iSCSI: proposal to solve the ISID issues John, >This is an > Implementation decision! I have been trying to point out that it is *not* an implementation decision *whether* to require ISID-configurability (Note below). OTOH, *how* to configure the ISIDs is an implementation decision (as Jim pointed out earlier), so also the decision of *if* it should be made a public API. Note: And I say this based on three factors - - multiple NICs in the Node sharing the same Node Name - stated objective of allowing multiple sessions between a given initiator node and a target portal group. - ISID RULE, which forbids parallel nexus As a final note, Jim alluded to the possibility of "this naming authority can be elevated to the (SNIA-defined) coordinating entity or even the OS vendor" in future. That possibility requires external ISID-configurability as well, AND requires the API to be public. I see that Jim and Julian had already appreciated where I am coming from. I hope I did a better job of convincing you this time..... -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "John Hufferd" To: Cc: "Jim Hafner" ; Sent: Tuesday, October 30, 2001 1:48 PM Subject: Re: iSCSI: proposal to solve the ISID issues > > I do not like the word must even if it is in lower case. This is an > Implementation decision! and many/most will not need Admin help. > If you were to say "Should allow for configuration and coordination of > ISIDs, by the iSCSI/HBA Driver,to allow for configuration and coordination > of ISIDs for...." I could go along with that. How that driver gets the > information is its business. > > > > > > . > . > . > 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 > > > "Mallikarjun C." @ece.cmu.edu on 10/30/2001 11:53:20 AM > > Please respond to cbm@rose.hp.com > > Sent by: owner-ips@ece.cmu.edu > > > To: Jim Hafner/Almaden/IBM@IBMUS > cc: ips@ece.cmu.edu > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > Jim, > > I am in broad agreement with you on your suggestion, > and I agree that the ISID-configurability is a derivative > requirement - but my argument is that it's nevertheless > a crucial one to warrant making it explicit, but I can > live with the proposed compromise of making it a NOTE. > > Some comments - > > >There is a requirement > > that vendor NICs (managed by the same vendor driver) be configurable in > > their ISIDs. > > I am kind of perplexed on this underlying assumption that > a vendor NICs are "managed by the same vendor driver". As > you know, this is not always true. IMHO, regardless of > vendor and driver affiliations, an iSCSI initiator NIC MUST > have external ISID-configurability - that's a design constraint > on a NIC vendor (from the ISID rule)! [ Note that I am NOT > suggesting that the API be "public", it's upto the NIC vendor > on allowing third-party drivers - and I believe most would. ] > > With that, I would suggest the following wordsmithing, but > I will not press it any further... > > NOTE: For correct behavior (in particular with respect to the ISID > rule), a > vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must > allow > for configuration and coordination of ISIDs for all sessions managed > by > multiple instances of that hardware within a given iSCSI Node. Such > configuration might be either static (e.g., partitioned across all the > NICs > at initialization) or dynamic (e.g., on-line allocator). > > I hope the suggested wording (or something close to it) on the > Node name would make its way in. > > Finally, thanks for so patiently driving this issue! > -- > Mallikarjun > > > Mallikarjun Chadalapaka > Networked Storage Architecture > Network Storage Solutions Organization > MS 5668 Hewlett-Packard, Roseville. > cbm@rose.hp.com > > > Jim Hafner wrote: > > > > John and Mallikarjun, > > > > I appreciate where Mallikarjun wants to go here. There is a requirement > > that vendor NICs (managed by the same vendor driver) be configurable in > > their ISIDs. However, that requirement is more a derivative conclusion > of > > the rules (for a good and correct implementation) than it is a protocol > > requirement. A vendor that doesn't do this only steps on his own toes > when > > more than one of his cards is in a system! > > > > Perhaps we compromise and make this a big NOTE: > > > > NOTE: For correct behavior (in particular with respect to the ISID rule), > a > > vendor of iSCSI hardware implementations (e.g., NICs or HBAs) must > provide > > either driver software or external and public APIs to allow for > > configuration and coordination of ISIDs for all sessions managed by > > multiple instances of that hardware within a given iSCSI Node. Such > > configuration might be either static (e.g., partitioned across all the > NICs > > at initialization) or dynamic (e.g., on-line allocator). > > > > We can make the iSCSI Node Name a stronger requirement (that is, outside > of > > a NOTE). > > > > Does that help? > > > > Jim Hafner > > > > John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 10/29/2001 06:47:31 pm > > > > Sent by: owner-ips@ece.cmu.edu > > > > To: cbm@rose.hp.com > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > I have no problem with the Must have a way to have the Node name set. > > However, I do not grasp the problem you state here: > > > > "I don't believe the type of the ISID matters, nor does > > the NIC capability (coordinating vs not). If two initiator > > NICs share the same node name, they better not re-use the > > same ISID to a given target portal group. I was trying > > to capture the consequences of this reality." > > > > If the ISID includes the Vendor ID, I do not see the problem, unless the > > vendor can not assign the rest of the ISID. And I would say that it is > the > > vendors problem to work out. If you are saying that with NICs (not HBAs) > > that the SW Drivers will have a problem coming up with the ISID, I do not > > understand that either since most software is built by a Vendor, and if > not > > the Random type should work. > > > > Now in case you are saying something about the creation of a second > Session > > from the Initiator, which is to access the same Target Node. Then by > > definition, the ISID must be unique. (and it will probably need a Wedge > > Driver to operate correctly). I would think that a vendor should be able > > to come up with a unique qualifier for the session since they have 64K > > numbers to chose from. Remember the vendor only needs to coordinate the > > lower 2 bytes of the new ISID, with itself. So if they can not do that, > > ... Oh well ... > > > > Are we on the same page yet? > > > > . > > . > > . > > 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 > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > 06:35:55 > > PM > > > > Please respond to cbm@rose.hp.com > > > > Sent by: cbm@core.rose.hp.com > > > > To: John Hufferd/San Jose/IBM@IBMUS > > cc: ips@ece.cmu.edu > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > John, > > > > I take it that you don't have an issue with the > > Node Name part of the wording. > > > > I thought I answered your question by saying - > > > > "My point though is that by banning a duplicate nexus (that an > > inadvertently re-used ISID allows), we are making the ISID > > (dynamic/static) distribution an imminent hard requirement > > for all NICs in a given iSCSI initiator Node" > > > > The unspoken assumption above is that we would want to > > allow multiple sessions between an initiator node and > > a target portal group. > > > > I don't believe the type of the ISID matters, nor does > > the NIC capability (coordinating vs not). If two initiator > > NICs share the same node name, they better not re-use the > > same ISID to a given target portal group. I was trying > > to capture the consequences of this reality. > > > > Regards. > > -- > > Mallikarjun > > > > Mallikarjun Chadalapaka > > Networked Storage Architecture > > Network Storage Solutions Organization > > MS 5668 Hewlett-Packard, Roseville. > > cbm@rose.hp.com > > > > John Hufferd wrote: > > > > > > Mallikarjun, > > > I do not understand the purpose for your proposed wordage > > > > > > "All iSCSIinitiator hardware implementations MUST in addition also > > support > > > the operational ISID values to be (either statically or dynamically) > > > externally configurable." > > > > > > Why is this so important that it is a MUST. The purpose of the > proposal > > is > > > to eliminate the need for the above. At most it should only apply to > the > > > vendors (Probably Software and at Universities and IT shops) that use > the > > > RANDOM ISID type code. > > > > > > I do not see the need elsewhere. At most it could be "MAY". > > > > > > . > > > . > > > . > > > 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 > > > > > > "Mallikarjun C." @ece.cmu.edu on 10/29/2001 05:24:20 > PM > > > > > > Please respond to cbm@rose.hp.com > > > > > > Sent by: owner-ips@ece.cmu.edu > > > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > > cc: ips@ece.cmu.edu > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > Jim, > > > > > > Thanks for the quick response. > > > > > > As much as I would like to avoid consuming more bandwidth > > > on this topic, let me make one last strawman for wording below. > > > > > > > What words do you suggest? > > > ... > > > > And a lot depends on how > > > > functional the NICs are: (a) just network nics, (b) protocol nics, > but > > > not > > > > session coordinating nics (c) full session coordination nics (with > > driver > > > > assist) (d) fully autonomous session nics. How do we make a > > requirement > > > > that fits all the cases correctly? > > > > > > I have been implying iSCSI NICs in all my postings so far - > > > sorry, may be that wasn't very clear. "iSCSI Node name" comment > > > obviously wasn't targeted at simple network NICs. So clearly (a) > > > is out of discussion. But you are right - I wasn't very precise. > > > Here's a strawman - > > > > > > All iSCSI hardware implementations (as in NICs) MUST allow > > > the iSCSI Node Name to be externally configurable. All iSCSI > > > initiator hardware implementations MUST in addition also > > > support the the operational ISID values to be (either statically > > > or dynamically) externally configurable. > > > > > > > Making them configurable (at > > > > initialization time, e.g., as a range of values) or making them > dynamic > > > > (the driver generates them on demand) both fit the mold. So, I don't > > > think > > > > this one is a hard requirement. > > > > > > I agree that my earlier "range" wording was too constraining. > > > My point though is that by banning a duplicate nexus (that an > > > inadvertently re-used ISID allows), we are making the ISID > > > (dynamic/static) distribution an imminent hard requirement > > > for all NICs in a given iSCSI initiator Node - except it is > > > not sufficiently explicit. Please consider the above proposed > > > wording. > > > > > > > Well, I don't think so. If each vendor implements "conservative > reuse" > > > > within their own ISID namespace on their own NICs, then you get this > > > > property system wide. > > > > > > You are right, I guess I briefly overlooked the fact that ISID > > > includes the vendor identifier within, per the new proposal. > > > > > > I am personally okay with making "conservative reuse" a > > > SHOULD. > > > > > > Regards. > > > -- > > > Mallikarjun > > > > > > Mallikarjun Chadalapaka > > > Networked Storage Architecture > > > Network Storage Solutions Organization > > > MS 5668 Hewlett-Packard, Roseville. > > > cbm@rose.hp.com > > > > > > Jim Hafner wrote: > > > > > > > > Mallikarjun, > > > > > > > > Comments in line below > > > > > > > > Jim Hafner > > > > > > > > "Mallikarjun C." @core.rose.hp.com on 10/29/2001 > > > 12:17:49 > > > > pm > > > > > > > > Please respond to cbm@rose.hp.com > > > > > > > > Sent by: cbm@core.rose.hp.com > > > > > > > > To: Jim Hafner/Almaden/IBM@IBMUS > > > > cc: ips@ece.cmu.edu > > > > Subject: Re: iSCSI: proposal to solve the ISID issues > > > > > > > > Jim, > > > > > > > > Thanks for the excellent summary. Some questions/comments - > > > > > > > > - I assume that the NICs must enable the configuration of > > > > iSCSI Node name even in this proposal. If it is so, please > > > > call this out as a hard requirement in the main modelling > > > > discussion. > > > > > > > > > > > > This requirement doesn't change from before (but how it gets written > > into > > > > the spec may differ -- and we've had this discussion before). If a > > > vendor > > > > doesn't allow configuration of his NIC's iSCSI Node name, then his > NICs > > > > will be acting as their own iSCSI Node (that is, not representing the > > > > system they live in). One can argue that this is a legitimate > > > > implementation (just as writing user-level code that uses its own > iSCSI > > > > Node name). So a "hard requirement" may be a bit too strong. > However, > > I > > > > will go with the will of the group on this point. > > > > > > > > What words do you suggest? > > > > > > > > - In the case of multiple NICs from the same vendor operating > > > > in an end node, it appears to me that the proposal implicitly > > > > assumes an ISID-range to be configurable among those NICs > > > > (perhaps in vendor-unique ways, which is always what I expected). > > > > If this is a correct inference, there is again a hard > > > > requirement on the NICs to make the ISID range configurable. > > > > Please comment on any subtle qualitative change from the > > > > earlier situation that I may be missing. > > > > > > > > > > > > Well, the point is that the vendor can manage his own namespace for > his > > > > NICs anyway he/she/it wants to. Making them configurable (at > > > > initialization time, e.g., as a range of values) or making them > dynamic > > > > (the driver generates them on demand) both fit the mold. So, I don't > > > think > > > > this one is a hard requirement (though that is probably how most > > vendors > > > > will implement their NICs). In effect, the proposal gives vendors > more > > > > flexibility in their own space, without causing heterogenous > > > > interoperability problems within the host. And a lot depends on how > > > > functional the NICs are: (a) just network nics, (b) protocol nics, > but > > > not > > > > session coordinating nics (c) full session coordination nics (with > > driver > > > > assist) (d) fully autonomous session nics. How do we make a > > requirement > > > > that fits all the cases correctly? You clearly have in mind a > specific > > > > level of implementation within the NICs, but that may not be > > everybody's > > > > model. > > > > > > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > > particularly low-end that don't use reservations, can function more > > or > > > > > less OK without it. > > > > > > > > It seems we're attempting to set ourselves up for future in > > > > discussing the above requirement. Some questions - > > > > - It appears to me that the "conservative reuse" can not > > > > be enforced for initiators hosting NICs from different > > > > vendors (since the proposal allows ISID namespaces to > > > > be totally non-overlapping between non-homogenous NICs). > > > > Is this a fair assessment? > > > > > > > > Well, I don't think so. If each vendor implements "conservative > reuse" > > > > within their own ISID namespace on their own NICs, then you get this > > > > property system wide. As before, by owning their own piece of the > ISID > > > > namespace, they can implement what they want. So, you may have a > > > situation > > > > where some of your installed nics have this property and some don't. > > > > You'll find out (if your environment really needs conservative reuse) > > > that > > > > you haven't got it, and it becomes a marketing/purchase spec > > requirement. > > > > > > > > - Do you see a particular disadvantage for low-end systems > > > > if it's mandated (aside from the fact that they may be able > > > > to live without it)? > > > > > > > > No, but I don't see any way to really enforce it (or even really test > > > it). > > > > It's not a requirement of the protocol, per se. > > > > > > > > - Do you see any corner cases not being met (for future) > > > > if we don't make it a MUST (since you said "more or less > > OK")? > > > > > > > > No, I can't see that far into the future! :-{). One reason I'm being > > > cagey > > > > here is that I'm finding it difficult to find the right words to > > specify > > > > this as a hard requirement (but I'm no technical writer either!). > > > > > > > > > > > > Regards. > > > > -- > > > > Mallikarjun > > > > > > > > Mallikarjun Chadalapaka > > > > Networked Storage Architecture > > > > Network Storage Solutions Organization > > > > MS 5668 Hewlett-Packard, Roseville. > > > > cbm@rose.hp.com > > > > > > > > Jim Hafner wrote: > > > > > > > > > > Folks, (David Black in particular). > > > > > > > > > > Apologies for the long note, but the issue is complicated. > > > > > > > > > > The NDTeam have a proposal to resolve the concerns surrounding use > of > > > > > ISIDs as essential components (along with iSCSI Initiator Name) of > > > > > SCSI Initiator Portname. (This was rooted in private discussions > > > > > between John Hufferd, Julian and myself -- and came about as a > result > > > > > of the lengthy (and boring) discussions mostly myself and David > > > > > Black.) > > > > > > > > > > There are two somewhat orthogonal issues involved in this > discussion: > > > > > > > > > > 1) How to coordinate ISIDs in the initiator to minimize the risk of > > > > > accidentally breaking the ISID RULE (no parallel nexus) when > > > > > independent vendors co-exist in the same OS. > > > > > > > > > > 2) What ISID "reuse" rules should be specified to facilitate > current > > > > > and future (soon?) SCSI reservation semantics (and also internal OS > > > > > views of SCSI Initiator Ports). > > > > > > > > > > To address these two issues, we (NDT) propose the following: > > > > > > > > > > 1) Enlarge the ISID field in the Login Request and Response to > 6bytes > > > > > and structure it with a component that corresponds to a "naming > > > > > authority" (essentially the vendor generating the ISID). So > vendors > > > > > each have a piece of the ISID namespace to work with their own > > > > > components (HBAs, SW, etc). More details below. > > > > > > > > > > 2) ISIDs (within the namespace of a given iSCSIName) SHOULD be used > > as > > > > > conservatively as possible ("conservative reuse"). What this means > > is > > > > > that a given ISID should be reused for as many sessions (across > > > > > multiple target portal groups) as possible (but never to the same > > > > > target portal group twice -- that's the ISID RULE). > > > > > > > > > > NOTES and ADVANTAGES: > > > > > > > > > > (1-a) Each vendor owns his own piece of the ISID namespace, so in > > > > > effect, at the vendor-level, this provides a "partitioning" of that > > > > > namespace. > > > > > > > > > > (1-b) We don't need to specify an OS infrastructure requirement for > > > > > configuration of ISIDs -- each vendor can do it any way it chooses > > > > > (within its naming authority). > > > > > > > > > > (1-c) Breaking of the ISID RULE will only occur if a vendor messes > up > > > > > its own implementation. > > > > > > > > > > (1-d) This is not fundamentally different from David Black's > > > > > suggestion for a "key"; it just (a) defines it precisely and (b) > > > > > embeds it in an already defined (but enlarged) field. > > > > > > > > > > (1-e) Looking towards the future, as common ISID coordination > > > > > mechanisms are implemented between vendors (say, SNIA banding > > together > > > > > to define a precise API), this "naming authority" can be elevated > to > > > > > the coordinating entity or even the OS vendor. > > > > > > > > > > (1-f) ISIDs have no global uniqueness property. They need only be > > > > > unique between a named iSCSI initiator and iSCSI target portal > group. > > > > > That means that a vendor implementation can use the same algorithm > to > > > > > generate ISIDs (under its naming authority) in every machine (OS). > > > > > > > > > > (2-a) If a SCSI target (or logical unit) is holding state (say > > > > > persistent reservation) for a SCSI Initiator Port (named by iSCSI > > Name > > > > > and ISID), and the associated nexus/session is dropped for some > > > > > reason, "reuse" by that initiator of that ISID will restore to the > > > > > resulting new session that state (with no other action on the part > of > > > > > the upper SCSI layers). > > > > > > > > > > (2-b) "Reuse" of an ISID on different sessions to (necessarily) > > > > > different SCSI Target Ports (iSCSI Target portal groups), will > enable > > > > > the SCSI target/logical unit to recognize a common SCSI Initiator > > Port > > > > > for those two paths. This facilitates future changes to SCSI > > > > > reservations (at least). > > > > > > > > > > (2-c) An initiator driver implementated with "conservative reuse" > can > > > > > present to the OS a stable and fairly static view of the SCSI > > > > > Initiator Ports (one for each ISID). Current OS driver stacks > > > > > (including current wedge drivers) that are built on the presumption > > of > > > > > such a stable view, will not need modification to handle the more > > > > > dynamic nature of iSCSI's SCSI Initiator Port. [Note: the existence > > of > > > > > a SCSI Initiator Port presented to the OS does not *require* that > > this > > > > > port discover all possible targets; what the initiator builds > > sessions > > > > > to using a specific ISID will determine what is presented to the OS > > as > > > > > "devices" and LUs visible to that SCSI Initiator Port (could be > none > > > > > if that ISID is never actually used!).] > > > > > > > > > > (2-d) (Related to (2-c)): Adding a new (pseudo-static) SCSI > Initiator > > > > > Port is as simple as configuring another ISID! > > > > > > > > > > (2-e) Its debatable whether "conservative reuse" is a MUST or a > > > > > SHOULD. My personal opinion is "SHOULD", because many systems, > > > > > particularly low-end that don't use reservations, can function more > > or > > > > > less OK without it. This is an open question. > > > > > > > > > > DETAILS: > > > > > > > > > > 1) ISID Structure: > > > > > The 6byte ISID structure would be split into three parts: > > > > > "type" field (1byte) -- identifies the format of the naming > > > > > authority field > > > > > "naming authority" field (3bytes) -- identifies the vendor (or > > > > > group of vendors) generating this ISID > > > > > "qualifier" (2bytes) -- the free-space for ISID uniqueness > > > > > > > > > > The type field takes on three defined values with all other values > > > > > reserved: > > > > > Type naming authority format > > > > > 00h IEEE OUI > > > > > 01h IANA Enterprise Number (EN) > > > > > 02h "Random" > > > > > > > > > > The first types two provide a mechanism to uniquely (world wide) > > > > > identify the naming authority. A vendor with one or more OUIs and > > > > > possibly also Enterprise number MUST use at least one of these > > numbers > > > > > when it generates ISIDs. > > > > > > > > > > The "Random" type is for the case where the ISID generator (SW or > HW) > > > > > is provided by an entity that has no OUI or EN. This includes, for > > > > > example, > > > > > -- a user-written program that builds sessions (and has access to > the > > > > > system level iSCSI Name) > > > > > -- a university or other organization providing the component > > > > > -- a testing tool > > > > > > > > > > For the "Random" type, the naming authority field should be a > random > > > > > or pseudo-random number. (See below on how this affects > "conservative > > > > > reuse"). > > > > > > > > > > [Note: the "type" field needn't be this big, but NDT felt that (a) > > > > > 2bits was insufficient for the future, (b) the "type" field should > be > > > > > first, and (c) the "naming authority" field should be > byte-aligned.] > > > > > > > > > > 2) Conservative Reuse > > > > > > > > > > The "conservative reuse" principle of this proposal just says that > > > > > SCSI Initiator Portnames should be viewed as static things (as much > > as > > > > > possible) and reused (when feasible) to give the most stable > > > > > presentation of SCSI Initiator Ports to both the OS above and to > SCSU > > > > > targets across the wire. > > > > > > > > > > Whereas the current draft says "The ISID RULE does not preclude the > > > > > use of the same ISID to different Target portal groups", the > > > > > "conservative reuse" requirement would say that such reuse (using > the > > > > > same ISID to many target portal groups) is a SHOULD (or is that > > > > > MUST?). So, in one implementation, each iSCSI Initiator Portal > group > > > > > would get configured with iSCSI Name, and a (small) set of ISIDs. > > The > > > > > portal group might take this set of ISIDs as an ordered list. The > > > > > first session to a Target portal group would use the first ISID, > the > > > > > second to the *same* target portal group would use the second in > the > > > > > list, etc. The number of ISIDs would then define a configuration > > > > > parameter that can be interpreted as the maximum number of sessions > > > > > that can be built to a given target portal group. > > > > > > > > > > To facilitate "conservative reuse", the "qualifier" field of a set > of > > > > > ISIDs SHOULD be generated using either a repeatable algorithm > > > > > (non-random or pseudo-random but based on a fixed seed) or any > > > > > algorithm and stored in a persistent location (e.g., registry or > /etc > > > > > file). > > > > > > > > > > For the "Random" type, "conservative reuse" may not be an issue > (say, > > > > > user application that doesn't care about reservations, etc.). When > > it > > > > > is, the "naming authority" field SHOULD also be generated by a > > > > > mechanism similar to that for the "qualifier" field as specified > > above > > > > > (e.g., defined in the SW at compilation time.) > > > > > > > > > > DOCUMENTATING CHANGES: > > > > > > > > > > The iscsi drafts would need the following minor changes to support > > > > > this proposal: > > > > > > > > > > NDT doc > > > > > (a) define the structure of the ISID field (as described above) > > > > > (b) add some notes about implementation in the presense of > > > > > "conservative reuse" (e.g., that ISID should be configured once, > say > > > > > at install time, then reused on subsequent reboots, even for > "Random" > > > > > type). > > > > > > > > > > iSCSI MAIN doc: > > > > > (a) move the CID field in Login Request to another reserved field. > > > > > (b) expand the ISID field in Login Request and Response to > encompass > > > > > the previous 4 bytes. > > > > > (c) add a sentence where the ISID field is defined indicating that > > > > > this field is a structured value, showing the structure (as above) > > and > > > > > point to the NDT document. > > > > > (d) add some text to "Note to Implementors" on "conservative > reuse". > > > > > > > > > > Comments? > > > > > > > > > > Jim Hafner > > > > -- > > 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 Oct 31 14:16: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 OAA28487 for ; Wed, 31 Oct 2001 14:16:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VIea317613 for ips-outgoing; Wed, 31 Oct 2001 13:40:36 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9VIeXl17601 for ; Wed, 31 Oct 2001 13:40:33 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA57866 for ; Wed, 31 Oct 2001 12:37:33 -0600 Received: from d04nms41.raleigh.ibm.com (d04nms41.raleigh.ibm.com [9.67.228.19]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id f9VIdu8129566 for ; Wed, 31 Oct 2001 13:39:56 -0500 Subject: Re: is TargetName always mandatory or not? To: ips@ece.cmu.edu Cc: "John Hufferd" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andre Asselin" Date: Wed, 31 Oct 2001 13:40:55 -0500 X-MIMETrack: Serialize by Router on D04NMS41/04/M/IBM(Release 5.0.8 |June 18, 2001) at 10/31/2001 01:39:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John & Julian, How about this for the section 5 text: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The initial login request of the leading Login MAY also include the SessionType key=value pair, in which case if the SessionType is not "discovery", then the initial login request MUST also include the key=value pair TargetName. John, I disagree with your second statement: I don't see any way you could have 2 different sessions established within the same portal group with the same InitiatorName, ISID, and TSID. The spec. says that a nexus, and therefore an iSCSI session, is uniquely identified by the InitiatorName, ISID, TSID, and portal group tag. There is no mention of TargetName contributing to the identificaiton of a session. In my opinion, a non-leading connection should NOT have the TargetName, since it doesn't contribute anything. Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC John Hufferd/San To: Julian Satran/Haifa/IBM@IBMIL Jose/IBM@IBMUS cc: ips@ece.cmu.edu Sent by: Subject: Re: is TargetName always mandatory or not? owner-ips@ece. cmu.edu 10/31/2001 04:20 AM Julian, I think the TargetName should be included on the Initial Login Request on the Leading Login. It seem strange to permit the Authentication functions to proceed if perhaps the intended Target is different then the one doing the Authentication. The way it currently is written, you could pass all the Security test and then find out just before going into Full Function Phase, that it was intended for some other Target. Seems like a waste. My I think that TargetName should also be on all connections on the Initial Login Request. Here is my thinking: The SSID (ISID+TSID) is unique only with regards to a Specific Initiator and Target Node Pair. It is therefore not clear that just knowing the SSID and InitiatorName is enough to understand what session the subsequent connections are being attached to. And it is possible that the CID could be also overlapped with another session. Therefore, I think it make since to determine all this on the initial Login on every Connection, so you know at the beginning what values can be negotiated, or that are being set to the right Session. . . . 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 10/30/2001 11:33:50 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: is TargetName always mandatory or not? It is the leading login: The section 5 paragraph will read: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The leading Login request MAY also include the SessionType key=value pair in which case if the SessionType is not "discovery" then the leading Login Request MUST also include the key=value pair TargetName. Julo Andre Asselin/Raleigh/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 31-10-01 02:08 Please respond to Andre Asselin To: "IPS Reflector (E-mail)" cc: Subject: is TargetName always mandatory or not? In section 5 of the spec, it says "If the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName.". However, in Appendix D, the description for TargetName says it is Leading Only. Should TargetName not be Leading Only, or should the text in section 5 say that TargetName must be in the initial Login Request of a leading connection? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 14:20: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 OAA28535 for ; Wed, 31 Oct 2001 14:20:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VIZ9e17161 for ips-outgoing; Wed, 31 Oct 2001 13:35:09 -0500 (EST) 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 f9VIZ7l17157 for ; Wed, 31 Oct 2001 13:35:07 -0500 (EST) Received: from trebiaazner66z (gtp-61.iol.unh.edu [132.177.125.61]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V875QM8Y; Wed, 31 Oct 2001 13:34:31 -0500 Message-ID: <008f01c16232$4d808640$3d7db184@trebiaazner66z> From: "Anshul Chadda" To: Subject: Re: iSCSI: current UNH Plugfest Date: Wed, 31 Oct 2001 12:34:27 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01C16208.61112AE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 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_008C_01C16208.61112AE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello: As this issue has come up with setting CHECK CONDITION in the SCSI = Response. It is assumed that if CHECK CONDITION is set in the SCSI = Response PDU, then there has to be sense data accompanied with it. So as = far as I see it, it would help if the following sentence in the draft = has the MUST/must in there. In the current wording, i can think that if = there is no data segment in the SCSI Response PDU for a CHECK CONDITION, = it is still OK. In draft 8, the sentence looks like the following:=20 ------------------------------------------------------- 3.4.6 Data Segment - Sense and Response Data Segment iSCSI targets MUST support and enable autosense. If Status is CHECK = CONDITION (0x02), then the Data Segment contains sense data for the = failed command. ------------------------------------------------------- It can be changed to the following: ------------------------------------------------------- 3.4.6 Data Segment - Sense and Response Data Segment iSCSI targets MUST support and enable autosense. If Status is CHECK = CONDITION (0x02), then the target MUST have sense data in the data = segment for the failed command. ------------------------------------------------------- I don't know if there is a reason that the draft has the wording in the = current way. Apologies if this subject has already been discussed.=20 Regards, Anshul -------------------------------------------------------------------------= ---------------------------------------- 5. Some common error situations: 1) - when a SCSI Response contains a CHECK CONDITION (Status=3D0x02), some targets are not including the SenseLength as the first 2 bytes in the data segment. Although the format of the data = segment is clear from the diagram in section 3.4.6 on page 62 of draft 8 (page 63 of draft 8a), the last entry in the diagram for the SCSI Response PDU on page 58 of draft 8 (page 59 of draft 8a) is misleading because it mentions only the Sense Data and Response Data and omits the Sense Length. It would therefore be helpful if the last entry in the diagram on page 58 were changed to = explicitly reference the diagram on page 62, as in: Data Segment -- see section 3.4.6 (optional) ------=_NextPart_000_008C_01C16208.61112AE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello:
As this issue has come up with setting CHECK=20 CONDITION in the SCSI Response. It is assumed that if CHECK = CONDITION is=20 set in the SCSI Response PDU, then there has to be sense data = accompanied with=20 it. So as far as I see it, it would help if the following sentence in = the draft=20 has the MUST/must in there. In the current wording, i can think that if = there is=20 no data segment in the SCSI Response PDU for a CHECK CONDITION, it is = still=20 OK.
 
In draft 8, the sentence looks like the = following:=20
-------------------------------------------------------
3.4.6 Data Segment - Sense = and Response=20 Data Segment

iSCSI targets MUST support and enable autosense. If = Status is=20 CHECK CONDITION (0x02), then the Data Segment contains sense data for = the failed=20 command.

-------------------------------------------------------
 
It can be changed to the following:
 
-------------------------------------------------------
3.4.6 Data Segment - Sense = and Response=20 Data Segment

iSCSI targets MUST support and enable autosense. If = Status is=20 CHECK CONDITION (0x02), then the target MUST have sense = data in=20 the data segment for the failed command.

-------------------------------------------------------

<= /FONT>
I don't know if there is a reason that the draft = has the=20 wording in the current way.  Apologies if this subject has = already=20 been discussed.
 
Regards,
Anshul
 
------------------------------------------------------------= -----------------------------------------------------
 
5. Some common error = situations:

   1) -=20 when a SCSI Response contains a CHECK CONDITION=20 (Status=3D0x02),
      some targets are not = including=20 the SenseLength as the first 2
      bytes = in the=20 data segment.  Although the format of the data=20 segment
      is clear from the diagram in = section=20 3.4.6 on page 62 of draft 8
      (page 63 = of draft=20 8a), the last entry in the diagram for the=20 SCSI
      Response PDU on page 58 of draft = 8 (page=20 59 of draft 8a) is
      misleading because = it=20 mentions only the Sense Data and = Response
      Data=20 and omits the Sense Length.  It would therefore be=20 helpful
      if the last entry in the = diagram on=20 page 58 were changed to explicitly
      = reference=20 the diagram on page 62, as=20 in:

         Data Segment = -- see=20 section 3.4.6 (optional)


 
------=_NextPart_000_008C_01C16208.61112AE0-- From owner-ips@ece.cmu.edu Wed Oct 31 14:55: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 OAA29202 for ; Wed, 31 Oct 2001 14:55:59 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VJAWp20199 for ips-outgoing; Wed, 31 Oct 2001 14:10:32 -0500 (EST) 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 f9VJAVl20195 for ; Wed, 31 Oct 2001 14:10:31 -0500 (EST) 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 OAA02574 for ; Wed, 31 Oct 2001 14:10:25 -0500 (EST) Message-ID: <3BE04A51.199E8E20@cisco.com> Date: Wed, 31 Oct 2001 13:00:33 -0600 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: Re: iSCSI: New iSCSI MIB draft References: <3BDEE304.B89C3782@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 For those who are more pictorially inclined when looking at MIBs, I have an updated MIB tree drawing available at: ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-mib-structure-03.pdf -- Mark Mark Bakke wrote: > > We have submitted a new iSCSI MIB draft to the repository. > Until it becomes available, it may be retrieved as either > a gzipped or text version from: > > ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt.gz > > ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt > > A matching UML drawing is available at: > > ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-uml-model-03.pdf > > The table hierarchy has been significantly flattened. This does > not change the object model, but does reduce the number of redundant > levels of OIDs when address individual objects. I will send a > new table structure drawing soon. > > We will send a list of open issues to the IPS list shortly. > > Thanks, > > -- > 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 Oct 31 14:59: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 OAA29322 for ; Wed, 31 Oct 2001 14:59:35 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VJ3C919552 for ips-outgoing; Wed, 31 Oct 2001 14:03:12 -0500 (EST) 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 f9VJ3Bl19547 for ; Wed, 31 Oct 2001 14:03:11 -0500 (EST) 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 UAA35186 for ; Wed, 31 Oct 2001 20:03:04 +0100 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 f9VJ34B41554 for ; Wed, 31 Oct 2001 20:03:04 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: Re: question on whitespace in text negotiations X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 31 Oct 2001 21:03:01 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 31/10/2001 21:03:04, Serialize complete at 31/10/2001 21:03:04 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk They are significant. I will make the text say it explicitly in 3.10.4: 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). White space in key and values is significant. The key and value are separated by a '=' (0x3d) delimiter. Every key=value pair (including the last or only pair) MUST be followed by at least one null (0x00) delimiter. A list is a set of values separated by comma (0x2c). Julo Andre Asselin/Raleigh/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 31-10-01 18:25 Please respond to Andre Asselin To: "IPS Reflector (E-mail)" cc: Subject: question on whitespace in text negotiations Julian, Thanks for answering my previous question. I have another one for you: Sections 2.2.4 and 3.10.4 describe the format of text requests/responses, but doesn't address whether whitespace is significant or should be thrown away. For example, is "_MaxConnections_=_2" (where _ represents a space) valid or invalid? I get the feeling that whitespace is significant, but it would be nice if the spec explicitly said so. Thanks... Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 15: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 PAA29490 for ; Wed, 31 Oct 2001 15:07:46 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VJFQ520672 for ips-outgoing; Wed, 31 Oct 2001 14:15:26 -0500 (EST) 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 f9VJFOl20668 for ; Wed, 31 Oct 2001 14:15:25 -0500 (EST) 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 UAA90566 for ; Wed, 31 Oct 2001 20:15:15 +0100 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 f9VJFEY67798 for ; Wed, 31 Oct 2001 20:15:14 +0100 To: ips@ece.cmu.edu MIME-Version: 1.0 Subject: RE: iSCSI CRC check clarification X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: "Julian Satran" Message-ID: Date: Wed, 31 Oct 2001 21:15:12 +0200 X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.8 |June 18, 2001) at 31/10/2001 21:15:14, Serialize complete at 31/10/2001 21:15:14 Content-Type: text/plain; charset="us-ascii" Sender: owner-ips@ece.cmu.edu Precedence: bulk Comments in text - Julo "De, Tandra" 31-10-01 20:52 Please respond to "De, Tandra" To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI CRC check clarification Julian,me Thanks for you reply. First of all I am not so clear understanding the spec. By "reflecting" I meant to ask whether to bit swap the CRC first, and then complement it. Then put the CRC value in the wire in network byte order? I think there might be some confusion the way I have stated my questions. 1. My concern was that in order to match the examples numbers (put up in the Mailing List) I had to bit swap every message byte to calculate the CRC and then before transmitting the CRC, I bit swap the CRC and complement it - all these add quite a bit of latency calculating CRC on every header and data digests on both sides (Initiator and Target). So there may be a better way (rather faster way) to do bit swap on every msg byte. I tried to build the initial CRC table with bit swapped, but by doing this I could not come up with the examples numbers. I may have missed something here. I like to see a sample code that does the way the spec. says and avoids the overhead. +++ a friendly advise - you can build your tables so that you will need minimal bit swapping to have the bits get out in network order +++ 2. In the 08 draft Appendix A page 151 says - the coefficients of R(x) are considered a 32 bit sequence - the bit sequence is complemented and the result is CRC By reading these lines I wasn't clear whether I should be doing what I have stated in #1. I have again attached my code of CRC calculation if you could either verify this or rather reply me a with a sample code, it will be greatly appreciated. Also this will clear up my misunderstanding. Thanks again, Tandra (tde@corp.adaptec.com) +++ there are very good texts on this on the network and free CRC code. Dough Otis has put some on this list too+++ -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Tuesday, October 30, 2001 10:55 PM To: ips@ece.cmu.edu Subject: Re: iSCSI CRC check clarification Tandra, I am not sure I understand what you are talking about. The spec clearly states how the CRC should be calculated and what the bit order on the wire is. Perhaps by "reflecting" you are talking about the later. The examples where checked independently by me and at least 2 other persons. Regards, Julo "De, Tandra" 31-10-01 00:08 Please respond to "De, Tandra" To: Julian Satran/Haifa/IBM@IBMIL cc: "'ips@ece.cmu.edu'" , "De, Tandra" Subject: iSCSI CRC check clarification Julian, I followed few iSCSI CRC checking example threads and the thread file://www.pdl.cmu.edu/mailinglists/ips/mail/msg05931.html says that "Before transmission, the CRC bits must be reflected and complemented"; whereas, the iscsi- 08 draft only mentions about complementing the CRC before transmission. So attached you will find two software implementation code examples: crc_reflect.cpp and crc_no_reflect.cpp. I ran few test cases with the attached example code and when I do reflect bits I get 0: ff ff ff ff 4: ff ff ff ff 8: ff ff ff ff 12: ff ff ff ff 16: ff ff ff ff 20: ff ff ff ff 24: ff ff ff ff 28: ff ff ff ff 32: 43 ab a8 62 in the transmission side, and the reception side I get 0x1c2d19ed. But when I do not bit flip I get 0: ff ff ff ff 4: ff ff ff ff 8: ff ff ff ff 12: ff ff ff ff 16: ff ff ff ff 20: ff ff ff ff 24: ff ff ff ff 28: ff ff ff ff 32: 46 15 d5 c2 in the transmission side, and the reception side I do get 0x1c2d19ed though. I like to clarify which implementation we should use so that both Initiator and Target will be in sync. validating the CRC. I appreciate if you could verify the attached files to see I am missing anytbing. Also I think that it would help everyone who are dealing with iSCSI CRC if you could put up the finalized version of the code in the reflector. Thanks, Tandra (tde@corp.adaptec.com) #### crc_no_reflect.cpp has been removed from this note on October 31 2001 by Julian Satran #### crc_reflect.cpp has been removed from this note on October 31 2001 by Julian Satran #### op_crc.cpp has been removed from this note on October 31 2001 by Julian Satran From owner-ips@ece.cmu.edu Wed Oct 31 15:22: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 PAA29833 for ; Wed, 31 Oct 2001 15:22:40 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VJiqR23211 for ips-outgoing; Wed, 31 Oct 2001 14:44:52 -0500 (EST) 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 f9VJinl23204 for ; Wed, 31 Oct 2001 14:44:49 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel2.hp.com (Postfix) with ESMTP id A7DBCB41; Wed, 31 Oct 2001 11:44:45 -0800 (PST) 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 LAA16638; Wed, 31 Oct 2001 11:44:40 -0800 (PST) Message-ID: <3BE0569C.A6CCCAF5@cup.hp.com> Date: Wed, 31 Oct 2001 11:53:00 -0800 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [en] (X11; U; HP-UX B.11.00 9000/778) X-Accept-Language: en MIME-Version: 1.0 To: Anshul Chadda Cc: ips@ece.cmu.edu Subject: Re: iSCSI: current UNH Plugfest References: <008f01c16232$4d808640$3d7db184@trebiaazner66z> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Anshul, I don't know why the initiator should care if the sense data arrived along with the CHECK CONDITION scsi status or not. (?) Most, if not all, SCSI initiator stacks have some form of indicating sense_status from SCSI LLP (hba driver, device driver, mini-port driver, etc) to SCSI ULP (class driver, target driver, etc), which indicates what the status of the sense operation was and whether sense data is available or not. For instance, you also need to deal with a scenario where the target sends a SCSI status of CHECK CONDITION and accompanies it with the sense data in the data segment. However, the initiator encounters a data digest error on the sense data data segment and drops the sense data data segment. The initiator can always choose to complete the I/O and return the SCSI status back to its SCSI ULP, indicating that no sense data was available. I don't see why you would need the wording tightened to a MUST. Initiators must not assume that the sense data will always be available on a check condition. The sense operation may be unsuccessful and no sense data may be available. Regards, Santosh > Anshul Chadda wrote: > > Hello: > As this issue has come up with setting CHECK CONDITION in the SCSI > Response. It is assumed that if CHECK CONDITION is set in the SCSI > Response PDU, then there has to be sense data accompanied with it. So > as far as I see it, it would help if the following sentence in the > draft has the MUST/must in there. In the current wording, i can think > that if there is no data segment in the SCSI Response PDU for a CHECK > CONDITION, it is still OK. > > In draft 8, the sentence looks like the following: > ------------------------------------------------------- > 3.4.6 Data Segment - Sense and Response Data Segment > > iSCSI targets MUST support and enable autosense. If Status is CHECK > CONDITION (0x02), then the Data Segment contains sense data for the > failed command. > > ------------------------------------------------------- > > It can be changed to the following: > > ------------------------------------------------------- > 3.4.6 Data Segment - Sense and Response Data Segment > > iSCSI targets MUST support and enable autosense. If Status is CHECK > CONDITION (0x02), then the target MUST have sense data in the data > segment for the failed command. > > ------------------------------------------------------- > > I don't know if there is a reason that the draft has the wording in > the current way. Apologies if this subject has already been > discussed. > > Regards, > Anshul > > ----------------------------------------------------------------------------------------------------------------- > > 5. Some common error situations: > > 1) - when a SCSI Response contains a CHECK CONDITION (Status=0x02), > some targets are not including the SenseLength as the first 2 > bytes in the data segment. Although the format of the data > segment > is clear from the diagram in section 3.4.6 on page 62 of draft 8 > (page 63 of draft 8a), the last entry in the diagram for the > SCSI > Response PDU on page 58 of draft 8 (page 59 of draft 8a) is > misleading because it mentions only the Sense Data and Response > Data and omits the Sense Length. It would therefore be helpful > if the last entry in the diagram on page 58 were changed to > explicitly > reference the diagram on page 62, as in: > > Data Segment -- see section 3.4.6 (optional) > > -- ################################## 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 Wed Oct 31 15:41: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 PAA00806 for ; Wed, 31 Oct 2001 15:41:11 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VJe4h22790 for ips-outgoing; Wed, 31 Oct 2001 14:40:04 -0500 (EST) 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 f9VJe2l22785 for ; Wed, 31 Oct 2001 14:40:02 -0500 (EST) Received: from core.rose.hp.com (core.rose.hp.com [15.43.208.100]) by atlrel7.hp.com (Postfix) with ESMTP id 1EF2E1F751; Wed, 31 Oct 2001 14:37:22 -0500 (EST) Received: from swathi (swathi.rose.hp.com [15.43.213.237]) by core.rose.hp.com with SMTP (8.9.3 (PHNE_22672)/8.8.6 SMKit7.02) id LAA28187; Wed, 31 Oct 2001 11:41:22 -0800 (PST) Message-ID: <003c01c16243$d10410c0$edd52b0f@rose.hp.com> From: "Mallikarjun C." To: "Ken Sandars" , References: <058001c1622e$bb403710$2907a8c0@wombat> Subject: Re: iSCSI:SCSI responses for iSCSI errors Date: Wed, 31 Oct 2001 11:39:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 Ken, > imply the target waits for the entire Expected Data Transfer > Length worth to be transferred? I don't believe so. Target is expected to wait for the data in the pipe to drain (I believe this section is describing the fundamental behavior from the context of one outstanding R2T, section 8.4 spells out what ought to be done for multiple). So, the target does not have to generate a new R2T. The above behavior is to take care of the race condition where the initiator re-uses the same ITT (on receiving a response) for a different task on a different connection, when the stale data is still in the pipe. > Is it possible to just reject the original command PDU If you meant the usage of Reject PDU, the answer is no - as section 8.2 clearly calls out. A response PDU must be returned for concluding an instantiated task. Hope that helps. -- Mallikarjun Mallikarjun Chadalapaka Networked Storage Architecture Network Storage Solutions Organization Hewlett-Packard MS 5668 Roseville CA 95747 ----- Original Message ----- From: "Ken Sandars" To: Sent: Wednesday, October 31, 2001 9:08 AM Subject: iSCSI:SCSI responses for iSCSI errors > Gidday all, > > With reference to 3.4.2, when a target detects an error > does: > > '...MUST wait until it receives a Data PDU with the F > bit set, in the last expected sequence, before sending the > Response PDU' > > imply the target waits for the entire Expected Data Transfer > Length worth to be transferred? > > If so, the target may have to R2T for the solicited data! Should > it R2T with 'correct' values, regardless of what the initiator sent? > > In this case it is possible that this clean-up action actually solicits > all the required data, however, the command is still going to get > a response with sense data indicating an abort. > > Is it possible to just reject the original command PDU when validity > checking picks up one of these errors? Any Data-Out PDUs > in the pipeline which belong to this rejected command can be silently > discarded by the target. What am I missing? > > > Thoughts? > > Ken Sandars > ksandars@eurologic.com > Eurologic Systems > +44 117 930 9616 > > From owner-ips@ece.cmu.edu Wed Oct 31 16:49: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 QAA03870 for ; Wed, 31 Oct 2001 16:49:33 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VKkjT28801 for ips-outgoing; Wed, 31 Oct 2001 15:46:45 -0500 (EST) 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 f9VKkgl28792 for ; Wed, 31 Oct 2001 15:46:42 -0500 (EST) 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 MAA19420; Wed, 31 Oct 2001 12:39:37 -0800 (PST) Received: by hq-ex-c2.brocade.com with Internet Mail Service (5.5.2653.19) id ; Wed, 31 Oct 2001 12:39:36 -0800 Message-ID: From: Robert Snively To: "'Santosh Rao'" , Anshul Chadda Cc: ips@ece.cmu.edu Subject: RE: iSCSI: current UNH Plugfest Date: Wed, 31 Oct 2001 12:39:27 -0800 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: owner-ips@ece.cmu.edu Precedence: bulk The "MUST have sense information if CHECK CONDITION" is a property of SCSI that requires the use of autosensing, as iSCSI does. It is only non autosensing drivers that will present CHECK CONDITION indications with sense data missing. Sense Data will never be generated in a data segment to any command except REQUEST SENSE. In that case, CHECK CONDITION will never be indicated unless the REQUEST SENSE command failed in some way, and (if autosensing is used), the CHECK CONDITION will be associated with its own set of sense information in the response PDU. Note that if the unit cannot assemble relevant sense information from the attached hardware, that is in itself a CHECK CONDITION, and the corresponding inability to access critical hardware must be posted in the sense information. That is why MUST is the proper requirement. Bob > -----Original Message----- > From: Santosh Rao [mailto:santoshr@cup.hp.com] > Sent: Wednesday, October 31, 2001 11:53 AM > To: Anshul Chadda > Cc: ips@ece.cmu.edu > Subject: Re: iSCSI: current UNH Plugfest > > > Anshul, > > I don't know why the initiator should care if the sense data arrived > along with the CHECK CONDITION scsi status or not. (?) > > Most, if not all, SCSI initiator stacks have some form of indicating > sense_status from SCSI LLP (hba driver, device driver, > mini-port driver, > etc) to SCSI ULP (class driver, target driver, etc), which indicates > what the status of the sense operation was and whether sense data is > available or not. > > For instance, you also need to deal with a scenario where the target > sends a SCSI status of CHECK CONDITION and accompanies it > with the sense > data in the data segment. However, the initiator encounters a data > digest error on the sense data data segment and drops the sense data > data segment. The initiator can always choose to complete the I/O and > return the SCSI status back to its SCSI ULP, indicating that no sense > data was available. > > I don't see why you would need the wording tightened to a MUST. > Initiators must not assume that the sense data will always be > available > on a check condition. The sense operation may be unsuccessful and no > sense data may be available. > > Regards, > Santosh > > > > Anshul Chadda wrote: > > > > Hello: > > As this issue has come up with setting CHECK CONDITION in the SCSI > > Response. It is assumed that if CHECK CONDITION is set in the SCSI > > Response PDU, then there has to be sense data accompanied > with it. So > > as far as I see it, it would help if the following sentence in the > > draft has the MUST/must in there. In the current wording, i > can think > > that if there is no data segment in the SCSI Response PDU > for a CHECK > > CONDITION, it is still OK. > > > > In draft 8, the sentence looks like the following: > > ------------------------------------------------------- > > 3.4.6 Data Segment - Sense and Response Data Segment > > > > iSCSI targets MUST support and enable autosense. If Status is CHECK > > CONDITION (0x02), then the Data Segment contains sense data for the > > failed command. > > > > ------------------------------------------------------- > > > > It can be changed to the following: > > > > ------------------------------------------------------- > > 3.4.6 Data Segment - Sense and Response Data Segment > > > > iSCSI targets MUST support and enable autosense. If Status is CHECK > > CONDITION (0x02), then the target MUST have sense data in the data > > segment for the failed command. > > > > ------------------------------------------------------- > > > > I don't know if there is a reason that the draft has the wording in > > the current way. Apologies if this subject has already been > > discussed. > > > > Regards, > > Anshul > > > > > -------------------------------------------------------------- > --------------------------------------------------- > > > > 5. Some common error situations: > > > > 1) - when a SCSI Response contains a CHECK CONDITION > (Status=0x02), > > some targets are not including the SenseLength as the first 2 > > bytes in the data segment. Although the format of the data > > segment > > is clear from the diagram in section 3.4.6 on page 62 > of draft 8 > > (page 63 of draft 8a), the last entry in the diagram for the > > SCSI > > Response PDU on page 58 of draft 8 (page 59 of draft 8a) is > > misleading because it mentions only the Sense Data > and Response > > Data and omits the Sense Length. It would therefore > be helpful > > if the last entry in the diagram on page 58 were changed to > > explicitly > > reference the diagram on page 62, as in: > > > > Data Segment -- see section 3.4.6 (optional) > > > > > > -- > ################################## > 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 Wed Oct 31 17: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 RAA04800 for ; Wed, 31 Oct 2001 17:24:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VLXWJ02890 for ips-outgoing; Wed, 31 Oct 2001 16:33:32 -0500 (EST) 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 f9VLXUl02884 for ; Wed, 31 Oct 2001 16:33:30 -0500 (EST) Received: from hpcuhe.cup.hp.com (hpcuhe.cup.hp.com [15.0.80.203]) by palrel12.hp.com (Postfix) with ESMTP id 3EA9F1F905 for ; Wed, 31 Oct 2001 13:33:24 -0800 (PST) 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 NAA22047 for ; Wed, 31 Oct 2001 13:33:19 -0800 (PST) Message-ID: <3BE07014.5BA3E934@cup.hp.com> Date: Wed, 31 Oct 2001 13:41:40 -0800 From: Santosh Rao Organization: Hewlett Packard, Cupertino. X-Mailer: Mozilla 4.78 [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: current UNH Plugfest References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert Snively wrote: > > Sense Data will never be generated in a data segment to any command except > REQUEST SENSE. In that case, CHECK CONDITION will never > be indicated unless the REQUEST SENSE command failed in > some way, and (if autosensing is used), the CHECK CONDITION > will be associated with its own set of sense information in > the response PDU. The SCSI sense data is contained in the data segment of the SCSI Response pdu. Hence, it is possible for the initiator to receive the header of the scsi response pdu containing the SCSI Status, but not the data segment (sense data) of the scsi response pdu, due to a data digest error. - 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 Wed Oct 31 17:30: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 RAA04942 for ; Wed, 31 Oct 2001 17:30:15 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VLh5r03636 for ips-outgoing; Wed, 31 Oct 2001 16:43:05 -0500 (EST) 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 f9VLh3l03630 for ; Wed, 31 Oct 2001 16:43:04 -0500 (EST) 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 QAA28792 for ; Wed, 31 Oct 2001 16:40:29 -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 f9VLh2v128658 for ; Wed, 31 Oct 2001 14:43:02 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: is TargetName always mandatory or not? To: "Andre Asselin" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 31 Oct 2001 13:42:19 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/31/2001 02:43:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Andre, I looked again through the document and No where could I find a statement that you claimed as "a nexus, and therefore an iSCSI session, is uniquely identified by the InitiatorName, ISID, TSID, and portal group tag". It is the InitiatorName, ISID, TSID, with the TargetName and PortalGroup. Please point out to me in the Spec (8 or above), where I can find your statement on I_T Nexus. I did find the following (please ignore for this conversation the "i" and 't" stuff): "- Session: The group of TCP connections that link an initiator with a target, form a session (loosely equivalent to a SCSI I-T nexus). TCP connections can be added and removed from a session. Across all connections within a session, an initiator sees one "target image". " " - 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). " I have not found a place where Session ID is tied to the TSID. Hence my comment that we also need to have the TargetName in the Initial Login on all Connections. . . . 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 Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: John Hufferd/San Jose/IBM@IBMUS Subject: Re: is TargetName always mandatory or not? John & Julian, How about this for the section 5 text: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The initial login request of the leading Login MAY also include the SessionType key=value pair, in which case if the SessionType is not "discovery", then the initial login request MUST also include the key=value pair TargetName. John, I disagree with your second statement: I don't see any way you could have 2 different sessions established within the same portal group with the same InitiatorName, ISID, and TSID. The spec. says that a nexus, and therefore an iSCSI session, is uniquely identified by the InitiatorName, ISID, TSID, and portal group tag. There is no mention of TargetName contributing to the identificaiton of a session. In my opinion, a non-leading connection should NOT have the TargetName, since it doesn't contribute anything. Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC John Hufferd/San To: Julian Satran/Haifa/IBM@IBMIL Jose/IBM@IBMUS cc: ips@ece.cmu.edu Sent by: Subject: Re: is TargetName always mandatory or not? owner-ips@ece. cmu.edu 10/31/2001 04:20 AM Julian, I think the TargetName should be included on the Initial Login Request on the Leading Login. It seem strange to permit the Authentication functions to proceed if perhaps the intended Target is different then the one doing the Authentication. The way it currently is written, you could pass all the Security test and then find out just before going into Full Function Phase, that it was intended for some other Target. Seems like a waste. My I think that TargetName should also be on all connections on the Initial Login Request. Here is my thinking: The SSID (ISID+TSID) is unique only with regards to a Specific Initiator and Target Node Pair. It is therefore not clear that just knowing the SSID and InitiatorName is enough to understand what session the subsequent connections are being attached to. And it is possible that the CID could be also overlapped with another session. Therefore, I think it make since to determine all this on the initial Login on every Connection, so you know at the beginning what values can be negotiated, or that are being set to the right Session. . . . 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 10/30/2001 11:33:50 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: is TargetName always mandatory or not? It is the leading login: The section 5 paragraph will read: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The leading Login request MAY also include the SessionType key=value pair in which case if the SessionType is not "discovery" then the leading Login Request MUST also include the key=value pair TargetName. Julo Andre Asselin/Raleigh/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 31-10-01 02:08 Please respond to Andre Asselin To: "IPS Reflector (E-mail)" cc: Subject: is TargetName always mandatory or not? In section 5 of the spec, it says "If the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName.". However, in Appendix D, the description for TargetName says it is Leading Only. Should TargetName not be Leading Only, or should the text in section 5 say that TargetName must be in the initial Login Request of a leading connection? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 18:19: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 SAA05472 for ; Wed, 31 Oct 2001 18:19:05 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VMdGM07954 for ips-outgoing; Wed, 31 Oct 2001 17:39:16 -0500 (EST) 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 f9VMdCl07940 for ; Wed, 31 Oct 2001 17:39:13 -0500 (EST) Received: from localhost (rdr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id RAA17341 for ; Wed, 31 Oct 2001 17:39:12 -0500 (EST) Date: Wed, 31 Oct 2001 17:39:11 -0500 From: "Robert D. Russell" To: ips@ece.cmu.edu Subject: Re: iSCSI: current UNH Plugfest Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ips@ece.cmu.edu Precedence: bulk Attached are the new issues that arose during the iSCSI plugfest at UNH on Wednesday 31-Oct-2001. (Note: these issues do not take into account any modifications or clarifications that occured in the standard due to the issues raised on Monday or Tuesday.) Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774 ---------------------------------------------------------------------------- 1. Are receivers (initiator or target) REQUIRED to check that reserved bits and/or fields are set to 0? Section 3 on page 48 of draft 8 says: "Any bits not defined MUST be set to zero. Any reserved fields and values MUST be 0 unless specified otherwise." and Section 8.3 on page 127 of draft 8 says: "Explicit violations of the PDU layout rules stated in this document are format errors. This when detected, usually indicates a major implementation flaw in one of the parties. When a target or an initiator receives an iSCSI PDU with a format error, it MUST reset all transport connections in the session immediately and escalate the format error to session recovery (section 8.11.4)." According to these rules, a PDU with reserved bits and/or fields that are not set to 0 violates the PDU layout rules. Therefore, if an initiator or target receives such a PDU, it should immediately close all connections in the session and go to session recovery. Clearly a format error has extremely severe consequences! Although all vendors are setting reserved bits and fields to 0 on PDUs they are sending, many are NOT checking PDUs they are receiving to see if these bits and fields are set to 0. Basically, vendors are saying "who cares if reserved bits and/or fields in incoming PDUs are not zero? We do not want to take the time to do this checking, and there is no benefit to doing it. As long as the non-reserved bits and fields are set properly, we can and should proceed. Any time devoted to doing this checking is wasted in 99+% of the cases, and in the (unlikely) case that a non-zero bit or field is found, the consequences are too severe." There should be some statement in the standard to clarify what checking is required and what is optional. 2. A similar situation arises with respect to checking the consistency of fields such as Version-max, Version-min and Version-active in Login Requests and Login Responses. For example, consider the Version-max field. Section 3.12.5 says: "All Login requests within the Login phase MUST carry the same Version-max." All vendor initiators are setting Version-max correctly on all login requests they are sending, but many vendor targets are NOT checking received login requests to ensure that this rule is enforced. In particular, many targets simply use the Version-max and Version-min on the first login request they receive on a new connection, and then they ignore these fields on all subsequent login requests in the same login phase. Strictly speaking, a change in the Version-max field during the login phase constitutes a protocol error according to section 8.8 on page 130 of draft 8: "All violations of iSCSI PDU exchange sequences specified in this draft are also protocol errors. This category of errors can be addressed only by fixing the implementations; iSCSI defines Reject and response codes to enable this". Therefore the target should send back a login response with a status of 0x0200 and then close the connection. However, Section 3.12.5 also says: "The target MUST use the value presented with the first login request." This rule seems to imply that the value CAN change, because if it cannot change, then it doesn't matter which one of the login requests it is taken from, they are all the same anyway. The suggestion is to keep the requirement that the target MUST use the value presented on the first login request, but to allowed the target to ignore the value presented on all subsequent login requests in the same login phase. A similar rewording should be done for the other fields. 3. Can commands be sent out of order on the same connection? The behavior of targets is clearly specified in Section 2.2.2.3 on page 25 of draft 8, which says: "Except for the commands marked for immediate delivery the iSCSI target layer MUST eliver the commands for execution in the order specified by CmdSN." Section 2.2.2.3 on page 26 of draft 8 also says: "- CmdSN - the current command Sequence Number advanced by 1 on each command shipped except for commands marked for immediate delivery." but the meaning of the term "shipped" is vague, and does not necessarily require that the PDUs arrive on the other end of a TCP connection in the same order that the CmdSN values were assigned to these PDUs. Some initiators have been designed to send commands out of CmdSN order on one connection. Consider the situation where there is only one connection and a high-level dispatcher creates a PDU for a SCSI command that involves writing immediate data to the target. This PDU is enqueued to a lower-level layer which has to setup, start, and wait-for a DMA operation to move the immediate data into an onboard buffer before the PDU can be put onto the wire. While this is happening, the dispatcher creates another unrelated PDU for a SCSI read command (for example), and when this PDU is passed to the lower-level layer it can be sent immediately, ahead of the previous write PDU and therefore out of order on this connection. The standard clearly allows this to happen if the two PDUs were sent on different connections, and seems to imply that this can also happen when the two PDUs are sent on the same connection. The suggestion is to put in the standard an explicit statement that this is allowed or not allowed, as appropriate. If this is allowed, such a statement would avoid the erroneous assumption being made by some target implementers that within a single connection, commands will arrive in order. If this is not allowed, such a statement would avoid the erroneous assumption being made by some initiator implementers that within a single connection, commands can be put on the wire out of order. 4. Three numeric keys (MaxRecvPDULength, MaxBurstSize, FirstBurstSize) now allow: "A value of 0 indicates no limit." Is this useful? Does it buy anything? The difficulties implementers are having with this are: 1) It is a special case. 2) It causes discontinuous ranges (for example, [0,64..2**24]) 3) It violates the min/max function normally used for the key. 4) There is always a limit anyway. Consider FirstBurstSize, which can have a value that is described as "<0|number-64-2**24>", and for which the minimum of the 2 numbers is selected. I one side offers 0 to mean unlimited, and the other side has a limit, it will reply with that limit, say 128 Kbytes. Therefore, the result is not min(0, 128K) but rather max(0, 128K). The statement in the standard that "the minimum of the 2 numbers is selected" is therefore wrong when one of the numbers is 0. Furthermore, when an initiator or target receives an offer for one of these keys, it cannot simply check that the offered value is legal by testing it against some minimum and maximum. It must first check for 0 and then only if that check shows the value is non-zero can it do the min/max range check for legality (i.e., 64-2**24). Finally, there is always a limit. If nothing else it is the limit imposed by the 24-bit DataSegmentLength field of the PDU requesting the transfer. It is useless to specify a FirstBurstSize (or MaxRecvPDULength or MaxBurstSize) any bigger than that, because the largest possible DataSegmentLength in any PDU that can use this value is 2**24-1. The suggestion is to just eliminate this special case of 0 and require that the range 64-to-(2**24-1) be used instead -- it has exactly the same effect in all cases, it is easier to describe in the standard because it avoids all the extra words, and it is easier to code because it avoids all the special cases. NOTE: the standard should specify the limit in the ranges for MaxRecvPDULength, MaxBurstSize, and FirstBurstSize as 2**24-1 instead of 2**24. The number 2**24 cannot be represented in the 24-bit DataSegmentLength field and therefore can never be used. 5. This is a suggestion for a minor rewording in the standard to avoid misunderstandings. In Appendix E on page 188 of draft 8 it says: "The response to this command is a text response containing a list of targets and their addresses. Each target is returned as a target record. A target record begins with the TargetName text key, followed by a list of TargetAddress text keys, ..." In fact, there are situations where there are no targets and/or no addresses. These situations are clearly defined in the draft after the sentences quoted above, but it would help if those sentences at least hinted at the possibility that the lists could be empty or might not contain addresses. A possible rewording would be: "The response to this command is a text response containing a list of zero or more targets and, optionally, their addresses. Each target is returned as a target record. A target record begins with the TargetName text key, followed by a list of zero or more TargetAddress text keys, ..." 6. This is a suggestion for another very minor rewording in the standard. At the end of section 2.2.3 on page 29 of draft 8 it says: "Before full feature phase is established, only Login PDUs are allowed. ..." The suggested rewording is: "Before full feature phase is established, only Login Request and Login Response PDUs are allowed. ..." From owner-ips@ece.cmu.edu Wed Oct 31 18:19: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 SAA05499 for ; Wed, 31 Oct 2001 18:19:18 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VN0l109476 for ips-outgoing; Wed, 31 Oct 2001 18:00:47 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from wellington.xo.com (wellington.xo.com [207.155.252.73]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9VN0jl09472 for ; Wed, 31 Oct 2001 18:00:45 -0500 (EST) Received: from blekinge ([66.89.96.162]) by wellington.xo.com id SAA26670; Wed, 31 Oct 2001 18:00:39 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <008801c1625f$c3ed0470$1001010a@blekinge> From: "Peter Mellquist" To: "Mark Bakke" Cc: "IPS" References: <3BDEE304.B89C3782@cisco.com> <3BE04A51.199E8E20@cisco.com> Subject: Comments: New iSCSI MIB draft Date: Wed, 31 Oct 2001 14:59:54 -0800 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.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark, Everything looks well. I appreciate the UML diagrams. I have a general question in regard to the iscsiSessionAttributeTable. - What is the life of a row in this table? Do they persist after the session is gone? - Do rows come and go with each iSCSI session? I assume that this is so since iscsiConnectionNumber must have a value from (1..65535). I am considering session statistics (iscsiSessionStats ) in which a SNMP manager would like to access stats after the session has been terminated. With the current design, is it possible for this to work? Or... does this information exists only as long as a session is active. It would be nice to have historical iSCSI stats in the same manner as the RMON MIB does through the history group. Otherwise one would have to have an active SNMP manager running all the time gathering session info. Consider a session in which a number of errors occur to the point the session is terminated. How does an SNMP manager determine what the actual errors were? Thank you, -peter Peter Mellquist Seven-Systems Technolgies peterm@seven-systems.com ----- Original Message ----- From: "Mark Bakke" To: "IPS" Sent: Wednesday, October 31, 2001 11:00 AM Subject: Re: iSCSI: New iSCSI MIB draft > For those who are more pictorially inclined when looking at > MIBs, I have an updated MIB tree drawing available at: > > ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-mib-structure-03.pdf > > -- > Mark > > Mark Bakke wrote: > > > > We have submitted a new iSCSI MIB draft to the repository. > > Until it becomes available, it may be retrieved as either > > a gzipped or text version from: > > > > ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt.gz > > > > ftp://ftpeng.cisco.com/mbakke/iscsi/draft-ietf-ips-iscsi-mib-03.txt > > > > A matching UML drawing is available at: > > > > ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-ietf-iscsi-uml-model-03.pdf > > > > The table hierarchy has been significantly flattened. This does > > not change the object model, but does reduce the number of redundant > > levels of OIDs when address individual objects. I will send a > > new table structure drawing soon. > > > > We will send a list of open issues to the IPS list shortly. > > > > Thanks, > > > > -- > > 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 Oct 31 18: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 SAA05537 for ; Wed, 31 Oct 2001 18:23:21 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VMOmr06807 for ips-outgoing; Wed, 31 Oct 2001 17:24:48 -0500 (EST) 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 f9VMOkl06803 for ; Wed, 31 Oct 2001 17:24:46 -0500 (EST) 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 RAA63392 for ; Wed, 31 Oct 2001 17:22:11 -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 f9VMOiv130224 for ; Wed, 31 Oct 2001 15:24:44 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: is TargetName always mandatory or not? To: Andre_Asselin/Raleigh/IBM%IBMU Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 31 Oct 2001 14:24:02 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/31/2001 03:24:43 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Error in my attached Statement. I should have crossed out the TSID, sorry. . . . 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 John Hufferd/San Jose/IBM@IBMUS@ece.cmu.edu on 10/31/2001 01:42:19 PM Sent by: owner-ips@ece.cmu.edu To: Andre Asselin/Raleigh/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: is TargetName always mandatory or not? Andre, I looked again through the document and No where could I find a statement that you claimed as "a nexus, and therefore an iSCSI session, is uniquely identified by the InitiatorName, ISID, TSID, and portal group tag". It is the InitiatorName, ISID, TSID, with the TargetName and PortalGroup. -------------------------^^^^-- delete TSID from Sentence. Please point out to me in the Spec (8 or above), where I can find your statement on I_T Nexus. I did find the following (please ignore for this conversation the "i" and 't" stuff): "- Session: The group of TCP connections that link an initiator with a target, form a session (loosely equivalent to a SCSI I-T nexus). TCP connections can be added and removed from a session. Across all connections within a session, an initiator sees one "target image". " " - 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). " I have not found a place where Session ID is tied to the TSID. Hence my comment that we also need to have the TargetName in the Initial Login on all Connections. . . . 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 Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: John Hufferd/San Jose/IBM@IBMUS Subject: Re: is TargetName always mandatory or not? John & Julian, How about this for the section 5 text: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The initial login request of the leading Login MAY also include the SessionType key=value pair, in which case if the SessionType is not "discovery", then the initial login request MUST also include the key=value pair TargetName. John, I disagree with your second statement: I don't see any way you could have 2 different sessions established within the same portal group with the same InitiatorName, ISID, and TSID. The spec. says that a nexus, and therefore an iSCSI session, is uniquely identified by the InitiatorName, ISID, TSID, and portal group tag. There is no mention of TargetName contributing to the identificaiton of a session. In my opinion, a non-leading connection should NOT have the TargetName, since it doesn't contribute anything. Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC John Hufferd/San To: Julian Satran/Haifa/IBM@IBMIL Jose/IBM@IBMUS cc: ips@ece.cmu.edu Sent by: Subject: Re: is TargetName always mandatory or not? owner-ips@ece. cmu.edu 10/31/2001 04:20 AM Julian, I think the TargetName should be included on the Initial Login Request on the Leading Login. It seem strange to permit the Authentication functions to proceed if perhaps the intended Target is different then the one doing the Authentication. The way it currently is written, you could pass all the Security test and then find out just before going into Full Function Phase, that it was intended for some other Target. Seems like a waste. My I think that TargetName should also be on all connections on the Initial Login Request. Here is my thinking: The SSID (ISID+TSID) is unique only with regards to a Specific Initiator and Target Node Pair. It is therefore not clear that just knowing the SSID and InitiatorName is enough to understand what session the subsequent connections are being attached to. And it is possible that the CID could be also overlapped with another session. Therefore, I think it make since to determine all this on the initial Login on every Connection, so you know at the beginning what values can be negotiated, or that are being set to the right Session. . . . 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 10/30/2001 11:33:50 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: is TargetName always mandatory or not? It is the leading login: The section 5 paragraph will read: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The leading Login request MAY also include the SessionType key=value pair in which case if the SessionType is not "discovery" then the leading Login Request MUST also include the key=value pair TargetName. Julo Andre Asselin/Raleigh/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 31-10-01 02:08 Please respond to Andre Asselin To: "IPS Reflector (E-mail)" cc: Subject: is TargetName always mandatory or not? In section 5 of the spec, it says "If the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName.". However, in Appendix D, the description for TargetName says it is Leading Only. Should TargetName not be Leading Only, or should the text in section 5 say that TargetName must be in the initial Login Request of a leading connection? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 18:23: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 SAA05548 for ; Wed, 31 Oct 2001 18:23:28 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VN06S09422 for ips-outgoing; Wed, 31 Oct 2001 18:00:06 -0500 (EST) X-Authentication-Warning: ece.cmu.edu: majordom set sender to owner-ips@ece.cmu.edu using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ece.cmu.edu (8.11.0/8.10.2) with ESMTP id f9VMxxl09409 for ; Wed, 31 Oct 2001 17:59:59 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA104184 for ; Wed, 31 Oct 2001 16:57:20 -0600 Received: from d04nms41.raleigh.ibm.com (d04nms41.raleigh.ibm.com [9.67.228.19]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id f9VMxr881268 for ; Wed, 31 Oct 2001 17:59:53 -0500 Subject: Re: is TargetName always mandatory or not? To: "John Hufferd" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andre Asselin" Date: Wed, 31 Oct 2001 18:00:53 -0500 X-MIMETrack: Serialize by Router on D04NMS41/04/M/IBM(Release 5.0.8 |June 18, 2001) at 10/31/2001 05:59:52 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk John, WHOOPS! I was wrong; you are absolutely right that the spec says "TargetName" and not "TSID". When I was reading through it, I saw "TargetName", but read to myself "TSID". Apologies... In my defense (confusion?), however, 3.12.9 says TSID rather than TargetName is used to uniquely identify a session. Going by that, SSID + InitiatorName must be enough to uniquely identify a session. Jim Hafner pointed out to me that the I_T nexus is identified by one thing and the session is identified by another. If the two must have a 1-1 mapping in iSCSI, why are there two different identifiers? Why not just use the current definition of the I_T nexus to uniquely identify both the nexus and session (i.e. get rid of TSID)? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC John Hufferd To: Andre Asselin/Raleigh/IBM@IBMUS 10/31/2001 cc: ips@ece.cmu.edu 04:42 PM From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: is TargetName always mandatory or not?(Document link: Andre Asselin) Andre, I looked again through the document and No where could I find a statement that you claimed as "a nexus, and therefore an iSCSI session, is uniquely identified by the InitiatorName, ISID, TSID, and portal group tag". It is the InitiatorName, ISID, TSID, with the TargetName and PortalGroup. Please point out to me in the Spec (8 or above), where I can find your statement on I_T Nexus. I did find the following (please ignore for this conversation the "i" and 't" stuff): "- Session: The group of TCP connections that link an initiator with a target, form a session (loosely equivalent to a SCSI I-T nexus). TCP connections can be added and removed from a session. Across all connections within a session, an initiator sees one "target image". " " - 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). " I have not found a place where Session ID is tied to the TSID. Hence my comment that we also need to have the TargetName in the Initial Login on all Connections. . . . 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 Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: John Hufferd/San Jose/IBM@IBMUS Subject: Re: is TargetName always mandatory or not? John & Julian, How about this for the section 5 text: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The initial login request of the leading Login MAY also include the SessionType key=value pair, in which case if the SessionType is not "discovery", then the initial login request MUST also include the key=value pair TargetName. John, I disagree with your second statement: I don't see any way you could have 2 different sessions established within the same portal group with the same InitiatorName, ISID, and TSID. The spec. says that a nexus, and therefore an iSCSI session, is uniquely identified by the InitiatorName, ISID, TSID, and portal group tag. There is no mention of TargetName contributing to the identificaiton of a session. In my opinion, a non-leading connection should NOT have the TargetName, since it doesn't contribute anything. Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC John Hufferd/San To: Julian Satran/Haifa/IBM@IBMIL Jose/IBM@IBMUS cc: ips@ece.cmu.edu Sent by: Subject: Re: is TargetName always mandatory or not? owner-ips@ece. cmu.edu 10/31/2001 04:20 AM Julian, I think the TargetName should be included on the Initial Login Request on the Leading Login. It seem strange to permit the Authentication functions to proceed if perhaps the intended Target is different then the one doing the Authentication. The way it currently is written, you could pass all the Security test and then find out just before going into Full Function Phase, that it was intended for some other Target. Seems like a waste. My I think that TargetName should also be on all connections on the Initial Login Request. Here is my thinking: The SSID (ISID+TSID) is unique only with regards to a Specific Initiator and Target Node Pair. It is therefore not clear that just knowing the SSID and InitiatorName is enough to understand what session the subsequent connections are being attached to. And it is possible that the CID could be also overlapped with another session. Therefore, I think it make since to determine all this on the initial Login on every Connection, so you know at the beginning what values can be negotiated, or that are being set to the right Session. . . . 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 10/30/2001 11:33:50 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: is TargetName always mandatory or not? It is the leading login: The section 5 paragraph will read: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The leading Login request MAY also include the SessionType key=value pair in which case if the SessionType is not "discovery" then the leading Login Request MUST also include the key=value pair TargetName. Julo Andre Asselin/Raleigh/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 31-10-01 02:08 Please respond to Andre Asselin To: "IPS Reflector (E-mail)" cc: Subject: is TargetName always mandatory or not? In section 5 of the spec, it says "If the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName.". However, in Appendix D, the description for TargetName says it is Leading Only. Should TargetName not be Leading Only, or should the text in section 5 say that TargetName must be in the initial Login Request of a leading connection? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 18:25: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 SAA05573 for ; Wed, 31 Oct 2001 18:25:43 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VMWGw07406 for ips-outgoing; Wed, 31 Oct 2001 17:32:16 -0500 (EST) 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 f9VMWEl07398 for ; Wed, 31 Oct 2001 17:32:14 -0500 (EST) Received: from cisco.com (dhcp-161-44-68-189.cisco.com [161.44.68.189]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA26817 for ; Wed, 31 Oct 2001 17:32:07 -0500 (EST) Message-ID: <3BE07BD8.6DA95639@cisco.com> Date: Wed, 31 Oct 2001 16:31:52 -0600 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: is TargetName always mandatory or not? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit As I have said before, since authentication may need InitiatorName and (if not a discovery session) TargetName, both should be present in the first Login of every connection. Steve Senum John Hufferd wrote: > > Andre, > I looked again through the document and No where could I find a statement > that you claimed as "a nexus, and therefore an iSCSI session, is uniquely > identified by the InitiatorName, ISID, TSID, and portal group tag". It is > the InitiatorName, ISID, TSID, with the TargetName and PortalGroup. > > Please point out to me in the Spec (8 or above), where I can find your > statement on I_T Nexus. > > I did find the following (please ignore for this conversation the "i" and > 't" stuff): > > "- Session: The group of TCP connections that link an initiator with a > target, form a session (loosely equivalent to a SCSI I-T nexus). TCP > connections can be added and removed from a session. Across all connections > within a session, an initiator sees one "target image". " > > " - 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). " > > I have not found a place where Session ID is tied to the TSID. > > Hence my comment that we also need to have the TargetName in the Initial > Login on all Connections. > > . > . > . > 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 > > Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM > > Sent by: owner-ips@ece.cmu.edu > > To: ips@ece.cmu.edu > cc: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: is TargetName always mandatory or not? > > John & Julian, > How about this for the section 5 text: > > The initial Login request of the first connection of a session (leading > login) MUST include the InitiatorName key=value pair. The initial login > request > of the leading Login MAY also include the SessionType key=value pair, in > which case if the SessionType is not "discovery", then the initial login > request > MUST also include the key=value pair TargetName. > > John, > I disagree with your second statement: I don't see any way you could > have 2 different sessions established within the same portal group with the > same InitiatorName, ISID, and TSID. The spec. says that a nexus, and > therefore an iSCSI session, is uniquely identified by the InitiatorName, > ISID, TSID, and portal group tag. There is no mention of TargetName > contributing to the identificaiton of a session. In my opinion, a > non-leading connection should NOT have the TargetName, since it doesn't > contribute anything. > > Andre Asselin > IBM ServeRAID Software Development > Research Triangle Park, NC > > John > Hufferd/San To: Julian > Satran/Haifa/IBM@IBMIL > Jose/IBM@IBMUS cc: ips@ece.cmu.edu > Sent by: Subject: Re: is TargetName > always mandatory or not? > owner-ips@ece. > cmu.edu > > 10/31/2001 > 04:20 AM > > Julian, > I think the TargetName should be included on the Initial Login Request on > the Leading Login. It seem strange to permit the Authentication functions > to proceed if perhaps the intended Target is different then the one doing > the Authentication. The way it currently is written, you could pass all > the Security test and then find out just before going into Full Function > Phase, that it was intended for some other Target. Seems like a waste. > > My I think that TargetName should also be on all connections on the Initial > Login Request. Here is my thinking: > > The SSID (ISID+TSID) is unique only with regards to a Specific Initiator > and Target Node Pair. It is therefore not clear that just knowing the SSID > and InitiatorName is enough to understand what session the subsequent > connections are being attached to. And it is possible that the CID could > be also overlapped with another session. > > Therefore, I think it make since to determine all this on the initial Login > on every Connection, so you know at the beginning what values can be > negotiated, or that are being set to the right Session. > > . > . > . > 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 10/30/2001 11:33:50 PM > > Sent by: owner-ips@ece.cmu.edu > > To: ips@ece.cmu.edu > cc: > Subject: Re: is TargetName always mandatory or not? > > It is the leading login: > > The section 5 paragraph will read: > > The initial Login request of the first connection of a session (leading > login) MUST include the InitiatorName key=value pair. The leading Login > request MAY also include the SessionType key=value pair in which case if > the SessionType is not "discovery" then the leading Login Request MUST > also include the key=value pair TargetName. > > Julo > > Andre Asselin/Raleigh/IBM@IBMUS > Sent by: owner-ips@ece.cmu.edu > 31-10-01 02:08 > Please respond to Andre Asselin > > To: "IPS Reflector (E-mail)" > cc: > Subject: is TargetName always mandatory or not? > > In section 5 of the spec, it says "If the SessionType is not > "discovery" then the initial Login Request MUST also include the key=value > pair TargetName.". However, in Appendix D, the description for TargetName > says it is Leading Only. > Should TargetName not be Leading Only, or should the text in section > 5 > say that TargetName must be in the initial Login Request of a leading > connection? > > Andre Asselin > IBM ServeRAID Software Development > Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 18:27: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 SAA05585 for ; Wed, 31 Oct 2001 18:27:31 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VMZG607648 for ips-outgoing; Wed, 31 Oct 2001 17:35:16 -0500 (EST) 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 f9VMZEl07644 for ; Wed, 31 Oct 2001 17:35:14 -0500 (EST) Received: from cisco.com (dhcp-161-44-68-189.cisco.com [161.44.68.189]) by dogwood.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA29766 for ; Wed, 31 Oct 2001 17:35:08 -0500 (EST) Message-ID: <3BE07C8D.F57DEE77@cisco.com> Date: Wed, 31 Oct 2001 16:34:53 -0600 From: Steve Senum X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ips Subject: Re: iSCSI: is TargetName always mandatory or not? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit (This is a resend with the proper subject line) As I have said before, since authentication may need InitiatorName and (if not a discovery session) TargetName, both should be present in the first Login of every connection. Steve Senum John Hufferd wrote: > > Andre, > I looked again through the document and No where could I find a statement > that you claimed as "a nexus, and therefore an iSCSI session, is uniquely > identified by the InitiatorName, ISID, TSID, and portal group tag". It is > the InitiatorName, ISID, TSID, with the TargetName and PortalGroup. > > Please point out to me in the Spec (8 or above), where I can find your > statement on I_T Nexus. > > I did find the following (please ignore for this conversation the "i" and > 't" stuff): > > "- Session: The group of TCP connections that link an initiator with a > target, form a session (loosely equivalent to a SCSI I-T nexus). TCP > connections can be added and removed from a session. Across all connections > within a session, an initiator sees one "target image". " > > " - 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). " > > I have not found a place where Session ID is tied to the TSID. > > Hence my comment that we also need to have the TargetName in the Initial > Login on all Connections. > > . > . > . > 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 > > Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM > > Sent by: owner-ips@ece.cmu.edu > > To: ips@ece.cmu.edu > cc: John Hufferd/San Jose/IBM@IBMUS > Subject: Re: is TargetName always mandatory or not? > > John & Julian, > How about this for the section 5 text: > > The initial Login request of the first connection of a session (leading > login) MUST include the InitiatorName key=value pair. The initial login > request > of the leading Login MAY also include the SessionType key=value pair, in > which case if the SessionType is not "discovery", then the initial login > request > MUST also include the key=value pair TargetName. > > John, > I disagree with your second statement: I don't see any way you could > have 2 different sessions established within the same portal group with the > same InitiatorName, ISID, and TSID. The spec. says that a nexus, and > therefore an iSCSI session, is uniquely identified by the InitiatorName, > ISID, TSID, and portal group tag. There is no mention of TargetName > contributing to the identificaiton of a session. In my opinion, a > non-leading connection should NOT have the TargetName, since it doesn't > contribute anything. > > Andre Asselin > IBM ServeRAID Software Development > Research Triangle Park, NC > > John > Hufferd/San To: Julian > Satran/Haifa/IBM@IBMIL > Jose/IBM@IBMUS cc: ips@ece.cmu.edu > Sent by: Subject: Re: is TargetName > always mandatory or not? > owner-ips@ece. > cmu.edu > > 10/31/2001 > 04:20 AM > > Julian, > I think the TargetName should be included on the Initial Login Request on > the Leading Login. It seem strange to permit the Authentication functions > to proceed if perhaps the intended Target is different then the one doing > the Authentication. The way it currently is written, you could pass all > the Security test and then find out just before going into Full Function > Phase, that it was intended for some other Target. Seems like a waste. > > My I think that TargetName should also be on all connections on the Initial > Login Request. Here is my thinking: > > The SSID (ISID+TSID) is unique only with regards to a Specific Initiator > and Target Node Pair. It is therefore not clear that just knowing the SSID > and InitiatorName is enough to understand what session the subsequent > connections are being attached to. And it is possible that the CID could > be also overlapped with another session. > > Therefore, I think it make since to determine all this on the initial Login > on every Connection, so you know at the beginning what values can be > negotiated, or that are being set to the right Session. > > . > . > . > 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 10/30/2001 11:33:50 PM > > Sent by: owner-ips@ece.cmu.edu > > To: ips@ece.cmu.edu > cc: > Subject: Re: is TargetName always mandatory or not? > > It is the leading login: > > The section 5 paragraph will read: > > The initial Login request of the first connection of a session (leading > login) MUST include the InitiatorName key=value pair. The leading Login > request MAY also include the SessionType key=value pair in which case if > the SessionType is not "discovery" then the leading Login Request MUST > also include the key=value pair TargetName. > > Julo > > Andre Asselin/Raleigh/IBM@IBMUS > Sent by: owner-ips@ece.cmu.edu > 31-10-01 02:08 > Please respond to Andre Asselin > > To: "IPS Reflector (E-mail)" > cc: > Subject: is TargetName always mandatory or not? > > In section 5 of the spec, it says "If the SessionType is not > "discovery" then the initial Login Request MUST also include the key=value > pair TargetName.". However, in Appendix D, the description for TargetName > says it is Leading Only. > Should TargetName not be Leading Only, or should the text in section > 5 > say that TargetName must be in the initial Login Request of a leading > connection? > > Andre Asselin > IBM ServeRAID Software Development > Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 19:25: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 TAA05999 for ; Wed, 31 Oct 2001 19:25:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VNXm312087 for ips-outgoing; Wed, 31 Oct 2001 18:33:48 -0500 (EST) 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 f9VNXll12083 for ; Wed, 31 Oct 2001 18:33:47 -0500 (EST) 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 SAA22640 for ; Wed, 31 Oct 2001 18:31:13 -0500 Received: from d03nm041.boulder.ibm.com (d03nm041.boulder.ibm.com [9.99.140.41]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.98) with ESMTP id f9VNXjv202174 for ; Wed, 31 Oct 2001 16:33:45 -0700 Importance: Normal Subject: Re: is TargetName always mandatory or not? To: "Andre Asselin" Cc: ips@ece.cmu.edu From: "Jim Hafner" Date: Wed, 31 Oct 2001 15:33:43 -0800 Message-ID: X-MIMETrack: Serialize by Router on D03NM041/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/31/2001 03:33:45 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Andre, First, your comment "SSID + InitiatorName must be enough to uniquely identify a session" is target-centric. It would be different from the initiator's viewpoint. However, from the target's viewpoint, the target name is implicit and from the initiator viewpoint, the initiator name is implicit, so globally, the triple of the two names + SSID (made up of the ISID and TSID) form the identifier of the session. Locally (between two specific guys), the names are implicit so only the SSID is required. It's all a matter of point of view! As for the difference in identifiers, as I mentioned in the private note, the session is an iSCSI construct and is identified by iSCSI things. The nexus is a SCSI thing and is identified by SCSI constructs (based on how we've mapped the iSCSI things to SCSI things). However, you've brought to the fore again a related question: "what value does the TSID provide to the protocol?" I'm not going to answer that, but I will note that one target implementation that (I think) works is that the TSID = target portal group tag. The other thing to ask is "what value is there in the nexus identifier?" This is never really used in SCSI at all, so it's not a critical issue what composes it. However, it is important (IMO) that the SCSI ports have names and the logical derivative of that statement is that the nexus is identified by the concatenation of the SCSI port names (hence the definition we have). Jim Hafner Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 03:00:53 pm Sent by: owner-ips@ece.cmu.edu To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu Subject: Re: is TargetName always mandatory or not? John, WHOOPS! I was wrong; you are absolutely right that the spec says "TargetName" and not "TSID". When I was reading through it, I saw "TargetName", but read to myself "TSID". Apologies... In my defense (confusion?), however, 3.12.9 says TSID rather than TargetName is used to uniquely identify a session. Going by that, SSID + InitiatorName must be enough to uniquely identify a session. Jim Hafner pointed out to me that the I_T nexus is identified by one thing and the session is identified by another. If the two must have a 1-1 mapping in iSCSI, why are there two different identifiers? Why not just use the current definition of the I_T nexus to uniquely identify both the nexus and session (i.e. get rid of TSID)? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC John Hufferd To: Andre Asselin/Raleigh/IBM@IBMUS 10/31/2001 cc: ips@ece.cmu.edu 04:42 PM From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: is TargetName always mandatory or not?(Document link: Andre Asselin) Andre, I looked again through the document and No where could I find a statement that you claimed as "a nexus, and therefore an iSCSI session, is uniquely identified by the InitiatorName, ISID, TSID, and portal group tag". It is the InitiatorName, ISID, TSID, with the TargetName and PortalGroup. Please point out to me in the Spec (8 or above), where I can find your statement on I_T Nexus. I did find the following (please ignore for this conversation the "i" and 't" stuff): "- Session: The group of TCP connections that link an initiator with a target, form a session (loosely equivalent to a SCSI I-T nexus). TCP connections can be added and removed from a session. Across all connections within a session, an initiator sees one "target image". " " - 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). " I have not found a place where Session ID is tied to the TSID. Hence my comment that we also need to have the TargetName in the Initial Login on all Connections. . . . 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 Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: John Hufferd/San Jose/IBM@IBMUS Subject: Re: is TargetName always mandatory or not? John & Julian, How about this for the section 5 text: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The initial login request of the leading Login MAY also include the SessionType key=value pair, in which case if the SessionType is not "discovery", then the initial login request MUST also include the key=value pair TargetName. John, I disagree with your second statement: I don't see any way you could have 2 different sessions established within the same portal group with the same InitiatorName, ISID, and TSID. The spec. says that a nexus, and therefore an iSCSI session, is uniquely identified by the InitiatorName, ISID, TSID, and portal group tag. There is no mention of TargetName contributing to the identificaiton of a session. In my opinion, a non-leading connection should NOT have the TargetName, since it doesn't contribute anything. Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC John Hufferd/San To: Julian Satran/Haifa/IBM@IBMIL Jose/IBM@IBMUS cc: ips@ece.cmu.edu Sent by: Subject: Re: is TargetName always mandatory or not? owner-ips@ece. cmu.edu 10/31/2001 04:20 AM Julian, I think the TargetName should be included on the Initial Login Request on the Leading Login. It seem strange to permit the Authentication functions to proceed if perhaps the intended Target is different then the one doing the Authentication. The way it currently is written, you could pass all the Security test and then find out just before going into Full Function Phase, that it was intended for some other Target. Seems like a waste. My I think that TargetName should also be on all connections on the Initial Login Request. Here is my thinking: The SSID (ISID+TSID) is unique only with regards to a Specific Initiator and Target Node Pair. It is therefore not clear that just knowing the SSID and InitiatorName is enough to understand what session the subsequent connections are being attached to. And it is possible that the CID could be also overlapped with another session. Therefore, I think it make since to determine all this on the initial Login on every Connection, so you know at the beginning what values can be negotiated, or that are being set to the right Session. . . . 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 10/30/2001 11:33:50 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: is TargetName always mandatory or not? It is the leading login: The section 5 paragraph will read: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The leading Login request MAY also include the SessionType key=value pair in which case if the SessionType is not "discovery" then the leading Login Request MUST also include the key=value pair TargetName. Julo Andre Asselin/Raleigh/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 31-10-01 02:08 Please respond to Andre Asselin To: "IPS Reflector (E-mail)" cc: Subject: is TargetName always mandatory or not? In section 5 of the spec, it says "If the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName.". However, in Appendix D, the description for TargetName says it is Leading Only. Should TargetName not be Leading Only, or should the text in section 5 say that TargetName must be in the initial Login Request of a leading connection? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 19: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 TAA06157 for ; Wed, 31 Oct 2001 19:40:06 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id f9VNXDQ12028 for ips-outgoing; Wed, 31 Oct 2001 18:33:13 -0500 (EST) 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 f9VNXBl12023 for ; Wed, 31 Oct 2001 18:33:11 -0500 (EST) 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 SAA12648 for ; Wed, 31 Oct 2001 18:30:37 -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 f9VNX9v202104 for ; Wed, 31 Oct 2001 16:33:09 -0700 X-Priority: 1 (High) Importance: Normal Subject: Re: is TargetName always mandatory or not? To: "Andre Asselin" Cc: ips@ece.cmu.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John Hufferd" Date: Wed, 31 Oct 2001 15:32:26 -0800 X-MIMETrack: Serialize by Router on D03NM065/03/M/IBM(Release 5.0.8 |June 18, 2001) at 10/31/2001 04:33:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ips@ece.cmu.edu Precedence: bulk Andre, TSID, and therefore SSID is a handle that can be use to queue stuff within the scope of the Initiator Node and Target Node. The target can use what ever it wants in this field. Some Folks might want to use the TSID to be the Portal Group Tag and I think then it might be unique. But even then only within the InitiatorName+ISID Space. Anyway, you need to think of it only as a handle. Also since most folks will not have 64k Sessions into their box, some (most?) implementations might find it unique. But it is not unique in the Architecture. Now the important thing is that, as things stand now, the Login needs the InitiatorName, and the TargetName on the Initial Login of ALL Connections in order to uniquely identify secondary Connections to the Original Connection of the Session. Does that seem correct to you and others on the Reflector? . . . 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 Andre Asselin 10/31/2001 03:00 PM To: John Hufferd/San Jose/IBM@IBMUS cc: ips@ece.cmu.edu From: Andre Asselin/Raleigh/IBM@IBMUS Subject: Re: is TargetName always mandatory or not? (Document link: John Hufferd) John, WHOOPS! I was wrong; you are absolutely right that the spec says "TargetName" and not "TSID". When I was reading through it, I saw "TargetName", but read to myself "TSID". Apologies... In my defense (confusion?), however, 3.12.9 says TSID rather than TargetName is used to uniquely identify a session. Going by that, SSID + InitiatorName must be enough to uniquely identify a session. Jim Hafner pointed out to me that the I_T nexus is identified by one thing and the session is identified by another. If the two must have a 1-1 mapping in iSCSI, why are there two different identifiers? Why not just use the current definition of the I_T nexus to uniquely identify both the nexus and session (i.e. get rid of TSID)? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC John Hufferd To: Andre Asselin/Raleigh/IBM@IBMUS 10/31/2001 cc: ips@ece.cmu.edu 04:42 PM From: John Hufferd/San Jose/IBM@IBMUS Subject: Re: is TargetName always mandatory or not? (Document link: Andre Asselin) Andre, I looked again through the document and No where could I find a statement that you claimed as "a nexus, and therefore an iSCSI session, is uniquely identified by the InitiatorName, ISID, TSID, and portal group tag". It is the InitiatorName, ISID, TSID, with the TargetName and PortalGroup. Please point out to me in the Spec (8 or above), where I can find your statement on I_T Nexus. I did find the following (please ignore for this conversation the "i" and 't" stuff): "- Session: The group of TCP connections that link an initiator with a target, form a session (loosely equivalent to a SCSI I-T nexus). TCP connections can be added and removed from a session. Across all connections within a session, an initiator sees one "target image". " " - 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). " I have not found a place where Session ID is tied to the TSID. Hence my comment that we also need to have the TargetName in the Initial Login on all Connections. . . . 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 Andre Asselin/Raleigh/IBM@IBMUS@ece.cmu.edu on 10/31/2001 10:40:55 AM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: John Hufferd/San Jose/IBM@IBMUS Subject: Re: is TargetName always mandatory or not? John & Julian, How about this for the section 5 text: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The initial login request of the leading Login MAY also include the SessionType key=value pair, in which case if the SessionType is not "discovery", then the initial login request MUST also include the key=value pair TargetName. John, I disagree with your second statement: I don't see any way you could have 2 different sessions established within the same portal group with the same InitiatorName, ISID, and TSID. The spec. says that a nexus, and therefore an iSCSI session, is uniquely identified by the InitiatorName, ISID, TSID, and portal group tag. There is no mention of TargetName contributing to the identificaiton of a session. In my opinion, a non-leading connection should NOT have the TargetName, since it doesn't contribute anything. Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC John Hufferd/San To: Julian Satran/Haifa/IBM@IBMIL Jose/IBM@IBMUS cc: ips@ece.cmu.edu Sent by: Subject: Re: is TargetName always mandatory or not? owner-ips@ece. cmu.edu 10/31/2001 04:20 AM Julian, I think the TargetName should be included on the Initial Login Request on the Leading Login. It seem strange to permit the Authentication functions to proceed if perhaps the intended Target is different then the one doing the Authentication. The way it currently is written, you could pass all the Security test and then find out just before going into Full Function Phase, that it was intended for some other Target. Seems like a waste. My I think that TargetName should also be on all connections on the Initial Login Request. Here is my thinking: The SSID (ISID+TSID) is unique only with regards to a Specific Initiator and Target Node Pair. It is therefore not clear that just knowing the SSID and InitiatorName is enough to understand what session the subsequent connections are being attached to. And it is possible that the CID could be also overlapped with another session. Therefore, I think it make since to determine all this on the initial Login on every Connection, so you know at the beginning what values can be negotiated, or that are being set to the right Session. . . . 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 10/30/2001 11:33:50 PM Sent by: owner-ips@ece.cmu.edu To: ips@ece.cmu.edu cc: Subject: Re: is TargetName always mandatory or not? It is the leading login: The section 5 paragraph will read: The initial Login request of the first connection of a session (leading login) MUST include the InitiatorName key=value pair. The leading Login request MAY also include the SessionType key=value pair in which case if the SessionType is not "discovery" then the leading Login Request MUST also include the key=value pair TargetName. Julo Andre Asselin/Raleigh/IBM@IBMUS Sent by: owner-ips@ece.cmu.edu 31-10-01 02:08 Please respond to Andre Asselin To: "IPS Reflector (E-mail)" cc: Subject: is TargetName always mandatory or not? In section 5 of the spec, it says "If the SessionType is not "discovery" then the initial Login Request MUST also include the key=value pair TargetName.". However, in Appendix D, the description for TargetName says it is Leading Only. Should TargetName not be Leading Only, or should the text in section 5 say that TargetName must be in the initial Login Request of a leading connection? Andre Asselin IBM ServeRAID Software Development Research Triangle Park, NC From owner-ips@ece.cmu.edu Wed Oct 31 20:59: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 UAA07308 for ; Wed, 31 Oct 2001 20:59:53 -0500 (EST) Received: (from majordom@localhost) by ece.cmu.edu (8.11.0/8.10.2) id fA11C4218799 for ips-outgoing; Wed, 31 Oct 2001 20:12:04 -0500 (EST) 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 fA11C1l18779 for ; Wed, 31 Oct 2001 20:12:01 -0500 (EST) Received: from trebiaazner66z (student3-145.unh.edu [132.177.65.145]) by lucy.trebia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id V875QP25; Wed, 31 Oct 2001 20:11:29 -0500 Message-ID: <001b01c16269$c2275410$9141b184@trebiaazner66z> From: "Anshul Chadda" To: Subject: Fw: iSCSI: current UNH Plugfest Date: Wed, 31 Oct 2001 19:11:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ips@ece.cmu.edu Precedence: bulk Content-Transfer-Encoding: 7bit My intent in making the MUST requirement is to make target send the sense data along if it is setting the CHECK CONDITION in SCSI Response PDU (to support and enable AutoSense). If we are making the iSCSI standard tight enough to make target "support and enable AutoSense" (Clause 3.4.6, para 1 in draft 8), why not make a requirement for target to send sense data if CHECK Condition is set (to make fully tight). I am not even addressing situations that can happen on the initiator side. Also, it is upto the initiator to handle a situation where SCSI Response PDU has CHECK CONDITION set but no sense data with it. There are many reasons why this can happen, one reason can be data digest error as you pointed out. And the MUST requirement should not make the initiator assume things if the SCSI Response PDU has the CHECK condition set. Regards, Anshul ----- Original Message ----- From: "Santosh Rao" To: Sent: Wednesday, October 31, 2001 4:41 PM Subject: Re: iSCSI: current UNH Plugfest > > Robert Snively wrote: > > > > Sense Data will never be generated in a data segment to any command except > > REQUEST SENSE. In that case, CHECK CONDITION will never > > be indicated unless the REQUEST SENSE command failed in > > some way, and (if autosensing is used), the CHECK CONDITION > > will be associated with its own set of sense information in > > the response PDU. > > The SCSI sense data is contained in the data segment of the SCSI > Response pdu. Hence, it is possible for the initiator to receive the > header of the scsi response pdu containing the SCSI Status, but not the > data segment (sense data) of the scsi response pdu, due to a data digest > error. > > - Santosh > > > -- > > ################################## > > Santosh Rao > > Software Design Engineer, > > HP-UX iSCSI Driver Team, > > Hewlett Packard, Cupertino. > > email : santoshr@cup.hp.com > > Phone : 408-447-3751 > > ################################## >
-----Original Message-----
From: = owner-ips@ece.cmu.edu=20 [mailto:owner-ips@ece.cmu.edu]On Behalf Of Julian=20 Satran
Sent: Tuesday, October 09, 2001 2:45 PM
To: = ips@ece.cmu.edu
Subject: Re: Addition of CmdSN in Data-out=20 PDU


Inconsistency can be=20 legitimate. CmdSN is ephemeral. It can be reused, it may have large = holes and=20 using it in an implementation is as bad as a hashed index. =
I you want to pursue this please forward a = draft=20 showing what the distinct application advantages are to the = list.=20
It can include pseudo-code, = flowcharts or=20 whatever else you think that you need to convince the list.=20

Julo


Paul Koning=20 <pkoning@jlc.net>=20

09-10-01 21:59 =
Please respond to Paul Koning =

        =
        To: =    =20    andy@windriver.com
        cc:       =  Julian=20 Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
        Subject:     =  =20  Re: Addition of CmdSN in Data-out PDU

     =20  


Excerpt of message (sent 9 October 2001) by andy = currid:
>=20
> Julian, all
>
> I second Matthew's request to = have CmdSN=20 present in DataOut PDUs.
> ...
> When receiving = unsolicited=20 DataOut PDUs, a target must currently use
> the ITT to determine = the=20 command with which the DataOut is associated.
> In the absence = of=20 hardware assist such as a CAM, a target implementation
> must = search a=20 list of non-final commands currently queued within the
> session = to=20 match the ITT. When many such commands are queued (which ought
> = to be=20 the case for performant implementations), that search will = relatively
>=20 inefficient, no matter how the search is optimized (binary search,=20 hash
> table, etc.).

I'll add my voice to the set. =  Andy's=20 arguments make perfect sense.
Lookups on unstructured IDs are a = pain.=20  Hashing can be fast, but hash
table changes typically aren't. =  The nasty case is a lookup on a set
of unstructured IDs that = changes=20 very rapidly, which is exactly the
case we have here.

> = Placing=20 CmdSn in DataOut will allow a target to instantly access the
> = queued=20 command with which an unsolicited DataOut is associated, = without
>=20 performing a search. Mapping from a CmdSN into a queue location = within
>=20 the target is almost certainly a constant time=20 operation.

Exactly.

> I don't see any performance = issues with=20 making this change. I don't
> think it's a big imposition on an=20 initiator to include the associated
> CmdSN in a DataOut PDU. Do = any=20 initiator implementors feel this would
> be a problem?
> =
>=20 On the target end, I don't think consistency checking is an issue. In=20 a
> solicited data out carrying CmdSN, targets would be free to = ignore=20 CmdSN
> and simply use TTT as they do today. There's no = obligation to=20 verify
> CmdSN is consistent with the DataOut's associated = command,=20 though such
> a check is likely to be cheap.

Consistency = checking=20 could be left out entirely if we wish.  That
would be my = inclination.=20  Or it could be made optional -- or even, if
people insist, = mandatory.=20  It's very cheap if that's done.  The
response to an=20 inconsistency should be harsh (terminate the session,
for example) = because=20 it will only happen if the sender is defective.

   =20 paul