SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI immediate Delivery Behaviour


    • To: <ips@ece.cmu.edu>
    • Subject: Re: iSCSI immediate Delivery Behaviour
    • From: "Julian Satran" <Julian_Satran@hotmail.com>
    • Date: Fri, 27 Apr 2001 07:16:43 +0300
    • Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01C0CEEA.031375D0"
    • Disposition-Notification-To: "Julian Satran" <Julian_Satran@hotmail.com>
    • Sender: owner-ips@ece.cmu.edu

    Charles,
     
    We have  have a mail blackout - they move some boxes to a new building.
    Here is what I wrote you.
     

    Julo

    To: ips@ece.cmu.edu

    cc:

    From: Julian Satran/Haifa/IBM@IBMIL

    Subject: Re: iSCSI: Immediate Delivery Behavior

    Charles,

    There is an explicit statement that iSCSI uses TCP and this implies that on any given connection nothing can be delivered out of order.

    However if there is a hole in the iSCSI queue (e.g., due to a digest error) immediate commands can still be delivered out of order.

    In 7.3 there is description of how to handle task management to cover for those cases.

    Regards,

    Julo

    Please respond to Charles Monia <cmonia@NishanSystems.com>

    To: "Ips (E-mail)" <ips@ece.cmu.edu>

    cc: Charles Monia <cmonia@NishanSystems.com>

    Subject: iSCSI: Immediate Delivery Behavior

     

     

    Hi:

    The behavior for immediate commands seems ambiguous and possibly needlessly

    complex.

    Rev 06 says the following regarding ordered delivery to the SCSI layer:

    "Except for the commands marked for immediate delivery the iSCSI

    target layer MUST deliver the commands to the SCSI target layer in

    the order specified by CmdSN. Commands marked for immediate delivery

    may be handed over by the iSCSI target layer to the SCSI target layer

    as soon as detected. iSCSI may avoid delivering some command to the

    SCSI layer if so required by some prior SCSI or iSCSI action (e.g.,

    clear task set Task Management request received before all the

    commands it was supposed to act on)."

    In a non-striped session consisting of one TCP/IP connection, the above

    could be interpreted to allow the delivery of an immediate command before

    other partly received commands that were previously issued. As a result, an

    operation, such as an abort task, might bypass the command to be aborted --

    even if both were sent on the same connection.

    Assuming that's true, I believe a useful simplification is to require that

    all traffic flowing over a given TCP/IP connection be delivered to the SCSI

    layer in the order received over that connection. In a striped session, an

    immediate command might therefore leapfrog commands on other connections but

    would never bypass commands on the same connection. In my opinion, that

    simplifies the problem of properly purging commands and stale PDUs in the

    wake of a task management operation.

    Charles

    Charles Monia

    Senior Technology Consultant

    Nishan Systems

    email: cmonia@nishansystems.com

    voice: (408) 519-3986

    fax: (408) 435-8385



Home

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