SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI draft 02: digests



    
    
    Mark,
    
    Giving it some more thought..
    
    Since you cant take anything in the header/packet as valid and the event
    should be rare
    I think that will simply add another AEN request to logout with digest
    failure as a reason
    and take recovery from there.  I think that will make also Steph happy -
    with layering not being violated -:)
    
    Regards,
    Julo
    ---------------------- Forwarded by Julian Satran/Haifa/IBM on 05/12/2000
    09:39 ---------------------------
    
    Julian Satran
    05/12/2000 08:31
    
    To:   ips@ece.cmu.edu
    cc:
    From: Julian Satran/Haifa/IBM@IBMIL
    Subject:  Re: iSCSI draft 02: digests  (Document link: Julian Satran -
          Mail)
    
    Mark,
    
    I also gave it some more thought.
    
    Since a digest failure is a transport failure that went undetected by TCP
    dropping and restarting a connection won't do us to much good - if we use
    the same link we may end up having some more.
    
    We should treat them as iSCSI failures and have iSCSI restart the command
    without restarting the connection.
    
    Regards,
    Julo
    
    Mark Bakke <mbakke@cisco.com> on 05/12/2000 00:18:28
    
    Please respond to Mark Bakke <mbakke@cisco.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   ips@ece.cmu.edu
    Subject:  Re: iSCSI draft 02: digests
    
    
    
    
    Julian-
    
    Here's what we had in mind for recovering from digest/CRC failures:
    
    1. If the digest failure is on a command, status, or iSCSI header,
       this means that a length field could be corrupted.  This should
       not happen often, but it may be possible to re-send the command
       if both the initiator and target can do session recovery as in
       the iSCSI spec.  In any case, the connection should be terminated,
       and a new one built in its place.  If session recovery is supported
       and is successful, the missing iSCSI PDU(s) during and after the
       digest failure are re-send, re-responded, and no harm done.  If
       session recovery fails, the upper SCSI layer must receive the
       failure, and do whatever recovery is necessary.  In any case, the
       old connection should not be used after the failure.
    
    2. If the digest failure is on a SCSI data block, iSCSI length fields
       are not affected, so there may be a possible way to resend the
       data.  However, doing this is probably not worthwhile, so I think
       that in the data digest case, the same recovery as in (1) should
       be used.
    
    --
    Mark
    
    julian_satran@il.ibm.com wrote:
    >
    > Like on a data failure on any bus. Raise a check condition and end the
    > command with an error but let it go up to
    > the normal end.  I will spec it.
    >
    > Thanks,
    > Julo
    >
    > Matt Wakeley <matt_wakeley@agilent.com> on 29/11/2000 01:39:22
    >
    > Please respond to Matt Wakeley <matt_wakeley@agilent.com>
    >
    > To:   ips@ece.cmu.edu
    > cc:
    > Subject:  iSCSI draft 02: digests
    >
    > In appendix A is a (brief) description of the iSCSI header and data
    > digests.
    >
    > What is the expected behavior if there is a digest failure?  Just throw
    the
    > PDU away?
    >
    > -Matt
    
    --
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    
    
    
    
    
    


Home

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