September 2000 Minutes
IEEE
Storage System Standards
Working Group
(P1244)

Minutes
Meeting held September 12 through September 14, 2000
At the National Center for Atmosperic Research, Mesa Lab, Boulder, Colorado
Evening out at Sunflower Restaurant, Boulder

Curtis Anderson, SSSWG Chair, presiding
Jack Cole, IEEE Sponsor


1244.1  Architecture/Data Model
        Geoff Peck (principal), Curtis Anderson, Joel Williams,
        Murali Sathyanarayana
1244.2  Session Security, Authentication, and Initialization Protocol
        Bruce Haddon (principal 2000-), Jan Klier (principal 1997-2000),
        Curtis Anderson, Joel Williams
1244.3  Media Management Protocol
        Murali Sathyanarayana (principal), Curtis Anderson, Joel Williams
1244.4  Drive Management Protocol
        Joel Williams
1244.5  Library Management Protocol
        Joel Williams

ATTENDANCE (7).

* Minutes from the July meeting were approved without change.

* The schedule for the next two meetings was confirmed for 11/14-11/16
and 1/16/01-1/18/01.  Jack Cole and Joel Williams will host the November
meeting at the SES facility in Green Belt, MD.  We need to find a
location for the January meeting.

* 1244.6 "Data export/import" - Joel pointed out that the HTML-based
example that was posted to the email list was not the same as the XML
example.  The HTML-based example had a flat structure of tables and rows
while the XML example was a nested hierarchy.  All agreed that the flat
table/row representation was better, but there was no clearcut reason for
the group to select the HTML-based approach or the XML approach to the
exclusion of the other.  The decision was made that 1244.6 would allow
for both formats, conforming implementations can do one or both.  Curtis
will generate a new XML example structured as tables and rows and post
it to the email list as a final check.  Joel will merge his existing
document with text from Curtis on how the XML variant will look.

* 1244.8 "C language API" - Paul is continuing to make progress on this.
He has started from the SmartMedia/OpenVault implementation and is rolling
that API forward to match the requirements of the IEEE MMS standard.  The
API will have both an asynchronous interface, and a synchronous interface
built on top of that.  The API will only support MMP, not LMP or DMP.  It
will be a relatively raw interface in that it will simply give back to the
app whatever has arrived on the connection.  The API should include support
for the new event notifications and session disconnect/reconnect features,
but we will need to add notes on the lack of applicability of those
features to the initial version of MMP.

* 1244.9 & 1244.10 "User and Admin CLI" - Alan has produced a strawman of
the proposed commands and their option strings.  We need list of "common"
operations that a System Administrator or an Operator might perform so that
we can offer simpler access to the common operations versus the less
common operations.  The strawman needs another refinement pass, then we
can proceed to a full writeup.

* Futures List, "Session Disconnect/Reconnect" - There were no additional
comments or criticisms of the proposal from the July meeting, so we will
proceed with editing the appropriate standards documents to include support
for the proposal.  These changes will not take effect until after the next
ballot of the standard, they will only be in the working documents as we
proceed toward the next revision of the standards.

* Futures List, "Event Notification Model" - We made a note to verify how
a denial-of-service attack could be executed using events, and how such an
attack could be prevented.  There were no other comments or criticisms
of the proposal from the July meeting, so we will proceed with editing the
appropriate standards documents to include support for the proposal.
These changes will not take effect until after the next ballot of the
standard, they will only be in the working documents as we proceed toward
the next revision of the standards.

* Futures List, "Central Configuration Management" - Paul gave an overview
of the problem and one possible solution.  The problem is that some pieces
of information (a drive's name for example) must be represented in the MMS
environment in more than one place, and all such places must match or the
system will not work correctly.  There is currently no defined way to cross
check that those values match.  The proposal is a way to enable a tool that
would obtain those values from the user at configuration time, and then
apply them in all of the places they need applying.  The group decided that
there would be enough value in this to proceed to producing a fleshed-out
strawman of the proposal.

* Futures List, "LM-Based Drive Selection" - No discussion.
* Futures List, "Automatic Interlibrary Transfer" - No discussion.
* Futures List, "Fine Grained Security" - No discussion.
* 1563.1 & 1563.2 "Tape Standards" - No discussion.
* 1563.3 "Tape Format" - No discussion.

* Evangelism: Continuing discussion of how we can get more attention for
the MMS standards.  Bruce has tentatively reserved space in the December
issue of the SIGOPS journal for an article we might write.  Bruce has
also submitted an abstract for a paper to be presented at the next Mass
Storage Conference.  We might be able to cooperate with other standards
or industry organizations to get attention from their constituencies.

------------------------- Discussion on the Mover -------------------------

* We examined the question of "why do we want a Mover", and came to the
following set of reasons, ordered according to their importance:
1) label protection, generation, and verification (use ANSI or not?)
2) location transparency of the drive and the app
3) common access and control semantics across all drives and all OS platforms
4) application portability
5) logical volume support (spanning of data sets across multiple tapes)
6) byte stream support (hiding record boundaries)
7) visibility of service characteristic (bandwidth, data path issues, etc)
8) software RAIT support

* We examined the question of "who are we trying to make this useful for",
and came to the following set of examples.  Again, it is ordered:
1) processing of tape labels by an MMS
2) support for simple applications, users of byte streams on tape
3) data intensive apps (scientific, documentation, etc)
4) data logging (OLTP transaction journals, data acquisition, etc)
5) HSM, archival, backups
6) HPSS

* We applied constraints to any solution we might come up with:
+ The Mover is only applicable to sequential media, ie: no disks.
+ The Mover must be able to negotiate the data transport mechanism to use.
+ The app should be able to influence the choice of data transport mechanism.
+ A drive handle must include info on which transport mechanism it is to be
  used with.  For example, "iscsi://179.23.63.12:659".
+ We will not change the requirement that a DM must be running on the same
  machine as the application.
+ A Mover needs to interpose on any control and tape movement operations,
  in order to protect any labels, but may not need to on read or write
  operations.

* Most data transport mechanisms appear to be locally attached to a machine,
just like regular SCSI.  For example, the IETF's new "iSCSI" protocol might
appear to be different, but platform vendors will provide drivers to make
iSCSI-attached drives appear just like they were locally attached.  This is
needed in order for regular filesystems to access their underlying disk
drives if those drives are attached via iSCSI instead of regular SCSI or
Fibre Channel.

* Network topology and performance info is not represented anywhere.
Maybe it should be so that, for example, the app can ask the MMS for a
minimum bandwidth to/from the drive.  The data rate currently advertised
by a DM is the native rate of the drive, not what can be achieved via an
MMS Mover across a clogged network.  How can we possibly gather, represent,
or show this info?

---------------------------- Discussion on NDMP ----------------------------

* In order to evaluate current standards and technology that are relevant
to our Mover discussion, I invited Roger Stager of Legato to come to this
meeting.  Roger was one of the initial developers of the NDMP protocol.

* Roger presented a description of evolution of the NDMP architecture from
NDMPv1 to NDMPv3.  The plans for NDMPv4 are mostly just cleanups and
tightening of the spec.  The plans for NDMPv5 incude support for fan-in
of data sources into a single data stream, fan-out of a single data stream
onto multiple tapes, and inline translation filters for the contents of
the data stream.

* NDMP defines separate modules for robotic library control (called "SCSI"),
control of the tape drive (called "tape"), data movement to/from the tape
(called "mover"), data movement to/from the filesystem (called "data"), and
session control (called "control").

* In practice, data flows between the "data" and "mover" modules.  The NDMP
specification does not directly define how the data is passed from one to
the other.  It defines "address types", where an "address type" defines
how the mover and data modules pass data between themselves.  The only
currently defined "address types" are "local" for all-in-one-box use, and
"tcp" which says the data will pass through a simple TCP pipe with no
encoding, encapsulation, or metadata of any kind.  NDMP only supports a
byte stream model, record boundaries are not representable or preserved.

* An MMS Mover would need to support more than just TCP as a data transport
mechanism, eg: "direct" as in a /dev/rmt* handle, "unixdomain" as in a UNIX
domain socket, etc.  Some or all of these would need to go into the NDMP
specification as registered "address types".

* An MMS Mover would also need to handle the case where there was no NDMP
server available, it must be able to use a local drive as well as NDMP
access to remote drives.

* One possible approach to the MMS using NDMP as a data transport mechanism
would be to define new cmds in MMP that would allow access to the data path,
define a new module in 1244.1 that interfaces to NDMP, and then define the
interface between the MM and the newly defined module.  The app would
request a mount operation using access mode tokens specifying the data
transport mechanism.  When the mount was complete, the MM would return an
access handle that could be used with the given transport mechanism.  For
example, the handle for a TCP/IP based transport would probably include a
host name/address and a port number, while a handle for a local transport
mechanism might be a simple pathname.  Data read/write commands as well as
tape motion commands would pass through MMP, giving the MMS a chance to skip
forward over any tape labels if the app did a rewind operation.

Next Meeting:
        November 14-16, 2000, at the SES's offices, Greenbelt, MD.

Future Meetings:
        January 16-18, 2001, somewhere in the Bay Area, hosting sought.

Active discussion continues on the above topics on the email reflector
"work@ssswg.org".  Please subscribe if you are interested in hearing more
by sending email to "majordomo@ssswg.org" with a body of "subscribe work".

SSSWG Home