Subject: RE: iSCSI: multiple sessions b/n a pair of WWUIs.

From: "John Hufferd" <[email-masked]>
Date: Mon, 7 May 2001 20:58:14 -0700

David,
let me argue another side.  I was about to send my version of what Jim
said, but I think Jim, as usual was "dead on".  It is important to be
completely correct here.  This direction seemed to be having an influence
on MIBs and other things.  Though it is possible to do what you suggest, I
would say that doing so causes unintentional thought problems.  That is,
it is important that the Initiator Side (or the Target Side)  have a way
that the Management/Configuration Software can tell the iSCSI Port what the
iSCSI Node Name is, and what ISID value (or Range) should be used.  This is
true if the iSCSI Port is a SW entity or a HW iSCSI Host Bus Adapter (HBA).

It is much simpler for an iSCSI Port to use one ISID for every session it
creates to any target, then to have an algorithm for deriving one.  (Yes, I
know someone has to do that, but I think it should be done at the
Configuration Software level instead of at the iSCSI Port level.)

Also, since a second session by the same iSCSI Initiator Port, to the same
iSCSI Target Port is not, in my opinion "legal", it is not clear to me that
any given iSCSI Port needs any more then one ISID.  If we say anything
else, I think we risk the danger of mixing the concept of Wedge Driver in
with the concept of iSCSI Port, and that will do us all a disservice.

Some folks are going to want to define Wedge Drivers, and there should be
no interfering thought that some how the same iSCSI Initiator Port can have
Multiple Sessions to the same iSCSI Target Port (this is the domain of
Multiple Connections per Session).  Wedge Drivers, if needed, should be
seen as something that span iSCSI Initiator Ports and address specific
iSCSI Target Ports.  (Implementations may blur the levels here, but the
concepts should be clear.)

Therefore, I suggest that we Not put any such notes, like you suggest, in
the draft, but in fact encourage a single ISID/TSID per iSCSI
Initiator/Target Port.

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

[email-masked]@ece.cmu.edu on 05/07/2001 07:52:08 PM

Sent by:  [email-masked]

To:   Jim Hafner/Almaden/IBM@IBMUS, [email-masked]
cc:   [email-masked]
Subject:  RE: iSCSI: multiple sessions b/n a pair of WWUIs.

While Jim's correct ... in Marj's defense, what
she wrote is a fairly obvious way to implement
it, and that might be worth noting in the draft.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

> -----Original Message-----
> From:   Jim Hafner [SMTP:[email-masked]]
> Sent:   Monday, May 07, 2001 10:44 PM
> To:     KRUEGER,MARJORIE (HP-Roseville,ex1)
> Cc:     [email-masked]
> Subject:     RE: iSCSI: multiple sessions b/n a pair of WWUIs.
>
>
> Marj,
>
> I think you've stretched my words too far.  The requirement is for a
> single
> logical unit to recover enough identity information provided through the
> I_T_L nexus to reestablish the reservation.  That means that the
name+ISID
> must be unique *from the viewpoint of a single iSCSI target device*.  So
> it's more like the
> "initiator must have unique ISID for all sessions with <delete>all
> targets</delete> any given target device".
>
> The best way to think about this is the following:
> 1) only a single target's (actually logical unit's) view of the initiator
> counts in this regard
> 2) there are no rules in SCSI concerning multi-target device interactions
> In other words, for these rules, look only from inside a target going
out.
>
> Jim Hafner
>
>
> "KRUEGER,MARJORIE (HP-Roseville,ex1)"
> <[email-masked]>@ece.cmu.edu
> on 05/04/2001 05:39:35 PM
>
> Sent by:  [email-masked]
>
>
> To:   "'Matt Wakeley'" <[email-masked]>, [email-masked]
> cc:
> Subject:  RE: iSCSI: multiple sessions b/n a pair of WWUIs.
>
>
>
> > One clarification: these are unique between any I-T *pair*.
> > (you make it sound like an initiator must have a unique ISID
> > for all sessions
> > with all targets)
> >
> > -Matt
>
> The ISID must be unique within the iSCSI layer on an iSCSI device - that
> amounts to "initiator must have unique ISID for all sessions with all
> targets".
>
> To quote Jim "The requirement in name+disc that a given initiator name
> cannot reuse an ISID for two different sessions comes as a consequence a
> number of things (which are described in the draft).  The gist is that
> this
> is needed to provide the correct context for restoration of reservations
> state (and other nexus state) to a particular nexus after logout/login.
In
> other words, if the session goes down for some reason, the target needs
> clear context to restore nexus state to a rebuilt session. The only tool
> it
> has is uniqueness of Name+ISID combination within its name space."
>
> -Marj
>
>

---

From: Santosh Rao <[email-masked]>
Date: Tue, 08 May 2001 11:03:27 -0700

Douglas Otis wrote:

>  The usefulness of ISID is also
> diminished if the client is not expected to maintain this value as unique
> across all Targets.

I agree with the above and have stated to similar effect in my response
to Matt. A practical usage of ISID within an initiator node name space
is to assign it as unique across all targets, allowing the same ISID to
be used as a lookup key of the session for any given target port/node.

Not applying uniqueness in ISID assignment across all targets would then
require initiators to implement a second key mechanism for target
lookup.

- Santosh

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 8 May 2001 10:44:47 -0700

John,

I am a bit confused by your comments.  From my understanding, the Initiator
model is now multi-port where each service port is identified by Initiator
Label+ISID.  Where I agree the essential aspect required by the Target is to
have a unique means of identifying the Initiator, the added requirement of
ensuring ISID is unique for all Targets does not detract from this essential
requirement stated by Jim.  With a multi-port model, an Initiator can indeed
have multiple sessions.  With the abstract service port, the need for the
wedge driver changes as the service port is no longer tied to physical
hardware.  This abstraction does the right thing unlike those that attached
to the physical hardware.

It is really hinged on how you wish the database held in the Initiator
sorted: ISID or Target Label.  It seems appropriate to attach structures on
those ISIDs that represent reconnections or reservations.  On the other
hand, you seem to be advocating a name list.  The usefulness of ISID is also
diminished if the client is not expected to maintain this value as unique
across all Targets.

Doug

---

From: Santosh Rao <[email-masked]>
Date: Tue, 08 May 2001 17:53:03 -0700

Santosh Rao wrote:

> As for the uniqueness of ISID across all initiators, is there any reason
                                       ^^^^^^^^^^^^^^^
should read "across all targets"

> not to allow implementations to do that ? I would have thought that is
> the most typical use of an ISID and also allows initiators to lookup
> their target structures based on ISID.

---

From: Santosh Rao <[email-masked]>
Date: Tue, 08 May 2001 17:44:41 -0700

John,

By the name-disc definition, an iSCSI initiator or target port is a
logical entity that constitutes the end points of a session.

Hence, there never can be 2 sessions b/n the *same* 2  initiator &
target port. Each session established spawns a *new* initiator and
target iSCSI port.

Going by the above semantics, there is always only 1 ISID/TSID per iSCSI
Initiator/Target port. 

Hence, I'm unable to understand your statements below.

Regards,
Santosh

John Hufferd wrote:
> any given iSCSI Port needs any more then one ISID.  I
>