Editor's note: These minutes have not been edited.
Subject: MsgWay-WG IETF34 Minutes
Date: Thu, 07 Dec 95 22:32:58 -0800
From: cohen@myri.com
------------------------------------------------------------------------------
Minutes of a meeting of the MsgWay-WG, IETF'34 (Dec-4-95)
(reported by Fred Shirley, Craig Lund, and Danny Cohen)
-------------------------------------------------------
Area: Network
Area Director: Frank Kastenholz
WG Chair: Danny Cohen
Attendees:
1 Danny Cohen <Cohen@myri.com>
2 Craig Lund <CLund@mc.com>
3 R. Kent Koenninger <KentK@cray.com>
4 Larry Samberg <lss@mass-usr.com>
5 Dan Schoo <dschoo@usr.com>
6 Phil Irey <pirey@relay.nswc.navy.mil>
7 Paul Mylotte <mylotteps@btlip11.bt.com>
8 Bob Fish <bfish@hprpcd.rose.hp.com>
9 Fred Shirley <FShirley@sanders.com>
10 Doug Leifer <Leifer@umich.edu>
11 Kim Morla <kmorla@pucp.edu.pe>
12 Ed Sullivan <Sullivan@iphase.com>
13 Roger Cheng <roger@paradise.ccl.itri.org.tn>
14 Mark Pullen <mpullen@gmu.edu>
15 Doug Sheppard <sheppard@pbi.net>
16 Frank Kastenholz <Kasten@ftp.com>
17 Tony Skjellum <Tony@cs.msstate.edu>
18 Stuart Venten <SVenten@adtran.com>
19 Jon Postel <Postel@isi.edu>
........................................................................
MINUTES
The MessageWay Working Group met on Monday afternoon, led by Danny Cohen
of Myricom.
Craig Lund (of Mercury) suggested that everyone introduce themselves.
During the introductions it became clear that many people in the room
were new to MessageWay. Therefore, Craig spent a few minutes introducing
MessageWay's goals (primarily low latency).
Danny Cohen (of Myricom) gave a quick summary/overview of the MessageWay-EEP
(End/End Protocol).
The EEP includes a new proposal for handling the "Endianess" issue.
The Endian proposal resulted in a long discussion. At the end, Tony
Skjellum (of Mississippi State University) moved that Danny "find an
additional bit somewhere" to expand to include 16 bits and 128 bits.
Craig seconded the motion. No vote was taken (we never vote).
Tony also moved that "8 bits be equivalent to heterogeneous, i.e., no
byte swapping needed" that idea will probably be in the next draft.
The MessageWay-RRP (Router/Router Protocol) was presented by Danny in more
detail, and a detailed example was presented.
Frank Kastenholz (of FTP.com) brought up the history of the priority
field in IP. Danny responded with more history. No changes to MessageWay
were suggested.
Craig brought up the Denver meeting's security discussion (hacking L2
routes). Nobody wanted to discuss it again.
One of the gentlemen from U. S. Robotics objected to Danny's
characterization of the Source Address field as "useful only for error
messages". The gentleman pointed out that network sniffers and masking
operations will use the Source Address field.
Craig asked, for the third meeting in a row, that Danny drop use of
the word "host" in the MessageWay document and use "Node" instead.
Danny agreed (again).
Tony gave a viewgraph presentation on a proposed three-level
definition of application program interfaces (APIs) for MessageWay.
Although these APIs may not be included in the MessageWay standard,
they are needed so that users can develop code (drivers) for MessageWay.
The three proposed API levels are:
Level 1: Basic Features -- These include low-level access to
MessageWay functions, such as packet transfer,
priority/preemption, primitive active packets (PAPs),
inquiry functions, and primitive collective operations.
Level 2: Added Features -- These include more complex functions intended
to make the system more reliable, e.g., barrier/multicast/gather.
Level 3: Security Features -- These include support for secure MPI
(and other higher-level protocols), such as security hooks
and encrypted headers.
Kent Koenninger (of Cray) praised our focus on MPI as a good start.
However, he said that we cannot ignore NFS, DFS, and FTP. Everyone
agreed, but nobody promised to look into these protocols. A short
discussion of the merits of running TCP and UDP on top of MessageWay
followed. No conclusion was reached.
Kent was a new attender at the meeting, having been encouraged by ARPA
to participate. At the request of the group, Kent gave an informal
overview of Cray's GigaRing (aka SCX) SAN and Cray's possible interest
in using MessageWay to interconnect GigaRing with other types of SANs
(e.g., competitors' SANs, which are "heterogeneous" to Cray). GigaRing
uses counter rotating SCI-like rings, with 13 address bits and 1.6
MBytes/second throughput per ring. Their regular packet type is 256
Bytes long, but they usually do DMA transfers using MPI gets and puts.
GigaRing is only going to be used for new computers (such as the T3E),
not legacy computers (such as the T3D). GigaRing has single-purpose
nodes for connecting to high-speed interconnects such as Fibre Channel.
It also has a multi purpose node with an SBus interface for
accommodating other interconnects, such as Myrinet. Cray has no current
plans to support PCI.
Kent also discussed ways to map MessageWay onto GigaRing. We also talked
about potential methods of including Cray in our heterogeneous testing.
........................................................................
NEXT STEPS
* By Dec-15-95 the present draft documents (plus minor modifications)
will be submitted to the IETF as draft-standards. This includes:
** Proposed Standard for the MessageWay Packets
** Proposed Standard for the MessageWay Inter-SAN Routing
** Proposed Standard for the Format of the MessageWay RRP Messages
The members of the MsgWay-WG are encouraged to submit
comments regarding these three documents before Jan-15-95
(the sooner, the better).
* On Jan-15-95 close the waiting-for-comments period from the members of
the MsgWay-WG regarding these documents, and start their final editing.
* By Feb-7-95 circulate the "final" version of these documents to the
members of the MsgWay-WG for final comments (through Feb-12).
* On Feb-14-95 submit the final version to the IETF for approval as
draft-standard.
* The next meeting of the MsgWay-WG will be at IETF'35, during the week
of Mar-4-96, in Los Angeles.
******************************************************************************