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



    
    
    Except for sending the status - an executing command helds-up the LU queue
    and makes the "local" recovery simpler than clearing the LU queue and
    resending the commands. Add to this the fact that you don't have ACA
    for service responses not seen by the target (and even for those seen) and
    you have a perfect "appetite enhancer" for command recovery. The issue in
    my mind is to make this a mandatory behaviour that can only be excplicitily
    called off by the target or initiatior  (by clearing the LU) or make it
    negotiable at login.
    
    Julo
    
    "Y P Cheng" <ycheng@advansys.com> on 31/01/2001 07:24:02
    
    Please respond to "Y P Cheng" <ycheng@advansys.com>
    
    To:   "'Ips@Ece. Cmu. Edu'" <ips@ece.cmu.edu>
    cc:
    Subject:  iSCSI: CmdSN and Retry
    
    
    
    
    A few points herein would help reduce the confusion of ordered delivery
    using CmdSN and error retry.
    
    If the initiator sends both commands A and B to a target and requires B to
    follow A.  After completing A with an error condition, nothing prevents the
    target to start B immediately.  Therefore, what do we accomplishing by
    retrying A?  In every SCSI implementation I know of, initiator is always
    ultimately responsible of understanding the ordered execution as well as
    retry.  Therefore, the retry corner cases pointed by Santosh simply will
    not
    exist with properly behaved initiator, unless an iSCSI initiator will
    behave
    differently.  Since TCP ensures ordered delivery, for an iSCSI session with
    multiple TCP connections, all we need to do is to ensure the sequentiality
    of CmdSN from multiple connections.  The real question is what is the
    timeout value of TCP before starting retransmit?  Even if we yank a TCP
    connection, it does not change the requirement of enforcing sequential
    CmdSN.
    
    I am not aware of any SCSI target allocates resource for status phase.
    Once
    the status is sent, all resources are released.  If the initiator times out
    the status, it retries the whole command.  A target certainly can timeout
    the ACK of the status before releasing all resources.  But, the target
    timeout should be shorter than that of the initiator.  But, it gets really
    confusing if the target TCP has a shorter timeout value than the initiator
    TCP.
    
    A header digest error is same as a missing PDU except it is detect by
    iSCSI,
    not TCP.  Because TCP has delivered the segment, it is possible for the
    receiver to quickly notify the sender to resend the erroneous header.
    Again, for a target if non-zero CmdSN is enforced, it must wait for the
    resend.
    
    In conclusion, if CmdSN is enforced, a target must take the TCP transport
    delivery sequentially whether there is one or more TCP connections because
    the missing one could just be an ordered-queue or head-of-queue. For a
    header digest error, a target can't proceed until it gets the missing
    header
    as long as CmdSN is non-zero.  Since a target will always move to next
    command as soon as it completes one with or without error, all application
    software and initiators should know better not to send a SCSI request which
    depends on the success of a previous request.
    
    The exception to the above discussion is the tape I/O.  This is because the
    tape devices use "lying writes".  Once write data gets into device buffer,
    the device takes full responsibility of writing the data to media.  All
    read
    data are buffered.  Another read follows an erroneous one reads the same
    data.
    
    Y.P. Cheng, CTO, ConnectCom Solutions Corp.
    
    
    
    
    


Home

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