96-274r0 -- Proposed Change in QErr=1 Behavior for SPC-2

ROWEBER at acm.org ROWEBER at acm.org
Mon Nov 25 14:13:52 PST 1996

* From the SCSI Reflector (scsi at symbios.com), posted by:
* ROWEBER at acm.org
Firstly, I apologize for letter bombing the reflector and then leaving town.
By way of explanation, I believed that there was time pressure to complete
preparation and deliver of the proposal.  But, having succeeded at meeting
the publication goal, I then needed to attend to other job goals.

While I appreciate Charles' offer to take the blame, you all should continue
to toss the stones in my direction.  You're going to get to toss stones at
the January Working Group meeting.  So, why not engage in a little "pre-
season" practice.

I will now attempt to address some of the issues raised during my absence.

Those folks who have attempted to guess my motives for making the proposal
have gravely misjudged me.  While I certainly have a host-software past and
might reasonably be expected to make proposals with software advantages in 
mind, such is not the case here.

There is a serious protocol instability in the case where QErr=1 is combined 
with a multi-initiator environment.  The original proposal presents one 
example of the instability and Charles Binford has offered a second example 
in a recent message to the reflector.  Other people who have examined the 
problem description have offered comments such as, "Yep, the standard is

As I see it, I'm doing something equivalent to telling the committee that
the bus is unstable, unless it is terminated.  In this case, unlike issues 
of termination, the committee probably has many options for resolving the 
protocol standardization failure.  I proposed a solution because past 
experience shows that the committee is more likely to act on a proposal 
containing a solution than on a complaint that lacks the specificity of 
a proposed change.

I am, by no means, wedded to the specific solution contained in the r0
proposal.  (Nobody in their right mind would expect to get an r0 proposal
past this crowd.)  However, I am disappointed by the absence of counter 
proposals.  It's so atypical of the X3T10 membership to pretend that if 
nobody sees a problem then it will just go away.


    "The fact is that the QErr feature was designed for single 
    initiator systems and multi-initiator systems were supposed 
    to use the ACA ACTIVE technique (or at least ..."

If QErr=1 was intended for use only by single initiator systems, then why does
the standard describe in excruciating detail how the device server shall behave
with respect to multiple initiators?  If the problems in multi-initiator
environments were known from the outset, why were they swept under the rug?
(Oops, strike that 'when did you stop beating your wife' question.)  But 
regardless of the past, the problems are known clearly now and they demand 
action.  It is, at best, unfair to the readers of the standard to imply that 
QErr=1 will work in a multi-initiator environment without some type of 
extraordinary effort on the part of the application clients.

In defense of the r0 proposal, I offer the following points:

    1) The behavior experienced in single initiator environments is
       not changed.  This covers the majority of the cases.
    2) The behavior in multi-initiator environments is fully stabilized.
       None of the problems described thus far will occur in systems
       where the proposal is adopted.
    3) The proposal requires no functions that are not already present
       in devices that implement the Basic queuing model.  The ABORT 
       TASK SET task management function is required for devices that 
       implement the Basic queuing model.  The proposal requires a
       behavior that is essentially the same a an ABORT TASK SET, 
       whenever a CHECK CONDITION status is sent to the application 
       client.  (This analysis is based on a review of 96-198r3.  
       It assumes that the table on the first page of that proposal 
       was not changed in 96-198r4, which comes from my recollection 
       of actions taken at the November SCSI Working Group meeting.)

Yes, the proposal requires a change in the behavior of QErr=1 in a 
multi-initiator environment.  Since the currently specified behavior 
is dysfunctional, a change (some kind of change) is required.

Ralph O. Weber                E-Mail: ralph.weber at symbios.com
Symbios Logic Inc.             Voice: 214-733-3594
17304 Preston Road               Fax: 214-713-8121
Suite 635                   SCSI BBS: 719-533-7950 300--14400
Dallas, TX 75252                                   baud

* For SCSI Reflector information, send a message with
* 'info scsi' (no quotes) in the message body to majordomo at symbios.com

More information about the T10 mailing list