Subject: Unsolicited data PDU retry

From: "Tony Battersby" <[email-masked]>
Date: Tue, 6 Aug 2002 14:22:18 -0400

In section 5.2.1 Usage of Retry (draft 15), it is specified that initiators
can resend commands that have not been acknowledged for a timeout period.
Does this retry include re-sending unsolicited data PDU's?  The target is
supposed to ignore non-immediate commands with duplicate CmdSN's or CmdSN's
outside the expected range, which takes care of immediate data, but I don't
see anywhere where it is specified that the target should ignore duplicate
or unexpected unsolicited data PDUs.  Or, is the target supposed to hold on
to unsolicited data PDU's for a command that it does not know about (e.g.
because the command PDU was discarded due to a digest error) and then later
re-associate the unsolicited data PDU's with the correct command when the
command PDU is re-sent by the initiator?

The last paragraph of section 2.4.2.2 gives some rules for the ordering of
unsolicited data for different commands, which may also be related.

Thanks,
Anthony J. Battersby
Cybernetics

---

From: Bill Studenmund <[email-masked]>
Date: Thu, 8 Aug 2002 10:51:39 -0700 (PDT)

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