Re: iSCSI ACA requirement

["Julian Satran" <Julian_Satran@il.ibm.com>]

Hard to support if you do not make your voices heard on the ips list.
I took the liberty of forwarding it to the list.
There seem to be serious misgivings about ACA as a good mechanism to enforce ordering.
And SHOULD is "almost must" in IETF lingo.
I recall that the SHOULD was agreed to alleviate the concern of gateway manufacturers that they will have to "emulate" ACA for
older devices that do not support ACA.  It was considered that SHOULD will allow then not to support it for those targets that do not support it and still claim iSCSI compliance.

Julo

Kalman Meth 04-04-02 21:39

To:        Julian Satran/Haifa/IBM         cc:                 From:        Kalman Meth/Haifa/IBM@IBMIL         Subject:        iSCSI ACA requirement

----- Forwarded by Kalman Meth/Haifa/IBM on 04-04-02 10:38 PM -----

"James P. Allen" <jpallen@austin.ibm.com> 04-04-02 07:42 PM Please respond to "James P. Allen"

To:        Kalman Meth/Haifa/IBM@IBMIL         cc:        Rakesh Sharma/Austin/IBM@IBMUS, conklin@austin.ibm.com         Subject:        iSCSI ACA requirement

Kalman

   I think we should argue that the wording of MUST is retained for
   iSCSI. NACA=1 is needed for other reasons not alluded below. One
   such condition is the race condition windows that can exist after a
   check condition--especially if another initiator has changed the
   mode sense values. Without NACA=1, commands may be queued in the
   iSCSI adapter or the TCP/IP stack that will be issued before the
   device specific code can intervene. These types of issues can lead
   to data integrity issues (i.e. changing cache settings or block
   sizes).

   On  FC today, all of the major vendors (EMC, LSI, Shark, Hitachi,
   Maxstrategy now part of SUN) support NACA=1. So I don't think it is
   accurrate to say NACA=1 device support on FC is rare.


   Thanks.



----- Forwarded message from Rakesh Sharma <rsharma@austin.rr.com> -----

From: "Rakesh Sharma" <rsharma@austin.rr.com>
To: <conklin@us.ibm.com>, "James P Allen" <jpallen@us.ibm.com>,
        "Bob G Kovacs" 
 <bkovacs@us.ibm.com>,
        "Rakesh Sharma" <rakesh@us.ibm.com>
Subject: Fw: iSCSI ACA requirement - FYI
Date: Tue, 12 Mar 2002 22:49:26 -0600
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-MIMETrack: Itemize by SMTP Server on D04NM103/04/M/IBM(Release 5.0.9a |January 7, 2002) at
 03/12/2002 11:44:59 PM


----- Original Message ----- 
From: Julian Satran 
To: ips@ece.cmu.edu 
Sent: Saturday, February 02, 2002 1:22 AM
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





----- End forwarded message -----

-- 
==============================================================================
Jim Allen    IBM eServer p-Series,      AIX Base Device Drivers   Austin, TX

Internet: jpallen@austin.ibm.com  
Notes   : Get real!  (jpallen@austin.ibm.com@internet)
Office  : 5E-017/905,              ZIP 905-5E17
Phone   : (512)-838-3346             T/L: 678-3346
FAX                 : (512)-838-3509                      T/L: 678-3509
==============================================================================