Summary

  • RFC 908 defined reliable message delivery without making in-order application delivery compulsory; the delivery mode was selected when the connection opened.
  • A cumulative ACK marked the unbroken receive edge, while EACK named later segments already received correctly, allowing the sender to retransmit the gap instead of the entire later run.
  • Neither an ACK, an EACK, an OPEN connection nor IANA protocol number 27 proved application completion, and RFC 908 deliberately left the final pre-close confirmation with the user.

A hole, then useful data

Imagine a loader sending blocks 100, 101, 102 and 103 into a remote machine. Block 101 disappears in transit. Blocks 102 and 103 reach the receiver with valid checksums. A transport that equates reliability with ordered delivery has only one public story: everything after the hole waits. The receiver may possess later bytes, but the application cannot act on them and the sender may learn little beyond the last continuous position.

RDP gave the receiver a second statement. Its normal ACK still identified the last segment received in sequence. Its extended acknowledgement, EACK, could additionally list 102 and 103 as correctly received out of sequence. The gap remained real. The later receipts also became real. When 101 was retransmitted, the sender did not need to resend evidence the receiver had already supplied.

That sounds familiar to readers accustomed to selective acknowledgements. The historically important point is narrower. RDP did not stop at selective wire evidence. It also asked, when the connection was opened, whether the application required sequenced delivery. If the answer was no, the receiver could copy 102 and 103 to user buffers before 101 arrived. If the answer was yes, it retained their receipt state but delayed their delivery. The same reliability machinery supported two application contracts.

Why a reliable transport declined to impose order

RFC 908 was written for packet-oriented work such as remote loading, memory dumping and debugging. A memory image could not tolerate a missing block. That made positive acknowledgement and retransmission non-negotiable. But a loader might know where each block belonged from information inside the message. For that program, arrival order was an avoidable delay. A debugger, by contrast, might need a breakpoint command to take effect before a command telling the target to continue. There, reordering could change the result.

The protocol therefore standardized less than a universal notion of correctness. It standardized what both applications shared: message identity within a connection, corruption checking, duplicate rejection, positive receipt evidence, retransmission of missing segments and a bounded flow-control window. It left the semantic dependency between messages to the application that understood it.

This is not vagueness. The wire rules were detailed. It is restraint about which rule belonged on the wire.

Two receive records, not one verdict

RDP maintained a cumulative boundary in RCV.CUR: the last segment received correctly and in sequence. A segment at the left edge of the acceptance window advanced that boundary and produced an ordinary cumulative ACK. A valid later segment inside the window was recorded separately and could produce EACK. The EACK variable area carried the sequence numbers of one or more out-of-sequence segments received with a correct checksum.

Those records answered different questions.

The cumulative ACK answered: how far does the receiver possess an unbroken sequence? EACK answered: which later islands are already present? Neither answered: did the application interpret the message, place it in durable storage or complete the requested operation?

The distinction also constrained the sender. Later EACKs did not move the left edge past the missing segment. The sender could continue only within the receiver's acceptance window. As later transmissions approached the fixed right edge, new sending stopped until the gap was acknowledged. Selective receipt avoided unnecessary retransmission; it did not grant unlimited flight around an unresolved loss.

Order belonged to the connection epoch

Sequenced delivery was not a switch that one endpoint could casually flip between adjacent messages. The application's Open request chose sequenced or non-sequenced delivery, and RFC 908 made that choice last for the connection's lifetime. The SYN carried the initial sequence number, maximum number of outstanding segments, maximum segment size and option flags, including the sequenced-delivery mode.

This made the connection an evidence epoch. A trace cannot interpret one EACK correctly without knowing which Open and SYN established the current state. The same out-of-order receipt has different application consequences under the two delivery modes. A packet capture that sees only data and acknowledgements but loses the establishment record can prove less than it appears to prove.

The buffer limits were similarly local but explicit. Each side stated what it could accept. The maximum outstanding count limited how many unacknowledged segments the peer could send, while the maximum segment size described the receiving buffer boundary. Those values were exchanged rather than ordained by a universal performance policy, and they remained fixed for that connection.

Acknowledgement was narrower than completion

RDP's simplicity becomes especially clear at close. A close request sent RST, entered CLOSE-WAIT and eventually discarded the connection record. The specification required the user to determine that all data had been reliably delivered before asking for close. The transport did not turn its reset-based shutdown into a final application receipt.

The boundary matters. An ACK showed that a segment was correctly received and accepted by the destination RDP. EACK showed the same for named segments outside the cumulative edge. Under non-sequenced mode, copying to a user buffer could follow. None of those events established that a loader committed a complete image, a debugger executed a command in the intended state, or a transaction became irreversible.

RDP also used a sequenced NUL segment to test a possibly half-open connection. An acknowledgement supported the claim that the remote RDP still recognized that transport state. It did not show that the remote application was healthy. A transport witness remained a transport witness.

Version 2: running experiments corrected the paper

Six years later, RFC 1151 recorded what experiments in 1986 and 1987 had found. The original 32-bit checksum behaved very differently across host data representations: optimized implementations on comparable hardware differed in cost by a factor of five. Version 2 replaced it with the 16-bit TCP checksum. It widened RDP ports from eight to sixteen bits and changed the version because those header changes were not a cosmetic restatement.

The update also repaired pseudocode. SND.UNA, defined as the oldest unacknowledged segment, had sometimes been assigned the acknowledged sequence itself; RFC 1151 corrected the next value to SEG.ACK + 1. The lesson is not that the newer paper made deployment universal. RFC 1151 explicitly described limited implementation demand and published focused corrections rather than a complete rewrite. The record shows implementation pressure changing a specification, while leaving adoption unproved.

The IANA Protocol Numbers registry still associates value 27 with RDP and RFC 908. That is a durable name-to-number record. It does not say a host implements version 1 or 2, that an EACK was honored, that any current path carries RDP, or that a named product ever conformed.

What the old split still teaches

“Reliable and ordered” is a useful bundle, but it is not a law of nature. RDP's design exposed the price of bundling: an application able to place independent messages may suffer delay and buffer pressure solely because a transport withholds later work behind an earlier gap. It also exposed the price of separating: an application with causal commands must not confuse early delivery with safe execution.

The responsible question is therefore not whether order is good. It is who knows whether order is required, where that choice is recorded and what evidence remains when packets are missing. RDP answered by putting a deterministic delivery-mode bit into the connection, keeping cumulative and selective receipt facts separate, and stopping its claim before application effect.

Sources