RE: iSCSI ACA requirement

["Elliott, Robert" <Robert.Elliott@compaq.com>]

You're confusing autosense with ACA.  Refer to Ralph Weber's article on
them excerpted from the ENDL letter:
	http://www.pdl.cmu.edu/mailinglists/ips/mail/msg03427.html

Short summaries:
autosense = returning sense data with the response PDU (rather than
requiring REQUEST SENSE)
ACA = special state the logical unit enters after returning a CHECK
CONDITION (and autosense data)

It would be a huge burden to have an iSCSI target layer try to implement
ACA on behalf of a SCSI logical unit layer which does not do so.

---
Rob Elliott, Compaq Server Storage
Robert.Elliott@compaq.com



> -----Original Message-----
> From: Jeff Fellin [mailto:jkf@research.bell-labs.com]
> Sent: Monday, February 04, 2002 1:30 PM
> To: Julian_Satran@il.ibm.com; ips@ece.cmu.edu; Black_David@emc.com
> Subject: RE: iSCSI ACA requirement
> 
> 
> I don't understand all the concern about the ACA being a MUST, because
> this is only in the iSCSI PDU's and not in the SCSI INQUIRY DATA. The
> iSCSI target can emulate the local device supporting ACA. 
> This is easily
> done by checking the status code on the returned command 
> (something that
> must alreadly be done), and if it indicates a SCSI error issuing a
> SCSI REQUEST SENSE command. When the response for the SCSI 
> REQUEST SENSE
> is returned, the target iSCSI implementation returns all the 
> information
> in the iSCSI SCSI CMD Response message. This eliminates 
> another round trip
> to retrieve the information. On the iSCSI initiator side the 
> local SCSI
> layer receives the Check condition with valid request and 
> sense data without
> the need of issuing the REQUEST SENSE with the round trip delay.
> 
> Jeff Fellin
> 
> > From owner-ips@ece.cmu.edu Mon Feb  4 14:09 EST 2002
> > X-Authentication-Warning: ece.cmu.edu: majordom set sender 
> to owner-ips@ece.cmu.edu using -f
> > From: Black_David@emc.com
> > To: Julian_Satran@il.ibm.com, ips@ece.cmu.edu
> > Subject: RE: iSCSI ACA requirement
> > Date: Mon, 4 Feb 2002 13:49:13 -0500 
> > Sender: owner-ips@ece.cmu.edu
> > Precedence: bulk
> > Content-Type: multipart/alternative; 
> boundary="----_=_NextPart_001_01C1ADAC.A3726D50"
> > Content-Length: 8875
> > X-Lines: 195
> > 
> > I thought the outcome of the previous lengthy discussion on
> > ACA was to make it a SHOULD.  That is also the right requirement
> > level for Julian's concern that failure to use ACA may have
> > performance consequences.  I agree with Dave Peterson that
> > requiring ACA behavior from devices that have no intention
> > of supporting it other than a possible need for compliance
> > with the iSCSI spec is pointless.  Let's make ACA a SHOULD.
> >  
> > Thanks,
> > --David
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
> > black_david@emc.com         Cell: +1 (978) 394-7754
> > ---------------------------------------------------
> > 
> > 
> > -----Original Message-----
> > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> > Sent: Saturday, February 02, 2002 2:22 AM
> > To: ips@ece.cmu.edu
> > Subject: Re: iSCSI ACA requirement
> > 
> > 
> > 
> > Dave, 
> > 
> > In fact we could make it SHOULD as ACA support is not 
> anymore critical
> > provided that the right exception mechanism for busy etc. 
> is in place and it
> > is now and does not use ACA(!).  However the effect on 
> performance could be
> > more taxing than in the case of FCP - the network diameter 
> supported is far
> > larger and the need to support commands in fly is more 
> important than in the
> > case of FCP. 
> > 
> > Julo 
> > 
> > 
> > 
> > 
> > 
> > 	"Dave Peterson" <dap@cisco.com> 
> > Sent by: owner-ips@ece.cmu.edu 
> > 
> > 
> > 02-02-02 00:17 
> > 
> > 
> >         
> >         To:        "Ips@Ece. Cmu. Edu" <ips@ece.cmu.edu> 
> >         cc:         
> >         Subject:        iSCSI ACA requirement 
> > 
> >        
> > 
> > 
> > I'm having heartburn with the statement in iSCSI rev 10 clause 9.2:
> > "As iSCSI can have many commands in-flight between 
> initiator and target,
> > iSCSI mandates support for ACA."
> > 
> > My understanding of the above statement is that iSCSI 
> target must indicate
> > support for NACA=1.
> > 
> > Requiring ACA is problematic and normally not necessary for 
> implementations
> > for a variety of reasons.
> > Examples:
> > a. A small number of devices actually support NACA=1.
> > b. In practice FC applications do not require command 
> ordering (i.e., use of
> > the Simple Queue Tag). If ordering is a consideration the 
> application will
> > issue the command and wait for the response.
> > c. The FC/FCP standards do not require NACA=1.
> > d. Complicates bridging implementations
> >                 - bridge must proxy NACA=1 for a device 
> that does not
> > support NACA=1
> >                 - bridge must maintain NACA behavior when 
> the end device
> > does not support
> > NACA=1
> > 
> > I do understand the benefits to requiring NACA=1 especially 
> when command
> > ordering and stateful operations are desired, but its not 
> realistic at this
> > time, IMHO.
> > As such this use of ACA should be a SHOULD, not a must or mandate.
> > 
> > Dave
> > 
> > 
> > 
> > 
> > 
>