RFC 49

NWG/RFC 49 📚 Conversations with Steve Crocker (UCLA) 🎀

• Author: Edwin W. Meyer, Jr., MIT Project MAC 💖
• Date: April 25, 1970 🌸
• Series: NWG/RFC 49
• Category, status, obsoletes, updates: none are listed in the original 🫶

Okay bestie, this one is a gossip recap of phone calls Edwin and Tom Skinner had with Steve Crocker at UCLA about their RFC 46 proposal. Lots of drama, lots of "wait, what about this?" 💅

---

Quick disclaimer first: Edwin is sharing both his personal opinions and what he thinks is the consensus of the Network Working Group at Project MAC. He uses "I" for himself and "we" for the group. 🧚

On April 21 and 23, Edwin and Thomas P. Skinner had phone calls with Steve Crocker at UCLA about the network protocol, mainly the RFC 46 proposal. Here's the tea ☕ (Edwin, if Steve reads this and I got something a little off, I'm sorry in advance 🙈)

1) Dynamic reconnection 🔁

Steve thinks the network folks will eventually realize they need dynamic reconnection. But there's no agreement on it yet, so it won't be in the first implementation. Project MAC is on board with leaving it out at first 👍

2) The INT command ⚡

Steve backed the INT network command from RFC 46. It lets a process that agreed to accept interrupts on a socket connection get reliably interrupted by the process on the other end. The interrupt makes the process abey its current execution and run a procedure it specified as the INT handler. (The NCP doesn't define the INT handler. That's the job of higher-level protocols.) 🔥

INT is made for a third-level User Control and Communication (UCC) protocol to build a "quit" signal. In that setup, both sides agree that an INT tied to a specific socket connection, sent over the NCP control link to the created process, counts as the standard "quit" signal. The created process brings an INT handler that does the "quit" thing. (Other third-level protocols can still read INT differently, which is totally fine 💜)

Some systems, like CTSS and Multics, do "quit" as a control character in the Teletype input stream. Others do it as a 200 ms spacing on the line. Project MAC thinks the first way is a bad idea inside the network, and the second way just isn't possible. Edwin gave a few reasons, and he thinks Steve agreed:

• (a) The link the quit character travels on might get blocked. 🚧
• (b) INT works best inside the NCP, but the NCP shouldn't impose any particular structure on the data it carries. Scanning the stream for a control character would force that structure. (More on this below.)
• (c) Scanning the input stream hurts NCP efficiency in a subsystem where speed is critical.

Steve pointed out that treating INT as "quit" shouldn't stop a HOST from also letting a control character in the input stream act as a "quit." Compromise unlocked 🔓

3) The instance tag debate 🏷️

Steve opposes both putting the instance tag in the socket identifier and reserving a null field in the identifier for future use. His reasons:

• (a) Multiple processes of one user should look the same to a foreign process. (Edwin agrees in some cases, like when processes are coordinating a joint action. But what about two processes of the same user that each want to use the network independently?) 🤔
• (b) If you want to connect to one of a foreign user's processes, you don't know its instance tag, and you can't easily find out. 😩
• (c) If an instance tag turns out to be useful later, it could be added, but with some difficulty. (Edwin argues that something as fundamental as the socket identifier length will be super resistant to change.)

Tom suggested that maybe the low-order three bits of the user code could be reserved for later use as an instance tag. He doesn't think a separate field matters much.

Edwin says Steve's arguments have merit, and Tom's idea might be the way to go. He's still undecided, so this one's up in the air 🎈

4) No special structure for the data 🧱

Steve and MAC both seem to agree that at the NCP level, no special structure should be put on transmitted data. To the NCP, all data is just bit strings of arbitrary length. A nice perk is that the messy character set question doesn't have to be settled at this protocol level. Adding a character set spec at the NCP level would slow down protocol agreement and make that character set harder to change later. (If there's going to be a standard character set, MAC prefers ASCII, because it's the preferred standard of their sponsoring organization 💅)

They also agree with Steve that there should be no optional echoing of messages at the NCP protocol level. (The SDC people in RFC 44 agree too 🫶)

5) No double padding 🙅‍♀️

Shoshani, Long, and Landsberg say in RFC 33 that they'd rather end messages on a word boundary than double pad. Steve agrees with MAC that double padding is not it 🙄

6) Queueing RFCs 📬

In RFC 46, MAC suggests queueing RFCs only for open sockets, and automatically rejecting RFCs to inactive or connected sockets through the CLS command. Steve wants RFCs to those sockets to be briefly queued instead. If the socket is still in an unacceptable state after a set interval from when the RFC arrived, then it gets rejected. This lets certain network command interactions with critical races actually be implemented. Edwin thinks limited queueing sounds reasonable 🌈

7) The UCC strategy showdown ⚔️

Steve, Tom, and Edwin talked about strategies for a User Control and Communication (UCC) protocol. Steve doesn't like MAC's UCC strategy from RFC 46 because it means keeping two full-duplex connections to the requestor process and switching between them.

Steve came up with a different plan. A process that wants to create a user process at a foreign HOST sends RFCs to sockets 0 and 1 belonging to the user whose process it wants to create. If those sockets are inactive, the NCP automatically sends the requests to the foreign HOST's logger process. The logger accepts the connection and does the login ritual. If it works, the logger creates a user process and releases the taken sockets so the created process can use them to talk to the requestor. (Edwin notes that this doesn't use reconnection at the network level, since the logger uses sockets belonging to the ultimate user. It does involve internal reconnection, though 🤓)

Tom and Edwin objected, because this pulls UCC protocol down into the NCP level. (The NCP would have to send all RFCs to inactive sockets 0 and 1 to a logger process.) Edwin then suggested combining the two ideas: the requestor sends a "signalling" RFC to a "signal" socket of the UCC process. The UCC rejects the RFC but remembers who called. Then it tries to connect two of the new process's sockets to the requestor's sockets and runs the login ritual through those. Steve liked this and asked Edwin to write it up ✍️

After the call, Edwin thought of some problems with this UCC strategy:

• (a) If the control sockets at a created process are limited to 0 and 1, a rightful user might not be able to reach a foreign UCC, because it's already talking to an imposter on those sockets. The logger will catch this and shut the imposter down, but it's still an annoying security breach. A malicious process could send multiple simultaneous requests to tie up the sockets and lock out a rightful user. A better fix is to let any socket pair of the potential user process act as the control path. That lets the UCC run simultaneous checks on competing requestors. 😤
• (b) Both Crocker's approach and the combined UCC identify the user to log in by giving a socket that belongs to a particular user. The logger now has to add an extra check that the user it's logging in actually owns the socket pair it's talking over. Edwin says that's backwards from the preferred approach: identify the user first, then work out the user code for their socket identifiers. 🙃
• (c) The requestor might not know the socket user code of the user it wants to log in as at the foreign HOST. (There's no basic reason the requestor and created processes need the same user code, as long as the requestor satisfies the foreign logger.)
• (d) In the combined strategy, the requestor has no way to say which socket user code it wants. The UCC can only assume the requestor wants to log in a process with the same socket user code as itself. (Edwin admits this might not sound like a big deal, but he imagines a scheme where a local process lets consoles attached to the local HOST log in at a foreign HOST without being logged in locally. 💻)
• (e) Letting a process pretend to be another process inside the network by using its socket user code is a potentially dangerous security breach, even with good intentions. Edwin thinks it should be a basic protocol law that NO PROCESS WHATSOEVER may request or accept connections, or send or receive data, over a socket with a user code that isn't its own. This doesn't apply to an NCP process that's responsible for that transmission. It also doesn't stop a privileged process from closing or rejecting connections between a foreign process and another local process. 🚨

Edwin still thinks the UCC proposal from RFC 46 is a good, workable scheme. It doesn't need socket reconnection, either explicitly across the network or implicitly inside an NCP, and none of the objections above apply to it. The only real downside he sees is that the requestor has to maintain and switch between two full-duplex connections. He doesn't think that's a serious hindrance, and he especially wants the network participants' comments on this point 💭

Good news: the UCC is a third-level protocol. The second-level NCP can be specified before the group finishes agreeing on a UCC, as long as the NCP lets a workable UCC be implemented. 🎉

Steve suggested there doesn't need to be one initial standard UCC, and that there could be several. MAC disagrees. If everyone is going to talk to each other, and not just within limited subsets of HOSTs in the network, there has to be an initial standard UCC that EVERYBODY implements. (Steve is right that other experimental UCCs can also be implemented. 🧪)

Edwin admits it's theoretically possible for each HOST to ship multiple software sets so a requestor can talk to loggers at HOSTs running different UCCs. But he doesn't think that'll happen in practice. Each HOST will implement whichever UCC protocol it likes best and provide just one software set, so requestors can only talk to HOSTs running similar UCCs. 🙃

Project MAC isn't excited about implementing a non-standard UCC just so they can talk to themselves. They want one UCC that's supported at every installation, so they can log in to all HOSTs with this protocol, and so users at every foreign HOST can log in to them. That's the whole vibe 👑🫶

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Altair Petrofsky 7/97 ]