00-390r0 Renaming SVP

Edward A. Gardner eag at ophidian.com
Mon Oct 23 10:19:54 PDT 2000


* From the T10 Reflector (t10 at t10.org), posted by:
* "Edward A. Gardner" <eag at ophidian.com>
*
The following is intended for discussion during the forthcoming T10 meeting
week.  A more attractively formatted pdf version will shortly be available
at:

The complete URL for download of the document is
http://www.t10.org/doc00.htm/00-390r0.pdf.

Edward A. Gardner               eag at ophidian.com
Ophidian Designs                719 593-8866 voice
1262 Hofstead Terrace           719 593-8989 fax
Colorado Springs, CO  80907     719 210-7200 cell

Document: T10/00-390r0  Date: October 23, 2000
To: T10 Committee Membership
From: Edward A. Gardner, Ophidian Designs
Subject: Renaming SVP

With the public release of the Infiniband specifications, I find myself
questioning whether I have taken the best approach to specifying SVP.
Experiences of the past months have demonstrated that there is ongoing
confusion about the purpose of SVP. One demonstration of this is that I have
been questioned about SVP's purpose at each of the last three T10 plenary
meetings. I've been questioned similarly in private conversations.

A related aspect is how one might determine compliance with SVP. The VI
Architecture specifies a communication model (message passing plus RDMA) and
a specific API (work lists plus doorbells plus other things). SVP only
requires the communication model, it does not require the API. Indeed, some
of the primary intended uses for SVP (e.g. Infiniband? storage devices) are
unlikely to use the VI Architecture's API. Yet I know of no way to specify
or determine compliance with a communication model. An oft-stated concern is
that compliance be stated in terms of the messages that appear on the wire,
not the programming methods that generate them.

I believe these problems are in part due to the emphasis given to the VI
Architecture in the SVP specification. SVP is based on a communication model
comprised of messaging plus RDMA. For perspective, the following is a
partial list of interconnects consistent with that communication model:
 Digital Equipment Corporation’s Systems Communication Architecture (SCA,
ca. 1982).
 Compaq’s ServerNet (formerly Tandem’s TNet, introduced 1993 or earlier).
 RDMA extensions under discussion for TCP/IP.
 VI Architecture.
 Infiniband.
I know there are others, including various academic proposals. The above are
just a few that I am personally aware of. SVP could in principle operate
compatibly on any of these using the same message formats. However, only the
VI Architecture and Infiniband appear commercially interesting at present.

The essence of this proposal is to remove "VI" and VI Architecture specific
terminology from the title and body of the specification, possibly excepting
incidental mention in the introduction. These will be replaced with the
specific communication model on which SVP is based. The specification will
start with a description of the communication model, then the rest of the
specification body written in terms of that model. An annex will define the
mapping of the renamed SVP to the VI Architecture API. Another annex will
define the mapping of the renamed SVP to Infiniband. I anticipate both of
these annexes will be normative. Additional similar annexes could be added
for other interfaces if justified.

This is, strictly speaking, merely a large editorial change, and one could
argue that it falls within the technical editor's editorial prerogative.
However it is prominent enough that I feel it warrants discussion comparable
to a substantive change. I don't care to risk being tasked to back out such
a large change :-).

For those who care about formal procedures, the applicable sentence of the
project proposal reads "The SCSI VI Protocol (SVP) will define a SCSI
protocol mapping onto the Virtual Interface Architecture and/or functionally
similar cluster protocols". Since the intent of this change is to first
define a model for "functionally similar cluster protocols", then specify
SVP in terms of that model, it is self-evident that this complies with the
project proposal.

Which brings us to the most contentious issue, a new name for SVP. Removing
"VI" from the title means removing the "V" from "SVP". I can't think of any
good alternative words beginning with "V". In discussing possible names with
various people, the best I've heard to date is DAS for Direct Access SCSI
(credit to Pankaj Mehra of Compaq’s Tandem division). "Direct Access" is
sort of an allusion to the use of RDMA and has a nice ring to it. Besides, I
look forward to talking about DAS disks :-). I'm open to other naming
suggestions, but please do not waste meeting time inventing them.


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list