SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: Unsolicited data PDU retry



    On Thu, 8 Aug 2002, Tony Battersby wrote:
    
    > Check out the last paragraph of section 2.2.4.2 of draft 15.  It is about
    > ordering rules for unsolicited data.  It seems to me that if the initiator
    > does re-send the unsolicited data, and another command with unsolicited data
    > is sent in between the first and second send attempts, then it might violate
    > the ordering rules in this section.  For example:
    >
    > Initiator sends command #1
    > Target receives command #1 successfully
    >
    > Initiator sends unsolicited data for command #1
    > Target discards the unsolicited data PDU due to a header digest error
    
    For this scenario to happen, it has to be either the last or the only
    unsolicited data PDU that bites it. Otherwise there will be a subsequent
    unsolicited data PDU that will expose the hole's presence, and then the
    target will send an error recovery R2T.
    
    > Initiator sends command #2
    > Target receives command #2 successfully
    >
    > Initiator sends unsolicited data for command #2
    > Target receives unsolicited data successfully
    >
    > (initiator times out)
    >
    > Initiator re-sends command #1
    > Target discards PDU because it is a duplicate
    
    At this point, if the target is feeling savy, it could realize that in
    addition to getting a duplicate command it will be getting duplicate data
    PDUs, and act accordingly.
    
    > Initiator re-sends unsolicited data for command #1
    > Target terminates the session because it received unsolicited data
    > out-of-order
    >
    > I suppose one could also argue that the target could detect the out-of-order
    > unsolicited data and terminate the session when it receives the unsolicited
    > data for command #2, because it was expecting the unsolicited data for
    > command #1 first.  In this case, the problem would be independent of
    > re-sending the unsolicited data PDU.
    
    I didn't think that ordering mattered across commands. If it did, then
    there would be little way to support multiple commands in progress at
    once. :-)
    
    > Maybe I am missing something.  I am not sure why the ordering rules are
    > there (implementation simplicity?), but it seems like if the target relied
    
    Yep, implementation simplicity.
    
    > on the ordering, it would make recovery impossible in this situation.  The
    > problem could be lessened either by requiring the target to close the
    > connection on a header digest error rather than having the option of
    > discarding the PDU, or else by eliminating the ordering rule.  Or, one could
    > just say, "Too bad; you can't recover from this."
    
    Take care,
    
    Bill
    
    


Home

Last updated: Thu Aug 08 15:18:58 2002
11569 messages in chronological order