In his paper “Timer-Based Mechanisms in Reliable Transport Protocol Connection Management,” published in 1981, Richard Watson provides a fundamental theory for achieving reliable transport connection management.
But what is connection management about? Transport protocols designed for reliable transmission provide one or more error-controlled channels between transport address pairs (associations). A connection is said to exist and state information is maintained in connection records at each end of an association. The process of proper synchronization and evolution of the connection records in the face of the possible transmission delays, errors, end-node crashes is called connection management.
Connection management has three logical phases:
- Initializing (opening) of the connection records at each end
- Evolving the state of the connection records during ongoing data transfer
- Terminating (closing) state information when no further data requires transferring
Watson formulates the logical conditions that need to be met in order to achieve reliable transport connection management during the opening and closing phases:
- O1: If no connection exists, then no packets from a previously closed connection should open a connection.
- O2: If a connection exists, then no packets from a previously closed connection should be accepted.
- C1: A receiving side must not close until it has received all of the sender’s retransmissions and can unambiguously respond to them.
- C2: Sending side must not close until it has received all acknowledgments (Acks) or allowed time for an Ack of its final retransmission to return before reporting a failure.
Ambiguity exists if a sender does not receive an Ack of some data sent. It will not know whether the data or the Ack got lost.
All reliable transport protocols require explicit or clearly understood implicit bounds on three lifetime factors:
- MPL (maximum packet lifetime): Maximum time a packet is allowed to live inside a network.
- R: The maximum time a sender requiring a positive Ack will keep trying to retransmit a packet before ceasing retransmission.
- A: The maximum time a receiver will hold a packet before sending an Ack.
Then, three conditions are sufficient to assure perfect error control:
- A1: An identifier (sequence number, SN) of an information unit used for assurance is never reused, while one or more copies (duplicates) of that unit or its Ack exist.
- A2: The assurance state or redundant information maintained at each end is never lost or damaged.
- A3: The assurance control information transmitted between each end is itself perfectly error controlled.
Watson compares how TCP and Delta-t, a transport protocol he developed at Lawrence Livermore Lab, deal with the three aforementioned conditions and relate them to the opening and closing conditions. TCP uses three separate management mechanisms to achieve assurance: 1) exchange of connection management (syn, fin) messages and associated state transitions, 2) careful choice of an initial sequence numbers and 3) assurance timers that implicitly bound MPL, A and R. On the other hand, Delta-t relies on a single timer mechanism that explicitly bounds MPL, A and R. This classifies Delta-t as a pure soft-state (SS) protocol, i.e., the state of a connection at the sender and receiver can be safely removed once the connection-state timers expire without the need for explicit removal messages. TCP’s approach can be viewed as a hybrid hard-state/soft-state (HS+SS) protocol.
The comparison is done in terms of complexity (special mechanisms and transition states required), message overhead and connection-record resources requires by both protocols. Watson proves that explicitly bounding MPL, R and A are necessary and sufficient conditions for synchronization. Delta-t achieves transport-connection management reliably and reduces the number of messages and the resources required to maintain a connection’s state providing a mechanism far simpler than in TCP.
Amongst Watson’s findings was also the decoupling of port allocation and synchronization, recognizing the distinction between the two functions.
So, why was TCP selected to replace NCP and not Delta-t? As John Day writes in his book “Patterns in Network Architecture: A return to fundamentals”: “Probably the foremost factor in the choice was that the Internet was a DoD (US Department of Defense) project and TCP was paid for by the DoD. This reflects nothing more than the usual realities of interagency rivalries in large bureaucracies and that the majority of reviewers were DARPA contractors”. Delta-t was a radically new idea in protocols with a more robust timer-based synchronization mechanism that essentially eliminated connection establishment and closing phases as new connections were established without an explicit handshaking or closing sequence. It also used separate PDU types for Ack and flow control and separated the transport and network functions.
Now, Recursive InterNetwork Architecture (RINA) uses a soft state data transfer protocol, the Error and Flow Control Protocol (EFCP) that is built around Watson’s Delta-t protocol. The principles proven by Watson were held intact. The main difference is that EFCP guided by another fundamental principle, the separation of mechanism and policy, is split into two independent protocol machines (Data Transfer Protocol and Data Transfer Control Protocol), loosely coupled through a state vector. This gives EFCP the ability to cover a wide range of operation by plugging different policies. Gursun et al. in “Performance and Robustness of Managing Reliable Transport Connections” provided a performance comparison study that compares the hybrid HS+SS approach of TCP against the SS approach of Delta-t. The results show that the SS approach is more robust, and has lower message overhead and higher goodput, making it the best choice for reliable applications. Also, Boddapati et al. in “Assessing the Security of a Clean-Slate Internet Architecture” proved that Delta-t is also more secure than TCP by comparing the security of RINA to the current Internet architecture.
And that takes us to the future… All these simply mean that the transport protocol of the future can be more efficient, more robust, more secure, more flexible and simpler.