|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Initiator-detected format or digest errorsSantosh, 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)
Home Last updated: Tue Sep 04 01:04:45 2001 6315 messages in chronological order |