SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: current UNH Plugfest



    Bob,
    
    Comments in text.
    
    Thanks,
    Julo
    
    
    
    
    "Robert D. Russell" <rdr@mars.iol.unh.edu>
    Sent by: owner-ips@ece.cmu.edu
    02-11-01 01:31
    Please respond to "Robert D. Russell"
    
     
            To:     ips@ece.cmu.edu
            cc: 
            Subject:        Re: iSCSI: current UNH Plugfest
    
     
    
    
    Attached are the new issues that arose during the iSCSI plugfest at
    UNH on Thursday 1-Nov-2001.
    
    Bob Russell
    InterOperability Lab
    University of New Hampshire
    rdr@iol.unh.edu
    603-862-3774
    
    ----------------------------------------------------------------------
    
    There were no new issues today!  Lots of people were busy sending
    data and interoperating with each other!  There were, however, a
    few suggestions/requests for clarifications in the standard:
    
    1. Since all Login Requests MUST be issued as immediate requests,
    the diagram in section 3.12 should show bit 6 of byte 0 as "1",
    not "I", and section 3.12.2 should simply be eliminated.
    
    ++++
    
    OK - Julo
    
    ++++
    
    2. The first paragraph of Appendix D should describe the special
    role of the first Login request on the first connection of a new
    session.  In particular, there are 3 keys that MUST be sent in
    that Login PDU (InitiatorName, SessionType if it is discovery,
    TargetName if the session is normal).  This is, in fact, yet
    another classification that is currently included within LO, but
    LO is too general, since LO allows keys to appear at any time
    during the leading login phase, and these keys must appear on the
    very first login PDU in that leading login phase.
    
    +++
    
    There is now a text in Section 5 that reads:
    
    The initial Login request of the first connection of a session (primary 
    login) MUST include the InitiatorName key=value pair. The primary Login 
    request MAY also include the SessionType key=value pair in which case if 
    the SessionType is not "discovery" then the leading Login Request MUST 
    also include the key=value pair TargetName.
    
    
    +++
    
    3. A target cannot release its resources for a command until it
    receives an ExpStatSN back from the initiator that acknowledges
    receipt of the StatSN carried in the SCSI Response to that command.
    However, if the initiator does not have any more I/O to perform,
    that ExpStatSN will not come back to the target, and the target
    may end up holding on to those resources indefinitely.  This is a
    situation where initiator non-action can impact target performance,
    and could even lead to denial of service attacks if several
    initiators were to do this simultaneously to the same target.
    
    The standard provides the NOP-In/Out mechanism to deal with this:
    
    The last paragraph of section 2.2.2 says:
      During periods when traffic on a connection is unidirectional,
      iSCSI NOP-Out/In PDUs may be utilized to synchronize the command
      and status ordering counters of the target and initiator.
    
    and section 3.18 says:
      A NOP-Out may also be used to confirm a changed ExpStatSN if
      there is no other PDU to carry it for a long time.
    
    The question is, is there a recommended mechanism to trigger these
    NOP-pings?
    
    Clearly the target could set a timer, and if ExpStatSN is not
    received back at the end of the time interval, the target could
    send a NOP-in as a ping in order to get the initiator to send back
    a NOP-out with the updated ExpStatSN.
    
    Also clearly the initiator could set a timer, and if it has no
    traffic to send during the time interval, the initiator could send
    a NOP-out to deliver the updated ExpStatSN to the target.
    This approach is probably not as reliable as the first, since
    a) if the initiator does not do it, only the target gets hurt, and
    b) if the connection drops, the target will never receive the NOP-out.
    On the other hand, it may be more efficient for the initiator to do
    this, since a typical target may be dealing with hundreds of
    connections, and the initiator only a few.
    
    Which is the best procedure?  Are there other ways to do this?
    What is the recommended way, or is there a reason for the standard
    not to recommend a triggering mechanism, in which case, could
    the standard suggest methods or provide guidance, especially if there
    are better, less obvious ways to do it?
    
    +++
    
    There are no better ways to do it. However we see this a purely an 
    implementation matter.
    I assume that a target low on resources will try to recover some and ping 
    the initiators.
    
    +++
    
    
    
    
    
    
    


Home

Last updated: Mon Nov 05 04:17:34 2001
7552 messages in chronological order