Re: Unsolicited data PDU retry

[Bill Studenmund <wrstuden@wasabisystems.com>]

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