Re: iSCSI: Unsolicited data PDU retry

["Mallikarjun C." <cbm@rose.hp.com>]

Bill,

I do not quite follow what "could lead to a mess"....let me address what
I think is your question.

I did not say that target "drives the data-out sequencing" for unsolicited
data, only that the target drives the *error recovery* for all data-out (assuming
it received the command, so has the ITT context).

Let me attempt to rephrase.  A digest error as an example, taken on
one of the unsolicited data PDUs, would have to be recovered by the
target sending a recovery R2T - IOW, target driving the Data-Out PDU
recovery is true even for unsolicited data.

If I understand you correctly, you seem to suggest that retries may carry 
different header flags (F-bit and no-F-bit) - it's illegal.  Take a look at 5.2.1.

I believe the protocol does work correctly even if the initiator retransmits
Data-Out PDUs as it pleases, but that's not the design expectation.  I believe
that's all Tony's question was about.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com

----- Original Message ----- 
From: "Bill Studenmund" <wrstuden@wasabisystems.com>
To: "Mallikarjun C." <cbm@rose.hp.com>
Cc: <tonyb@cybernetics.com>; "Julian Satran" <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu>
Sent: Wednesday, August 07, 2002 1:20 PM
Subject: Re: Unsolicited data PDU retry


> 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
> 
>