Re: iSCSI draft 02: digests

[Mark Bakke <mbakke@cisco.com>]

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