RFC-203
by Darius Kazemi, July 22 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.
Error-resistant communication
RFC-203 is titled “Achieving Reliable Communication”. It's authored by Richard B. Kalin of MIT Lincoln Lab and dated August 10, 1971.
The technical content
This RFC introduces an idea for a “non-standard protocol” that is specifically for error-resistant communication.
The paper defines two kinds of transmission errors: errors where you don't get a message you were sent, and errors where you get a message that wasn't intended for you. So detecting an error of this type requires you to be able to tell if a message has been lost, and also to be able to tell if a message was the one you were supposed to receive.
“Garbled” messages can be detected by standard methods like checksums. Detecting the order in which a sequences of messages needs to be reconstructed can be solved simply by numbering messages sequentially.
Determining that a message has been lost needs to be done indirectly by making inferences, which can lead to false positives, but you could assume that an expected message that hasn't arrived in a long time can be lost, or a missing message in a sequence is lost, and so on. Lost messages can simply be requested a second time, and again, until the expected message is received.
Kalin proposes some rules for recovering lost messages, including that all messages should be in a sequence of messages, and messages received out of sequence should be discarded. He also says that there should be acknowledgement of receipt of every message, and that the sending host should not send a new message until it hears from its receiving host that the host has gotten the message.
He also offers a modified version that essentially allows for N messages to be sent before the sender waits for receipts, so that there's a sort of buffer of unacknowledged messages that is acceptable.
There are also some weird problems of starting and stopping messages that he addresses.
Analysis
This is a pretty dry paper, and also I wish he'd cover the drawbacks of this kind of error-resistant communication in detail. He's not proposing a replacement, simply an extra channel for presumably emergency communications that must be statistically zero-error, but the tradeoffs here are presumably high (I'm just thinking about all the waiting around that the sender and receiver have to do!).
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 an independent technologist and artist. I do a lot of work on the decentralized web with ActivityPub, including a Node.js reference implementation, an RSS-to-ActivityPub converter, and a fork of Mastodon, called Hometown. You can support my work via my Patreon.