Re: iSCSI: current UNH Plugfest

["Julian Satran" <Julian_Satran@il.ibm.com>]

Bob,

Comments in text.

Thanks,
Julo




"Robert D. Russell" <rdr@mars.iol.unh.edu>
Sent by: owner-ips@ece.cmu.edu
02-11-01 01:31
Please respond to "Robert D. Russell"

 
        To:     ips@ece.cmu.edu
        cc: 
        Subject:        Re: iSCSI: current UNH Plugfest

 


Attached are the new issues that arose during the iSCSI plugfest at
UNH on Thursday 1-Nov-2001.

Bob Russell
InterOperability Lab
University of New Hampshire
rdr@iol.unh.edu
603-862-3774

----------------------------------------------------------------------

There were no new issues today!  Lots of people were busy sending
data and interoperating with each other!  There were, however, a
few suggestions/requests for clarifications in the standard:

1. Since all Login Requests MUST be issued as immediate requests,
the diagram in section 3.12 should show bit 6 of byte 0 as "1",
not "I", and section 3.12.2 should simply be eliminated.

++++

OK - Julo

++++

2. The first paragraph of Appendix D should describe the special
role of the first Login request on the first connection of a new
session.  In particular, there are 3 keys that MUST be sent in
that Login PDU (InitiatorName, SessionType if it is discovery,
TargetName if the session is normal).  This is, in fact, yet
another classification that is currently included within LO, but
LO is too general, since LO allows keys to appear at any time
during the leading login phase, and these keys must appear on the
very first login PDU in that leading login phase.

+++

There is now a text in Section 5 that reads:

The initial Login request of the first connection of a session (primary 
login) MUST include the InitiatorName key=value pair. The primary Login 
request MAY also include the SessionType key=value pair in which case if 
the SessionType is not "discovery" then the leading Login Request MUST 
also include the key=value pair TargetName.


+++

3. A target cannot release its resources for a command until it
receives an ExpStatSN back from the initiator that acknowledges
receipt of the StatSN carried in the SCSI Response to that command.
However, if the initiator does not have any more I/O to perform,
that ExpStatSN will not come back to the target, and the target
may end up holding on to those resources indefinitely.  This is a
situation where initiator non-action can impact target performance,
and could even lead to denial of service attacks if several
initiators were to do this simultaneously to the same target.

The standard provides the NOP-In/Out mechanism to deal with this:

The last paragraph of section 2.2.2 says:
  During periods when traffic on a connection is unidirectional,
  iSCSI NOP-Out/In PDUs may be utilized to synchronize the command
  and status ordering counters of the target and initiator.

and section 3.18 says:
  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.

The question is, is there a recommended mechanism to trigger these
NOP-pings?

Clearly the target could set a timer, and if ExpStatSN is not
received back at the end of the time interval, the target could
send a NOP-in as a ping in order to get the initiator to send back
a NOP-out with the updated ExpStatSN.

Also clearly the initiator could set a timer, and if it has no
traffic to send during the time interval, the initiator could send
a NOP-out to deliver the updated ExpStatSN to the target.
This approach is probably not as reliable as the first, since
a) if the initiator does not do it, only the target gets hurt, and
b) if the connection drops, the target will never receive the NOP-out.
On the other hand, it may be more efficient for the initiator to do
this, since a typical target may be dealing with hundreds of
connections, and the initiator only a few.

Which is the best procedure?  Are there other ways to do this?
What is the recommended way, or is there a reason for the standard
not to recommend a triggering mechanism, in which case, could
the standard suggest methods or provide guidance, especially if there
are better, less obvious ways to do it?

+++

There are no better ways to do it. However we see this a purely an 
implementation matter.
I assume that a target low on resources will try to recover some and ping 
the initiators.

+++