Re: iSCSI: session login and ISID

[Stephen Bailey <steph@cs.uchicago.edu>]

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

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

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

> The WWUI is also needed if we are to support multiple I_T nexuses 
> 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