Re: iSCSI: session login and ISID

[Sandeep Joshi <sandeepj@research.bell-labs.com>]

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

Stephen Bailey wrote:
> 
> 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