SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


Home

Last updated: Tue Sep 04 01:03:52 2001
6315 messages in chronological order