Summary
- RFC 1693, an Experimental memo from November 1994, explored partial-order and partial-reliability service as a proposed TCP extension. Its four-record database example allowed one, two, four or 24 output orders depending on the query.
- The RFC opened with an IESG note declining to recommend implementation of the TCP changes and valuing the analysis of misordered and incomplete data outside TCP. The proposal's durable question was how much ordering an application actually needs.
A very punctual clerk blocks the useful result
Suppose a server sends four database records. The first stalls in transit, while the second reaches the receiver. A fully ordered byte stream waits for the first before presenting the second. That is the bargain TCP ordinarily offers: reliable, ordered delivery. The 1981 TCP specification, RFC 793, built a dependable sequence for applications. Yet a database query may accept the second record immediately. Holding it behind a missing predecessor can make the transport a clerk who refuses to hand over a perfectly valid form because the previous envelope has not arrived.
T. Connolly, P. Amer and P. Conrad turned that annoyance into the four-record thought experiment in RFC 1693. Order the records by four distinct salesperson names and there is one acceptable sequence. Order them by location, with two records from the same city, and there are two acceptable sequences. Order by a description shared in two pairs and there are four. Omit ORDER BY and all 4!, or 24, permutations satisfy the query. The arithmetic describes an invented example, but the dependency it exposes is real: some results must precede others, while some may trade places.
The authors called that middle ground partial order. A receiver would deliver an object when all predecessors required by the application's declared order had arrived. Independent objects could move past one another. The proposal required a way to communicate or negotiate the valid order and an algorithm at the receiver to decide when an arriving object was ready. This was stricter than simply throwing records into the room and looser than making all four march in one file.
They also separated order from reliability. A database result may need every record eventually but tolerate several permutations. A multimedia stream may have components that require order within a channel while allowing some obsolete frames to be lost. RFC 1693 discussed both dials. It considered video, two audio channels, text and sign-language imagery as streams with different rates and dependencies, and it looked at window refresh as another example. The useful contract depends on which objects matter to which later objects, and which losses the application can absorb.
The authors proposed a partial-order connection inside a modified TCP framework, including a connection setup that could recognize an ordinary peer. They explored potential savings from releasing eligible data instead of buffering it for a completely ordered delivery. Those savings were an analytical possibility, with examples and early implementation work behind the paper. No measured network-wide performance figure emerges from its four-record table.
Most strikingly, the editorial decision was printed at the front. The IESG note said the Transport Area Director and Transport Directorate did not recommend implementing the TCP modifications. It also called the treatment of misordered and incomplete data useful outside TCP. The idea and the proposed location for the idea received different judgments. The memo still earned an Experimental RFC, so the argument and its limits entered the record together.
That makes the four little database cards more interesting than a tale of a feature the Internet supposedly gained. They ask a precise question of any transport service: how much of its ordering work protects an actual application dependency, and how much keeps an over-punctual queue intact? RFC 1693 did not need to rewrite deployed TCP to make that question visible. The second record could have been useful while the first was still on the road.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





