IPS Requirements discussion points

[Ralph Weber <ralphoweber@compuserve.com>]

Okay, I admit it, I also noticed a few things in the iSCSI (Internet SCSI)
Requirements <draft-haagens-ips-iscsireqs-00.txt> that go beyond the realm
of typos.

Regarding the last sentence on page 4:

    At the current time, we do not seek a more generic requirements
    statement that would justify the choice of TCP (or another protocol)
    as transport, since the merits of using TCP are readily evident to the
    working group participants.

To me this looks like a boilerplate statement to which the parenthetical
phrase "(or another protocol)" was added with the result that it's just
plain confusing.  If "the merits of using TCP are readily evident" then why
would "another protocol" need any mention at all?

Regarding the following in 3.3 near the top of page 8:

     [R] Support SCSI SAM-2 architecture model.

          [D] It would be helpful to produce a document discussing iSCSI
          with reference to SAM-2.  No promises.

Both SPI-3 and FCP-2 contain an annex that relates the protocol to SAM-2.
The FCP-2 version of this is undergoing reconstructive surgery as part
of the preparations for first public review.  However, the finished FCP-2
effort should give iSCSI a substantial leg-up toward meeting the described
requirement.

Regarding the following in 3.3 near the bottom of page 8:

     [R] Support for SCSI Task Queuing.

          [D] SAM-2 defines task queuing, and so strictly speaking, we
          don't need to call this out specifically.  However, task queu-
          ing is not widely implemented today; and it will increase in
          importance with WAN IP networks, given speed-of-light delays.
          We are particularly interested in supporting task queuing of
          pipelined remote backup and asynchronous disk mirroring

          [D] Just because iSCSI supports task queuing doesn't mean that
          the end SCSI node is required to do so also.  Task queuing is
          an optional feature of SCSI.

Tapes do not widely implement task queuing (well okay, they practically
don't implement it at all).  Disks on the other hand are almost universal
in their support for task queuing.

It is also worth noting that a bridging product that provides task queuing
for underlying devices that do not support task queuing has cut itself a
chore that is larger than just passing commands and data back and forth.

Regarding the following in 3.3 at the bottom of page 8 and top of page 9:

     [R] Supports all SCSI-3 command sets [SPC-2, SBC, etc.].  There
     will be no requirement by T10 to modify the SCSI command documents.
     No modifications are required of the SCSI command layer implementa-
     tion, except possibly to lengthen task timers to accommodate wide-
     area delays due to speed-of-light and switching.

T10 believes that commands such as EXTENDED COPY and the disk XOR commands
require modifications to support target identifiers in the URL form and is
working on these modifications.

Regarding the following in 3.3 near the top of page 9:

     [R] Forward compatibility with future revisions of SCSI architec-
     ture and protocol.  Attention to clean layering of protocols.

          [D] This is a difficult requirement to achieve in practice,
          since we cannot predict how SCSI will evolve.  However, care-
          ful attention to protocol layering principles will help ensure
          this result.

Actually the problem here is SCSI history.  SCSI was developed with an
eye toward minimizing implementation costs with much less emphasis on good
layering practices.  That baggage can be very difficult to shed.  For
example, the use of mode pages (command layer constructs) to manage link
layer features totally ignores layering, but the Disconnect-Reconnect mode
page performs just such a function and recently two protocol-specific mode
pages were added not so much as an affront to layering common sense but
because no other practical mechanism could be found.  So there's one of my
favorite layering rat holes, let's talk about what's giving you headaches.

Regarding the following in 3.4 at the top of page 10:

          [D] SAM-2 seems to require this channel allegiance: "A task
          involving one initiator-target pair shall not specify a third
          SCSI device to participate in transmitting and receiving the
          remote procedure model elements for that task.  Thus, an SMU
          initiator [e.g., a host computer] shall not create a task
          using one service delivery port with the expectation that the
          data transfer or status return for that task would occur via a
          different service delivery port" [SAM-2, section  4.10.7,
          p.33].  Of course, interpretation of this clause depends on
          the definition of service delivery port.  If a service
          delivery port is a TCP connection, then channel allegiance is
          pretty clearly required.  But if a service delivery port is an
          iSCSI session or an abstract target device, then the interpre-
          tation of this clause is less clear.

Please be aware that the SMU concept will be removed from SAM-2 within the
next 6 to 9 months.  SMU was a proposal and it has fallen into disfavor
with T10.  The following diagrams illustrate the conceptual transition that
T10 is in the process of building/modifying definitions to support:

Past:

    +------------+
    | Initiators |    +--------+    +----------+
    | A1, A2,... |----| Port A |----|          |
    +------------|    +--------+    |          |+-----------+
                                    |          ||           |
                                    | Target 0 ||   LUN 0   |
                                    |          ||           |
    +------------+    +--------+    |          |+-----------+
    | Initiators |----| Port B |----|          |
    | B1, B2,... |    +--------+    +----------+
    +------------+


Probable future:

    +------------+
    | Initiators |    +--------+----------+
    | A1, A2,... |----| Port A | Target A |--+
    +------------+    +--------+----------+  |  +-----------+
                                             |  |           |
                                             +--|   LUN 0   |
                                             |  |           |
    +------------+    +--------+----------+  |  +-----------+
    | Initiators |----| Port B | Target B |--+
    | B1, B2,... |    +--------+----------+
    +------------+

Also, it looks to me like the multiple connections issue may be one that
IPS can solve on its own using an internal T10 agreement as a guideline.
>From the point of view of the SCSI Architecture Model, more than one
connection may be used to implement a service delivery port provided the
modeled capabilities of the port are maintained.  In Fibre Channel talk,
the use of 'hunt groups' is permissible at or below FCP-2 and outside the
scope of SAM.  Should IPS wish to revisit this perspective, please be aware
that the internal T10 agreement is not cast in stone.

Regarding the following in 3.4 at the bottom of page 10:

     [R] Command striping (load balancing) across multiple host and dev-
     ice interfaces.  It shall be possible to utilize multiple con-
     current paths between hosts and devices for the purpose of load
     balancing.

          [D] Load balancing refers to concurrent tasks from a single
          initiator.  There is no ordering constraint among these tasks.
          We aim to distribute these tasks (commands and their related
          data and status) across multiple host ports, links, switch
          ports and device ports, in order to achieve aggregate perfor-
          mance equal to a multiple of single link performance.

The statement 'There is no ordering constraint among these tasks.'
assumes that all tasks carry the SIMPLE queuing attribute.  While this is
consistent with the normal case queuing mindset, it is a very restrictive
assumption.

In regards to this and a couple other statements related to multiple
connections, it may be productive for IPS and T10 to discuss the
architectural meaning of terms like initiator, target, and port
realizing that the T10 definitions of these terms are in a state
of flux at the moment because T10 is trying to develop an acceptable
model for devices with multiple ports.

Regarding the following in section 4 at the top of page 21:

     [CAM-3] ANSI NCITS.  Dallas, William D., editor.  Information Tech-
     nology - Common Access Method - 3 (CAM-3)).  X3T10 Project 990D.
     rev 3, 16 Mar 1998.

T10 has withdrawn the CAM-3 project.  No further work will be done and no
standard will be produced.  I think the closest equivalent IETF classification
of the last CAM-3 draft would have to be 'Historic'.