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 2 Craig Lund 3 R. Kent Koenninger 4 Larry Samberg 5 Dan Schoo 6 Phil Irey 7 Paul Mylotte 8 Bob Fish 9 Fred Shirley 10 Doug Leifer 11 Kim Morla 12 Ed Sullivan 13 Roger Cheng 14 Mark Pullen 15 Doug Sheppard 16 Frank Kastenholz 17 Tony Skjellum 18 Stuart Venten 19 Jon Postel ........................................................................ 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. ******************************************************************************