Re: iSCSI: definition of TSID (2.11.4 of draft 07)

["Mallikarjun C." <cbm@rose.hp.com>]

Jim,

Sorry, I was travelling, so couldn't get back sooner.  Let me say first 
off that I am not disagreeing with you, only suggesting more explicit
wording.

I see that the text you sent offline does contain "assumption A" stated
explicitly - thanks.  I believe that's necessary since one could very
well
attach new connections to an existing SSID when its uniqueness is
maintained
between just the target portal group and the initiator. 

I am still though missing the rationale for mandating uniqueness of SSID
between the target (across all portals) and initiator.  I assume target 
knows the portal group based on which IP address the login arrives on - 
eventhough not explicitly carried in the payload.

Coming to my harping on the nexus identifier, there are two reasons -
    -  It seems to provide a nice rationale for the above issue (refer
       to my previous mail at the bottom on how).  Please set me
straight
       if I am totally ignoring something I shouldn't.
    -  You stated that iSCSI is the first transport which opens the 
       possibility of "parallel nexus" and so iSCSI mandates
implementations
       not to allow it - but appears to stop short of specifying an
       identifier/means to enforce this mandatory requirement.  May be
       it's just me who is troubled by this...

Regards.
-- 
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668 Hewlett-Packard, Roseville.
cbm@rose.hp.com

       
Jim Hafner wrote:
> 
> Mallikarjun,
> 
> There are two assumptions that go into the model and requirements (as I see
> it).  One is currently implicit in draft-07 and is an iSCSI issue, the
> other is a bit more explicit and is a SCSI issue with iSCSI implications.
> These are
> 
> A) (Uniqueness of SIDs) Between a given iSCSI Initiator Node and iSCSI
> Target Node there can be only one session with a given SID.  [This is
> implied by the language that says that a login attempt that uses an
> existing SID=ISID||TSID is an attempt to *add* a connection to the existing
> session. (This is the response I got from Julian when I suggested making
> this explicit.)
> 
> B) (No parallel I_T nexus) Between a given SCSI Initiator Port and SCSI
> Target Port there can be only one nexus.  [With the definition of SCSI
> Initiator Port as the endpoint of a session identified by iSCSI Initiator
> Name + ISID, and with the definition of the SCSI Target Port as the target
> portal group identified by the iSCSI Target Name + portal group tag, we get
> the ISID RULE as stated (or intended) in the draft.]
> 
> The minimalist requirement is to meet the these two rules (assumptions).
> 
> There is a typo in the text you quote.  It should read "The TSID name space
> of the iSCSI Target should be partitioned among the target portal groups".
> But as we've discussed this really less of a requirement than it is a
> desirable "note to implementers" (and I'm going to propose that this sort
> of text move to that section).
> 
> In what you say below, the "no parallel nexus" (assumption B) is enforced
> by the ISID RULE.  Assumption A (uniquely identified sessions) is enforced
> if the target does the right thing when selecting a TSID *to pair with* an
> ISID.  My text for the definition of TSID simply says that the target
> should find a new TSID that enforces Assumption A (no more and no less).
> All the stuff about partitioning name space belongs in "notes to
> implementers".  So, between my proposed definition of TSID and the ISID
> RULE, both assumptions are satisfied and the model works.  No finer
> restrictions are required *by the model*.
> 
> Note that in all this description, we haven't had to provide a formal
> definition of "nexus identifier".
> The reason is two fold.  First, independent of what we might use to
> identify them, the I_T nexus is defined as a relationship between a SCSI
> Initiator Port and a SCSI Target Port.  Assumption B says we can't have two
> such relationships active at one time.  As I've noted above, the ISID RULE
> enforces that.  Second, the nexus identifier doesn't get used in SAM-2
> explicitly anyway and in SAM-3 it will probably be "up to the transport to
> define AND relative to the viewpoint of the initiator or target".  That
> last part means that the nexus identifier may not need a globally unique
> value, but may depend on whose end of the nexus you're looking from.  E.g.,
> the target side need only track the "relative target port" and need not
> care about the external address/name/identifier of that port when defining
> its value for the nexus identifier.  In short, the nexus identifier issue
> is tangential (and we can safely skip it formally).
> 
> Jim Hafner
> 
> [P.S. See also the proposed rewrite of the relevant draft sections in the
> stuff I sent you off-line, as well, and see if that doesn't help clarify.]
> 
> "Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 06:20:16 pm
> 
> Please respond to cbm@rose.hp.com
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
> 
> Jim,
> 
> Thanks for the explanation.
> 
> >The model says that the *combination of ISID || TSID* has to be unique
> >between a given initiator and a given target.
> 
> Actually, I do not find this formulation stated anywhere
> in rev07.
> 
> The closest about TSID assignment policy is this sentence
> in section 1.5.3: "The TSID name space of the iSCSI Initiator
> should be partitioned among the target portal groups."
> My earlier comments were based on this quote.
> 
> More importantly, let me try to understand the reasoning
> behind this formulation.  The only reason that I could come
> up with is to preclude a "parallel nexus".  In our previous
> conversation, we identified two types of nexus ids for this
> enforcement - a)InitiatorName-ISID-TargetName-TargetPortalGroupTag
> b)SSID-InitiatorName-TargetName.  By choosing the stated
> formulation (in conjunction with the ISID RULE), are you
> attempting to ensure that a parallel nexus cannot be created
> if one goes with either definition?
> 
> Thanks.
> --
> Mallikarjun
> 
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668   Hewlett-Packard, Roseville.
> cbm@rose.hp.com
> 
> >Mallikarjun,
> >
> >What you suggest is *more* than is required for uniqueness!  Again, that's
> >an implementation choice that goes beyond the model.
> >
> >The model says that the *combination of ISID || TSID* has to be unique
> >between a given initiator and a given target.
> >When you say " If there are multiple sessions with an initiator, each
> would
> >anyway be assigned a different TSID"  you are assuming that the TSID alone
> >provide the uniqueness (between a pair).   It can, but it's more than is
> >necessary.
> >
> >In short, you're still selecting an implementation.   Here's two other
> >implementations.  Suppose I have exactly one Target Portal Group.  Then I
> >can meet the uniqueness requirements by (a) enforcing the ISID RULE and
> (b)
> >using TSID=1 *for every session*!  This one is "minimalist" with respect
> to
> >the model.  (Because there is only one portal group, I can leverage the
> >uniqueness of the ISID to meet the general uniqueness rule -- it's very
> >different if I have more portal groups (see note below)) The "maximalist"
> >implementation with respect to the model is (a) enforce the ISID RULE and
> >(b') use a unique TSID for each session I have regardless of initiator
> >name!
> >
> >The spec should say what is required to implement the model.  In my mind,
> >that's the rule that says the combination of ISID and TSID (the SID) must
> >be unique between a pair (initiator and target).   And that's all I'm
> >asking for in the definition of TSID.
> >
> >Jim Hafner
> >
> >Note: If I had more than one portal group, I might legitimately see the
> >same ISID (from the same initiator) come in to each portal group.  In that
> >case, I need to use a different TSID for each such occurrence.  If I say,
> >for example, that each portal group always uses it's portal group tag as
> >it's TSID (not required, just a choice), then I get uniqueness of SID's
> >again.  This is again, a minimalist implementation with respect to the
> >model.   This also gives an example of why the TSID namespace "should" be
> >partitioned between the portal groups, so they can always be sure that
> they
> >won't accidentally create an SID that is the same as an existing one.  As
> >long as the "half" of the SID one portal group generates is different from
> >the half generated by another portal group, there will be no chance of
> >collision.  [This is delegation of naming authority!!!]  The same
> principle
> >holds on the initiator side in how it generates ISIDs.
> >
> >Are we getting closer?
> >
> >"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/28/2001 04:10:24 pm
> >
> >Please respond to cbm@rose.hp.com
> >
> >Sent by:  owner-ips@ece.cmu.edu
> >
> >
> >To:   Jim Hafner/Almaden/IBM@IBMUS
> >cc:   ips@ece.cmu.edu
> >Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
> >
> >
> >
> >Jim,
> >
> >I see your point about the current wording possibly suggesting
> >an implementation option.
> >
> >Can I suggest the following text:
> >
> >  The TSID is a target-assigned tag which together with the InitiatorName
> >  uniquely identifies the session within the target.
> >
> >It appears to me that it's all that's required for uniqueness, I
> >don't think we need to mention ISID here.  If there are multiple
> >sessions with an initiator, each would anyway be assigned a different
> >TSID.  What am I missing?
> >--
> >Mallikarjun
> >
> >
> >Mallikarjun Chadalapaka
> >Networked Storage Architecture
> >Network Storage Solutions Organization
> >MS 5668   Hewlett-Packard, Roseville.
> >cbm@rose.hp.com
> >
> >
> >>Marj,
> >>
> >>Comments in line (as usual...).  But for the person of few words, I'd
> >agree
> >>with just this text (your first sentence only):
> >>
> >>"The TSID is the target assigned tag for a session with a specific named
> >>initiator
> >>that, together with the ISID uniquely identifies a session with that
> >>initiator."
> >>
> >>(I moved the word "name" around because the session is with the initiator
> >>not with the name.)
> >>
> >>Jim Hafner
> >>
> >>
> >>"KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
> >@ece.cmu.edu
> >>on 08/28/2001 02:46:45 pm
> >>
> >>Sent by:  owner-ips@ece.cmu.edu
> >>
> >>
> >>To:   ips@ece.cmu.edu
> >>cc:
> >>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
> >>
> >>
> >>
> >>I'm curious why you've phrased it this way.  I think of it more like;
> >>
> >>"The TSID is the target assigned tag for a session with a specific
> >>initiator
> >>name that, together with the ISID uniquely identifies a session with that
> >>initiator.
> >><JLH>
> >>I don't really see the subtle difference between this text and mine, so I
> >>guess I don't have any problem with it.  At least it doesn't bind the
> >>definition to anything SCSI'ish.
> >></JLH>
> >>
> >>However, the target MUST enforce uniqueness of the SSID for a given I_T
> >>combination (in order for login and recovery rules to make sense).
> >><JLH>
> >>I think I see what you're getting at here, but I don't think the words
> >>capture it (it looks like an incorrect use of "I_T nexus" (a SCSI thing).
> >>Do you mean:
> >>
> >>  "However, the target MUST enforce the uniqueness of the SSID [aside:
> >>isn't this 'SID'?] for sessions with a given initiator."
> >>
> >>If so, I can go with this text, but I think this is stated in other
> places
> >>and need not be here.  But I won't argue if it is also here.
> >></JLH>
> >>
> >>The TSID MAY be a unique tag for a session with a specific initiator
> >name."
> >><JLH>
> >>I don't think this belongs at all.  It is an implementation statement and
> >>so outside the scope.  It's a true statement, but I don't think it should
> >>be made explicit (especially in this part of the document -- I'd have
> less
> >>problem with this in the "Notes to Implementers" but even then it is
> >>suggesting a prefered(?) implementation).
> >></JLH>
> >>
> >>I know the last "rule" is more for convenience than to follow the
> >"modeling
> >>rules" (but that's the most straight forward way to implement TSID
> >>assignment?).  From the target viewpoint, it must first set the context
> of
> >>the initiator name, secondly the ISID.
> >><JLH>
> >>First, it's not necessarily the most straightforward way. It could
> >generate
> >>a unique TSID for every session regardless of initiator name.  That gives
> >>it a twobyte pointer to the session context.  That's a lot more efficient
> >>(perhaps) than having to also have an initiator name in that "pointer".
> >>So, if you go with your implementation, you have to index on the
> >name+TSID,
> >>and that's too big, so you need an indirect pointer to the context and at
> >>that point it doesn't really matter what the TSID is relative to other
> >>TSIDs; you can use the name + joint SID=ISID||TSID as your index (it's
> >only
> >>2 bytes more out of a possible 258!).
> >>
> >>So, I argue for no statement about implementation options, leave that to
> >>the clever programmers!
> >></JLH>
> >>
> >>Marjorie Krueger
> >>Networked Storage Architecture
> >>Networked Storage Solutions Org.
> >>Hewlett-Packard
> >>tel: +1 916 785 2656
> >>fax: +1 916 785 0391
> >>email: marjorie_krueger@hp.com
> >>
> >>> -----Original Message-----
> >>> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> >>> Sent: Tuesday, August 28, 2001 12:59 PM
> >>> To: ips@ece.cmu.edu
> >>> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
> >>>
> >>>
> >>> Folks,
> >>>
> >>> The following text defines TSID in referenced document (and with the
> >>> changes proposed by Mallikarjun):
> >>>
> >>> "The TSID is a tag that identifies the SCSI initiator port.
> >>> TSID is set by
> >>> the target.  It MUST be valid only in the final response."
> >>>
> >>> I'm trying to figure out what the TSID has to do with the
> >>> SCSI initiator
> >>> port.  As I understand it, they are completely unrelated (at an
> >>> architecture level).  In implementation may choose to use the
> >>> TSID as a
> >>> pointer to the session in a unique way across all sessions in
> >>> the target or
> >>> in a unique way across all sessions with a given named iSCSI
> >>> initiator or
> >>> it can do any number of other things.  It is, in my opinion,
> >>> unrelated to
> >>> the SCSI initiator port.
> >>>
> >>> I would propose the following alternative text:
> >>>
> >>> "The TSID is a tag set by the target that, together with the ISID,
> >>> identifies a unique session with the initiator."
> >>>
> >>> Comments?
> >>>
> >>> Jim Hafner
> >>>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >