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

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

Jim,

>Now, B has done its job of enforcing no repeated
>ISID *to the same portal group* but A may be confused when a messages comes
>from B with SSID=(1,1).

I assume A knows the iSCSI target portal group for each SSID -
so has a means of distinction without crossing layers into TCP.

But, I see it's simpler to keep it this way.  I am perfectly okay
with this.  Thanks for the explanation.

>I have no objection to adding a sentence that defines
>the nexus identifier as the conjunction of the two SCSI portnames and
>observe that by this definition and the ISID RULE, two nexus with the same
>identifier should never occur.

Thanks, that is a reasonable way of suggesting a means of enforcement.

Regards.
--
Mallikarjun 


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


>Mallikarjun,
>
>Comments in line.
>
>Jim Hafner
>
>
>"Mallikarjun C." <cbm@rose.hp.com>@ece.cmu.edu on 08/30/2001 09:57:09 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,
>
>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.
>
><JLH>
>Are you saying that iSCSI *doesn't* need to ensure uniquess of SSID between
>a single iSCSI initiator and single iSCSI target?  Is that because of
>"locality" within the portal group?  Curious!   I had asked a number of
>months ago what the value of the SSID was in the first place!  I had
>thought that it was to parallel the S_ID, D_ID of FC, but the answer I got
>was "NO", it's just to give each end an inband handle for a session
>context.  I took that to imply some uniqueness.  Then I leveraged that for
>the model.
>
>But I think there might be problems (for one end or the other) if SSIDs are
>not unique.  Suppose initiator A opens one session (ISID=1) to target B on
>Portal Group X and gets TSID=1.  Then A opens session (ISID=1) to B on TG Y
>and again gets TSID=1.  Now, B has done its job of enforcing no repeated
>ISID *to the same portal group* but A may be confused when a messages comes
>from B with SSID=(1,1).  Unless it *also* tracks the TCP connection as part
>of the "session context", it can't tell to what session the message
>belongs.  [Note that in this example, B didn't 'partition' TSIDs between
>its portal groups -- this is what enabled the duplicate SSID to be
>created.]
>
>In short, it is possible for A to "live with" multiple independent sessions
>with the same SSID, but it crosses layering (it requires non-iSCSI protocol
>handles).  In a nut shell, I think we should require this SSID uniqueness.
></JLH>
>
>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...
><JLH>
>Well, yes, we haven't specified *directly* an identifier/means for
>enforcing no parallel nexus.  We have specified the ISID RULE.  Remember
>that I said that the nexus is a "relationship" (not an identifier) between
>two specific SCSI ports; the ISID RULE prevents two independent such
>relationships.  We don't have an explicit (SCSI) nexus identifier mechanism
>for checking, but we have an explicit iSCSI identifier mechanism for
>checking!.  But, if you prevent the relationship from coming into
>existence, then you get no matching nexus identifiers (regardless of how
>that might be reasonably defined) for free.
>
>Is this another one of those places where we're not explicit enough in the
>text?  :-{)
>
>To ease your mind, I have no objection to adding a sentence that defines
>the nexus identifier as the conjunction of the two SCSI portnames and
>observe that by this definition and the ISID RULE, two nexus with the same
>identifier should never occur.
>Does that cover it?
></JLH>
>
>
>
>
>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
>> >>>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> >
>> >
>> >
>
>
>