by Darius Kazemi, March 9 2019

In 2019 I'm reading one RFC a day in chronological order starting from the very first one. More on this project here. There is a table of contents for all my RFC posts.

Acknowledging ACK

RFC-68 is titled “Comments on memory allocation control commands: CEASE, ALL, GVB, RET, and RFNM”. It's dated August 31st 1970 and authored by Michel Elie of UCLA.

The technical content

Elie proposes a modification to the Request For Next Message signal: that the receiving Host not simply say “I am ready for another message” but actually acknowledge that it's received the message. It might even send back a checksum so the sending Host can make sure it was correctly received and not modified in transit.

Aside: what's a checksum? Well, let's say I send you the message “hello” and you want to prove to me that you received “hello”. One thing you could do is echo the message back to me and say “hello” but in a system like a computer network, this could start clogging things up pretty bad and would essentially double the traffic. So you could instead send back “5”, which I understand to mean you got a 5 letter word from me. That is somewhat helpful, but it's still possible you received “boing” and not “hello”. So we could do something where we assign numbers to each letter, a = 1, b = 2, ..., z = 26. And we add up the sum of our letters. So I send you “hello”, you respond “52”, which is the sum of the letters in “hello”. If you had gotten “boing” you would have sent “47” and I'd know there was something wrong with the message you received. While there are many words that sum up to “52”, most of them are words like “gfllo” that are obviously incorrect to the receiver, so this works as a really easy but not foolproof way to confirm a message without wasting space. Of course, checksums in computers work a little differently than this, but that's the principle.

The signal for acknowledgement is abbreviated “ACK”, and non-acknowledgment is “NACK”. A “NACK” signal would be an implied request to the sending Host to repeat its message so they can try again.

There is also mention of using two different ACK messages to signal memory allocation status. An “ACK (Continue)” message would say “I got your message and I have room for more messages”, and an “ACK (Cease)” would say “I got your message and I'm out of memory right now so don't send me anything else.”


I believe this is the earliest appearance of “ACK” in the RFC series. I'm unsure as to whether it was immediately implemented (I haven't read very far ahead) but ACK is used, more or less in the same way proposed here, in TCP, a protocol that powers much of the internet today. When I first saw the “RFNM” signal in early RFCs I thought, “huh that is like a simple proto-ACK”, and now I see this document suggesting the transformation.

This is just one of those moments where the hairs raise on the back of my neck! This ~600 word long note contains such an important suggestion that would in one way or another shape the future of the internet.

Further reading

TCP is first fully defined in RFC-675 in December 1974. You can see the mention of ACK signals clearly in the document.

How to follow this blog

You can subscribe to this blog's RSS feed or if you're on a federated ActivityPub social network like Mastodon or Pleroma you can search for the user “@365-rfcs@write.as” and follow it there.

About me

I'm Darius Kazemi. I'm a Mozilla Fellow and I do a lot of work on the decentralized web with both ActivityPub and the Dat Project.