Re: Unsolicited data PDU retry

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Wed, 7 Aug 2002, Mallikarjun C. wrote:

> Tony,
>
> In addition to what Julian said, let me add one more comment.
>
> Initiator is not expected to initiate any Data-Out recovery on its own -
> without being requested so via a recovery R2T by the target.  The unsolicited
> data PDU retry is not advised.  This follows from the design goal (e)
> in section 5.1.2 (top of page 80 in rev15) - only one side drives error
> recovery for a given class of PDUs, and target does it for Data-Out.
>
> Hope that clarifies.

Mallikarjun,

How can that be correct, though?

Maybe I'm mis-understanding something (or thinking you're side-stepping
something you're not), but it seems like that could lead to a mess.

First off, while you're right that the target drives data-out sequencing
with R2Ts, initial data is a little different. The initiator drives that,
subject to negotiation and spec rules. It decides if it wants to use
Immediate Data or unsolicited PDUs (assuming negotiations permit it).

From Julian's comment:

> As for the data our assumption has been that target will drop data for
> non-instantiated tasks (not a known ITT).

If we are retransmitting the command because we think it didn't get
received, then doesn't it seem sensible to conclude that the above text
triggered all of the unsolicited data getting dropped?

Also, at a basic level, regardless of retransmission or not, if the
initiator (re)sends a command PDU that indicates it will use unsolicited
data (F bit not set in command PDU), then doesn't it always have to send
the unsolicited data it just promised??

I could see an initiator choosing to retransmit a command without
immediate and unsolicited data (no data in PDU and F-bit set) and that
normal R2Ts would take over from there. But we don't require it to do so
at present, and if the initiator chooses to indicate the presence of
unsolicited PDUs, then I'd expect it to have to send them.

Take care,

Bill