Subject: Re: iSCSI: session login and ISID

From: "John Hufferd" <[email-masked]>
Date: Tue, 10 Apr 2001 09:54:14 -0700

Pierre, et.al.
There should be no reason that a specific OS, can not have multiple session
to the same Target, as long as the ISID is different.  It is up to the
installation/vendor to determine how to arrive at ISID.  They can also
determine that they want each iSCSI HBA to have a different ISID, and
arrive at unique ISIDs for each.  Then, as we talked, months and months
ago, it is then up to a Wedge Driver to sort out who get what requests, and
attempts to do load balancing.

The wedge driver is needed to make sure that the application does not have
to care which Session it is connected too, since they have no way to
specify it anyhow.  That is, the wedge driver needs to insure that it sends
no I/O to a LU on a specific session if it has sent previous I/O to that
same LU, on a different session, and still has its I/O outstanding.
Otherwise, out of order things will happen.  But this is a fairly easy
thing to handle in the  Wedge Driver.  There are some issues with
Persistence Reserve, but those can be handled also, by sending LU's I/O to
the Reserved LUs only on the same Session, on which the Reserve was issued.

Remember, it is only the multiple connections per session model that does
not require the Wedge Driver in order handle multiple connections.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: [email-masked]

Pierre Labat <[email-masked]>@ece.cmu.edu on 04/10/2001 08:12:22 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: iSCSI: session login and ISID

[email-masked] wrote:

> WWUI can be presented during login phase (2.10.9 is correct and in-line
> with 1.2.7) Two sesions can have the same ISID but will have different
> TSID. The question of whether more than one session should be allowed
> between a pair of wuis is under debate.
>

I think that several sessions should be allowed between a pair of wwuis
at least to handle the simple case where the initiator and the target have

two adapters each and each session wants to use a pair of adapter.

Regards,

Pierre

>
> Julo
>
> [email-masked] (Sandeep Joshi) on 09/04/2001 20:27:46
>
> Please respond to [email-masked] (Sandeep Joshi)
>
> To:   [email-masked]
> cc:
> Subject:  iSCSI: session login and ISID
>
> There seems to be a problem in distinguishing session logins, using
> only the ISID field in the Login Command.   It is possible that
> different initiators could try to start a session using the same ISID
> value.   One of those attempts will get rejected, since the ISID is
> the sole key to find if a session already exists. (note: TSID was
> sent as zero for the leading connection of session)
>
> The initiator WWUI does not seem to be available at this time.
> a) Appendix D.10 states that InitiatorWWUI is optional and defaults
>    to iSCSI.
> b) Section 2.10.9 on Login Command states that "initiator MAY provide
>    some basic parameters".
>
> On the other hand, Section 1.2.7 states that "the initiator MUST
> present both its initiator WWUI and target WWUI to which it wishes
> to connect during the login phase".
>
> The WWUI is also needed if we are to support multiple I_T nexuses
> between the same initiator and target.
>
> So it seems like Section 1.2.7 has the right spec.   Appendix D and
> Section 2.10.9 must then be corrected.  The descriptions in Sec 4.1
> and Section 1.2.3 may also need to be changed to reflect the fact
> that initiator WWUI must be supplied at session login.
>
> -Sandeep

---

From: "Jim Hafner" <[email-masked]>
Date: Wed, 11 Apr 2001 13:27:28 -0700

Folks,

As the one that started the debate (somewhat privately) on whether one or
more sessions can be allowed between the same two named guys, I think I'd
better cut in here.

I'll warn you that I'm going to be vague and skip a lot of the details.

The N&DT is debating the (critical in my opinion) mapping of the SCSI
Architecture constructs of SCSI Device, SCSI Port, SCSI Nexus and the
constructs of iSCSI (things with "unique names", sessions, etc.).   This
has consequences to reservations, scsi access controls, unit attention
conditions,etc.(all those things that are essentially nexus state).  To
complicate matters, SAM-2 is evolving as we speak.

One has to keep in mind that SCSI is NOT completely stateless with respect
to individual IOs (e.g., they are not self-authenticating).  E.g., a given
IO is allowed to proceed ONLY if the nexus on which it is sent is not
blocked by some reservation state on another nexus.

Now we come to the crux of the issue. In my opinion, there is a fundamental
assumption (not explicitly stated) in the SCSI architecture that there
never exist more than one nexus between the same two (named or addressed)
SCSI Ports.  Parallel and FCP get this for free because of protocol layer
constructs/limitations.   In my opinion, iSCSI needs to make a similar
restriction to meet this requirement.  (Why SAM-x needs it at all is rooted
in the nexus state; I could go into that, but I won't unless pressed,
preferably offline.)

The net of this is that whatever mapping of SAM-2 terms to iSCSI terms we
pick, there will need to be imposed some limitations on sessions (not clear
what yet) to meet this requirement.

The N&DT will soon be offering one approach to the mapping and the
resulting requirements.  Hopefully, it will meet everyone's requirements.

Jim Hafner

"Somesh Gupta" <[email-masked]>@ece.cmu.edu on 04-11-2001 11:57:04 AM

Please respond to <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL, <[email-masked]>
cc:
Subject:  RE: iSCSI: session login and ISID

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Tuesday, April 10, 2001 4:22 AM
> To: [email-masked]

Why are we debating this? Multiple sessions (one
connection per session) is a simpler, more robust and higher
performance model than multiple connections per session.

Somesh
> that initiator WWUI must be supplied at session login.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Santosh Rao <[email-masked]>
Date: Wed, 25 Apr 2001 17:01:45 -0700

> To: [email-masked], <[email-masked]> 
> From: "Jim Hafner" <[email-masked]> 
> Date: Wed, 11 Apr 2001 13:27:28 -0700 
                            
> Now we come to the crux of the issue. In my opinion, there
> is a fundamental assumption (not explicitly stated) in the
> SCSI architecture that there never exist more than one  
> nexus between the same two (named or addressed) SCSI Ports. 

Jim,

Is it not the case that the Service Delivery Port (a.k.a. SDP) comprises
of a (WWUI + session id). If this is correct, then, multiple sessions
for a given pair of WWUIs is not an attempt to establish 2 I-T nexus b/n
the same 2 names or addressed SCSI ports.

It would be 2 I-T nexus b/n 2 initiator SDPs and 2 target SDPs.

As indicated in my earlier mail on this subject, multiple sessions b/n a
given pair of WWUIs is required to deal with the following type of
configurations :

- host with 2 iSCSI initiator SDPs, init1 & init2.
- target with 2 iSCSI SDPs, tgt1 & tgt2.
- single connection sessions established as follows :
 init1 - tgt1
 init2 - tgt2

All the LUs of a target are seen through 2 different paths and these are
exported to upper layer wedge drivers that handle path failover and load
balancing. 

Failure to allow the above configuration would imply that iSCSI is
breaking wedge driver functionality as also requiring the deployment of
multi-connection session in order to achieve path failover and load
balancing features.

Regards,
Santosh

> Parallel and FCP get this for free because of protocol layer
> constructs/limitations. In my opinion, iSCSI needs to make a 
> similar restriction to meet this requirement.  (Why SAM-x needs 
> it at all is rooted in the nexus state; I could go into that, 
> but I won't unless pressed, preferably offline.)