Summary

  • RFC 916's SO flag made a one-octet payload occupy the header's LENGTH position, so the separate data part disappeared and the header checksum protected the character.
  • The same physical octet meant the receiver's Maximum Data Length during connection opening, an ordinary byte count on normal packets, or the data itself on an SO packet. Flags and accepted state—not the octet alone—authorized the interpretation.
  • One-bit sequence and acknowledgment fields were sufficient only because each direction allowed at most one response-requiring packet in flight; the economy and the limit were the same design decision.

Published in October 1984, RFC 916 proposed the Reliable Asynchronous Transfer Protocol, or RATP. Its expected environment was a full-duplex point-to-point link, usually an asynchronous RS-232 circuit connecting small computers, modems or devices that accepted commands. The RFC Editor record now classifies the document as Historic. That label describes its present archival status. It does not make the mechanism less exact.

The specification stated its order of priorities plainly: reliability first, then simple implementation. Dynamic window management and several outstanding packets were left out. Data still queued when the remote end closed was discarded, a choice the document said removed two states. This was not a miniature TCP pretending to have all of TCP's powers. It was a narrower connection whose limits bought a smaller state machine.

The data byte displaced its own length

A normal RATP header occupied four octets: a hexadecimal 01 synchronization leader, a control octet, an octet labelled data length and a header checksum. Ordinary data followed the header and ended with a separate 16-bit data checksum.

Interactive use created an awkward ratio. If a person typed one character and latency mattered, waiting to aggregate more characters would change the experience. Sending it immediately in the ordinary form required the four-octet header, the one data octet and two data-checksum octets: seven in all.

RATP supplied the SO, or Single Octet, control flag. When SO was set and SYN, RST and FIN were clear, the receiver already knew that the payload length was exactly one. A field saying “one” would repeat information carried by the flag. RFC 916 therefore put the character itself in the LENGTH position, omitted the data portion and let the header checksum cover the embedded character. The document described the reduction from seven octets to four as a 40 percent improvement in transmission efficiency.

Nothing was squeezed mathematically. Three octets disappeared because the protocol state made their work redundant: the flag supplied the length, the header slot supplied the data, and the header checksum supplied corruption detection for that data. SO did not compress a two-character string, remove acknowledgments or make every short packet four octets. It described one exact case.

One position carried three different contracts

The third header octet could not be interpreted from its location alone. In a packet bearing SYN, it was the Maximum Data Length, or MDL. The sender of that SYN was telling its peer the largest data portion it was prepared to receive in one packet. During the three-way opening exchange, each side declared its own limit.

On an established packet without SYN, RST or FIN, the same position was called LENGTH. If SO was clear, its value counted the data octets that followed, from zero through the peer's MDL. If SO was set, its value was not a count at all. It was the one data octet.

This was not permission for a decoder to guess among three plausible meanings. The control bits had to pass the header checksum, and the packet had to make sense in the receiver's connection state. Only then could the octet become capacity, count or content. A trace that preserved the byte but lost the flag or the connection epoch had preserved an inscription without its grammar.

The distinction also bounded error handling. If a header passed its checksum but declared an ordinary length larger than the receiving side's MDL, RFC 916 treated the event as a protocol violation or an unlikely undetected length error. The receiver reset the connection. MDL was not a friendly hint about buffer preference. It was a locally declared admission limit with a protocol consequence.

An endpoint could advertise MDL zero if it did not wish to receive data, permitting one-way use, although both sides could not choose zero if data was to move. The common protocol defined how the limit travelled and how violation was handled. The device owner retained the decision about its own capacity.

One bit was enough because the queue was one packet deep

RATP's sequence number (SN) and acknowledgment number (AN) were each one bit. A two-value sequence space sounds recklessly small until its invariant is included: in a particular direction, at most one packet was being sent or acknowledged at a time.

The receiver used the expected modulo-two value to distinguish the next packet from a duplicate of the one it had already acknowledged. The sender used the returned AN to retire its last response-requiring packet from the retransmission queue, then toggled its sequence bit. With no second unacknowledged packet to confuse with the first, one bit could do the required work.

The two directions were still independent. Once side A's last relevant packet had been acknowledged, A could send without waiting for B to have data of its own. An acknowledgment could be combined with outbound data when convenient. A pure acknowledgment did not itself demand another acknowledgment, avoiding an infinite exchange of receipts.

This is where the cost appears. The one-bit field was not an isolated cleverness; it encoded the absence of a window. On a link with a large bandwidth-delay product, waiting after every response-requiring packet would constrain throughput. On a slow interactive link and a small machine, the same restriction could make implementation, allocation and duplicate reasoning much easier. The right evaluation depends on the environment the protocol was designed to serve.

The receiver advertised the packet it could afford

RATP capped MDL at 255, so the largest ordinary packet was 261 octets: synchronization, the remaining header, a two-octet data checksum and 255 data octets. The specification drew an implementation consequence from that number: a receiver never needed to reserve more space for one incoming packet.

The cap alone did not decide the usable value. Each side put its own MDL into a SYN. A constrained endpoint could announce less. RFC 916 also connected the choice to external flow control: if long bursts tended to provoke inserted control characters at a particular baud rate, an implementation should choose a smaller maximum so some packets could pass without encountering that behavior.

The capacity contract therefore crossed layers without collapsing them. The protocol supplied one deterministic field and an enforcement rule. The operating system, device driver, modem path and available memory shaped the local number. The peer could either honor the advertised bound or lose the connection. No registry or continuing authority selected the value.

A packet boundary was not always a record boundary

The checked header determined how many more octets belonged to the packet. RATP used a starting synchronization pattern but no matching end delimiter; arbitrary patterns could occur in data. Once the header was trusted, its interpreted length made the packet end calculable.

Higher-level material could be larger than the MDL and require fragmentation. The EOR flag reported that a higher-level record ended in this RATP packet. The upper layer was responsible for setting and clearing it. A packet could therefore be complete as a link transfer while still being only one fragment of the object above it.

That separation matters to evidence. A valid header proves that a candidate header satisfied its checksum. An acknowledgment proves that the peer's RATP state accepted a packet in the sense defined by the protocol. EOR helps show a record boundary. None of them proves that an application interpreted the record, that a command was authorized or that its requested effect occurred.

Recovery had its own mechanism

RS-232 framed individual octets, not complete RATP packets. Noise could insert bytes or produce a false 01. The receiver scanned for that synchronization leader and then checked the three octets following it. If the header checksum failed, those three octets were treated as fresh input while synchronization search resumed. A false start therefore did not license the parser to skip an unknowable amount.

This recovery mechanism is context, not the article's main claim. RFC 1055 later documented SLIP's different bargain: delimiter and escape characters around IP datagrams, but no type field, no base-standard maximum and no serial-link error correction. The comparison shows that “serial protocol” did not imply one inevitable allocation of framing, reliability and negotiation.

RFC 1661 and RFC 1662 later specified PPP's protocol multiplexing, Link Control Protocol, negotiable link properties, flag framing, transparency and frame check sequence. Those documents are not proof that PPP descended from RATP. They make the older choice easier to see: RATP integrated reliable connection behavior, packet framing, capacity exchange and a special interactive optimization in one small point-to-point protocol.

RFC 793 supplied the contemporaneous TCP comparison RFC 916 itself invoked when declining dynamic window management. TCP served interconnected hosts with a much broader stream and sequencing contract. RATP combined datagram and reliable-connection functions on one point-to-point link and contemplated carrying fragments of higher-layer packets. Similar vocabulary did not make their operating surfaces interchangeable.

Sources and limits

This account uses RFCs 793, 916, 1055, 1661 and 1662 plus the RFC Editor's current record for RFC 916. They establish protocol definitions and bounded comparisons. They do not establish RATP's deployment prevalence, a direct lineage among the protocols, present product behavior or a modern incident.

A checksum is not a signature. A correct SO packet does not identify the human who typed the byte, authorize the receiving program to obey it, encrypt it or prove application completion. The durable historical point is smaller: four wire octets were enough only because both endpoints shared strict rules about state, capacity and what could still be outstanding.