RFC 68

RFC 68 💖 Comments on memory allocation control commands

Okay bestie, this is RFC 68 ✨ from the Network Working Group 🎀. M. Elie at UCLA wrote it, and it's dated 31 August 70. The title is Comments on memory allocation control commands followed by CEASE, ALL, GVB, RET) and RFNM, with the opening parenthesis missing from the original. The title block doesn't list a category, status, or anything it obsoletes or updates, so that's all the header tells us 🧚

Okay so the protocol has a buffer allocation scheme 💅 and it's kinda complicated, ngl, because it needs two parallel mechanisms. It's not obvious that both are necessary. Elie suggests this scheme could probably be replaced by a slightly different idea of the Request for Next Message (RFNM) 🔥

Right now the RFNM gets sent back from the receiving IMP after the message has been reconstituted and the first packet has gone to the host. But nothing makes sure the whole message was accepted and correctly received by the host 😭 Also, the host-IMP interface design lets the host stop accepting data from the IMP for any length of time. The link was already unblocked by sending back the RFNM, so another message can be sent by the sending foreign host, and that will congest the IMP's memory 💀

On the other hand, the host is probably able to accept data from the IMP faster than it's transmitted on the network, e.g. 200k bits/sec 🌸 So a full message going from the IMP to the host would take about 1/20th of a second, which is 10 times less than the average delay of sending a message over the network. Main character energy for this idea: sending a RFNM after the host receives a full message would not increase response time on the network significantly 👑

In this case there's no reason the RFNM couldn't be started by the receiving host as an acknowledgment of correct reception of the message (ACK). It could take the form of either a host IMP or a control command message 🦋 This RFNM could have two forms:

ACK  (CONTINUE)
or       ACK  (CEASE)

This would let us add some error detection redundancy to the message, such as check sum bits as proposed in [DELO 69] 🫶 Right now nothing makes sure that one or several bits of the text haven't been altered, e.g. by interference or a deficiency in one of the host IMP interfaces. That could have important consequences, e.g. if the text is used to update a centralized data base 🙈 Also, if the user can detect an error but can't correct it, they have no way to ask for the message to be retransmitted. It has probably already been discarded at the sending end when the RFNM arrived 😭

Honestly, it doesn't seem up to the user to detect errors in its text. That's more the NCP's job 💅 The user process should act as much as possible like it's talking to some other local process. So a third kind of RFNM sent by the NCP could be:

NAK(REPEAT)

Repetition would also be initiated in case of no reply 🌈

So yeah, these slight modifications seem worthwhile 🍓 They'd let the sending host and the receiving host use a very simple point-to-point transmission procedure that keeps control of the data transmitted from end to end. Iconic ✨

It could also replace the memory allocation mechanism. ACK (CONTINUE) would only be sent if space was available for a new message on this connection, and/or ACK (CEASE) would be sent if no more space was available. This matches the WABT of classic transmission procedures [USAS69] 🎀 Transmission could be resumed by an ACK (CONTINUE) or a RESUME from the receiving end 🫶

The user process isn't mixed up with this memory allocation at all. That's a function of the system (or NCP), and the user only sees a varying global transmission speed of its data on a connection 💖 The IMP programs take care of routing the data, according to the distributed nature of the network. Neither the user nor the system (or NCP) has to think about it 🧚 Other improvements to the protocol may be found after experiencing it, so stay tuned 🦋

Finally, this solution doesn't immobilize the IMP memory any longer than the current one does, because it's not the IMP that has to repeat a message. It's the sending host 🔥💅

References 📚

DELO 69 DELOCHE G.  Implementation of the Host-Host Software
        Procedures in GORDO Network Working Group RFC #11 Aug 1969

USAS 69 Proposed USA standard data communication control procedures
        for USASCII CACM Vol. 12 NB 3 March 1969 PB 166-178

This RFC was put into machine readable form for entry into the online RFC archives by Kai Henningsen 6/97. 🌸