SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: "kicker" reservation problem



    
    David,
    
    Comments in line (and we forgot to send our last dialogue to the reflector
    -- my fault -- so hopefully people (who care!) can catch up here.
    
    Jim Hafner
    
    
    Black_David@emc.com on 09/28/2001 01:50:46 pm
    
    To:   Jim Hafner/Almaden/IBM@IBMUS, Black_David@emc.com
    cc:
    Subject:  RE: iSCSI: "kicker" reservation problem
    
    
    
    Jim,
    
    > You wrote:
    >   If the proposed language is adopted to allow reservations to be shared
    >   across target ports, but be bound to initiator ports, the identities
    >   of the initiator ports have to be visible to the "application" so that
    >   it can control SCSI behavior with respect to reservations.
    > But that must also be true today (in a more static world).  If an
    > application requests a reservation for a logical unit on one I_T_L nexus,
    > it pretty much needs to know what path that is, so that it knows where to
    > direct it's IOs.  So, it needs some handle, identity, whatever for that
    > nexus within the operating system.  In the current reservation model, the
    > application probably can't deal with a completely opaque handle here. It
    > will need to know all the I_T_L paths so that is can do the registration
    > across all the paths.  In other words, it needs some internal identity
    for
    > the I and some external identity for the T.  That's true today and won't
    > change with the new proposal.
    >
    > If the proposed language is adopted, then it can take better advantage of
    > this information, by recognizing that it only needs to register when the
    > I's are different (not when either the I or T is different).
    
    I think I disagree.  Over in the FC world, I would expect applications
    to be written with a firm knowledge of when the I's (i.e., FC Initiator
    Ports)
    are the same or different and hence knowing whether they have to register
    without asking.  This implicit knowledge may be based on stuff like
    inspecting
    the /dev filenames in Unix.
    <JLH>
    That stuff in the /dev is the 'internal identity' I refer to in the next
    paragraph.
    </JLH>
    
    
    > In either case, it needs some internal identity for the "I'.  So long as
    > the iSCSI layer presents a representation of the 'I' as consistent with
    the
    > model, there is no problem.  The application doesn't need to see the
    ISID,
    > it needs to see the internal identity of the 'I' as the same if the
    > underlying ISIDs for the I_T_L nexus is the same.
    
    I think I'm expecting worse - applications that depend on having the same
    "I"
    and hence needing to instruct iSCSI to use the same ISID.  OTOH, you seem
    to be suggesting (below) a scenario in which iSCSI could declare by fiat
    that
    the "I"s are always different and hence applications always have to
    register;
    is that credible?
    <JLH>
    My question is: does the application EVER ask for a new nexus?  Doesn't it
    just takes what it gets from the layers below?
    
    The "needing to instruct iSCSI to use the same ISID" is really getting to
    the issue I address below about what drives the multi-path session creation
    in the first place.  If the application needs to "drive another session"
    then it better really be sure about the underlying transport (cause only
    iSCSI can really do that on the fly!).  If it has an API to say "make a new
    one", then it probably can say "make a new one through this (internally
    identified) I".  So, what's the problem?  The iSCSI layer will recognize
    the need to reuse the ISID and the upper layer never sees that value or any
    relationship with it and the I.
    
    BUT the usual model is the application gets whatever paths are "found" by
    the lower layers during discovery.  In that case, it can see the internal
    representation of the "I"s and do the thing it needs to do.  So, the
    question is "Does the application drive sessions or does the application
    make use of existing sessions?".  In my mind, the answer doesn't matter for
    the issue here.  Given a set of nexus, it can tell what I's are the same
    (by the internal handle) and desiring a new nexus using an existing I, it
    can ask the transport to make one for that I.
    
    On the other point, by declaring that the model says that the ISID names
    the port, then, yes, by fiat, if the ISIDs are different, then the ports
    are different too and that should be reflected to the upper layers (as far
    as they go, anyway). It's not that iSCSI 'declares' them different, just
    that they will be different by the model.   This comment was assuming the
    current model.  It gets weirder in the alternative model (there's no name
    to hang anything on! so no basis to say they are the same or not).
    </JLH>
    
    > At least it some layer has a way to tell that the I's are the same or
    not.
    > If the target generated SSIDs entirely, there would never be two nexus
    with
    > the same I (and different T) and so the whole multipathing issue gets
    much
    > more complex.  The application would ALWAYS have to work through each
    nexus
    > (as it does today, but for different reasons).
    
    Or we'd have to invent some way for an application to tell iSCSI when the
    application requires it to reuse an existing "I" identity.  As indicated on
    the list, I think there are advantages to this being something other than
    the ISID so that it has no role in the basic iSCSI protocol (e.g., yet
    another
    key=value pair passed on login to tell the Target how the application using
    it expects reservations to behave).  This is moving away from the usual
    SCSI
    model in which sessions are established in advance to one in which
    applications
    can cause sessions to be established, and that may be a serious change.
    <JLH>
    I don't think this is really necessary or reasonable.  If there is/will be
    an API to ask for a new nexus that has some properties (same "I") as an
    existing nexus, then it doesn't have to know about the ISID, just the
    representation of the "I" internally.  It's iSCSI's job to represent the
    same ISID'ed sessions as the same "I" in this interface.  That can't be
    that hard.
    </JLH>
    
    > The issue here comes, not from the application getting a handle on the
    > I_T_L nexus (and perhaps its internals). It's more a question of what
    layer
    > is going to generate all those paths (nexus) in the first place?  Right
    > now, every SCSI Initiator Port does a greedy job of building nexus to
    every
    > SCSI Target Port it can find on the bus (fabric).  With iSCSI, that model
    > changes dramatically.  Someone has to drive this nexus building in a more
    > constructive manner since initiator ports need to be created on the fly.
    > Once their built, the rest goes according to plan (as it does today).
    But
    > building them at all may require more application intervention OR each
    > iSCSI Initiator Portal Group does it's most aggressive best (subject to
    > some configuration limit of how many connections per session and how many
    > sesssions per target portal group and .....).
    
    I think that your "application intervention" line of thinking will lead to
    my concern that application control over whether two nexii have the same
    or different "I" is going to be required, not just application visibility.
    Let me know if you wind up someplace else and how/why you got there.
    <JLH>
    Like I said, if we end up (later) with an application intervention, then it
    only need use the internal "I", not the ISID and it's the responsibility of
    the iSCSI layer (presenting the SAM model to the upper layer) to make sure
    the ISID is reused when required.
    </JLH>
    
    > You wrote..
    >   At best, T10 is probably looking towards
    >   Fibre Channel in which session endpoints are static hardware
    interfaces.
    >   The easiest way to get back in line with T10 would be to forbid iSCSI
    >   sessions from spanning network interfaces, and then use the IP address
    >   of the network interface as the SCSI Initiator Port Name, but that
    would
    >   be a significant change from the approach we've been pursuing to date.
    > I think that's an unfair statement about T10.  The person pushing this
    new
    > stuff is active in SRP and in iSCSI and is fully aware of the issues and
    > implications.  But on the other hand, T10 can only deal with things which
    > fit within its model space.  That includes "named Initiator Ports" (with
    > the name being persistent and immutable).  They don't have to be static
    or
    > hw, just named.
    
    Maybe the FC bit is unfair, but SAM is clearly written with a worldview
    that Ports are static entities, similar to its worldview that transports
    operate synchronously (e.g., see my recent reply to Bob Snively on this
    topic).
    <JLH>
    I won't disagree with SAM having a "static" mindset.  But that certainly is
    not a question of what direction they're "looking towards" so much as the
    25 years of (proven) legacy and baggage they carry with them (and have to
    keep from breaking).  The other thing to note is that SAM has had (a) very
    little concern about initiator ports (except as the source of a scsi task,
    aka application client) and (b) even less concern about initiator devices.
    It didn't matter so much when there was only one (or two) initiator(s) on
    the bus.  It's a very different story with fabrics (as I'm sure you know).
    SAM is going through growing pains to deal with this.
    
    Perhaps all this will be moot after SAM-3, but I'm not entirely sure about
    that.
    </JLH>
    
    > This whole thing would have been a lot easier if we never had multiple
    > connection sessions.  But that was a choice made early.  Now we see what
    we
    > can do with what we have.
    
    Right ... actually this problem is caused by sessions that span network
    interfaces - multiple connections on a single interface don't cause these
    problems (but cause a different set elsewhere because IETF does not want to
    encourage a repetition of the HTTP multiple connection stuff done by
    browsers).
    
    
    > You wrote:
    >   Alternatively, we could invent yet another software name for the SCSI
    >   Initiator Port that exists primarily to cope with this new notion of
    >   reservation scope,
    > But as I've argued before, any other name still has the same problems of
    > namespace, use, generation, coordination.  The ISID was a name already
    > there and suited the purposes.   If we go away from ISIDs for other
    > reasons, then we still need another name, and we still need a rule that
    > says that 'named' port can't login twice with the same target portal
    group
    > and .... we're back where we are now.
    
    But the moment we put that name under application control, some large
    hammers become available.  On Windows, one obvious thing to do is make
    the "software names" GUIDs which have uniqueness properties that can be
    controlled without coordination among the entities generating them.  One
    can also use OIDs, vendor unique names (e.g. com.ibm.tsm.---).
    <JLH>
    If we can put that name under application control, why can't we put the
    ISID under application control?  What's so fundamentally different?
    Because one is in the iSCSI layer?  FCname are in the FC layer, pSCSI
    address ids are in the pSCSI layer.  It all amounts to the same thing (I
    think).
    </JLH>
    
    > I've been around this bend many many times and always come
    > back to the same place.  Can I stop now? :-{)
    
    Not yet - I think this is exploring new territory :-).
    <JLH>
    Da...
    </JLH>
    
    
    Thanks,
    --David
    
    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
    black_david@emc.com       Mobile: +1 (978) 394-7754
    ---------------------------------------------------
    
    
    
    


Home

Last updated: Fri Sep 28 20:17:22 2001
6846 messages in chronological order