Subject: Re: Initiator-detected format or digest errors

From: "John Hufferd" <[email-masked]>
Date: Tue, 8 May 2001 23:31:26 -0700

Santosh,
It is not clear that your approach is good for tapes.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: [email-masked]

Santosh Rao <[email-masked]>@ece.cmu.edu on 05/08/2001 05:28:02 PM

Sent by:  [email-masked]

To:   Matt Wakeley <[email-masked]>, Julian
      Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: Initiator-detected format or digest errors

Why can't iSCSI apply a simple policy of discarding any PDU that has a
digest error or a format error ? Can the draft allow for such
implementations that wish to discard the PDU and do nothing more ? This
is all that FC initiators and targets need to do and they can recover
fine from CRC errors !

A dropped PDU will result in one of the following scenarios :

---------------------------------------------------------------
format error or digest error
impacts                                 Scenario
---------------------------------------------------------------
i) iSCSI Command                        Initiator timeout.
                                        (could be detected
                                        early on when initiator
                                        retries command on seeing a
                                        large diff b/n ExpCmdSN and
                                        current CmdSN.

ii) READ Data PDU                       I/O underrun, detected thru a
                                        mis-match b/n count of DataSNs
                                        received and EndDataSN.

iii) WRITE Data PDU                     If this is not the "F" data PDU
                                        for that R2T data phase, this
                                        results in a target timoeut
                                        followed by target aborting the
I/O
                                        at the end of R2T data phase and
                                        sending an aborted response
back.

                                        If this is a "F" data PDU,
results
                                        in initiator timeout. (scenario
1).

iv) R2T PDU                             Target timeout. Initiator
timeout.

v) Status PDU                           Initiator timeout.

From an implemenation's perspective, generating all of these REJECT
commands is just adding overhead and complexity, requiring the
allocation of resources [possibly by the host] for a REJECT PDU and
having to transmit a REJECT in response to each PDU that had either a
format or digest error.

Any diagnostic info can be logged as counters within the
implementation's MIB. A format error or digest error causes the PDU to
be discarded. As it is, we need to apply a discard policy for the
"header digest error" & format error cases. Simplification of all digest
error and format error handling to a "discard policy" keeps
implementations [and the protocol] simple.

- Santosh

Matt Wakeley wrote:
>
> The target can log the reject for further analysis.
>
> Why do you keep trying to eliminate simple things that can be used for
> debugging?
>
> -Matt
>
> [email-masked] wrote:
> >
> > Matt,
> >
> > 3 reasons:
> >
> > a. the initiator drives recovery. What can a target do with the reject?
> > (he is probaly in need of a reset)
> >
> > b.the initiator is unaware of the target state after thhe error
> >
> > c.there is reject command (and response) -:)
> >
> > Julo
> >
> > Matt Wakeley <[email-masked]> on 06/04/2001 00:43:08
> >
> > Please respond to Matt Wakeley <[email-masked]>
> >
> > To:   IPS Reflector <[email-masked]>
> > cc:
> > Subject:  Re: Initiator-detected format or digest errors
> >
> > Why not send a reject back to the originator of the bad frame, and just
let
> > the task time out?
> >
> > -Matt
> >
> > [email-masked] wrote:
> > >
> > > Tom,
> > >
> > > An initiator will pass the appropriate response to the SCSI layer and
> > will
> > > abort the task if it can identify one.  Further behavior of
initiators
> > and
> > > targets is implementation dependent.
> > >
> > > 6.2 specifies this.
> > >
> > > Julo
> > >
> > > "Thomas McSweeney" <[email-masked]> on 04/04/2001 13:57:20
> > >
> > > Please respond to "Thomas McSweeney" <[email-masked]>
> > >
> > > To:   [email-masked]
> > > cc:
> > > Subject:  Initiator-detected format or digest errors
> > >
> > > Section "2.20 Reject" talks about the target receiving a bad frame
and
> > > sending Reject.  What should an Initiator do if it receives a PDU
with a
> > > format or digest error?  Should it send Reject?  If so, we'll need to
> > > ensure that the Initiator fields of the MIB include an object to
count
> > > Reject commands transmitted.
> > >
> > > Tom McSweeney
> > > iSCSI Development, Storage Systems Group, IBM
> > > Email: [email-masked]
> > > Phone: (USA) 919-254-5634  (tie line: 444-5634)
> > > Fax:   (USA) 919-254-0391  (tie line: 444-0391)

---

From: Santosh Rao <[email-masked]>
Date: Wed, 09 May 2001 09:09:44 -0700

John,

I am appealing against having to respond with a REJECT on the occurrence
of format errors and digest errors. The results of such an approach were
documented in my last mail [further below]. Tape recovery can still be
achieved by :

a) issuing a SNACK on seeing a hole at the initiator. Issuing an R2T to
request the missing data on seeing a hole at the target. (merely
dropping a PDU without having to REJECT it would still cause a hole to
be seen and allow recovery through either a SNACK or a request to
re-transmit).

or :

b) Initiator issues a "command retry" to recover from an I/O underrun or
an I/O timeout [assuming the target has buffered all the data in its
iSCSI layer]. This approach would require implementations to splice the
ULP TOV into a lower I/O timeout to allow for a potential "command
retry" at the iSCSI layer before the expiry of ULP TOV.

Not using the REJECT should not hinder recovery (?).

Regards,
Santosh