SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: CmdSN during the Login phase



    
    Mark,
    
    Why should one use a different mechanism during login than anywhere else?
    Besides Login sequencing for non leading connections is important for
    recovery (login of a new connection has to come after the logout of the
    old).
    
    CmdsN starts from the leading login (the leading login is guaranteed to be
    serialized) and is following it every command/request that is non-immediate
    is counted.
    
    Julo
    
    Mark Bakke <mbakke@cisco.com> on 17-07-2001 23:48:57
    
    Please respond to Mark Bakke <mbakke@cisco.com>
    
    To:   Matt Wakeley <matt_wakeley@agilent.com>
    cc:   ips@ece.cmu.edu
    Subject:  Re: iSCSI: CmdSN during the Login phase
    
    
    
    
    
    Given that this is being interpreted differently by enough
    implementations, I would prefer to see us take a step back
    and look at which of Scott's three options should make the
    most sense.  It looks like options #1 and #2 are what is
    currently being implemented, regardless of what's specified.
    
    However, a connection technically can't really be part of a
    session (sharing its work load) until it has completed a
    successful login phase.  There's also little reason for
    numbering until the login phase is complete, since the login
    and text responses during negotiation are synchronous, and
    pertain only to the connection, rather than the session.
    
    I would recommend stating that a connection joins (or becomes,
    if it's the first one) a session after the login response
    with the F bit set is sent (on a target), or after the login
    response with the F bit set is received (on an initiator),
    and that CmdSN is not necessary until such a time, especially
    since CmdSN is per-session, not per-connection.  This is
    identical to Scott's option 3.
    
    I think that defining it this way would remove any further
    ambiguity on when a connection is part of a session.  Since
    it appears that most implementations will have to modify their
    login code anyway, this shouldn't be too bad.
    
    --
    Mark
    
    Matt Wakeley wrote:
    >
    > I think it's pretty obvious that it's your option #1: (the initiator
    supplies
    > the initial CmdSN in the login PDU, and for every command PDU after that,
    the
    > CmdSN gets incremented, just like in "full feature phase")
    >
    > 2.10.7 CmdSN says "CmdSN is either the initial number of a session..."
    > [Julian, this should say "initial command number of a session"]
    >
    > So, the Login PDU defines the first CmdSN.
    >
    > 1.2.2.1 says "Commands in transit from the initiator to the target layer
    are
    > numbered by iSCSI; the number is carried by the iSCSI PDU as CmdSN".
    Text
    > commands are commands, so they are numbered also.
    >
    > It goes on to say "CmdSN - the current command Sequence Number advanced
    by 1
    > on each command shipped except for commands marked for immediate
    delivery."
    >
    > I agree that this needs to be cleaned up. CmdSN and StatSN should work
    during
    > login just like they do during "full feature phase" - there is no reason
    why
    > the should not, and making them always work the same removes complexity
    and
    > interoperability problems.
    >
    > -Matt
    >
    > "Scott M. Ferris" wrote:
    > >
    > >   At what point during the Login Phase of a leading connection (null
    > > TSID) does a session exist?
    > >
    > >   Section 2.10.7 describing CmdSN for the Login PDU indicates that
    > > when TSID is null, CmdSN indicates the starting Command Sequence
    > > number for this session.
    > >
    > >   For interoperability, it is important to define precisely when a
    > > session exists, so that all initiators and targets agree on when
    > > CmdSNs are significant, and do not reject or ignore PDUs due to
    > > differing assumptions of how the CmdSN numbering should be done during
    > > the Login Phase.
    > >
    > > Some of the possible choices for session start are:
    > >
    > > 1) a session starts before the initiator sends anything, and the Login
    > >    PDU is the first PDU of a session.
    > >
    > > 2) a session starts when the initiator receives a (possibly partial)
    > >    Login Response with an accept status class and a non-zero TSID, and
    > >    the next PDU sent by the initiator is the first PDU of the session,
    > >    which uses the same CmdSN as the Login PDU.
    > >
    > > 3) a session starts when the initiator receives a Final Login
    > >    Response, and the next PDU sent by the initiator is the first PDU
    > >    of the session, which uses the same CmdSN as the Login PDU.
    > >
    > >   After searching through draft 6, I was unable to find anything that
    > > clearly indicated which if any of the above possibilities was correct,
    > > or, if more than one is possible, how the initiator and target are
    > > supposed to determine what CmdSN numbering scheme the other side is
    > > using for the Login Phase.
    > >
    > >   The UNH draft-6 initiator appears to use choice #1.  The Cisco
    > > draft-6 initiator and target use choice #2.  This can cause the UNH
    > > initiator to hang when trying to login to the Cisco target, since the
    > > initiator may send a Text PDU with CmdSN 2, while the target is
    > > waiting for a PDU with CmdSN 1.
    > >
    > >   Section 1.2.2.2 states that "Status numbering starts after
    > > Login. During login, there is always only one outstanding command per
    > > connection and status numbering is not strictly needed but may be used
    > > as a sanity check."
    > >
    > >   A similar argument could be made that CmdSN is not needed during the
    > > Login Phase, suggesting choice #3 may be the simplest.
    > >
    > >   I also think section 1.2.2.2 is problematic, as it appears to
    > > contradict itself by saying that status numbering is not used during
    > > login, and then follows up saying status numbering may be used during
    > > login.
    > >
    > > --
    > > Scott M. Ferris,
    > > sferris@acm.org
    
    --
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    
    
    
    


Home

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