RFC-151

by Darius Kazemi, May 31 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.

Conflicts between levels

RFC-151 is titled “Comments on a Proferred Official ICP”. It's by Arie Shoshani of System Development Corporation, and dated May 10th, 1971.

The technical content

Shoshani begins by pointing out a race condition that is possible in the Initial Connection Protocol as specified in RFC-123. He suggests that the eventual ICP spec should explicitly contain the fix for the race condition.

He then provides some general commentary on the ICP.

  1. Related to Bhushan's complaint in RFC-148, since the Host-Host protocol says that NCPs should be prepared to accept byte sizes between 1 and 255 bits, the fact that the ICP limits the first few messages to 32 bit bytes conflicts with the Host-Host protocol.
  2. The ICP is missing an ALL (“allocate”) command that is present in the Host-Host protocol. This is another conflict.
  3. He disagrees with RFC-127 where it states that the initial connection must be a single message containing 32 bits of data since it conflicts with the Host-Host protocol.

Analysis

His point about the 32-bit byte size restriction being unnecessary seems flat-out wrong to me. He says that “it is up to the sending process to chose the byte size”. The thing is, the fixed byte size on those first messages seems to be there in order to reduce the amount of time the well-known ICP socket needs to be open. Remember that there is a socket that is always open and listening for new connections, whose only job it is to shunt a new connection to a different socket and then listen for the next request for a new connection. If the data size is not agreed upon in advance then there is more processing needed, which means that ICP listener socket will be locked more often, slowing down the network in general.

His point about the missing allocation command also seems wrong, as I see an allocation command right there in RFC-127. If he's referring to that initial 32 byte connection and thinks it shouldn't be a special case, well then yes, I guess that is concerning. But I think it's clear that this special case should exist (since the ICP listening socket needs to be open as much as possible).

I don't know, I just fully disagree with Shoshani here but also, I've had trouble with his past RFCs! I found his RFC-144 to be counterproductive as it never defined the thing it was discussing (data sharing).

Shoshani really doesn't like conflicts between second-level and third-level protocols. And yes that conflict shouldn't be there but I think it could be resolved with a change to the Host-Host protocol providing room for the exception in the ICP case.

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.