Subject: RE: iSCSI: Out Of Sequence due to null sequence with multiple con nections.

From: "Binford, Charles" <[email-masked]>
Date: Tue, 3 Apr 2001 12:33:30 -0400

See comments below, marked with ++++

Charles Binford
Pirus Networks
316.315.0382 x222

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, April 02, 2001 2:13 PM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI: Out Of Sequence due to null sequence with
multipleconn ections.

It still appears to me that the behavior that
Charles wants is available by sending the task management
function twice - once for immediate delivery and once for
ordered delivery.  Duplication on all connections would
not be necessary in the normal case because the ordered
instance would naturally come behind the unordered ones.
The timer seems to be something that ought to be taken
up under error recovery in general (and in particular,
we should consider letting TCP time out the connection
rather than adding yet another recovery timer).  IMHO,
the bottom line is that the logic to duplicate the task
management commands at the Initiator and coordinate
them at the Target costs implementation complexity,
and I have not seen a convincing statement of what
we're buying with that added complexity.

It may be the case that applications don't want to be
bothered with sending task management commands twice,
in which case we have a coordination problem of some
form that has to be addressed in iSCSI.

+++++++++++++++
I would state this much stronger.  Applications had better not have to know
that it is iSCSI underneath vs. FCP or parallel SCSI else I believe we
missed the objective (granted, some things such as target address space are
unavoidably different, but I believe task management functions should be the
same).  The transport needs to handle the transport issues without exposing
quirks to the SCSI or application layer.

I would be more agreeable if David was advocating the iSCSI layer was
responsible for sending task management functions twice, once with, once
without ordering.  This puts the handling of the iSCSI specific ordering
issue in realm of iSCSI.  My caution to this approach is that is changes the
behavior of the target slightly.  The SCSI target layer will see the task
management function twice, not once.  I can't think of any scenario where
this would matter, but I get nervous when we change behavior from the norm.
++++++++++++++++++ cb

For further discussion,
--David

---

From: [email-masked] (Sandeep Joshi)
Date: Thu, 5 Apr 2001 23:47:59 -0400 (EDT)

> Unfortunately, I think we have an impossible situation.  It appears to me
> that
> we have to pick at most two of the following three goals, as I have yet to
> see
> any way to achieve all three for a single task management command on a
> multiple connection session:
> 
> (1) The command takes effect immediately and its status/response
>         is available immediately.
> (2) The command affects all commands in flight, and its status/response
>        is delayed until all such effects are complete.
> (3) There is no significant visible departure from existing SCSI task
>        management behavior.
> ...
> ...
> Sandeep's proposal to create state in the target either fails to achieve
> (1) [if the response is delayed until the state is removed] or violates SAM2
> [returns the response to the task management command before the task
> management command is complete].  Having state linger after a completed
> LUN or TARGET RESET is almost certainly wrong.

Hi David,

Still wading thru related emails but I believe that if a refCmdSN
is added to the task management PDU (not present currently but
could be added for task-related management commands), then it 
might fix the above-mentioned flaws and allow for safe execution 
and immediate delivery of the abort task to the target.  

refCmdSN (cmdSN of refTaskTag) can tell you where the abort task 
command was received in the target command stream.

Processing at target :
1) Initiator task tag reuse : should not happen before refCmdSN
   so can be used for comparisons until refCmdSN expires.
2) State deletion : can be done by target after refCmdSN PDU
   has arrived and is processed/dropped.
3) If Abort task command is early (refCmdSN not arrived) : 
   then create state and drop PDUs when they arrive.
4) If Abort task command is Late (executing now beyond refCmdSN): 
   target sends a task response of task-not-found (this return 
   code exists in the draft).   Otherwise, we may cancel the
   wrong task if the initiator task tag has been reused!
5) If Abort task reaches when target is executing refCmdSN : 
   pass abort task to SCSI layer and return response.
6) Task response can be returned as appropriate to conform with
   SAM2 - either after in-flight commands arrive or immediately
   since the target knows what needs to be done later.  I am slightly 
   confused here since your goals (1)&(2) appear to be contradictory
   for application to in-flight commands.. it depends on semantics 
   what "taking effect" implies ?

One question is, is it reasonable to assume that the initiator
knows the cmdSN of an issued original task(cmdSN<->initiator taskTag).  
This knowledge may be anyway needed if commands are to be re-issued 
in cmdSN order during recovery of a broken connection.  Its an 
implementation issue but can be debated.

Any other holes that we see..
1) multi-NIC initiators ?
2) dont want to introduce state at target ?
3) may affect iSCSI routers or gateways in strange ways ?
4) linked command issues ?

thanks,
-Sandeep

---

From: [email-masked]
Date: Sat, 7 Apr 2001 18:57:35 +0200

CmdSN is meant to be short lived.  Commands numbers are not retained after
command start executing.  However you would like to have a task management
command operating on task executing.

Julo

[email-masked] (Sandeep Joshi) on 06/04/2001 05:47:59

Please respond to [email-masked] (Sandeep Joshi)

To:   [email-masked]
cc:
Subject:  RE: iSCSI: Out Of Sequence due to null sequence with multiple con
      nections.

Hi David,

Processing at target :

thanks,
-Sandeep