Subject: Re: Unsolicited data PDU retry

From: "Julian Satran" <[email-masked]>
Date: Wed, 7 Aug 2002 19:56:00 +0300

Tony,

Not all the recovery details are made explicit in text.
The code is a bit more complete but it is also not exhaustive.
It is meant to model recovery for interoperability.

As for the data our assumption has been that target will drop data for 
non-instantiated tasks (not a known ITT).
As for duplicates ignoring duplicates is implied by the window rules in 2.

Julo

"Tony Battersby" <[email-masked]>
Sent by: [email-masked]
08/06/2002 09:22 PM
Please respond to tonyb

        To:     <[email-masked]>
        cc: 
        Subject:        Unsolicited data PDU retry

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: "Mallikarjun C." <[email-masked]>
Date: Wed, 7 Aug 2002 11:24:27 -0700

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

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 7 Aug 2002 13:20:00 -0700 (PDT)

> recovery for a given class of PDUs, and target does it for Data-Out.

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

> 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

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 7 Aug 2002 16:09:35 -0700

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

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 7 Aug 2002 17:19:02 -0700 (PDT)

> I think is your question.

Ok.

> it received the command, so has the ITT context).

Ahh...

> different header flags (F-bit and no-F-bit) - it's illegal.  Take a look at 5.2.1.

Yes, you are correct that that's what the spec says about the packet.

Well, here's what I thought was the mess. You're suggesting that, when
REtransmitting a command, it is ok to send a command that indicates we're
sending more PDUs (F-bit not set) and to then NOT send them as we're
plugging a command hole. That really strikes me as a protocol violation.
It may not be by the letter of the protocol, but it just seems wrong. I
mean I doubt we be happy with an implementation that did that on the
initial transmission, so why do it on the retransmission?

Think about what's going to happen to this command (assuming I understand
you right). Either we are really plugging a hole or we aren't. If we
aren't, the target will drop the repeat and the unsolicited data on the
floor.

But if we really are plugging a hole, we send this one command and then we
have to wait until the target times out and requests error recovery R2Ts.
i.e. because of that one error, we now have to wait both the initiator and
the target timeout period before things start to get fixed. Also, having a
perceived error state on the initiator's side need the target to perceive
an error to fully recover seems cumbersome.

If that's really considered the best thing to do, well, it will work. It
just seems sub-optimal.

Take care,

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 07 Aug 2002 19:37:03 -0700

>You're suggesting that, when
> plugging a command hole.

Sorry, but I never said it - perhaps I was just unclear.  On the
contrary, 
I am suggesting that the command retry mechanics must be identical.

All I said was that the target is responsible for Data-Out recovery
*when*
it did receive the command earlier.  If the initiator is suspecting that 
the command never got there, it's obligated to repeat the entire command
retry sequence - including the unsolicited data, if any.
-- 
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
MS 5668	Hewlett-Packard, Roseville.
[email-masked]

---

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

> I am suggesting that the command retry mechanics must be identical.

Ahhh!!! My appologies. I think we're in violent agreement. :-)

Take care,

Bill