RFC 107
Output of the Host-Host Protocol Glitch Cleaning Committee
RFC 107 🎀 Output of the Host-Host Protocol Glitch Cleaning Committee
Okay bestie, let's start with the title block tea ☕💅:
- Network Working Group, NIC # 5806 🌸
- Authors: Robert Bressler, Steve Crocker, William Crowter, Gary Grossman, Ray Tomlinson, James Withe 👑
- Where and when: UCLA, 23 March 1971 🦋
- Category or status: the original doesn't list one 🤷
- Supersedes: RFC #102, entirely 💜
- Updates: Document #1, as an official modification 🧚
Introduction ✨
So the Host-Host Protocol Glitch Cleaning Committee had its second meeting at UCLA on 8, 9 March 1971 🌸, after asking the whole network community what they thought. [The results of the (slightly larger) committee's first meeting are documented in RFC #102.] The committee agreed on several modifications to the protocol in Document #1, and they're all listed below 💖.
At each meeting, the committee quickly handled all but one of the existing topics 🙈. At the first meeting, most of the time went to the interrupt mechanism, and that discussion is summarized in RFC #102. At the second meeting, the committee spent almost all of its time on the notion of bytes 🫠, and that discussion is summarized after the list of modifications.
This RFC entirely supersedes RFC #102 and is an official modification of Document #1. A revision of Document #1 will be written shortly to incorporate the changes listed here 🦋.
NCP implementers, listen up 📣: you need to incorporate these changes as soon as possible. You also need to estimate the date your NCPs will be ready and tell Steve Crocker or his secretary, Byrna Kristel 💌.
Modifications 🧚
I Bytes ✨
Heretofore, a connection was a bit stream. Henceforth, it is to be a byte stream 🌈, with the byte size, S, indicated in the STR command and in each message. The byte size meets the constraints: 1 <= S <= 255.
The choice of the byte size for a connection is a 3rd level protocol issue, but the size stays constant for the life of a connection 💅. Each message must contain an integral number of text bytes (see below).
II Message Format 💖
The message format is changed to the format shown in figure 1 🎀.
The fields S and C are the byte size and byte count. The S field is 8 bits wide and must match the byte size specified in the STR which created the connection. The C field is 16 bit long and specifies the number of bytes in the text portion of the message. A zero value in the C field serves no purpose, but it is explicitly permitted 🙃.
The M1 and M2 fields are each 8 bits long and must contain zero. The M3 field is zero or more bits long and must be all zero. The M3 may be used to fill out a message to a word boundary. It is followed by padding 🧸.
The text field consists of C bytes, where each byte is S bit long. The text field starts 72 bits after the start of the message 🦋.
Heads up, this part is important 🚩: the partition of a byte stream into messages is an artifact required by the subnet. No semantic content is attached to message boundaries. In particular:
32 bits
|<--------------------------------->|
+-----------------------------------+
| |
| leader |
| |
+--------+--------+-----------------+
| | | |
| M1 | S | C |
| | | |
+--------+--------+-----------------+
| | ^ |
| M2 | | |
| | | |
+--------+ | |
| | |
| | |
| |
| Text |
// //
| | |
| | |
| | |
| | |
| | +--------+
| | | |
| | | M3 |
| v | |
+-----------------+--------+--------+
| |
| 10 --------- 0 | <-- Padding
| |
+-----------------+
Typical Message
Figure 1- A message with a zero value for C has no meaning 🫠, although it is legal, and it does use up resource allocation. (See Flow Control below.)
- A receiver may not expect to see 3rd level control information synchronized with message boundaries. In particular, if the notion of record is defined for a connection, the receiver must expect multiple records and/or record fragments within one message. (However, control messages obey special rules. See below.)
III Message Data Types 🎀
No notion of data type is defined as part of the 2nd level protocol 🙅. 3rd level protocols may include the notion if they want. Either way, data types cannot be synchronized on message boundaries.
IV Reset and Reset Reply 🔄
A new pair of one bit control commands, RST (reset) and RRP (reset reply), are added ✨. The RST is interpreted as a signal to purge the NCP tables of all existing entries which arose from the Host which sent the RST. The Host receiving the RST acknowledges by returning an RRP. The Host sending the RST may proceed to request connection after receiving either a RST or RRP in return. An RST is returned if the second Host comes up after the first Host 🌸.
V Flow Control 🌸
The flow control techniques are changed in two ways. First, the Cease mechanism is discontinued 🛑. The 10HI and 11HI messages will no longer be recognized by the Imps, and the Imps will no longer generate the 10HI, 11HI or 12HI messages.
Second, the allocation mechanism now deals with two quantities: bits and messages 🍓. The receiver allocates each of these quantities separately. The sender and receiver each must maintain a 16 bit unsigned counter for messages and a 32 bit unsigned counter for bits. When sending a message, the sender subtracts one from the message counter, and the text length from the bit counter. The receiver decrements its counter similarly when receiving the message. The sender is prohibited from sending if either counter would be decremented below zero. Similarly, the receiver is prohibited from raising the current message allocation above 2**16 - 1, or the current bit allocation above 2**32 - 1.
The TEXT LENGTH of a message is the product of S, the byte size, and C, the number of bytes. These values always appear in the first part of the message, as described under Message Format 🧮.
The ALL, GVB, and RET commands are modified to treat two quantities. Their formats are given under Control Command, below. The GVB command is further modified to make it possible to ask for none of the allocation to be returned 🙈. The new GVB command has four eight bit fields. The first two fields are the op code and the link, as before. The next two fields contain numbers fM and fB, which control how much of message and a bit allocation are to be returned. Each of these numbers is interpreted as "the number of 128ths of the current allocation" to be returned if it is in the range of 0 to 128, and is to be interpreted as "all of the current allocation", if it is in the range 128 to 255 💜.
VI Control Message 🫶
The control link is changed to link 0, and link 1 is not to be used. The old and new protocols may therefore coexist 🤝.
Messages sent over the control link have the same format as other regular messages, as described above under Message Format. The byte size field must contain the value 8.
Control messages may not contain more than 120 bytes of text, so the value in the byte count field is thus limited to 120. This limitation is intended to help smaller hosts 🧚.
Control messages must contain an integral number of control commands. Control commands, therefore, may not be split across control messages 💅.
VII Link Assignment 🦋
The links are now assigned as follows:
0 control link
1 old protocol's control link - to be phased out
2 - 31 links for connections
32 - 190 reserved -- not for current use
191 to be used only for measurement work under direction
of the network measurement center (UCLA)
192 - 255 available for any private experimental use.VIII Fixed Length Control Commands 💅
The ECO, ERP and ERR commands are now fixed length. The ECO and ERP are now 16 bit long: 8 bits of op code and 8 bits of data. The ERR command is now 96 bits long: 8 bits of op code, 8 bits of error code, and 80 bits of text. 80 bits is long enough to hold the longest non-ERR control command 🔥.
IX Control Command Formats 🔥
As mentioned above, the formats of the STR, ALL, GVB, RET, ECO, ERP and ERR commands have changed, and the commands RST and RRP have been added. The formats of these commands are given here 👑.
| 8 | 32 | 32 | 8 |
+-----+-----------------------+-----------------------+-----+
| | | | |
1. | STR | send socket | receive socket | |
| | | | ^ |
+-----+-----------------------+-----------------------+--|--+
|
| 8 | 8 | 16 | 32 | +-- byte size
+-----+-----+-----------+-----------------------+
| | | | |
2. | ALL | link| msg space | bit space |
| | | | |
+-----+-----+-----------+-----------------------+
| 8 | 8 | 16 | 32 |
+-----+-----+-----------+-----------------------+
| | | | |
3. | RET | link| msg space | bit space |
| | | | |
+-----+-----+-----------+-----------------------+
| 8 | 8 | 8 | 8 |
+-----+-----+-----+-----+
| | | | |
4. | GVB | link| fM | fB |
| | | ^ | ^ |
+-----+-----+--|--+--|--+
| |
| +-- bit fraction
+-------- message fraction
| 8 | 8 |
+-----+-----+
| | |
5. | ECO |data |
| | |
+-----+-----+
| 8 | 8 |
+-----+-----+
| | |
6. | ERP |data |
| | |
+-----+-----+
| 8 | 8 | 80 |
+-----+-----+---------------------- // -----------------------+
| | | |
7. | ERR | | text |
| | ^ | |
+-----+--|--+---------------------- // -----------------------+
|
+-- error code
| 8 |
+-----+
| |
8. | RST |
| |
+-----+
| 8 |
+-----+
| |
9. | RRP |
| |
+-----+Okay so the op code values are right here, and these numbers are the whole point 🔢:
NOP = 0
RTS = 1
STR = 2
CLS = 3
ALL = 4
GVB = 5
RET = 6
INR = 7
INS = 8
ECO = 9
ERP = 10
ERR = 11
RST = 12
RRP = 13Discussion on Byte Streams ✨
So the earlier spec said connections would just be conduits of bit streams 🫧. That gave maximum generality but minimum efficiency 😭. Then everyone got obsessed with efficiency, the problem got examined, and it turned out bit streams caused two kinds of inefficiency 💀
- Receiving Hosts had to do expensive shifting just to glue together the text of successive messages. Sending Hosts often had to shift text fields as well, so they could line up on word boundaries 🥲.
- Sending NCP's were banned from hanging onto ANY text for an indefinite time if they could send even one bit 🚫. This rule existed to prevent possible deadlocks, and the example is pure drama 🎭. Processes A and B are chatting over a pair of connections, one in each direction, and each one produces exactly one bit of output for every bit of input. If A's NCP holds a waiting bit because it wants to pack it together with later output from A, then B can't output, and neither can A. Lowkey a total standoff 🙃. So unless there is some guarantee that the data in the sending NCP's buffers isn't crucially needed on the receive side, the sending NCP must assume otherwise and transmit any waiting data as soon as it's able ✨.
These considerations led to the idea of a "transmission unit" that the NCP's would know about. The big question became what the typical and/or possible transmission unit sizes were 🤔. For character-oriented interaction, 8-bit transmission units seemed reasonable 🌸. For line-oriented interaction, the transmission unit might best be the line itself, which means variable length, or it might be best to consider the transmission unit to be a character instead 📏. For file transfer, it might be desirable for the transmission unit to be a multiple of the word lengths of both machines, but the last part of the file may not form a whole transmission unit if the unit is too large 📁. The consensus became that the transmission unit should not be divisible under any circumstances, and should therefore be fairly small. The notion of transmission unit thus seems to be synonymous with byte, so the term "transmission unit" got dropped 👋.
Subsequent discussion of the deadlocks and wakeup aspect revealed that there may be two byte sizes associated with a single connection 🦋:
- Transmission from the sending process to the sending NCP is in bytes of size S. The sending NCP must send a message whenever the link is unblocked, the message counter is at least 1, the bit counter is at least S, and the least S bits of text are ready. The message must contain an integral number of bytes.
- At the receiving side, there may be a different byte size R for transmission from the receiving NCP to the receiving process. An example of where
R <> Sis suggested by UCSB, which is providing a file system for transparently storing binary files 💾. It's reasonable that a using HOST might send with 36-bit bytes, while the UCSB file system might want to receive 32-bit increments 🧮.
It is clear that from a network protocol point of view, only the byte S is relevant, and this is the quantity that gets communicated in the STR command in every message 📬. The choice of the byte size R is up to the receiving user, and its meaning is how often the receiving NCP should wake up the receiving process ⏰. It may also happen that a receiving process has an agreement with the receiving NCP that's more complex than "please wake me every R bits." For example, the NCP might scan for new-line characters before waking up the receiving process 📝.
In the new protocol, it's the receiver's option to refuse a request for connection on the basis of the proffered byte size 🙅♀️. Conceptually, we imagine that NCP's are capable of handling all byte sizes, and that such a choice would be up to the third level programs (user programs, loggers, telnets, etc.) 🧚. Some Hosts, small ones in particular, may know enough about their third level programs to restrict the variety of byte sizes which can be sent or received 🍓. While it is a matter of local policy, the committee strongly suggests that NCP's be capable of handling all byte sizes 🫶. One of our committee, moreover, feels strongly that NCP's should be written to be able to receive all byte sizes S and provide for different byte sizes R for transmission to the user process 👑.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Enrico Bertone 4/97 ]
📦 where this page comes from
- ietf: rfc107 1971-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms