Subject: iSCSI: session login and ISID

From: [email-masked] (Sandeep Joshi)
Date: Mon, 9 Apr 2001 13:27:46 -0400 (EDT)

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: Stephen Bailey <[email-masked]>
Date: Wed, 11 Apr 2001 10:35:56 -0400

Sandeep,

> One of those attempts will get rejected, since the ISID is the sole
> key to find if a session already exists.

As Julian mentioned, TSID is actually the key a target uses to
associate a login to an existing session.  ISID is an opaque (to the
target) convenience to the initiator.

> (note: TSID was sent as zero for the leading connection of session)

The allocated TSID from a leading login is returned in the Login
Response(es).

> to connect during the login phase".

Hm.  There does seem to be a contradiction.  I prefer the 1.2.7
stipulation for esoteric reasons which will either be revealed
eventually (in which case, they must have been intrinsically correct)
or squashed like a bug (in which case they are irrelevant).

> between the same initiator and target.  

I don't see this.  I agree that we want to allow an arbitrary number
of sessions between a pair of targets.  Julian says it's an open
issue.  I don't see why.  Perhaps he's referring to the fact that we
do want to discourage the use of multiple connections (or sessions)
between an I and a T simply for the purposes of winning a bigger share
of a congested network link.

As far as I can tell, the (possibly between the lines) specified
mechanism supports multiple connections and sessions between an I and
a T.  If an initiator wants a new session, it sets TSID == 0, and it
gets a new session.  No reason why it couldn't have multiple
connections between the same endpoints within a session too.

Steph

---

From: Sandeep Joshi <[email-masked]>
Date: Wed, 11 Apr 2001 11:40:59 -0400

Stephen,

Yes, I did see the elegance of the generating sessionID=ISID+TSID 
(rudimentary diffie-hellman)

The questions have been resolved...I was looking for a way to
track initiator sessions at the target but misread appendix D to 
think initiatorWWUI is optional (its optional only for the target 
which seems fine).

thanks,
-Sandeep