SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: Error recovery level 2 Question



    This was my take on this while it was being developed:

     

    The initiator should continue as normal. This means it should assume the PDUs in the stack were sent and so it should send the next PDU. The target will detect holes in the DataSN and will then use the recovery R2T.

     

    Things will then pickup as per the text below.

     

    If the lost connection was on the last PDU or the last PDU was already on the stack, then the initiator will timeout due to the missing response and send an abort. Then, hopefully, re-try the command.

     

    Eddy

     

    -----Original Message-----
    From: Nandakumar Ramamurthy [mailto:nramamur@npd.hcltech.com]
    Sent: Wednesday, March 05, 2003 3:42 AM
    To: kevin_lemay@agilent.com
    Cc: ips@ece.cmu.edu
    Subject: Re: Error recovery level 2 Question

     

    Hi Kevin,

     

    In my understanding, the initiator must wait for

    a recovery R2T from the target.

     

    This is conveyed by the following sections of the draft :

     

    10.17.1
    "For iSCSI, Data-Out PDU retransmission is only done if the
    target requests retransmission with a recovery R2T."

     

    6.2.2 (Allegiance Reassignment)
    "In reassigning connection allegiance for a command, the targets
    SHOULD continue the command from its current state."

     

    "For all types of commands, a reassignment request implies that the
    task is still considered in progress by the initiator and
    the target must conclude the task appropriately if the target
    returns the "Function Complete" response to the reassignment
    request. This might possibly involve retransmission of data/R2T/
    status PDUs as necessary, but MUST involve the (re)transmission of
    the status PDU."

     

    From the above it seems to be implied that the target, after returning

    the 'Function Complete' response for the "task reassign" request,

    might retrasmit 'data' in case of a 'READ' (or) an 'R2T' in case of a 'WRITE'.

     

     

    6.1.4.1 (Recovery Within-command)
    "To avoid a race with the target, which may already have a recovery
    R2T or a termination response on its way, an initiator SHOULD NOT
    originate a SNACK for an R2T based on its internal timeouts (if
    any). Recovery in this case is better left to the target."

     

     

    Thanks,

    Nandakumar
    Member Technical Staff
    HCL Technologies, Chennai, INDIA.
    http://www.hcltech.com/san

     

     

    ----- Original Message -----

    Sent: Wednesday, March 05, 2003 4:44 AM

    Subject: Error recovery level 2 Question

     

    > Julian,
    >  
    > Assume that I have a multi-connection session to a target when one of the connections fails.
    >  
    > What is the completion of the following diagram (assume 8K PDUs and maxBurst = 64K):
    >  
    > Initiator                          Target
    > ----------                        ---------
    > Write Cmd (64K no Immediate) --->
    >                              <---  R2T Offset 0, len=64K
    > Data PDU (8K DataSN 0)       --->
    > Data PDU (8K DataSN 1)       --->
    >    --- Connection Lost ---
    >  
    >  
    > On 2nd connection:
    > Logout (for recovery)        --->
    >                              <---  Logout Response
    > Task Mgnt (Reassign)         --->
    >                              <--- Task Mgnt Response - OK
    >  
    > What Comes Next?
    >  
    > Is a recovery R2T expected from the target?
    > or does the Initiator continue to send data PDUs to the target?
    >  
    > If the initiator continues to send, what is the proper place to continue. I may have submitted several PDUs to the stack that were never received before the connection loss was detected.
    >  
    > The read request seems fairly straight forward, but the write case is not clear (at least to me...)
    >  
    > Thanks for any help,
    >  
    > Kevin Lemay



Home

Last updated: Wed Mar 05 09:19:11 2003
12393 messages in chronological order