RFC-176
by Darius Kazemi, June 25 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.
The correct view
RFC-176 is titled “Comments on Byte Size for Connections”. It's authored by Bhushan, Kanodia, and Metcalfe of MIT, as well as Jon Postel of UCLA. It's dated June 14th, 1971.
The technical content
This RFC addresses a longstanding issue of byte size on the network.
Essentially, “byte size” is a way of regularly parceling up a group of ones and zeroes. While today we often of think of a byte as eight bits, the definition has always been up to interpretation and context. Depending on who you ask, a 16-bit computer either deals in “bytes” that are 16 bits in length, or it deals in “words” that are two 8-bit bytes in length (since 8*2 = 16). This is further complicated by serial versus parallel transmission of bits. I include this aside not to say that one way is right or wrong, but rather that “what is a byte” is a more complicated and contentious question than it first looks.
This RFC begins with a brief outline and history of different views on byte sizes on ARPANET.
The original ARPANET design was for a bit stream, which is essentially a system of “1-bit bytes” with no special or implied demarcations or groupings of bytes. This was scrapped in RFC-107 three months prior to the publication of this RFC. In RFC-151, Shoshani says that byte size should be completely irrelevant to 3rd-level (user-level) processes. (You can read my post on RFC-151 for why I think that's really wrong.)
The current authors argue that 3rd level processes should set the byte size for a given connection.
The next portion of the RFC concerns this question: if I am a service running on the network, and a user connects to me, should I be allowed to say “you may only speak to me using this specific byte size”?
The authors state:
For TELNET and ICP, the byte size choice is straight forward as data is naturally in 8-bit multiples (8-bit ASCII characters in TELNET, and 32-bit socket numbers in ICP). But for data transfer protocols, the byte size choice is more complex, as data may be structured in a variety of byte sizes. Specifying a byte size for a data transfer connection reduces efficiency in instances where connection byte size does not correspond to data byte size. Further, filler fields will be required for data blocks which are not a multiple of the fixed byte size. This imposes an additional overhead.
In general the authors argue that a 3rd level protocol will be more efficient, at least in terms of program size, if a byte size is specified ahead of time. They do admit that the move to byte streams in RFC-107 is kind of saying that the efficiency of the Network Control Program is more important than the efficiency of user processes. But they maintain that the most important efficiency is the combined efficiency of both the NCP and the user process, and that allowing user processes to specify byte size will, on the balance, increase combined efficiency.
They conclude by saying, essentially, “Now can we please stop arguing about this until the next major revision of the Host-Host protocol?”
Analysis
The authors bravely label their conclusion about byte size being a 3rd-level concern as being The Correct View.
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.