Re: Initiator-detected format or digest errors

[Santosh Rao <santoshr@cup.hp.com>]

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



John Hufferd wrote:
> 
> 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: hufferd@us.ibm.com
> 
> Santosh Rao <santoshr@cup.hp.com>@ece.cmu.edu on 05/08/2001 05:28:02 PM
> 
> Sent by:  owner-ips@ece.cmu.edu
> 
> To:   Matt Wakeley <matt_wakeley@agilent.com>, Julian
>       Satran/Haifa/IBM@IBMIL
> cc:   ips@ece.cmu.edu
> 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
> >
> > julian_satran@il.ibm.com 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 <matt_wakeley@agilent.com> on 06/04/2001 00:43:08
> > >
> > > Please respond to Matt Wakeley <matt_wakeley@agilent.com>
> > >
> > > To:   IPS Reflector <ips@ece.cmu.edu>
> > > 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
> > >
> > > julian_satran@il.ibm.com 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" <rf42tpme@us.ibm.com> on 04/04/2001 13:57:20
> > > >
> > > > Please respond to "Thomas McSweeney" <rf42tpme@us.ibm.com>
> > > >
> > > > To:   ips@ece.cmu.edu
> > > > 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: rf42tpme@us.ibm.com
> > > > Phone: (USA) 919-254-5634  (tie line: 444-5634)
> > > > Fax:   (USA) 919-254-0391  (tie line: 444-0391)
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard