Summary

  • RFC 2140 argued that selected TCP control-block observations, particularly MSS and RTT estimates, could be associated with a host pair rather than learned anew by every short connection. It was an Informational proposal, not an Internet Standard or a report of measured Internet-wide gains.
  • Its temporal case reused observations after a connection closed. Its ensemble case dealt with concurrent connections, where copying a congestion window to each new flow could multiply aggregate load; a fair-share division was proposed for examination, not demonstrated as deployed policy.
  • Sharing also transfers error. Stale or manipulated values could impair later short flows, so the memo called for validation and limits, and excluded security-sensitive sequence numbers from shared performance memory.

What survived the closing handshake

Picture two small requests sent to the same remote host, one after the other. The first connection measures a round-trip time and receives a maximum segment size. It closes. The second connection begins with a fresh TCP control block, although the endpoints may still have useful information about the route. RFC 2140 made that discarded observation its starting problem. Published in April 1997 as an Informational memo, it argued for interdependent control blocks to improve transient behavior, especially when short connections and simultaneous Web transfers were common.

The control block was not one indivisible bundle. It carried pointers to local buffers and a retransmission queue, the connection's ports and state-machine timers, and feedback such as round-trip estimates, maximum segment size and congestion information. A buffer pointer plainly belongs to its own process. A connection's sequence and protocol state cannot be handed to an unrelated application conversation. Touch separated those from micro-state that might describe the path between two hosts.

Even inside that latter group he distinguished observations such as MSS and RTT, which might be copied, from window information meaningful only across the group's aggregate traffic.

That distinction is the article's historical hinge. The useful object was not a resurrected connection. It was a narrowly scoped memory from which a new connection might initialize selected estimates. A host-pair key was a practical approximation to path commonality, not a certificate that the route, bottleneck or competing traffic had stayed the same.

A cache has a clock

The memo named two schedules. Temporal sharing reads observations left by an earlier, now closed connection. It described SunOS 4.1.3 T/TCP extensions and a FreeBSD port that cached MSS and RTT parameters. That evidence establishes limited historical examples. The same section says reuse of the congestion window had been discussed but was not yet implemented in that example.

The update moments mattered. An observed MSS option could refresh the cached MSS when it arrived; a connection closing could update cached RTT and RTT variance. The latter used an average across connections rather than the calculation used within one connection. RFC 2140 explicitly warned that the resulting cached RTT might be inappropriate. An old number could remove some relearning cost and still misdescribe the next exchange.

Ensemble sharing posed a different timing problem. Several connections may open before any one closes. A cache updated only at close gives those simultaneous arrivals no shared observation. The memo therefore considered earlier updates for concurrent use. Copying MSS or RTT is conceptually different from copying congestion permission: each newly initialized congestion window adds possible traffic to a shared path. Even an ordinary one-segment initial window increased the ensemble's sum in the memo's analysis. Giving every new connection a copy of an established flow's larger window would enlarge the sum further.

Touch explored dividing an available aggregate window among N+1 connections and reducing the existing N shares accordingly. This was a proposed accounting rule, not a measured performance result or settled fairness doctrine. The memo says the equal-share assumption may be wrong and calls for further study. Its point was to expose that a saved window cannot be treated as several independent grants to transmit.

The memory can carry damage

Sharing across connections expands the reach of a bad observation. RFC 2140 described how a zero or falsely small window could slow later connections, with short flows bearing much of the loss before they had time to correct the estimate. It called for checking shared values against default minimums when a new control block is made, limiting the influence of incoming packets on ongoing shared state, and isolating application-modified or unauthenticated state unless explicitly permitted. It also confined sharing to performance factors: TCP sequence numbers belonged outside the cache.

These safeguards were part of the proposal's reasoning, not proof that a secure shared-state service was deployed. The memo offered no throughput benchmark that would establish the promised improvement. It did not prove that a host pair always implies one path. Its later replacement, RFC 9040, obsoleted RFC 2140 in 2021 and supplied a more detailed account of what sharing entails. That later history should not be read backward as a feature already present in 1997.

The durable insight is smaller and sharper than “TCP should remember.” Information acquired by one connection has an owner, an update time, a scope and a failure mode. RFC 2140 made each of those questions visible before a new flow could borrow an old answer.

Sources and limits

The account reports what the RFCs proposed and documented. It does not infer current stack behavior, a measured speedup, a verified shared route or Internet-wide adoption from those texts.