RE: iscsi: rev 05 2.5.1 requires ACA support

[julian_satran@il.ibm.com]

Prasenjit,

I think that David gave you a fair summary of the situation.  The only
think that I am uneasy about is that
we (iSCSI) have direct way of controlling it.  We require a target to
support ACA because we know that
on iSCSI connections there may be commands in flight. We have nothing to do
with the way the SCSI initiator is going to use this (if at all). An iSCSI
initiator is unaware of the ACA support.  It would have been cleaner if SAM
had something to say about high latency delivery subsystems and the
requirements those create on targets and initiators.

Regards,
Julo

From: Prasenjit Sarkar@IBMUS on 16/03/2001 19:24

To:   Black_David@emc.com
cc:   ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL, owner-ips@ece.cmu.edu
From: Prasenjit Sarkar/Almaden/IBM@IBMUS
Subject:  RE: iscsi: rev 05 2.5.1 requires ACA support  (Document link:
      Julian Satran - Mail)

Hi David and Julian,

To impart some finality into the discussion, can you summarize for
the benefit of the mailing list what is distinctive about iSCSI that ACA
must be made mandatory for targets. I'm not trying to start an argument
here, but a few words of motivation might help us to understand
as to why iSCSI-ACA must be made manadatory (required in most situations)
versus optional (implement where needed).

Regards,
Prasenjit

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose



|--------+------------------------>
|        |          Black_David@em|
|        |          c.com         |
|        |          Sent by:      |
|        |          owner-ips@ece.|
|        |          cmu.edu       |
|        |                        |
|        |                        |
|        |          03/16/2001    |
|        |          06:21 AM      |
|        |                        |
|--------+------------------------>
  >----------------------------------------------------|
  |                                                    |
  |      To:     Julian Satran/Haifa/IBM@IBMIL,        |
  |       ips@ece.cmu.edu                              |
  |      cc:                                           |
  |      Subject:     RE: iscsi: rev 05 2.5.1 requires |
  |       ACA support                                  |
  |                                                    |
  |                                                    |
  >----------------------------------------------------|



If that's the case, then the wording that Ralph
pointed out needs to be modified to indicate that
ACA is used only when appropriate.

--David

> -----Original Message-----
> From:         julian_satran@il.ibm.com [SMTP:julian_satran@il.ibm.com]
> Sent:         Friday, March 16, 2001 2:34 AM
> To:           ips@ece.cmu.edu
> Subject:           RE: iscsi: rev 05 2.5.1 requires ACA support
>
>
>
> We are aware of the support for ACA missing from some drivers.
> The situation is even exacerbated by the fact that certain exceptions
that
> are not errors per-se
> will require ACA to be fired to accomodate for commands in flight (like
> reservations, busy, task-set-full).
>
> However actions at the initiator can be fine-tuned with the NACA bit in
> CDB
> and the ACA atrribute for the task.
>
> Julo
>
> Black_David@emc.com on 16/03/2001 03:46:29
>
> Please respond to Black_David@emc.com
>
> To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> cc:
> Subject:  RE: iscsi: rev 05 2.5.1 requires ACA support
>
>
>
>
> > After an error if you have commands in flight you want them all dropped
> > until you specifically reset the ACA and restart the queue (prevent
> things
> > to be executed out of order).
>
> The T10 folks will have to go after this one in more detail, but Julian's
> above statement is correct *only* if the commands in flight depend on
> the one that caused the error (i.e. executing them out of order will
cause
> problems).  This is generally not the case for disks where the usual
> practice is to enforce command execution order dependencies
> (e.g., database write ordering) in the operating system and applications
> by waiting for responses (yes it's possible to do better, but lots of
> existing software doesn't).  The result is that commands in
> flight can be executed in arbitrary order with arbitrary ones of them
> failing without causing further difficulties.  As Ralph has pointed out,
> most hosts do not use ACA for disk-based storage, and if iSCSI
> always does ACA, this will cause nasty integration issues.
>
> Just to stir the pot further, I believe Fibre Channel provides a negative
> example, because if FC drops a frame (which is not a good idea,
> but can still happen), the FC component that dropped the frame has no
> clue about what ACA is, or how to get the target (which is not the
> same piece of hardware) to enter ACA state.  Both Class 2 and Class 3
> are vulnerable to this.
>
> Tapes are another matter - do we still have a tape expert on the list?
>
> I thought where we were headed on ACA was something along the
> lines of:
> - Targets MUST implement.
> - Initiators MAY use.
> - Initiator support for ACA is NOT REQUIRED.
> which would imply a text key for Initiators to tell Targets
> whether ACA behavior is expected.  Did I miss something?
>
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>
>
>