Summary

  • RFC 1644's TCP Accelerated Open compared a monotonically increasing connection count in an initial SYN with a server's per-client cached count. A higher value let the server treat the SYN as new and deliver its data before completing the ordinary three-way handshake.
  • CC.NEW was a deliberate loss-of-confidence signal: after restart, wraparound or an unknown prior count, it invalidated the server cache and forced normal handshake validation. CC.ECHO let the client validate that the SYN/ACK referred to its opening count.
  • These mechanisms bounded old transport duplicates. They did not authenticate a peer, prove a safe path, or produce an application commit receipt. RFC 6247 later moved T/TCP to Historic after it failed to see widespread use and security issues were reported.

The first packet crossed a decision boundary

RFC 1644 described an Experimental extension for short request/response exchanges. Ordinary TCP required the opening handshake to complete before data was transferred. T/TCP instead allowed an active opener to place request data in the initial SYN together with a 32-bit connection count, or CC.

The server kept the last valid CC received from each client host. If the new value was greater than the cached value, the TCP Accelerated Open test passed. The specification then allowed the server to update its cache and pass the data in that SYN to the user process. If the value was not greater, the server could not tell whether the segment was an old duplicate or merely out of order, so it fell back to the normal three-way handshake.

The cache comparison was therefore an action gate. It converted one observed relation — new count greater than remembered count — into permission for early transport delivery. That relation was useful, but narrow. It depended on the cache owner, its lifetime, the client counter's monotonicity and the association between a remote host and the cached entry.

CC.NEW made the uncertainty explicit. When a client restarted, wrapped its counter or lacked a remembered value for the server, it sent CC.NEW rather than ordinary CC. Receipt invalidated the server's cache entry and forced a three-way handshake. A design that can say “my continuity assumption is no longer safe” is stronger than one that silently treats missing state as success.

The return path had its own check. A server's SYN/ACK echoed the client's opening count in CC.ECHO; the client used that value to validate the reply before delivering response data. This was not a general identity credential. It linked a response segment to the count in a particular opening exchange.

Transport at-most-once stopped before business completion

RFC 1644 used the language of at-most-once operation, but immediately bounded “transaction” to an elementary transport request/response sequence. It expressly said that this did not imply application transaction semantics such as a multi-phase commit. The minimum T/TCP exchange still used three segments.

That distinction matters whenever the request has an irreversible effect. Early delivery can establish that bytes were handed to the server-side process under the protocol's duplicate test. It cannot establish that the process parsed them, authorized the caller, wrote durable state, charged an account, emitted a downstream command, rolled back on error or returned a response matching the final result.

A retry policy needs more evidence than the transport cache. If the client sees no usable response, the possibilities include loss before the server, rejection by the transport, delivery without execution, execution before a lost response, partial execution, or execution followed by an application failure. A monotonic CC does not collapse those states into one answer. Exactly-once business behavior still requires an application operation identifier, durable deduplication record and result receipt within the application's own authority boundary.

Peer identity and path safety also remained separate. The connection count was not a cryptographic identity proof, and the RFC did not turn middleboxes, routing, implementation correctness or current deployment into verified facts. In 2011, RFC 6247 moved RFC 1644 to Historic, stating that the affected TCP extensions had not seen widespread use and noting reported T/TCP security issues. RFC 9293, not RFC 1644, is the current TCP standards-track baseline.

Closing fast did not erase every old state

T/TCP also shortened TIME-WAIT for short connections. CC values helped distinguish newer incarnations from “antique duplicates,” and a new SYN could act as an implicit acknowledgement while state from the previous incarnation was being retired. But the shortcut was conditional: connections lasting longer than the maximum segment lifetime still required the ordinary delay, and the state machine retained special transition rules.

The same discipline applies to the whole design. A successful cache test justified one local transition. CC.ECHO justified one client-side validation. Transition to ordinary TCP preserved normal semantics when the transaction assumptions stopped holding. None of those local receipts should be promoted into a universal statement about the application, the organization behind the peer or the path the packets traversed.

Sources and limits

  • RFC 1644, the T/TCP functional specification and its TAO, CC, CC.NEW, CC.ECHO, TIME-WAIT and standard-TCP transition rules.
  • RFC 6247, the later Historic reclassification, deployment statement and security caveat.
  • RFC 9293, the current TCP specification baseline.
  • RFC 2140, a distinct later proposal about sharing selected host-pair TCB measurements across connections.
  • Minimum Initial Specification, the design discipline of keeping common rules narrow and locally verifiable.

These sources do not prove current T/TCP deployment, application correctness, authenticated identity, safe middlebox handling or an exactly-once business outcome.