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

From: "Jim Hafner" <[email-masked]>
Date: Tue, 28 Aug 2001 12:59:11 -0700

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

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 28 Aug 2001 14:46:45 -0700

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.

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

The TSID MAY be a unique tag for a session with a specific initiator name."

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.  

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked] 

> -----Original Message-----
> From: Jim Hafner [mailto:[email-masked]]
> Sent: Tuesday, August 28, 2001 12:59 PM
> To: [email-masked]
> Subject: iSCSI: definition of TSID (2.11.4 of draft 07)
> 
> 
> Folks,
>

---

From: "Jim Hafner" <[email-masked]>
Date: Tue, 28 Aug 2001 16:38:18 -0700

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." <[email-masked]>@ece.cmu.edu on 08/28/2001 04:10:24 pm

Please respond to [email-masked]

Sent by:  [email-masked]

To:   Jim Hafner/Almaden/IBM@IBMUS
cc:   [email-masked]
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.
[email-masked]

>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)" <[email-masked]>
@ece.cmu.edu
>on 08/28/2001 02:46:45 pm
>
>Sent by:  [email-masked]
>
>
>To:   [email-masked]
>cc:
>Subject:  RE: iSCSI: definition of TSID (2.11.4 of draft 07)
>
>
>
><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>
>
><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>
>
><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>
>
><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

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 28 Aug 2001 18:20:16 PDT

Jim,

Thanks for the explanation.

>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

---

From: "Julian Satran" <[email-masked]>
Date: Wed, 29 Aug 2001 09:44:22 +0300

Jim,

I think that Mallikarjun is right. Along with all our clever model elements
that closely align whatever we have with SAM
we have lost a statement about  the session-ID being unique (although it is
implied by the rest - how else could you know to what session to add a new
connection).  We should say - in 1.2.1 something like:

"A session-ID uniquely identifies a session at the initiator and at the
target."

Julo

"Mallikarjun C." <[email-masked]>@ece.cmu.edu on 29-08-2001 04:20:16

To:   [email-masked]
cc:

Jim,

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka

---

From: "Jim Hafner" <[email-masked]>
Date: Fri, 31 Aug 2001 08:59:59 -0700

Mallikarjun,

Comments in line.

Jim Hafner

"Mallikarjun C." <[email-masked]>@ece.cmu.edu on 08/30/2001 09:57:09 pm

To:   [email-masked]
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

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." <[email-masked]>@ece.cmu.edu on 08/28/2001 06:20:16 pm
>

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 31 Aug 2001 10:26:26 PDT

Jim,

>Now, B has done its job of enforcing no repeated
>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

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

Regards.
--
Mallikarjun 

Mallikarjun Chadalapaka