Subject: Re: iSCSI: CmdSN during the Login phase

From: "Julian Satran" <[email-masked]>
Date: Tue, 17 Jul 2001 12:06:04 +0300

The issue of the leading connection goes beyon numbering. The leading
connection login has to end (successfully) before any other login (if any)
can start. Obviously CmdSN starts from the leading login.

The text for CmdSN in Login now reads:

1.1.1     CmdSN

   CmdSN is either the initial command sequence number of a session (for
   the first Login of a session - the "leading" login) or the command
   sequence number in the command stream.

 All logins after the leading one can proceed in parallel.

 To achieve this "serialization" TSID is specified as valid only with the
 Login response with F bit on.

 The F-Bit text in the response reads:

1.1.1     F (Final) bit

   Final bit is set to one in the Final Login Response. A Final bit of 0
   indicates a "partial" response, which means "more negotiation needed".

   A login response with a F bit set to 1 MUST NOT contain key=value pairs
   that may require additional answers from the initiator.

 And the TSID:

1.1.1     TSID

   The TSID is an initiator identifying tag set by the target.  It MUST be
   valid only if the login is accepted and the F bit is 1

 Julo

"Scott M. Ferris" <[email-masked]> on 17-07-2001 01:26:13

Please respond to "Scott M. Ferris" <[email-masked]>

To:   [email-masked]
cc:
Subject:  iSCSI: CmdSN during the Login phase

  At what point during the Login Phase of a leading connection (null
TSID) does a session exist?

  Section 2.10.7 describing CmdSN for the Login PDU indicates that
when TSID is null, CmdSN indicates the starting Command Sequence
number for this session.

  For interoperability, it is important to define precisely when a
session exists, so that all initiators and targets agree on when
CmdSNs are significant, and do not reject or ignore PDUs due to
differing assumptions of how the CmdSN numbering should be done during
the Login Phase.

Some of the possible choices for session start are:

1) a session starts before the initiator sends anything, and the Login
   PDU is the first PDU of a session.

2) a session starts when the initiator receives a (possibly partial)
   Login Response with an accept status class and a non-zero TSID, and
   the next PDU sent by the initiator is the first PDU of the session,
   which uses the same CmdSN as the Login PDU.

3) a session starts when the initiator receives a Final Login
   Response, and the next PDU sent by the initiator is the first PDU
   of the session, which uses the same CmdSN as the Login PDU.

  After searching through draft 6, I was unable to find anything that
clearly indicated which if any of the above possibilities was correct,
or, if more than one is possible, how the initiator and target are
supposed to determine what CmdSN numbering scheme the other side is
using for the Login Phase.

  The UNH draft-6 initiator appears to use choice #1.  The Cisco
draft-6 initiator and target use choice #2.  This can cause the UNH
initiator to hang when trying to login to the Cisco target, since the
initiator may send a Text PDU with CmdSN 2, while the target is
waiting for a PDU with CmdSN 1.

  Section 1.2.2.2 states that "Status numbering starts after
Login. During login, there is always only one outstanding command per
connection and status numbering is not strictly needed but may be used
as a sanity check."

  A similar argument could be made that CmdSN is not needed during the
Login Phase, suggesting choice #3 may be the simplest.

  I also think section 1.2.2.2 is problematic, as it appears to
contradict itself by saying that status numbering is not used during
login, and then follows up saying status numbering may be used during
login.

--
Scott M. Ferris,
[email-masked]

---

From: "Matt Wakeley" <[email-masked]>
Date: Tue, 17 Jul 2001 12:28:51 -0700

"Scott M. Ferris" wrote:

>   If the Login PDU is going to have a valid CmdSN rather than an
> InitCmdSN, why does the Login Response have an InitStatSN rather than
> a StatSN?

Because the login may be adding another connection to a multiconnection
session.  In that case, it is not the initial CmdSN, it is the next valid
CmdSN of the session.

The StatSN is on a per connection basis, so everytime you open up a new
connection, you have an initial StatSN.

-Matt

---

From: "Scott M. Ferris" <[email-masked]>
Date: Tue, 17 Jul 2001 12:47:40 -0500 (CDT)

>    sequence number in the command stream.

  That text in 1.1.1 by itself is not sufficient to convince me that
CmdSN starts from the leading login.  It also needs to be made clear
that the leading Login PDU is considered part of the session.  In
earlier drafts, the Login PDU had a field called InitCmdRN, and the
text seemed to imply the InitCmdRN (and InitStatRN of the Login
response) refered only to subsequent PDUs, not the current PDU.

  If the Login PDU is going to have a valid CmdSN rather than an
InitCmdSN, why does the Login Response have an InitStatSN rather than
a StatSN?  The naming is inconsistent, and the InitStatSN text in
2.11.5 still reads to me as if the InitStatSN refers only to
subsequent PDUs, and is telling the initiator what StatSN the target
will start with later, not acting as a StatSN itself.  It would seem
more consistent for the Login Response to have a StatSN it could use.
Perhaps that is already the intended meaning, and I'm just finding
2.11.5 unclear.

  Somewhere in the draft, I'd like to see a precise definition of when
a session starts.  I don't think that either defat 06 or 06-97 is
sufficiently clear on that point.  By putting a CmdSN on the leading
Login PDU and calling it the initial CmdSN of a session, a session
appears to be defined as existing before any PDUs are sent, which
seems rather odd to me, and not what I would have expected.  It seems
more natural to me to define a session as existing after a successful
leading Login.

  I suppose a session could be defined as existing as soon as the
target receives a leading Login PDU, though I'm not sure that
definition is consistent with section 1.2.1, which states that "A
session is defined by a session ID that is composed of an initiator
part and a target part."  I read that as saying that a session exists
when you have a session id, which contains an ISID and a TSID.  To get
a TSID, you need the initiator to send the target a Login PDU with an
ISID.  To get a Login PDU to the target, you need to already have a
session, since the leading Login PDU is the first PDU of a session.
There's a circular dependency there.

  That definition also seems inconsistent with the first paragraph of
section 1.2.3, which seems to imply a connection becomes part of
session only at the end of a login by placing "and mark the connection
as belonging to an iSCSI session" last, after all of the other login
activities.

  From just a numbering perspective, I agree that numbering starting
from the Login PDU makes a lot of sense.  The problems I have with the
draft 06 (and 06-97) come from the definition of a session, since the
CmdSN is defined as numbering PDUs in a session, not just numbering
PDUs.

-- 
Scott M. Ferris,
[email-masked]