RFC 176

Comments on Byte Size for Connections ✨

okay bestie, this is RFC 176 🦋 It's a Request for Comments (#176, NIC #7100) from the Network Working Group, written by A. Bhushan (MIT), R. Kanodia (MIT), R. Metcalfe (MIT), and J. Postel (UCLA). It's dated 14 June 1971 and it's in Categories: C and D. It doesn't list anything it obsoletes or updates. 💖

The Three Views 🌈

so there are at least three views on byte size for network connections* 👀

1. Byte size should not be used at all.
2. Byte size is solely for the convenience of NCP's.
3. Byte size choice is a user-level prerogative.

view #1 is that network connections are bit streams 🌊 and messages should carry bit counts (i.e., a byte size of 1). this was around before the "Glitch Cleaning" of RFC 107, but it got tossed for byte streams because of stated efficiency reasons in storage management and message concatenation. it's giving "we already moved on" 💅

view #2 is basically a special reading of RFC 107. in this one, byte size is entirely a 2nd level (i.e., NCP) issue, and there's no requirement that 3rd level user processes be able to specify byte size. this view shows up in RFC 151 by Shoshani 🙈

* Byte size for connection is the byte size selected by sending NCP, as explained in RFC 107 (Output of Host-Host Protocol Glitch Cleaning Committee). 📚

view #3 says user processes are always allowed to choose byte size for a connection, either explicitly (by specifying a byte size parameter) or implicitly (the byte size depends on I/O mode). an NCP is allowed to use a default byte size if the user doesn't specify one. 🎀

The Correct View 👑

the third view is the correct interpretation of RFC 107, and I'm not even being dramatic about it. RFC 107 says on page 2, "the choice of the byte size for a connection is a 3rd level protocol issue." 😭 to stay consistent with TELNET, ICP, and other 3rd level protocols that need a specific byte size for a connection, it's imperative that the matching 3rd level processes can specify (and_impose) a particular byte size to the NCP. NCP implementors, take note 📝

On Specifying Fixed Byte Sizes in 3rd Level Protocols 🧚

okay so if we think byte size is a 3rd level issue, we still have two questions to answer. first, should 3rd level protocols lock in one specific byte size for every connection that uses them? second, if yes, what should that size be? 🤔

there are two arguments for fixed byte sizes in 3rd level protocols. the first is a potential mismatch problem: RFC 107 doesn't require NCPs to handle all byte sizes 1 through 255. using a fixed byte size of 8-bits or 8-bit multiples fixes this because it's acceptable to all hosts (including terminal IMPs) ✨

the second argument is about efficiency. if everyone agrees beforehand that only one specific byte size gets used, programs can be more efficient (less program space, and maybe less run time) 🏃‍♀️ this assumes the byte size for a connection matches the natural byte structure of the data moving over it.

for TELNET and ICP, the choice is straightforward because the data is already in 8-bit multiples (8-bit ASCII characters in TELNET, and 32-bit socket numbers in ICP) 💜 data transfer protocols are messier, though, because their data can be structured in all kinds of byte sizes. fixing the byte size for a data transfer connection hurts efficiency whenever the connection byte size doesn't match the data byte size. filler fields are also needed for data blocks that aren't a multiple of the fixed byte size, and that's extra overhead 😩

even if every host accepted arbitrary byte sizes, and the 3rd level protocol didn't fix one, the inefficiency wouldn't go away completely. under current specifications "the byte size is fixed for the life of a connection".* so byte size can't change mid-connection, even when the structure of the data changes. the inefficiency is only solved for data with a constant byte structure. it's giving "only some of the time" 🙃

so given where the network is right now, fixing byte size in 3rd level protocols looks like a good idea. it gets rid of the potential mismatch problem and improves efficiency at least for TELNET and ICP. for data transfer the efficiency story is more complicated, as we covered above, but it isn't clear that overall efficiency would get worse if a fixed byte size were required 🌸

On Reopening the Byte Size Issue 🔥

all of that exposes some weak spots in the efficiency arguments for byte streams on network connections. moving from bit stream to byte stream may have cost us some generality, and it's not clear how much overall efficiency we actually gained. sometimes the gain in NCP efficiency comes straight out of user process efficiency 💀

* RFC 107, page 2

and honestly, for the efficiency arguments to hold, byte size shouldn't be an NCP prerogative. what matters is the combined efficiency, not just NCP efficiency. limiting byte size choice to NCPs also creates a mismatch risk not only between communicating NPCs but also at the user-NCP interface. so letting a user process specify byte size is a step in the right direction, given that we've adopted byte streams 🦋

our take is to set aside the bit stream vs. byte stream question until there's serious consideration of a major Host-Host Protocol overhaul. later on we'll have a better sense of the relative efficiency merits 🍓

[ This RFC was put into machine readable form for entry into the online RFC archives by BBN Corp. under the direction of Alex McKenzie. 12/96 ] 🫶