Subject: Re: iSCSI Change - New NOP-Out/In text

From: "Julian Satran" <[email-masked]>
Date: Thu, 16 Aug 2001 19:10:05 +0300

Sandeep,

ITT is the only indicator now that a response is expected.

As much as possible means 4096 (I'll try to put it in here too).

Julo

Sandeep Joshi <[email-masked]>@research.bell-labs.com on
16-08-2001 18:39:34

Please respond to Sandeep Joshi <[email-masked]>

Sent by:  [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
Subject:  Re: iSCSI Change - New NOP-Out/In text

Julian,

Two comments

(1) Sec 1.1.1 should state that the initiator task tag is also valid
    when the initiator sends a NOP-Out on its own.
    The word "only" below is misleading (and perhaps misplaced)

  >  The NOP-Out must have the Initiator Task Tag set to a valid value
only
  >  if a response in the form of NOP-In is requested.

(2) does "as much as possible" imply zero is value (i.e. duplicate
nothing?)
  >    duplicating the data that was provided in the NOP-Out
  >    (if any) as much as possible.

-Sandeep

Julian Satran wrote:
>
> Here  is the new NOP-Out/In text (2.12 & 2.13):
>
> 1.1  NOP-Out
>
>    Byte /    0       |       1       |       2       |       3       |
>       /              |               |               |               |
>      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
>      +---------------+---------------+---------------+---------------+
>     0|X|I| 0x00      |1| Reserved (0)                                |
>      +---------------+---------------+---------------+---------------+
>     4| Reserved (0)  | DataSegmentLength                             |
>      +---------------+---------------+---------------+---------------+
>     8| LUN or Reserved (0)                                           |
>      +                                                               +
>    12|                                                               |
>      +---------------+---------------+---------------+---------------+
>    16| Initiator Task Tag or Reserved (0xffffffff)                   |
>      +---------------+---------------+---------------+---------------+
>    20| Target Transfer Tag or Reserved (0xffffffff)                  |
>      +---------------+---------------+---------------+---------------+
>    24| CmdSN                                                         |
>      +---------------+---------------+---------------+---------------+
>    28| ExpStatSN                                                     |
>      +---------------+---------------+---------------+---------------+
>    32/ Reserved (0)                                                  /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
>    48| Digests if any...                                             |
>      +---------------+---------------+---------------+---------------+
>      / DataSegment - Ping Data (optional)                            /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
>
>    The NOP-Out with the Initiator Task Tag set to valid value (not the
>    reserved 0xffffffff) acts as a "ping command".
>
>    This form of the NOP-Out can be used to verify that a connection is
>    still active and all its components are operational. This command MAY
>    use in-order delivery or immediate delivery. The NOP-Out may be useful
>    in the case where an initiator has been waiting a long time for the
>    response to some command, and the initiator suspects that there is
some
>    problem with the connection.  When a target receives the NOP-Out with
a
>    valid Initiator Task Tag, it should respond with a Nop-In Response,
>    duplicating the data that was provided in the NOP-Out (if any) as much
>    as possible.  If the initiator does not receive the NOP-In within some
>    time (determined by the initiator), or if the data returned by the
>    NOP-In is different from the data that was in the NOP-Out, the
initiator
>    may conclude that there is a problem with the connection. The
initiator
>    then closes the connection and may try to establish a new connection.
>
>    A NOP-Out should also be used to confirm a changed ExpStatSN if there
is
>    no other PDU to carry it for a long time.
>
>    The NOP-Out can be sent by an initiator because of a NOP-In with the
>    Target Transfer Tag set to a valid value (not the reserved
0xffffffff).
>    In this case the NOP-Out Target Transfer Tag must contain a copy of
>    NOP-In Target Task Tag.
>
> 1.1.1     Initiator Task Tag
>
>    An initiator assigned identifier for the operation.
>
>    The NOP-Out must have the Initiator Task Tag set to a valid value only
>    if a response in the form of NOP-In is requested.
>    If the Initiator Task Tag does not contain a valid value, the CmdSN
>    field contains as usual the next CmdSN but CmdSN is not advanced and
the
>    I bit must be set to 1.
>
> 1.1.2     Target Transfer Tag
>
>    A target assigned identifier for the operation.
>
>    The NOP-Out MUST have the Target Transfer Tag set only if it is issued
>    in response to a NOP-In with a valid Target Transfer Tag, in which
case
>    it copies the Target Transfer Tag from the NOP-In PDU.
>
>    When the Target Transfer Tag is set, the LUN field MUST be also copied
>    from the NOP-In.
>
> 1.1.3     Ping Data
>
>    Ping data is reflected in the NOP-In Response. Note that the length of
>    the reflected data is limited to 4096 bytes and the initiator should
>    avoid sending more than 4096 bytes. The length of ping data is
indicated
>    by the Data Segment Length.  0 is a valid value for the Data Segment
>    Length - and indicates the absence of ping data.
>
> 1.2  NOP-In
>
>    Byte /    0       |       1       |       2       |       3       |
>       /              |               |               |               |
>      |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
>      +---------------+---------------+---------------+---------------+
>     0|1|1| 0x20      |1| Reserved (0)                                |
>      +---------------+---------------+---------------+---------------+
>     4| Reserved (0)  | DataSegmentLength                             |
>      +---------------+---------------+---------------+---------------+
>     8| LUN or Reserved (0)                                           |
>      +                                                               +
>    12|                                                               |
>      +---------------+---------------+---------------+---------------+
>    16| Initiator Task Tag or Reserved (0xffffffff)                   |
>      +---------------+---------------+---------------+---------------+
>    20| Target Transfer Tag or Reserved (0xffffffff)                  |
>      +---------------+---------------+---------------+---------------+
>    24| StatSN                                                        |
>      +---------------+---------------+---------------+---------------+
>    28| ExpCmdSN                                                      |
>      +---------------+---------------+---------------+---------------+
>    32| MaxCmdSN                                                      |
>      +---------------+---------------+---------------+---------------+
>    36/ Reserved (0)                                                  /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
>    48| Digests if any...                                             |
>      +---------------+---------------+---------------+---------------+
>      / DataSegment - Return Ping Data                                /
>     +/                                                               /
>      +---------------+---------------+---------------+---------------+
>
>    When a target receives the NOP-Out with a valid Initiator Task Tag
(not
>    the reserved value 0xffffffff), it MUST respond with a NOP-In with the
>    same Initiator Task Tag that was provided in the NOP-Out Command. It
>    SHOULD also duplicate up to first 4096 bytes of the initiator provided
>    Ping Data. For such a response, the Target Transfer Tag MUST be
>    0xffffffff.
>
> 1.2.1     Target Transfer Tag
>
>    A target assigned identifier for the operation.
>
>    A target may issue a NOP-In on its own to test the connection and the
>    state of the initiator. If the target wants to test the initiator, it
>    sets the Target Task Tag to a valid value (not the reserved
0xffffffff)
>    in order to ask for an answer from the initiator. In this case the
>    Initiator Task Tag MUST be 0xffffffff and the LUN field MUST contain a
>    valid LUN. If the target wants only to test the connection, both tags
>    MUST hold the reserved value 0xffffffff and the LUN field is reserved.
>
>    A target may also issue a NOP-In on its own to carry a changed
ExpCmdSN
>    and/or MaxCmdSN if there is no other PDU to carry them for a long
time.
>
>    Whenever the NOP-In is not issued in response to a NOP-Out the StatSN
>    field will contain as usual the next StatSN but StatSN for this
>    connection is not advanced.
>
> 1.2.2     LUN
>
>    A LUN MUST be set to a correct value when the Target Transfer Tag is
>    valid (not the reserved value 0xffffffff).

---

From: "Wheat, Stephen R" <[email-masked]>
Date: Thu, 16 Aug 2001 09:09:30 -0700

Julian,

As a relatively new reader of all this good material, perhaps some "new
eyes" editorial questions/suggestions are of value.  My apologies up front
if this doesn't meet with the WG protocol for such suggestions.

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 16, 2001 8:09 AM
To: [email-masked]
Subject: iSCSI Change - New NOP-Out/In text
   
+++ srw
The first two paragraphs intermix rational and specification for a "ping
command".
Rational is also repeated.
For brevity and clarity, I suggest striving to keep rational segregated from
semantic definition.

Also, the target's semantics are inconsistent between the NOP-out and NOP-in
paragraphs.

I offer the following text update.

I am willing to do such editorial changes for the rest, but am awaiting
whether the suggestions are valuable.
+++ srw

   A NOP-Out may be sent by an initiator as a "ping command".  This form of
the NOP-Out
   can be used to verify that a connection is still active and all its
components are
   operational.  Based upon whether a corresponding NOP-In is received, this
   provides an initiator a way to determine whether it may be necessary to
   close the connection and try to establish a new connection.

   A NOP-Out is also sent by an initiator in response to a NOP-In.

   A NOP-Out may also be used to confirm a changed ExpStatSN if there is
   no other PDU to carry it for a long time.

   This command MAY use in-order delivery or immediate delivery.

   When used as a ping command, the Initiator Task Tag MUST be set to valid
value (not the
   reserved 0xffffffff).

   Upon receipt of a NOP-In with the
   Target Transfer Tag set to a valid value (not the reserved 0xffffffff),
   the initiator MUST respond with a NOP-Out. In this case the NOP-Out
Target Transfer
   Tag MUST contain a copy of NOP-In Target Task Tag.

   When a target receives the NOP-Out with a
   valid Initiator Task Tag, it MUST respond with a Nop-In Response (see
NOP-in).
                                ^^^^ consider MUST???

1.1.1     Initiator Task Tag

   The NOP-Out MUST have the Initiator Task Tag set to a valid value only
   if a response in the form of NOP-In is requested.
   If the Initiator Task Tag does not contain a valid value, the CmdSN
   field contains as usual the next CmdSN but CmdSN is not advanced and the
   I bit must be set to 1.

   The NOP-Out MUST have the Target Transfer Tag set only if it is issued
   in response to a NOP-In with a valid Target Transfer Tag, in which case
   it copies the Target Transfer Tag from the NOP-In PDU.

---

From: "Wheat, Stephen R" <[email-masked]>
Date: Thu, 16 Aug 2001 13:10:53 -0700

Here is a (maybe partial) draft of the suggested NOP-In rewording.  Whether
this type of commentary is worthwhile, please let me know.

Embedded are some questions I have from the original writing this morning.

As a commentary/question, shouldn't all fields be documented, rather than
having their semantics covered in other field documentation???

At the very least, I'd appreciate the text to be changed to answer my
questions embedded below.

BTW, since a NOP-In could result in a corresponding NOP-Out, the name of the
ping data fields is kind of lopsided.  I.e., for NOP-Out, it is "Ping Data",
and for NOP-In, it is "Return Ping Data."  A NOP-Out's ping data is "return
ping data" when sent as a response to a NOP-In.  So, how about just calling
it "Ping Data" in both messages??

Stephen

==================

1.2  NOP-In

   NOP-In is either sent by a target as a response to having received a
NOP-Out,
   as a "ping" to an initiator, or a means to carry a changed ExpCmdSN
   and/or MaxCmdSN if there is no other PDU to carry them for a long time.

   When a target receives the NOP-Out with a valid Initiator Task Tag (not
   the reserved value 0xffffffff), it MUST respond with a NOP-In with the
   same Initiator Task Tag that was provided in the NOP-Out Command. It
   SHOULD also duplicate up to first 4096 bytes of the initiator provided
   Ping Data.

   If the target is responding to a NOP-Out, this is set to ?????????

   If the target is initiating a NOP-Out as a Ping (intending to receive a
corresponding
   NOP-Out), this field is set to a valid value (not the reserved
0xffffffff).

   If the target is initiating a NOP-Out without wanting to receive a
corresponding
   NOP-In, this field MUST hold the reserved value of 0xffffffff.

1.2.2   Initiator Task Tag
   When the NOP-Out is in response to a NOP-In, this is the same value as
found in the NOP-Out.

   Otherwise, this field MUST be 0xffffffff.

1.2.3     LUN

   A LUN MUST be set to a correct value when the Target Transfer Tag is
   valid (not the reserved value 0xffffffff).  Otherwise, it SHOULD be set
to the
   reserved value of 0.

1.2.4  StatSN
   Whenever the NOP-In is not issued in response to a NOP-Out the, StatSN
   field will contain the next StatSN but StatSN for this
   connection is not advanced.  Otherwise, it will be set to ????????.

1.2.5  Data Segment Length
   The number of bytes in the Return Ping Data.  The range is [0..4096].

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 16 Aug 2001 23:25:50 +0300

Correct. In addition the CmdSN is not advanced if ITT is invalid. and the
loop is broken by not leeting the target ship
a NOP-In with both tags valid.

Julo

"Ayman Ghanem" <[email-masked]>@ece.cmu.edu on 16-08-2001 19:08:59

Please respond to "Ayman Ghanem" <[email-masked]>

Sent by:  [email-masked]

To:   <[email-masked]>
cc:
Subject:  RE: iSCSI Change - New NOP-Out/In text

From reading the new text, the initiator/target task tags are used to
indicate what the poll-bit used to do. If the task tag is valid, then a
response is requested, otherwise its a one-way message. The way I
understand
1.1.1 is that the initiator can send a NOP-Out on its own and set the itt
to
valid/reserved value depending on whether it is requesting a NOP-In or not.

-Ayman

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Sandeep Joshi
> Sent: Thursday, August 16, 2001 10:40 AM
> To: Julian Satran
> Cc: [email-masked]
> >    response to some command, and the initiator suspects that
> there is some
> >    problem with the connection.  When a target receives the
> NOP-Out with a
> >    NOP-In is different from the data that was in the NOP-Out,
> the initiator
> >    may conclude that there is a problem with the connection.
> The initiator
> >    A NOP-Out should also be used to confirm a changed ExpStatSN
> if there is
> >    avoid sending more than 4096 bytes. The length of ping data
> is indicated
> >    A target may also issue a NOP-In on its own to carry a
> changed ExpCmdSN

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 17 Aug 2001 13:16:44 +0300

Stephen,

Here is an edited version of the text. As you can see I am not a fan of
verbosity in a standard.
I hope it is a bit clearer.
The are no other changes than editorials.

Please feel free to send me or any other author any changes you propose.
If those are purely editorial you may want to refrain from sending them to
the list.
However you may want to send them to the list if you are somehow not
satisfied with either the answers you got
or think that the list should know about it anyhow.

And as I said there will be an editorial revision coming after 08.

Julo

1.1  NOP-Out

   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |

   A NOP-Out may be used by an initiator as a "ping command", to verify
   that a connection/session is still active and all its components are
   operational.  The NOP-In response is the "ping echo".

   A NOP-Out may also be used to confirm a changed ExpStatSN if there is no
   other PDU to carry it for a long time.

   When used as a ping command, the Initiator Task Tag MUST be set to valid
   value (not the reserved 0xffffffff).

   Upon receipt of a NOP-In with the Target Transfer Tag set to a valid
   value (not the reserved 0xffffffff), the initiator MUST respond with a
   NOP-Out. In this case, the NOP-Out Target Transfer Tag MUST contain a
   copy of NOP-In Target Task Tag.

   When a target receives the NOP-Out with a valid Initiator Task Tag, it
   MUST respond with a Nop-In Response (see NOP-In).

1.1.1     Initiator Task Tag

1.1.3     Ping Data

   avoid sending more than 4096 bytes. The length of ping data is indicated

1.2  NOP-In

   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |

   NOP-In is either sent by a target as a response to a NOP-Out, as a
   "ping" to an initiator, or a means to carry a changed ExpCmdSN and/or
   MaxCmdSN if there is no other PDU to carry them for a long time.

   MUST also duplicate up to first 4096 bytes of the initiator provided

   If the target is responding to a NOP-Out, this is set to the reserved
   value 0xffffffff.

   If the target is sending a NOP-In as a Ping (intending to receive a
   corresponding NOP-Out), this field is set to a valid value (not the
   reserved 0xffffffff).

   If the target is initiating a NOP-In without wanting to receive a
   corresponding NOP-Out, this field MUST hold the reserved value of
   0xffffffff.

1.2.2     LUN

---------------------- Forwarded by Julian Satran/Haifa/IBM on 17-08-2001
12:44 ---------------------------

"Wheat, Stephen R" <[email-masked]> on 16-08-2001 19:09:30

Please respond to "Wheat, Stephen R" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:

Julian,

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 16, 2001 8:09 AM
To: [email-masked]
Subject: iSCSI Change - New NOP-Out/In text

+++ srw
The first two paragraphs intermix rational and specification for a "ping
command".
Rational is also repeated.
For brevity and clarity, I suggest striving to keep rational segregated
from
semantic definition.

Also, the target's semantics are inconsistent between the NOP-out and
NOP-in
paragraphs.

   operational.  Based upon whether a corresponding NOP-In is received,
this

1.1.1     Initiator Task Tag

"Wheat, Stephen R" <[email-masked]> on 16-08-2001 23:10:53

Please respond to "Wheat, Stephen R" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:

BTW, since a NOP-In could result in a corresponding NOP-Out, the name of
the
ping data fields is kind of lopsided.  I.e., for NOP-Out, it is "Ping
Data",
and for NOP-In, it is "Return Ping Data."  A NOP-Out's ping data is "return
ping data" when sent as a response to a NOP-In.  So, how about just calling
it "Ping Data" in both messages??

Stephen

==================

1.2  NOP-In

1.2.2   Initiator Task Tag

1.2.3     LUN

1.2.4  StatSN

"Wheat, Stephen R" <[email-masked]> on 16-08-2001 23:41:33

Please respond to "Wheat, Stephen R" <[email-masked]>

Ooops, this paragraph should have been changed

to

   When a target receives the NOP-Out with a valid Initiator Task Tag (not
   the reserved value 0xffffffff), it MUST respond with a NOP-In.

Where the particular fields of the response are covered in their sections.

Seriously, are you wanting editorial comments about clarity, readability,
and consistency?

Stephen

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 17 Aug 2001 14:29:42 +0300

Time is depending on the target and link. As customary in TCP/IP based
networks the timeouts have to be determined based on the link
characteristics.

Julo

"Asai Thambi S P" <[email-masked]> on 17-08-2001 10:27:42

Please respond to "Asai Thambi S P" <[email-masked]>

To:   <[email-masked]>, Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  Re: iSCSI Change - New NOP-Out/In text

Sorry for the previous mail, which was sent accidentally.

Julian,

I have some questions.

* Section 1.1  NOP-Out

                                            The NOP-Out may be useful
   in the case where an initiator has been waiting a long time for the
   response to some command, and the initiator suspects that there is some
   problem with the connection. .....

   If the initiator does not receive the NOP-In within some
   time (determined by the initiator),

    ? The draft doesn't say what a long time is?

    Section 7.11.1 says as follows:

         The timeout value to be used by a target is outside the scope
           of this document.
    and
         The timeout value to be used by an initiator is outside the
           scope of this document.

    ? How the initiator/target times out is not defined? Then what that
long time refers
    to?

* Section 1.1.3     Ping Data

    ? The text starts abruptly that ping data is reflected....
       It doesn't say what the ping data is?

- asai.

----- Original Message -----
From: Julian Satran <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 16, 2001 08:39 PM
Subject: iSCSI Change - New NOP-Out/In text

1.1  NOP-Out

   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |

   This form of the NOP-Out can be used to verify that a connection is
   still active and all its components are operational. This command MAY
   use in-order delivery or immediate delivery. The NOP-Out may be useful
   in the case where an initiator has been waiting a long time for the
   response to some command, and the initiator suspects that there is some
   problem with the connection.  When a target receives the NOP-Out with a
   valid Initiator Task Tag, it should respond with a Nop-In Response,
   duplicating the data that was provided in the NOP-Out (if any) as much
   as possible.  If the initiator does not receive the NOP-In within some
   time (determined by the initiator), or if the data returned by the
   NOP-In is different from the data that was in the NOP-Out, the initiator
   may conclude that there is a problem with the connection. The initiator
   then closes the connection and may try to establish a new connection.

   A NOP-Out should also be used to confirm a changed ExpStatSN if there is
   no other PDU to carry it for a long time.

   The NOP-Out can be sent by an initiator because of a NOP-In with the
   Target Transfer Tag set to a valid value (not the reserved 0xffffffff).
   In this case the NOP-Out Target Transfer Tag must contain a copy of
   NOP-In Target Task Tag.

1.1.1     Initiator Task Tag

1.1.3     Ping Data

1.2  NOP-In

   Byte /    0       |       1       |       2       |       3       |
      /              |               |               |               |

   sets the Target Task Tag to a valid value (not the reserved 0xffffffff)

   A target may also issue a NOP-In on its own to carry a changed ExpCmdSN
   and/or MaxCmdSN if there is no other PDU to carry them for a long time.

1.2.2     LUN