Re: iSCSI: Concerns raised about ACA and denial of service conditions

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

Ralph,

This is a request for clarification.

Isn't the behavior you describe being controlled by the TST (and QErr)
field from the Control Mode Page (SPC2)
and the value of 001 insures that an ACA condition caused by one initiator
does not cause tasks from another initiator
be rejected?



Regards,
Julo



Ralph Weber <ralphoweber@compuserve.com> on 24-07-2001 03:59:23

Please respond to ENDL_TX@computer.org

To:   IPS Reflector <ips@ece.cmu.edu>
cc:
Subject:  iSCSI: Concerns raised about ACA and denial of service conditions




The SCSI Commands, Architecture, and Protocols working group
reviewed a proposal by Ed Gardner based on input from Julian
Satran, the intent of which is to invoke ACA when a BUSY,
TASK SET FULL, or RESERVATION CONFLICT status occurs.  The
CAP working group had several questions regarding the need
for this proposal.  Ed and I explained as best we could
the iSCSI need for this capability to support high latency
links.  Generally, our explanations were deemed inadequate
and several calls were heard along the lines of "if this
is so important why isn't anybody here to defend it?"

However, that was not the worst of the troubles visited
on the proposal.  Several people noted problems with using
ACA to preserve synchronization following a rejected command,
since ACA locks out all initiators, not just the one
initiator whose command was rejected.  For example, suppose
one initiator holds a reservation.  A second initiator sends
a command and gets back RESERVATION CONFLICT, causing an ACA.
The first initiator cannot access the device until the second
initiator clears the ACA.  If the second initiator simply
does nothing (whether maliciously or due to crashing), the
first initiator is permanently locked out from accessing the
device it has reserved.

Ed plans to be in London and will be happy to discuss this
there.  I will miss London due to the T11 meeting.

The T10 CAP working group is seeking clarification
from the iSCSI team regarding their desires in this
matter.  Is a feature that opens opportunities for
denial of service attacks really the desired result?
If not, it is the opinion of the CAP working group,
that ACA is not the desired mechanism and further
consideration of the real requirements is needed.

All responses to this message will be collected in
a T10 document for delivery to the CAP working group.

It is advisable that someone who can defend the
iSCSI requirements attend the next CAP working
group meeting to be held Wednesday, September 12,
2001 from 9 a.m. to 7 p.m., continuing if necessary
on Thursday, September 13, 2001 from 8:00 a.m. to
9:45 a.m. (or until all agenda items are completed).
The meeting will be at the Hilton Waterfront Hotel
(714-960-7873) in Huntington Beach, CA, hosted by
QLogic.  More information on the meeting can be
obtained from the T10 web site www.t10.org.

Thanks.

Ralph...