Summary

  • RFC 1106 described an experimental NAK and a 30-bit TCP receive-window option. It said the extensions had been implemented and shown to work using NASA resources, while explicitly declining to propose them as an Internet standard.
  • RFC 1110 found a condition outside that bounded success: the larger window left TCP's 32-bit sequence space unchanged, allowing a sequence number to be reused after four round trips. A sufficiently delayed duplicate could then look current.
  • The NAK had its own evidence limit. It reported that expected data had not arrived yet, but the receiver could not know whether the data was late or lost, or whether noise or congestion caused the gap. Test result, option agreement, gap report, retransmission, protocol safety and adoption were separate facts.

The successful test and the failed generalization were both true

RFC 1106 arrived in June 1989 with a claim that deserves to be read at its exact scale. R. Fox wrote that the two TCP extensions had been implemented and shown to work using resources at NASA. The same status paragraph called the protocol experimental, said the extensions were not proposed as an Internet standard and presented them as a starting point for research.

There was no contradiction. An implementation could move data in the environment that its operators had assembled. That evidence established code, negotiated state and measured behavior under those conditions. It did not enumerate every path behavior the wider Internet might introduce.

The memo itself disclosed the boundary. Its abstract said the main unresolved issue was congestion versus noise. It asked whether the options applied to the Internet as a whole rather than only to high-bandwidth-delay networks, and described their use in an isolated satellite-network environment. The qualification was part of the result, not a footnote to erase.

The current RFC Editor record lists RFC 1106 as Historic in the Legacy stream and points to RFC 6247. The IETF Datatracker preserves the text and present record. That later status does not make the 1989 implementation imaginary. It changes a different fact: what authority and adoption the document carries now.

A gap was visible before its cause was known

The first extension was a negative acknowledgement, or NAK. Ordinary cumulative acknowledgements described the left edge of received data. RFC 1106 wanted the receiver to react earlier when an arriving segment revealed a gap: identify the first missing sequence number and ask the sender to retransmit the data needed to move that edge.

The receiver's observation was narrow. RFC 1106 said directly that it could not distinguish data that would arrive late from data lost forever. Sending a NAK for a merely delayed segment could create an unnecessary duplicate. Not sending one for a true loss could leave a large satellite pipe idle while ordinary TCP recovery waited.

The option was therefore advisory. It was not retransmitted if damaged. The sender could ignore it or resend immediately. If the NAK disappeared, ordinary TCP recovery remained responsible. A trace showing “NAK sent” proved a receive-stream gap and a request at one moment. It did not prove permanent loss, sender action, successful recovery or delivery.

Nor did the gap identify its cause. RFC 1106 discussed noisy links and congestion drops while naming congestion versus noise as unresolved. The same missing sequence could follow corruption, queue overflow, delay or reordering. A receiver that saw absence did not inherit the observation or authority required to diagnose the path.

The big window advertised memory, not safety

The second extension addressed the 16-bit receive-window limit. A 64 KiB window could not keep a large bandwidth-delay path full. RFC 1106 proposed a 30-bit window: the ordinary header retained the lower bits while TCP options carried the upper portion.

Both endpoints had to agree during SYN and SYN-ACK. After agreement, every later packet was expected to carry the upper receive-window bits. This negotiation established that two implementations would interpret the field in the proposed way. It did not show that the representation preserved every invariant on every possible path.

The advertised window was also not bandwidth. It described how much unacknowledged data the receiver was prepared to accept under its buffer policy. RFC 1106 warned that those buffers were valuable machine resources: an arbitrary large window could exhaust memory, crash a machine or starve other work. The NASA work was considering restricting large windows to programs that explicitly needed them.

Thus even inside the proposal, three quantities stayed distinct. The path had a bandwidth-delay product. The receiver offered buffer space. The sender still had to govern how much it put in flight. A large number in one field did not allocate capacity across the path or guarantee throughput.

Two months later, the old packet returned in a new cycle

August brought RFC 1110, A. McKenzie's short comment on the big-window option. It supplied the missing environmental condition: the Internet could lose, reorder and duplicate packets. TCP's 32-bit sequence numbers were only effectively unique because the receive window and a bound on packet lifetime kept an old byte from becoming plausible again.

With a 16-bit window, RFC 1110's model delayed reuse of a sequence number for 65,536 round trips. RFC 1106 expanded the window to 30 bits without expanding the sequence space. Reuse could occur after four round trips. A NAK could request a duplicate after one. If the earlier packet remained in the network for roughly five round trips, it could return when the same sequence number lay inside a later cycle of the window. TCP might accept old data as new.

That counterexample did not prove the NASA-resource test false. RFC 1110 even hypothesized an isolated satellite network that was effectively memoryless: it either delivered in order or lost the packet. Under that condition, the delayed-duplicate problem would not arise. The general Internet supplied a different condition, so the approach could not be generalized.

This was the decisive separation. A test can demonstrate behavior only over the states the test allows. A protocol invariant must survive the states the deployment environment allows. When the second set is larger, successful execution is necessary evidence and still insufficient proof.

History kept the proposal, the objection and the later design apart

The later record did not compress this exchange into “experiment failed.” RFC 4614 classified RFC 1106 as found defective for general use, said RFC 1110 deprecated its approach and recorded that the options were not adopted by the larger community. It also noted NAK use in SCPS-TP. That narrower reuse did not turn the RFC 1106 bundle into an Internet standard.

In 2011, RFC 6247 formally moved RFCs 1106 and 1110 to Historic with several TCP extensions that had never seen widespread use. “Not widespread” and “never implemented” are different claims. The archive can preserve both the bounded implementation and the absence of broader adoption.

Modern high-performance TCP also solved related problems with separate mechanisms. RFC 7323 defines Window Scale as an offer rather than a promise, negotiated in SYN segments. It points to selective acknowledgements for describing received and missing segments, and uses timestamps with PAWS to protect against old duplicates after sequence-number wrap. Those mechanisms are not the RFC 1106 option, and the shared problem does not establish a direct lineage. Their separation nevertheless shows why “make the window bigger” was never the whole design.

The evidence object needed the environment attached

A durable experiment record needs more than the result. It needs the implementation version, topology, packet-lifetime assumptions, reordering and duplication behavior, error model, buffer policy, offered window, traffic pattern, observation points and conditions excluded by the test.

Without that envelope, “worked” becomes portable when the evidence was not. An endpoint handshake becomes proof of path safety. A receiver's gap becomes a diagnosis. A retransmission request becomes recovery. A local throughput figure becomes adoption. A later Historic label then swings too far in the other direction and erases the experiment that really occurred.

RFC 1106 and RFC 1110 are valuable together because neither record has to impersonate the other. The first preserved what ran. The second preserved the state that had not been tested. Protocol history becomes reliable when it keeps both.

Sources