Third-party SCSI data transfers

Don Tolmie det at lanl.gov
Tue Sep 20 15:03:49 PDT 1994


Time for me to eat some crow, and also to flame.  I am now donning my
asbestos shorts.... flame ON....

There were comments received from Bob Snively of Sun, and Dick Watson of
Livermore, both of which read unintended things into my proposal to use
SCSI on top of TCP/IP.  They also raised some valid criticisms of my
proposal.

    I was not proposing that the host be aware of the low-level SCSI
    command requirements, or that third-party transfers are unneeded
    or unwanted.  I fully support the Mass Storage System Reference
    Model.

What I was proposing, albeit half-baked, was to use TCP/IP as the vehicle
for transporting high-level SCSI commands, e.g., GPP, and the associated
data, between the different systems.

My view of Lansing's original proposal is that SCSI sits above the data
link layer (loosely using the OSI reference model terms).  My view of
Lansing's proposal looks like:

    Client A      Network Cloud     +--------------------+
    +------+    +---------------+   |+------+            |
    | SCSI |    |               |   || SCSI |            |
    |------|    |               |   ||------|  Storage   |
    | DLL  |    |               |   || DLL  |  System    |
    |------|    |               |   ||------|  Processor |
    |  PH  |----|               |----|  PH  |            |
    +------+    |               |   |+------+            |
                |               |   +--------------------+
                |               |                    |
                |               |         trusted -->|
                |               |           path     |
                |               |                    |
    Client B    |               |   +--------------------+
    +------+    |               |   |+------+            |
    | SCSI |    |               |   || SCSI |            |
    |------|    |               |   ||------|  Storage   |
    | DLL  |    |               |   || DLL  |  Device    |
    |------|    |               |   ||------|            |
    |  PH  |----|               |----|  PH  |            |
    +------+    +---------------+   |+------+            |
                                    +--------------------+

   where DLL = Data Link Layer protocol
          PH = Physical Layer protocol

My proposal has the same general organization with the protocol stacks in
each device replaced with:

    +------+
    | SCSI |   I am assuming that only high-level the SCSI commands
    |------|   will use this path, i.e., those referring to file
    | TCP  |   transfers.  Low-level SCSI commands, e.g., seek, status,
    |------|   sector addresses, etc., would only appear on the "trusted
    |  IP  |   path".
    |------|
    | DLL  |
    |------|
    |  PH  |
    +------+

The advantages of this approach were listed in my previous posting, and are
summarized here.

1. TCP is available on most machines and for most media
2. Can intermix media through bridges, routers and gateways
3. Easy coexistence with other networked devices and systems
4. Takes advantage of TCP/IP protocol suite and work by others
5. Provides wide area network capability
6. TCP and IP are robust with good error controls and recovery
7. TCP and IP are complete, tested, enhanced, and proven in practice
8. NFS is an example of a system running on top of UDP/IP

Disadvantages of using TCP/IP, which I did not previously list, but have
been pointed out by others, include:

1. TCP and IP may add complexity and possible poor performance
2. The storage device may not have enough intelligence to do TCP/IP
3. TCP and IP are intended for point-to-point, with no provision for third
party transfers

I feel that a disadvantage of Lansing's proposal is that it does not scale
to large systems with many attachments, or to systems with other than
excellent error characteristics.  I feel that TCP/IP covers both of these
problems.

The questions then become:

1. What is the environment you are aiming for?
    a. Heterogeneous or homogenous media?
    b. Is it essentially error free?
    c. Large or small number of interconnected systems?
2. How much network capability, error recovery, etc. will need to be added
to SCSI to work without TCP/IP?
3. How easy would it be to add a third-party-transfer capability to TCP/IP?
4. Would a non-TCP/IP solution run significantly faster than TCP/IP?

I admit that I do not know the answers to any of these questions.  My
motivation is to avoid re-inventing the wheel if possible.

Flame OFF...  Please note that I am trying to be constructive.

The bottom line is that you pay your money and take your choice.  One
choice is to provide for both capabilities.

+===========================================================+
! Don Tolmie                        Internet: det at lanl.gov  !
! Los Alamos National Laboratory    Phone: 505-667-5502     !
! CIC-5, MS-B255                      Fax: 505-665-7793     !
! Los Alamos, NM  87545                                     !
+===========================================================+






More information about the T10 mailing list