SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



    
    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...
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:04:14 2001
6315 messages in chronological order