RE: iSCSI ACA requirement

[Black_David@emc.com]

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