Re: Initiator-detected format or digest errors

[julian_satran@il.ibm.com]

Do we have to go through this cycle again?

We started by saying that we discard anything that looks bad (that is also
good against denial of service atatcks)
the we moved to reject to simplify "debugging" (never a good longtime
decision - the best would be to have a silent or verbose option with silent
being mandatory to implement), now we have a request to have a verbose
initiator mode
and another one (vocal) to move back to silent mode.

And yes Santosh you have all the mechanisms to work in silent mode and a
verbose (reject) is required only for debugging (logging).

Julo

Santosh Rao <santoshr@cup.hp.com> on 09-05-2001 03:28:02

Please respond to Santosh Rao <santoshr@cup.hp.com>

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)
 - santoshr.vcf