INTERIM MEETING REPORT Minutes of the MessageWay Working Group (msgway) Reported by Danny Cohen, Myricom, Inc. Interim Meeting, October 1995 The MesageWay Working Group met on the afternoon of the last day of the October MPI meeting in Denver. The meeting started off with introductions. Several curious MPI people attended. Therefore, Craig described the Group's history and goals. Danny brought out his technical introduction slides. The router-to-router protocol (RRP) draft was introduced at this meeting. The gentleman from IBM described his security concerns with the L2 headers in the end-to-end protocol. The group understood his concern, but did not find them very relevant to MsgWay. Tony Skjellum put up a series of handwritten slides describing his thoughts on a MsgWay API that would work well under MPI. There was discussion over whether an API specification should be part of the standard. No decision was reached. Tony will prepare a presentation on MPI/MsgWay for the next meeting. The MessageWay Working Group will meet at the next IETF in Dallas. Representatives of the Working Group were invited to present MsgWay to the ANSIX3T11 group in order for them to consider implementation of MsgWay overHiPPI and Fibre Channel. This will take place in San Diego on Dec-7-95. CURRENT MEETING REPORT Second Meeting, December 1995 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 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, 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." This 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 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: 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. 2. Added Features These include more complex functions intended to make the system more reliable, e.g., barrier/multicast/gather. 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 attendee 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 o By December 15, 95 the present draft documents (plus minor modifications) will be submitted to the IETF as draft-standards. This includes: o Proposed Standard for the MessageWay Packets o Proposed Standard for the MessageWay Inter-SAN Routing o Proposed Standard for the Format of the MessageWay RRP Messages The members of the MessageWay Working Group are encouraged to submit comments regarding these three documents before January 15, 1996 (the sooner, the better). o On January 15, 1996, close the waiting-for-comments period from the members of the MessageWay Working Group regarding these documents, and start their final editing. o By February 7, 1995, circulate the "final" version of these documents to the members of the MessageWay Working Group for final comments (through February 12, 1996). o On February 14, 1996, submit the final version to the IETF for approval as draft-standard. o The next meeting of the MessageWay Working Group will be at the 35th IETF in Los Angeles.