Subject: iSCSI: About CA, ACA, and AutoSense

From: Ralph Weber <[email-masked]>
Date: Sun, 18 Feb 2001 05:42:52 -0600

I keep getting requests to sort out CA (Contingent Allegiance), ACA
(Auto Contingent Allegiance) and AutoSense.  Since what I do mostly
is write articles for the ENDL Letter, I've taken these repeated
requests as a suggestion that an article dedicated to the subject
be cobbled together.

The ENDL Letter publisher, I. Dal Allan, and I have produced the
article reproduced below in the belief that it will prove useful 
to everyone who is wresting with porting SCSI to IP. 

As you peruse the article you will find some pretty deep history
on the topic of CA, ACA, and AutoSense.  The ENDL Letter has been 
published since 1984.  If you are interested in subscribing to the 
ENDL Letter please contact me directly.

Thanks.

Ralph Weber
Editor
ENDL Letter

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

                Distributed with Permission of the Publisher

ENDL Inc. grants the right to distribute the article entitled "WHERE IS YOUR 
ALLEGIANCE" to the IETF (Internet Engineering Task Force). Reproduction of 
the contents in any published form shall attribute ENDL as the source.

ENDL Inc. specializes in marketing and engineering consultation on interface 
issues, systems architecture and storage technology. The ENDL Letter 
provides subscribing clients with detailed coverage of industry activities
in a style that is suited to both marketing and engineering personnel.

The ENDL Letter is published monthly by ENDL Inc. 

The article which follows was prepared by ENDL Letter editor Ralph Weber of 
ENDL Texas and edited by I. Dal Allan of ENDL.

  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

(C) Copyright 2001 ENDL 

                          WHERE IS YOUR ALLEGIANCE

Several times in recent months there have been discussions about Contingent 
Allegiance, Auto Contingent Allegiance, and AutoSense. While most of these 
exchanges have originated from IPS (IP Storage) folks trying to learn the 
SCSI ropes, the level of confusion indicates that a review might be helpful 
to our readers. 

History

In the beginning there was CA (Contingent Allegiance) and though everybody 
did not like it, there was no doubt that CA was a fact of SCSI-2 life. The 
event that forced CA into existence was the decision to separate telling the 
initiator an error had occurred from telling the initiator what kind of 
error it was that occurred. 

 o First, tell the initiator that an error occurred (Check Condition status) 
 o Second, if the initiator asks, tell the initiator what the error was (the 
   Request Sense command and returned Request Sense data) 

Since the earliest days of SCSI there were those who believed it would be 
best to send both Check Condition status and the Request Sense data in the 
same Status phase. There was opposition though, primarily from those who 
believed that by including the controller in the device there would be no 
errors and providing sense data would be so exceptional it should be done as 
a separate action.

And as for those who believed so sincerely. Why list names, when we can be 
politically incorrect and stamp a stereotype? Disk drive vendors dominated 
the SCSI committee then, as they do now, and as a group there is little or 
no appreciation of the complexities involved in error recovery of different 
device types. 

History repeated itself when Fibre Channel development fell into the same 
trap, and designed around disks in the PLDA (Private Loop Direct Attach) 
Technical Report. PLDA is why FCP-2 (Fibre Channel Protocol) was needed, to 
add a whole new way of doing error recovery in order to handle tape drives. 

There was one memorable convert from the side of separate actions. It was 
nowhere near as dramatic a conversion as on the road to Damascus, but when 
Paul Nitza (then with Emulex) declared war on Request Sense during SCSI-2, 
he shocked the members. 

Paul had always been a target kind of guy, but when he was assigned to write 
initiator drivers he discovered just how the lack of AutoSense made life 
miserable for the host. Charged with zeal, Paul came armed with enough fire-
power to convince the committee to incorporate his ideas into at least one 
of the draft revisions. 

    SCSI WORKING GROUP MARCH 18-20 1987

    Bundled into Paul Nitza's command queuing proposal was AutoSense; 
    a method which allows the target to automatically return Sense 
    Data upon a Check Condition. If an error occurs during execution 
    the target follows the procedure of: 

              Status Phase             Check Condition 
              Data In Phase            Sense Data 
              Message In Phase         Command Complete Message 

    Harlan Andrews (Apple) had serious reservations about this 
    sequence because a Data In phase could mislead initiators (host 
    bus adapters) into transferring the Sense Data into the host 
    system memory behind the completed data transfer. 

    Paul's justification for including AutoSense as part of command 
    queuing is that he does not want the target forced to retain all 
    the status associated with queued commands. At present, SCSI 
    requires that sense be retained until the next command but in a 
    command queued environment, sense would have to be retained until 
    a tag was re-used. Bob Snively (then Adaptec now Brocade) felt 
    retaining one byte of sense per tag was a minor burden as it does 
    not require much buffer storage. 

Unfortunately for SCSI users, Paul decided to leave Southern California and 
left Emulex to head East to Ohio and set up his shingle as a consultant. No 
client came along to support/subsidize his continued participation in the 
committee, and without Paul as champion, the initiative faltered and died. 

    SCSI WORKING GROUP JANUARY 6-8 1988

    Jim McGrath (Quantum) nominated himself as leader of the AEN 
    (Asynchronous Event Notification) expunge task force by declaring 
    similar distaste for AutoSense, and adding that to his campaign. 
    His rationale is that the AutoSense justification is based on 
    performance, yet the number of errors in a disk system are so low 
    it cannot possibly make any difference. 

      "AutoSense adds one more mechanism to an already over-burdened, 
       complex structure to handle an event that might happen only 
       once a week." 

    X3T9.2 SCSI MEETING FEBRUARY 22-23, 1988

    AutoSense died, and is to be removed from SCSI-2. There were no 
    protests from anyone in the tape area. 

Request Sense remained as a burr in the side of progress, because command 
queuing brought with it the attendant problem of how to make sure Request 
Sense data hung around long enough to be collected by Request Sense. Assume 
two commands in the queue get errors, what then? You have to get inventive, 
so CA was spawned to make the target stop doing things which might produce 
more errors whenever it has to send a Check Condition to the initiator. 

CA begins when the Check Condition is sent, and stays in force until the 
next command arrives from the initiator to which the Check Condition was 
sent. Basically, the initiator gets exactly one chance to send the Request 
Sense command and learn what error caused delivery of the Check Condition. 

A number of factors kept AutoSense alive in the waning year of SCSI-2, and 
CA was one of the primary reasons.

    SCSI WORKING GROUP JANUARY 9-11 1989 

    Steve Goldman (then DPT) had left the X3T9.2 plenary in December 
    vowing to return in another attempt to obtain Terminate Immediate. 
    Return he did, with a thick document and Paul Nitza's (then OTL) 
    support: obtained by coupling Terminate Immediate with AutoSense. 
    A historical note here, AutoSense had been proposed by Paul early 
    in SCSI-2, and it had been removed after he left Emulex, stopped 
    being an editor, and missed several meetings.....

    When Paul wanted to know why AutoSense had been removed from 
    earlier SCSI-2 revisions he sparked a debate on the merits of 
    AutoSense saving any time. Actually, little is saved as far as the 
    target is concerned. The target may save a little on responding to 
    selection plus parsing of a Request Sense command; but this is not 
    the right place to focus on time savings. 

    Paul struck on part of the problem: a long initiator delay if 
    beaten out on bus arbitration by a higher priority device. This is 
    likely to happen only on heavily-used systems and did not seem to 
    concern too many members. 

    Gary Stephens (IBM) mentioned the time it takes an initiator to 
    re-dispatch another command to Request Sense, but it seemed to be 
    regarded as being of even less importance than Paul's comment. 
    NOTE: Dispatch time can be a big number in many operating system 
    environments, and can easily fall into the 2-8 msec range. 

    Debate ended with AutoSense being made a SCSI-3 item. Resistance 
    appears to be based more on emotion and target microcode than on 
    system considerations. 

Six months later there still had been no final, irrevocable decision on what 
to do with AutoSense. 

    SCSI WORKING GROUP JULY 10-11 1989

    As John Lohmeyer (NCR) worked his way down the list of "oldies," 
    he asked:

      "If everybody keeps asking for AutoSense, how come we keep 
       voting it out?" 

    Despite several attempts over the last two years, AutoSense has 
    never made it, and the conclusion was that nobody had thoroughly 
    thought through the problems of integrating AutoSense in a 
    backwards-compatible manner. 

    Gary Stephens (then IBM now FSI) suggested extending Status phase 
    to include Sense Data... 

The reticence to incorporate AutoSense left all the eggs in the CA basket. 

While a CA is in force the target is prohibited from doing more work on the 
commands in its queue. This restriction is not to be nice to the initiator, 
it is to make sure the target does not do something that might generate a 
second Check Condition and corrupt the original Request Sense data. 

While the CA is in force, the target is prohibited from accepting commands 
from an initiator other than the one to which the Check Condition status was 
sent. All such commands get returned with a Busy status, and again the goal 
is to prevent the target from getting into a spot where the original Sense 
data becomes corrupted.

When the initiator to whom the Check Condition status was sent finally sends 
a command, the CA is cleared and all proceeds according to the rules defined 
by the Control mode page settings. Typically, everything proceeds as if the 
CA had never happened. Request Sense provides the details about the cause of 
the Check Condition and the initiator deals with the error. 

What if the command sent by the initiator is not a Request Sense? Say bye 
bye, because the Request Sense data is sent to the bit bucket and everything 
continues on as if the CA had never happened. The initiator has one and only 
one shot to retrieve the Request Sense data (use it or lose it). 

These rules are simple, ironclad, and easy to follow but things took their 
first twist for the complicated when Gary Stephens (then IBM, now FSI) had 
an idea. 

  "Why can't we have a CA that lasts until the initiator says to return to 
   normal?" 
  "That way if complex error recovery is required in response to the Request 
   Sense data, the target will stay in a CA-like state until the recovery is 
   all completed." 

Thus was born ECA (Extended Contingent Allegiance). The major beneficiary 
was intended to be tapes, so processing at end of reel could be accomplished 
under an ECA state with the yet-to-be-completed writes held in the queue 
until the new reel was mounted and ready to receive more data. 

ECA was always optional with the initiator using a Control Mode Page bit to 
tell the target that ECA was to be used instead of CA for handling Check 
Conditions. When ECA was in effect, the target told the initiator that ECA 
was being entered by sending an Initiate Recovery message and the initiator 
told the target to exit the ECA state by sending a Release Recovery message. 
Between the time those two messages were sent the CA-like state was extended 
to become ECA, with the initiator being able to send as many new untagged 
commands as it liked while the ECA was in effect. 

And how important was ECA in the greater scheme of things? Let's be generous 
here and say that one or two companies implemented ECA because they thought 
it was a great idea, another one or two implemented it because a customer or 
supplier told them to, but otherwise ECA was generally unloved. 

The combination of CA and ECA was livable for the SCSI-2 parallel bus but 
times changed dramatically when Fibre Channel and its other serial protocol 
brethren came along. Serial SCSI stirred the murky waters into a veritable 
froth of confusion. 

All was not well in parallel land either. George Penokie (then IBM and now 
Tivoli) entered stage left to tilt at one of the longest spinning windmills 
in SCSI history. George clarified the queuing model, and gave it a new coat 
of polish to carry it forward into the IU (Information Unit) world of Fibre 
Channel. Nailing this task down took a whopping 18 revisions of the proposal 
and nearly two years of monthly multi-hour excursions to the front of some 
meeting room somewhere to be pummeled by proponents of this or that. 

ECA proponent Gary Stephens was convinced his day had come. 

  "With IUs in transit in both directions, you're going to have to use ECA 
   to block new commands until the initiator can find out that it's got to 
   send a Request Sense command to get the data." 
  "CA will not be good enough because a command in flight will look to the 
   target like it should be the Request Sense command needed to collect the 
   sense data, but it's really just the wrong command at the wrong time." 

The packetized protocol of Fibre Channel had no low level messaging between 
target and initiator which could carry the Initiate Recovery message. A new 
invention was required, and thus was born ACA (Auto Contingent Allegiance). 

ACA was one part CA, one part ECA, and one part entirely different. 

 o Like CA, ACA happened automatically upon delivery of a Check Condition 
   status. 
 o Like ECA, ACA stayed in force until the initiator said uncle by sending a 
   Clear ACA task management function (which translated to a new message on 
   the parallel bus or a magic bit in a Fibre Channel IU). 
 o Unlike either of its progenitors ACA created a totally task attribute (or 
   queue tag) to mark commands that would be allowed to execute during an 
   ACA state, cleverly called the ACA attribute. 

For a while there, it looked like ACA was actually going to get used in the 
Fibre Channel world as it was the only game in town to preserve the Request 
Sense data until an ACA tagged Request Sense command could be sent to get 
the details of why the Check Condition occurred. 

As things turned out, ECA inventor Gary Stephens was the unwitting killer of 
ACA. This might be hard to explain without some background so here goes with 
another flashback to earlier pages of the Happenings to set the stage. 

    SCSI FORUM MARCH 13-15 1991

    Gary Stephens' (IBM) opening was like a pitch for a new breakfast 
    cereal. 

      "Introducing! New High Fibre SCSI." 

    Gary was talking about the SPP (SCSI-3 Packetized Protocol), a new 
    twist from the same folks who brought us SCSI-1 and SCSI-2........ 

      "Most of the logical elements remain familiar to SCSI fans. The 
       Message system, Command Descriptor Blocks, Command Parameter 
       Data, Command Response Data and Logical Block Data are all 
       present. Regular Status plus a new element, AutoSense are 
       there."
      "I lost my bid for AutoSense in SCSI-2, but now it's back." 

    Gary had several flow charts of transfers between Initiator and 
    Target to demonstrate the logic of SPP. He complemented this with 
    configurations that showed how Fiber Channel can be configured 
    Point-to-Point, Switched Multi-Point or as a Ring. 

      "SCSI via the Fibre Channel will be the next revolution in 
       peripherals attachment technology."

Gary opened up the floodgates. 

 o In October 1992, Ed Gardner (then DEC now Ophidian Designs) proposed that 
   an AutoSense capability be added to the 1394 SBP (Serial Bus Protocol). 
 o Despite opposition earlier in the year, by September 1993, AutoSense had 
   been integrated into SSA (Serial Storage Architecture) SSP (Serial SCSI-3 
   Protocol). 

AutoSense soon came to be perceived as a solution to nasty situations which 
required ACA, as illustrated by this quotation from Bob Snively (then Sun 
Microsystems now Brocade) from the SCSI Working Group in May 1994. 

      "AutoSense is a better solution for non-interlocked protocols 
       than ACA, and all the serial protocols provide it."

Bob took the necessary steps to make ACA optional, and so far as ENDL knows, 
it is unused (to no one's surprise).

The ultimate triumph of AutoSense came when George Penokie and Jeff Williams 
(then Hewlett Packard now Seagate) brought a new generation Packetized Prot-
ocol for parallel SCSI to committee. Here is a key point made in the April 
1998 Happenings.

    The really important thing about the SPI Status IU is that it 
    contains sense data, thus giving SCSI parallel its first AutoSense 
    capability. 

Long and Short of It

Given the twisted history of how ACA and AutoSense grew out of ECA and CA, 
and because 'Auto' is the first word in both AutoSense and ACA, there is a 
lot of folklore around which feature does what and why. Most of it borders 
on mythology, and here is the ENDL slice and dice of reality. 

There are two general problems to be solved: 

 o Getting the Request Sense data to the initiator 
 o Blocking target activity until the initiator has been able to do every-
   thing needed to recover from an error 

The matrix of problems and solutions looks like this. 

                                      +--------------------+ 
                                      |      Solution      | 
                +---------------------+--------+-----------+ 
                | Problem             | SCSI-2 |  SCSI-3   | 
                +---------------------+--------+-----------+ 
                | Getting the Request |   CA   | AutoSense | 
                | Sense data          |        |           | 
                +---------------------+--------+-----------+ 
                | Blocking activity   |   ECA  |    ACA    | 
                +---------------------+--------+-----------+ 

 o CA makes sure an initiator can get Request Sense data by blocking activ-
   ity for an extremely limited period of time i.e. until the next command. 
 o AutoSense makes sure the initiator gets Request Sense data the way some 
   folks always thought it should be done, by co-locating the Request Sense 
   data with the Check Condition status. 

Despite the commonality of names, ACA is not a special case of CA, ACA is 
the SCSI-3 version of ECA. Once you accept this it comes as no surprise to 
learn that ACA is implemented with about the same lack of enthusiasm as ECA. 

(C) Copyright 2000 ENDL

---

From: [email-masked]
Date: Mon, 19 Feb 2001 12:34:06 +0200

Ralph,

Thanks a lot for shading light on the history of Autosense and ACA.
It will certainly help clarify the recovery discussion thread within IPS.

Regards,
Julo