ACA

Kurt Chan kc at core.rose.hp.com
Thu Jan 5 10:12:21 PST 1995


| >  Is there a means for a Target to be required to retain sense data
| >  until it receives acknowledgement from the Initiator that the sense
| >  data has been delivered?  
| 
| In my opinion, this has to be addressed in the SCSI protocol definition. If
| there is a significant possibility of unacceptable packet loss, some layer
| within the transport system, possibly the SCSI protocol layer itself, must be
| prepared to deal with the problem.
| 
| >  On a channel model, the REQ/ACK handshakes
| >  on the sense data may be sufficient.  However, on a FC network using
| >  FCP in class 3, the current definition of ACA is insufficient to
| >  ensure sense data preservation.  After several readings, it appears
| >  that there are still some channel-based assumptions in SAM and other
| >  X3T10 documents.
| 
| The only assumption in SAM is that all recoverable communications errors are
| handled within the transport system transparently to the application.
| Therefore, any error of this type that is reported to an application is
| considered fatal.

Hi Charles,

  Since Request Sense with the ACA attribute currently clears sense
data during ACA, there are two ways we've thought of to try and make
sense data delivery reliable in FC using FCP class 3.  There are
undoubtedly others we haven't thought of:

1) Require an extra acknowledgement to FCP_RSP in FCP, along with
   requiring a Sequence Retry protocol by the Target.

2) Bind the sense data to the ACA condition.  Request Sense does not
   clear the sense data, but a hard reset, power-on, or CLEAR ACA
   would (anything that clears the ACA condition).

Item (1) would meet your requirement, but is not defined in FCP and
would be difficult considering the FCP community performs Exchange
recovery only in SCSI (retry the entire command), not Sequence
recovery (retry a "phase").

Item (2) requires changes to the ACA definition in SAM, since multiple
Request Senses keep returning the same sense information - a change
|from all previous implementations.

There's a philosophical question of whether a ULP designed to work on
a channel should have to perform the "extra" ULP interlocks typically
found on ULPs designed to run over networks, or whether the link
layers of those networks should be designed to make everything above
them on the stack reliable.

I have some conflicting opinions myself on this subject, depending on
whether we're taking an architectural or a pragmatic view of the
problem.

Let's talk about this some more next week.

Regards,
Kurt.




More information about the T10 mailing list