Questions on iSCSI 07

["Lee Xing" <lxing@Crossroads.com>]

Hi All,

I have a few questions on iSCSI 07.  I would appreciate it if someone
could explain them.

Thank you.


Lee Xing
Sr. Software Engineer
Crossroads Systems, Inc.

----------------------------------------------
Q1:
Page 104: "Operational parameters MAY be negotiated outside (after) the
login phase."
Page 157: "Some session specific parameters MUST be carried only on the
leading connection and cannot be changed after the leading connection
login..."

If operational parameters are considered as session parameters, then
should we reword the sentence on page 104, such as "Some operational
parameters MAY be negotiated outside (after) the login phase."?

----------------------------------------------
Q2: 
Page 22: "Any PDU except login and text, which is sent on a TCP
connection before this connection gets into full feature phase, is a
protocol error."

Page 169: "To make use of SendTargets, an initiator must first be logged
in to one of two types of targets."

Since SendTargets is one of the keys for Text Cmds, and we can't issue
it before logging in, we probably should reword the sentence on page 22.

----------------------------------------------
Q3: Page 169: "If it logs in to any other target, the session the
session can be either a discovery session or a normal operational
session".  Should we delete one "the session" from this sentence?

----------------------------------------------
Q4: Why don't section 1.2.2.1 & 1.2.2.2 address where CmdSN & StatSN
should start from (0, 1, or whatever) explicitly like DataSN does?
Should we initialize the counters before start the process?

----------------------------------------------
Q5: Page 102: "An operational parameter negotiation on a connection
SHOULD not start before the security/integrity negotiation if such a
negotiation exists.  Operational parameters negotiated inadvertently
before the security/integrity negotiation MAY be reset after the
security/integrity negotiation at the explicit request of the initiator
or target."

The question is under which circumstance do we need to negotiate
operational parameters before security/integrity negotiation?  If it's
unlikely to happen, why do we leave a potential security hole here?

----------------------------------------------
Q6: 
Page 21: "... ... If an initiator and target are connected through more
than one session, both the initiator and target perceive the other as a
different entity on each session (a different I_T nexus in SAM-2
parlance)."

Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

The sentence on page 21 tells us multi-sessions between an initiator and
a target are allowed; while the sentence on page 69 implies they are
not.  We probably need to clear it a bit.

----------------------------------------------
Q7:
Page 69: "When a target is detecting an attempt to open a new session by
the same initiator (same InitiatorName and ISID) it MUST check if the
old session is active.  If it is not the old-session must be reset by
the target and the new session established. Otherwise the Login MUST be
terminated with a Login Response."

What does "reset" exactly mean here?

----------------------------------------------
Q8: This question is on multi-path.  Suppose two NICs are connected to
the same target, therefore we could have at least two target addresses
a1 & a2.  Suppose address a1 needs to be dedicated to a particular
initiator I1.  Is it OK if we let the target to hide a1 from (i.e. not
sending a1 with "SendTargets" cmd response to) all initiators except I1,
or do we need to modify 07 to do so?

The current Standard 07 on page 171 says "If a SendTargets response
reports an iSCSI address for a target, it SHOULD also report all other
addresses in its portal group in the same response."

----------------------------------------------
Q9:  This is a performance-related question.

After the first (leading) connection logs into a normal operational
session, why can't the same initiator have an option to just "spawn"
more "full featured" connections with the same target without running
Login handshake processes (i.e. authenticate the parties, negotiate the
session's parameters, open security associations protocol and make
connections as belonging to a session) again.  It would be more
efficient if we could have this option.

It seems feasible because:

  - it's not necessary to authenticate both parties 
    again after doing so on the first (leading) 
    connection.
  - security is still possessed without running
    Login process on the following connections 
    because the first (leading) connection has to 
    run Login process, and no extra connections 
    can be spawned without logging into the first 
    one.
  - session parameters, generally, are the same
    for connections within a session.  If not, they
    can be re-negotiated later.
  - All connections within a session belong to
    the same I_T nexus.
  - Text Cmds can be used to "spawn" full-featured 
    connections without adding too much stuff into 
    iSCSI Standard or making it too complex.