Subject: [Ips] CmdSN, StatSN in text PDUs

From: "Dean Scoville" <[email-masked]>
Date: Wed, 14 Jan 2004 10:43:58 -0800

Julian,

Could you please confirm whether my understanding of CmdSN and StatSN for 
Text PDUs is correct? The behavior of CmdSN when C=1 isn't explicitly stated 
in the draft, so I'm assuming CmdSN is still advanced. Here are my thoughts:

   The initiator should always increment CmdSN after sending a 
   non-immediate Text Request PDU, regardless of whether the Final and/or
   Continuation flags are set in the PDU header. CmdSN should never be advanced,
   however, after sending an immediate Text Request PDU.

   The target should always increment StatSN after sending a Text Response PDU,
   regardless of the values of the Final and Continuation flags in the PDU header.

Is this a correct understanding of CmdSN and StatSN operation in Text PDUs? 

(Note: For the purposes of this question, I'm ignoring the case of Text PDU 
retransmissions caused by SNACKs, digest errors,  or timeouts when 
ErrorRecoveryLevel >0.)

thanks,
Dean Scoville

---

From: Julian Satran <[email-masked]>
Date: Thu, 15 Jan 2004 10:40:47 +0200

Dean,

"Dean Scoville" <[email-masked]> wrote on 14/01/2004 20:43:58:

>    Continuation flags are set in the PDU header. CmdSN should never 
beadvanced,
>    however, after sending an immediate Text Request PDU. 

Correct.

>    regardless of the values of the Final and Continuation flags in the

Correct again.

> retransmissions caused by SNACKs, digest errors,  or timeouts when 

Correct on both - Julo

---

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 15 Jan 2004 15:07:59 -0500 (EST)

Julian:

I have a question about what Response code a target should send
in the following situation.

1. An initiator sends an immediate command, with I=1, ITT=t,
   and CmdSN = x.

2. At some later time, the initiator decides to abort that task,
   so it sends a task management function request with I=1, ITT=u,
   RTT=t, CmdSN = y and RefCmdSN = y (CmdSN = y = RefCmdSN in
   order to refer to an immediate command as required by 10.5.5),
   and y is within the valid CmdSN window.

3. The target receives the task management function request to abort
   RTT = t, but it cannot find this task (either because it
   never received it or because it already finished it or whatever...)
   The 3 cases listed in 10.6.1 for the ABORT TASK function do not
   seem to apply in this case, because:
      a) the RTT does not identify a valid task
      b) the RefCmdSN is not less than the CmdSN in the TM request
      c) the RefCmdSN is not outside the valid CmdSN

Since none of these 3 cases apply, should the target respond with
"Function complete", by analogy with point b), or with
"Task does not exist", by analogy with point c)?

My preference would be point b), "Function Complete", but clearly
it could go either way.

In either case, perhaps a clarification is needed as a separate point for
aborting tasks (essentially corresponding with the separate point described
in 10.5.5 to deal with tasks created by immediate commands):

   d) If the Referenced Task Tag does not identify an existing
   task but if the CmdSN indicated by the RefCmdSN field in the
   Task Management function request equals the CmdSN field in the
   Task Management function request, then targets must return the
   "xxxx" response.

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: [email-masked]
Date: Thu, 15 Jan 2004 14:45:11 -0800 (PST)

> in the following situation.

Hmmm... It's a good one.

> My preference would be point b), "Function Complete", but clearly

I'd say the right response is "Task does not exist." I took the "command
does not exist but CmdSN is in window" case as applying to non-immediate
commands only. In that case we build a "never run me I've already been
aborted" entry in the CmdSN-waiting-queue. We then return "Function
Complete" as we have aborted this command we haven't received yet. :-)

It's a way to abort commands while we're in cleanup/facing connectivity
issues. Or so I thought.

>    Task Management function request, then targets must return the

Agreed, clarification is good.

Take care,

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 16 Jan 2004 15:39:51 -0800

My recollection is that "Function Complete" was
meant to be returned for all "valid" abort requests
- "valid" being within the CmdSN window.  Clarifying
so would also be consistent with the last para in
section 6.9.  IIRC, the special casing for immediate commands
(RefCmdSN=CmdSN) was introduced a little later in
iSCSI's design thus leaving the original text incomplete.

My suggestion would be to provide two clarifications -

a) Add "(or Referenced Task Tag in the case of immediate
    commands)" to last para in 6.9 so it becomes:

"If the abort request is received and the original command is
missing, targets MUST consider the original command with that
RefCmdSN (or Referenced Task Tag in the case of immediate
commands) to be received and issue a Task Management response
with the response code: "Function Complete".  This response
concludes the task on both ends."

b) Add "or equal to" to the 10.6.1 bullet (b) so it in
    part becomes:

"....is within the valid CmdSN window and less than or
equal to the CmdSN of the Task Management function
request itself,...."
-- 
Mallikarjun

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

---

From: Julian Satran <[email-masked]>
Date: Mon, 19 Jan 2004 00:45:53 -0800

Bob,

Sorry for not being able to answer earlier.
Strange how memory works. I recall a long discussion with Mallikarjun over 
this exact matter at a lunch table in a London restaurant.
We concluded that for an immediate command we should be silent (i.e., the 
standard text should not say anything explicit abut it).
Immediate commands have an "aura of uncertainty". 
The target has no way of distinguishing if the initiator issued an 
immediate command with ITT=t and the command was lost or the the command 
was executed already or the command is still in flight (recall that 
immediate commands are not creating holes). 

The initiator may eliminate the ambiguity (in flight or not) by issuing at 
least one non-immediate command between the immediate command and it's 
abort.

The target may answer with "function complete" only if it can 
unambiguously determine that the task with ITT=t was issued (if at all) 
prior to the abort (this was the reason for RefCmdSN=CmdSN).

Otherwise it should answer with "task does not exist".

I think that the text covers both cases but we may want to add the 
"unambiguous case" to 6.9 explicitly.

Regards,
Julo

"Mallikarjun C." <[email-masked]> 
17/01/2004 01:39

To
"Robert D. Russell" <[email-masked]>
cc
Julian Satran/Haifa/IBM@IBMIL, [email-masked]
Subject
Re: [Ips] ABORT of immediate commands

Mallikarjun Chadalapaka

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 20 Jan 2004 11:19:24 -0800

Julian,

You may be correct in your recollection of
our conversation.  Let me state my current
reasoning for the response I had below.

As you say, immediate commands have an aura of
uncertainty.  So unless the target has a record
with an ordered list of all the ITTs of the tasks
it had executed, it cannot be certain about having
ever received a RefTT (assuming the target doesn't
currently have it executing).  But then again,
having the RefTT in its record is not a guarantee
that the initiator is wanting to abort the same
instance of that RefTT (RefTT could've been reused).

It therefore seemed to me that the target would
almost be forced to respond with a "task does not
exist" if the task isn't currently executing, eventhough
the odds of losing the immediate command (digest
failures) are considerably small.

Since this target behavior is different from that
exhibited for non-immediate commands (for which "function
complete" responses are the most likely), I suggested
what I did.  But perhaps the inherent ambiguity wrt
immediate commands is reason enough to require a
different behavior, I guess I personally don't see
it that way.

Regards.
-- 
Mallikarjun

Mallikarjun Chadalapaka

Julian Satran wrote:

> Strange how memory works. I recall a long discussion with Mallikarjun 
> over this exact matter at a lunch table in a London restaurant.
> We concluded that for an immediate command we should be silent (i.e., 
> the standard text should not say anything explicit abut it).
> The initiator may eliminate the ambiguity (in flight or not) by issuing 
> at least one non-immediate command between the immediate command and 
> it's abort.
>

---

From: [email-masked]
Date: Tue, 20 Jan 2004 19:18:38 -0800 (PST)

> different behavior, I guess I personally don't see

I realize I'm chiming in much after the initial discussions, but I'd like
to vote for a difference in behavior, based on the difference in
underlying command behavior between immediate and non-immediate commands.

For an unreceived non-immediate command, "Function complete" makes sense
as we can remember the task has been aborted even though we haven't
received it yet. Either way, it's aborted. :-)

Immediate commands, though, as you note, can't really do that. So I think
just returning "Task does not exist" seems best.

Take care,

Bill

---

From: Julian Satran <[email-masked]>
Date: Tue, 20 Jan 2004 22:09:11 -0800

Mallikarjun,

Our conclusion at the time was that the target should answer based on what 
it has.
If it doesn't have the task it should respond that it doesn't have it.
If the initiator wants more guarantees it should not send immediate 
commands that may need aborting.
I don't see anything to justify revisiting this item.

Regards,
Julo

20/01/2004 11:19

To
Julian Satran/Haifa/IBM@IBMIL
cc
[email-masked], "Robert D. Russell" <[email-masked]>
Subject
Re: [Ips] ABORT of immediate commands

Julian,

Regards.
-- 
Mallikarjun

Mallikarjun Chadalapaka

---

From: Paul Koning <[email-masked]>
Date: Wed, 21 Jan 2004 14:25:27 -0500

>>>>> "Julian" == Julian Satran <[email-masked]> writes:

 Julian> Mallikarjun, Our conclusion at the time was that the target
 Julian> should answer based on what it has.  If it doesn't have the
 Julian> task it should respond that it doesn't have it.  If the
 Julian> initiator wants more guarantees it should not send immediate
 Julian> commands that may need aborting.  I don't see anything to
 Julian> justify revisiting this item.

I agree with that reasoning.

    paul

---

From: Julian Satran <[email-masked]>
Date: Thu, 22 Jan 2004 03:56:10 +0200

That is what the spec says today. Julo

[email-masked] 
Sent by: [email-masked]
20/01/2004 19:18

To
"Mallikarjun C." <[email-masked]>
cc
Julian Satran/Haifa/IBM@IBMIL, [email-masked], "Robert D. Russell" 
<[email-masked]>
Subject
Re: [Ips] ABORT of immediate commands

Take care,

Bill