Subject: Re: iSCSI-related conclusions from Orlando interim Meeting

From: [email-masked]
Date: Mon, 22 Jan 2001 10:28:02 +0200

Santosh,

I am not sure that I understand your points.

   Point c - is irrelevant as task management function are just that task
   management functions and not commands (i.e., have no ordering, queueing
   etc. associated with its SCSI execution)
   we choose to get a task management function a task-id only to simplify
   request response handling in the iSCSI layer - and not because there is
   a SCSI task context associated with it
   the side effects that David (Black) was referring I think are the
   following:
     if at the target you get to abort a task that has not arrived yet and
     since you are bound to use service response function complete you
     should (at the target) dutifully note the referenced-id and abort it
     when it arrives - as you are forbidden (by SAM) to send any more
     responses for this task; this may lead to interesting cleanup problem
     if the referenced id was never sent - and you will have to handle this
     (practically you can remove the mark when CmdSN arrives or after an
     interval if you don't have a CmdSN and either inform or not the
     initiator)
     if at the target you get a clear task set you may end not clearing
     tasks you where supposed too or clearing tasks you where not supposed
     too (as there is no ordering implied)
   The solution suggested - order the task management at iSCSI level is
   straightforward
     task management functions request can be delivered to SCSI and
     executed IMMEDIATELY and the CmdSN they carry should be viewed only as
     a "boundary" for their applicability

Immediate delivery was meant to be used in cases in which you are confident
that ordered delivery does not matter. This might be a drastic action (like
target rest) or things that we did not consider yet.

Julo

Santosh Rao <[email-masked]> on 22/01/2001 02:05:22

Please respond to Santosh Rao <[email-masked]>

To:   [email-masked]
cc:   [email-masked]
Subject:  Re: iSCSI-related conclusions from Orlando interim Meeting

> - Abort WARNING will be added to the draft.
> - Immediate Delivery of Aborts and similar task management commands
>   may have unexpected results when multiple TCP connections are in use
>   because Abort, Clear Task Set, etc. may bypass command(s) to be
>   aborted/cleared on other TCP connections.
> - Ordered Delivery should be used instead when this is a concern.

Is the above referring to ordered delivery as in CmdSN based ordering or
the use of the Ordered Task Tag ?

I see the following issues with this :

a) CmdSN defines the order of delivery from the iSCSI layer to the SCSI
   ULP at the target.

   Abortion of active tasks will involve the invalidation of the
   SCSI State information [being accessed by either adapter micro-code
   or the FPGA/ASIC] maintained for these tasks.
   This process is kicked off in the iSCSI layer and this abort
   functionality in the iSCSI layer will also need to be subject to the
   ordering constraints of CmdSN. (in addition to the ordering of delivery
   to the SCSI ULP).

b) A received Task Management command [on, say, connection 'x']
   cannot be performed due to previous CmdSNs not yet
   having arrived. (In the case where another connection 'y' in the
   session is faulty and CmdSNs sent on connection 'y' have'nt arrived).

c) Ordered Task Tags should not be used with error recovery Task
   Management commands, since this can result in a deadlock of the task
   mgmt command in case the older tasks are'nt completing in the SCSI ULP
   due to some ULP problem. ("An Ordered Task cannot enter the enabled
   state until all older tasks have completed.")

d) Given that Immediate command delivery (CmdSN of 0) is un-usable for
   task management commands, is there any other application for this
   feature? If not, all references to it can be removed from the draft and
   CmdSN can start from 0.

Regards,
Santosh

--
#################################
Santosh Rao
Software Design Engineer,
HP, Cupertino.
email : [email-masked]
Phone : 408-447-3751
#################################

---

From: [email-masked]
Date: Mon, 22 Jan 2001 11:01:51 -0500

> I assume the below is referring to targets using NOP-IN as a NOP request
in
> order to test a connection (?)
> 
> If so, I don't see how this can result in a loop. 

Both NOP-IN and NOP-OUT contain a flag requesting a response (i.e., send the
other sort of NOP back).  If every NOP has that flag set, the two sides will
trade
NOPs forever.  Forbidding that flag to be set when a NOP is sent in response
to a NOP is the most direct way of making sure this doesn't happen.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: [email-masked]
Date: Mon, 22 Jan 2001 10:58:17 -0500

> the use of the Ordered Task Tag ?

It's CmdSN, not Task Tag.  Santosh's issues appear to be with the Task
Tag, which is not what is being pursued.  Using the Task Tag in this fashion
would cause all sorts of problems.

--David

---

From: [email-masked]
Date: Mon, 22 Jan 2001 18:07:47 +0200

Besides there is no way (no SAM defined way) to order task management
functions.
Task management is handled by the task manager while tasks (commands) are
handled by the
device server.

Julo

[email-masked] on 22/01/2001 17:58:17

Please respond to [email-masked]

To:   [email-masked], [email-masked]
cc:   [email-masked]
Subject:  RE: iSCSI-related conclusions from Orlando interim Meeting

It's CmdSN, not Task Tag.  Santosh's issues appear to be with the Task
Tag, which is not what is being pursued.  Using the Task Tag in this
fashion
would cause all sorts of problems.

--David

---

From: "Jim Hafner" <[email-masked]>
Date: Mon, 22 Jan 2001 14:08:29 -0800

Mark and David,

Though we haven't discussed this within NDT, this issue is a bit broader
(applicable to all key:value pairs in login and text messages).

Some have suggested full C syntax, others have said that hex is sufficient.

I'd like to support the two most important cases:
1) representation of 'integer' type values with represent a quantity (like
length, size, count, etc.)
2) binary strings (as might occur in WWUIs, or other binary entities that
don't necessarily represent a 'quantity'

For the first, decimal seems the most natural.  For the latter, hex seems
best suited.    For WWUI's, we've already weakly proposed a format that
implies hex.  Perhaps in other cases, the prefix '0x' or the prefix 'hex='
would be a good way to indicate non-decimal format.

Jim Hafner

Mark Bakke <[email-masked]>@ece.cmu.edu on 01-22-2001 06:16:55 AM

Sent by:  [email-masked]

To:   David Robinson <[email-masked]>
cc:   [email-masked]
Subject:  Re: iSCSI-related conclusions from Orlando interim Meeting

That's right.  The N&D team will send a new draft soon with the
encodings.  Some of the options for encoding binary data are hex,
decimal, octal, and uuencode.  We will probably suggest hex; it
uses more space than unicode, but for most binary names, is the
simplest and most readable.  Please stay tuned.

David Robinson wrote:
>
> [email-masked] wrote:
> > It's a bit cryptic.  The conclusion in the room was
> > to convert binary values to/from text representations
> > for the purpose of negotiation (and use UTF-8 for the
> > text).  This was felt to be simpler than defining new
> > formats for binary values.
>
> So if I want to send the binary data 0101101011110000
> I first turn that into text "5AF0" then encode that into
> UTF-8 "5AF0" (printable ASCII is a no-op in UTF-8)?
>
> I'll buy that.
>
> Any statement as to the text encoding? Hex? Decimal? Octal?
>
>         -David

--
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: [email-masked]
Date: Tue, 23 Jan 2001 17:00:35 +0200

I'll think about it.

Julo

Santosh Rao <[email-masked]> on 22/01/2001 19:32:43

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: iSCSI-related conclusions from Orlando interim Meeting

> I am reluctant to consider any procedure that originates a command at the
> target.

Julian,

iSCSI targets are already allowed to originate Async Messages. This is not
a new procedure being proposed.

>
> Note however that a target in trouble may drop a TCP connection and force
> an initiator to recover.

This does not communicate to the initiator the reason for the connection
close. It is better to use an Async Message for this purpose than
abruptly terminate the connection, for the same reason that one would
rather use a Lgout than close a connection. [in the case where a Logout
is sent on the same connection that is being cleaned up.]

Regards,
Santosh

>
> Santosh Rao <[email-masked]> on 21/01/2001 21:21:46
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   [email-masked]
> On the subject of Async Message "Target requests a logout", which is a
> ping-pong procedure to achieve a logout, it may be worth considering an
> alternate Async Message in its place that indicates "Target is logging
out
> for error recovery" and allow the target to follow up the Async Message
> with a connection close.
>
> This will simplify target driven connection level error recovery.
>
> Regards,
> Santosh
>