[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    iSCSI: About CA, ACA, and AutoSense

    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.
    Ralph Weber
    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. 
    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. 
        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.
        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 
      "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 
     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 
          "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 
          "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 
    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 
    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


Last updated: Tue Sep 04 01:05:31 2001
6315 messages in chronological order