RFC 37

RFC 37: Network Meeting Epilogue, etc. 🎀

Okay bestie, the header tea ☕: this is RFC 37, "Network Meeting Epilogue, etc.", from the Network Working Group 🦋. It's written by S. Crocker of UCLA and dated 20 March 1970 💖. The header doesn't list a category or status, and it doesn't say it obsoletes or updates anything 🤷.

The Meeting 🌸

Okay so on Tuesday, March 17, 1970, Crocker hosted a Network meeting at UCLA 💅. About 25 people showed up, including reps from MIT, LL, BBN, Harvard, SRI, Utah, UCSB, SDC, RAND and UCLA 🔥. He presented a modification of the protocol in NWG/RFC #33, and the modifications are sketchily documented in NWG/RFC #36. The main glow-up is the facility for dynamic reconnection ✨.

The protocol based on sockets and undistinguished simplex connections is very different from the older protocol documented in NWG/RFC #11 😭. The push for these changes came from the network meeting on December 8, 1969, at Utah, where people seriously challenged the limits of a log-in requirement and the inability to connect arbitrary processes 🙈. So the main reason for this recent meeting was to sample opinion on the new protocol 🧐.

Recollections may vary, but Crocker's opinion is that the protocol was widely accepted, and the criticism and discussion fell into two categories 💜:

1. Questioning the complexity and usefulness of the full protocol, especially the need for dynamic reconnection.
2. Other topics, particularly character set translation, higher level languages, incompatible equipment, etc.

What was notably missing? Any criticism of the basic concepts of sockets and connections 👑. (Some has since surfaced 👀.) These agreements were made:

1. By April 30, Crocker would be responsible for publishing an implementable specification along the lines presented.
2. Any interested party would communicate with him (at least) immediately if they wished to modify the protocol.
3. If major modifications came under consideration, interested parties would meet again. This would happen in two to three weeks.
4. Jim Forgie of Lincoln Labs tentatively agreed to host a meeting on higher level network languages, probably near Spring Joint time 🌈.

Mailing List Changes 💌

Paul Rovner of LL is getting replaced by James Forgie 🫶. Here's the new contact info, verbatim:

                   James Forgie
                   Mass. Institute of Technology
                   Lincoln Laboratory C158
                   P.O. Box 73
                   Lexington, Mass. 02173

                   telephone at (617) 862-5500 ext. 7173

And Professor George MEaly is being added to the list 🎓. Here's his info, typos and all:

                   George Mealy
                   Rm. 220
                   Aitken Computation Lab.
                   Harvard University
                   Cambridge, Massachusetts 02138

                   telephone at (617) 868-1020 ext. 4355

Process 🧚‍♀️

Okay the vocab moment: in all of their writing, the team uses process to mean a program that has an assigned location counter and an address space 💅. A program is just a pattern of bits stored in some file 📁. A new process is only created by an already existing process. The previous process has to run an atomic operation (forc, attach, etc.) to make that happen 💖. Processes can either cause their own demise, or get terminated by another (usually superior) process 💀.

This matches the definition Vyssotsky, et al gave on pp. 206, 207 of "Structure of the Multics Supervisor" in the FJCC proceedings, 1965 📚.

Here's the lowkey big deal: because a process can create another process, and because the two are usually indistinguishable from the outside, Crocker knows of no reasonable way for two processes to request a connection directly with each other 🙃. That's exactly why the function of sockets is to provide a standard interface between processes 🔌✨.

The Days After 🦋

In the time since the meeting, Crocker had conversations with Steve Wolfe (UCLA-CCN), Bill Crowther (BBN), and John Heafner and Erick Harslem (RAND) 🗣️. Wolf's comments will show up as NWG/RFC #38, and they fall into a class Crocker will comment on below 👀.

Crowther sent in the following, and it's giving clever 💡:

"A brief description of two ideas for simplifying the host protocol described at the March meeting. These ideas have not been carefully worked out. Idea 1. To Reconnect. -------------------- "A NCP wanting to Reconnect tells each of his neighbors "I want to reconnect". They wait until there are no messages in transit and respond "OK". He then says "Reconnect as follows" and they do it. In the Rare condition, the NCP gets back an "I want to reconnect instead of an "OK", then one must go and one must stop. So treat a "reconnect" from a higher Host user etc. as an ok and from a lower as a "No-wait until I reconnect you" and do the connection. Idea 2 ------ "Decouple connections and links. Still establish connections, but use any handy link for the messages. Don't send another message on a connection until a FRNM comes back. Include source and destination socket numbers in the packet. "To reconnect, say to each of neighbors "please reconnect me as follows...". Hold onto the connect for a short time (seconds) and send both packets and connection messages along toward their destinations. I haven't worked out how to keep the in-transit messages in order, but probably everything works if you don't send out a reconnect when RFNM's are pending."

Crocker's take on Bill's first idea: it doesn't seem decisively better, and after some thought it isn't very different either 🤔. He's considering it, and he has no strong feelings yet, but he's trying to develop some 💭.

Bill's second idea, though? It seems to go against Crocker's whole idea of what links are for 😤. One argument for decoupling connections and links is that the number of connections between two hosts might want to exceed 255. And even if it doesn't, isolating dependencies in design is just sounder practice 🧠. BUT, the newly provided Cease on Link facility* (page 22 of the soon-to-be-released BBN report #1822, revised Febuary 1970) becomes useless 💀. (Bill, who just put that feature in, doesn't care 🙄.) Another objection: it seems intuitively bad to waste the chance to use the link field to carry information. (Note the conflict of gut-level feelings 🫠.)

Then Crocker talks about RAND. In a conversation with John Haefner and Eric Harslem of RAND, they pointed out that the current protocol makes no provision for error detection and reporting, status testing and reporting, and expansion and experimentation 🚨. Error detection and status testing will need some extended discussion to see what's actually useful, and Crocker expects that discussion will happen while implementation moves along 🛠️. But leaving room for protocol expansion and experimentation? That's best done now 💅.

So he suggests reserving two areas for expansion 🎀:

• One is that only a fraction of the 256 links get used, say the first 32.
• The other is using command codes from 255 downward, with permanent codes assigned from the number of links in use up to 32. Crocker feels it's quite unlikely we'd need more than 32 for quite some time. Moreover, the network probably wouldn't handle the traffic implied by heavy link assignment. (These two things aren't necessarily strongly coupled: you can have many links assigned but only a few carrying traffic at any given time.)

Some of Heafner's and Harslen's other ideas may show up in NWG/RFC form 📨.

Immediate Interaction ⏰

For the next several days, Crocker is still interested in those editicisms of the current protocol that might lead to rejection or serious modification of it 🧐. After that, the focus shifts to refinement, implementation, extension, and utilization 🚀. He can be reached at UCLA through his secretary Mrs. Benita Kristel at (213) 825-2368 📞. Also, everyone is invited to contribuet to the NWG/RFC series 🌈. Unique numbers are assigned by Benita 🔢.

* The Cease on Link facility is a way a receiving host modifies RFNM's so as to carry a flow-quenching meaning. An alternative proceedure is to use a host-to-host control command 🚦.

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Ron Fitzherbert 1/97 ]