Subject: iSCSI ACA requirement

From: "Dave Peterson" <[email-masked]>
Date: Fri, 1 Feb 2002 16:17:36 -0600

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

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 2 Feb 2002 09:22:25 +0200

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" <[email-masked]>
Sent by: [email-masked]
02-02-02 00:17

        To:     "Ips@Ece. Cmu. Edu" <[email-masked]>
        cc: 
        Subject:        iSCSI ACA requirement

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

---

From: [email-masked]
Date: Mon, 4 Feb 2002 13:49:13 -0500

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
[email-masked]         Cell: +1 (978) 394-7754
---------------------------------------------------

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Saturday, February 02, 2002 2:22 AM
To: [email-masked]
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 

02-02-02 00:17 

Dave

---

From: Jeff Fellin <[email-masked]>
Date: Mon, 4 Feb 2002 14:29:45 -0500 (EST)

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 [email-masked] Mon Feb  4 14:09 EST 2002
> X-Authentication-Warning: ece.cmu.edu: majordom set sender to [email-masked] using -f
> From: [email-masked]
> To: [email-masked], [email-masked]
> Subject: RE: iSCSI ACA requirement
> Date: Mon, 4 Feb 2002 13:49:13 -0500 
> Sender: [email-masked]
> Precedence: bulk
> Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1ADAC.A3726D50"
> Content-Length: 8875
> X-Lines: 195
>

---

From: "Elliott, Robert" <[email-masked]>
Date: Mon, 4 Feb 2002 13:46:12 -0600

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
[email-masked]

> From: Jeff Fellin [mailto:[email-masked]]
> Sent: Monday, February 04, 2002 1:30 PM
> To: [email-masked]; [email-masked]; [email-masked]
> > Content-Type: multipart/alternative; 
> boundary="----_=_NextPart_001_01C1ADAC.A3726D50"
> > Content-Length: 8875
> > X-Lines: 195
> >