Reliable Transport Service

Reliable transport service has three aspects, user multiplexing, connection management and data transfer. Data transfer provides for the reliable exchange of data between connected users. Connection management provides for the establishment and termination of connections between users. Users can open and close connections to other users, and can accept or reject incoming connection requests. Resources are acquired when a user enters a connection, and released when the user leaves the connection . An incoming connection request is rejected if the user has filed or it transport entity does not have adequate resources for new connections.

A key concern of transport protocols is to ensure that a connection is not infiltrated by old messages that may remain in the network from previous terminated connections. The standard techniques are to use the 3-way handshake mechanism for connection management and the sliding window mechanism for data transfer within a connection. These mechanisms use cyclic sequence numbers to identify the connection attempts of a user and the data blocks within a connection. The protocol must ensure that received cyclic sequence numbers are correctly interpreted and this invariably requires the network to enforce a maximum message lifetime.

Each user goes through a succession of incarnations. An incarnation of a client is started whenever the client requests a connection to any server. An incarnation of a server is started whenever the server accepts a (potentially new) connection request from any client. Every incarnation is assigned an incarnation number when it starts; the incarnation is uniquely distinguished by its incarnation number and user id.

Once an incarnation 'x' of a user 'c' is started in an attempt to connect to a user 's', it has one of two possible futures. The first possibility is that at some point 'x' becomes open and acquires an incarnation number y of some incarnation of 's'; at some later point 'x' becomes closed. The second possibility is that 'x' becomes closed without ever becoming open. This can happen to client incarnation either because its connection request was rejected by the server or because of failure (in the server, the client, the relevant transport entities, or the channels). It can happen to a server incarnation either because of failure or because it was started in response to a connection request that later turns out to be a duplicate request from some old, now closed, incarnation.

Because of failures, it is also possible that an incarnation 'x' of 'c' becomes open to incarnation 'y' of 's' but 'y' becomes closed without becoming open. This is referred to as a half-open connection. A connection is an association between two open incarnation. Formally, a connection exists between incarnation 'x' of user 'c' and incarnation 'y' of user 's' if y has become open to 'x' and 'x' has become open to 'y'. The following properties are desired of connection management:

Consistent connections - If an incarnation x of user c becomes open to an incarnation 'y' of user 's', then incarnation 'y' is either open to 'x' or will become open to 'x' unless there are failures.

Consistent data-transfer - If an incarnation 'x' of user 'c' becomes open to an incarnation 'y' of user 's', then 'x' accepts received data only if sent by 'y'.

Progress - If an incarnation 'x' of a client requests a connection to a server, then a connection is established between 'x' and an incarnation of the server within some specified time, provided the server does not reject x's request and neither client, server nor channels fail within that time.

Terminating handshakes - The transport entity (of either user) cannot stay indefinitely in a state (or set of states) where it is repeatedly sending messages expecting a response that never arrives.

Unreliable Transport Service

Unreliable transport service involves two aspects: user multiplexing and unreliable data transfer between users. A transport protocol can achieve this simply by adding user multiplexing to the message transfer service provided by the network layer. When a user generates a data segment destined to a remote user, the transport protocol gives the network layer a packet containing the user's local port number, the user's remote port number, the user's remote host IP address, the user's transport protocol number, and the data segment.

When the network entity at a host receives a packet, it first looks for a local user with local port number equal to the packet's destination port number, remote port number equal to the packet's sender port number, remote host address equal to the packet's sender IP address and transport protocol number equal to the packet's transport protocol number. If it finds such a user, it passes the packet's data segment to the user. Otherwise, it looks for a local user (presumably a server) with local port number equal to the packet's destination port number, remote port number and host address equal to nil, and transport protocol number equal to the packet's transport protocol number. It it finds such a user, it passes the packet's data segment to the user. Otherwise, it discards the packet.

User Multiplexing

User-to-user communications requires that network packets contain header information identifying the source and destination users, in addition to the source and destination hosts. In the TCP/IP architecture, hosts are identified by IP addresses and users are identified by port numbers. The obvious way to identify users on a host is to assign a distinct port to every users, so that any user is identified network-wide by its port number and its host's IP address. But this is not what is done. Instead each user is identified network-wide by the following attributes: local port number, remote port number, local host IP address, remote host IP address, and transport protocol number. The remote port number and IP address are the local port number and IP address of the remote peer users; if the remote user is not known, the remote port number and IP address are nil.

The transport protocol number identifies the particular transport protocol (For e.g. UDP or TCP) being accessed by the user. A user's local port number is assigned as soon as the user starts to use the transport service. The user's remote port number and IP address are assigned as soon as it learns of the local port number and host IP address of its intended peer user. Every IP network packet has the local port number of the originating user, called sender port number, the local port number of the intended destination user, called destination port number, the sender and destination IP addresses, and the transport protocol number. This approach of using local and remote that numbers and IP addresses to identify a user supports the client-server paradigm. This enables the clients to handle the same services simultaneously.

Consider a host H providing a service over a certain transport protocol (For e.g. FTP over TCP). H dedicates a specific local port number, say p1, to the service. H creates a server user, say S, with local port number set to p1, transport protocol number set appropriately, and remote port number and IP address set to nil. When a client user, say C on another host G wants to avail of this service, C would get local port number set to an arbitrary value, say p2, remote port number set to p1, remote IP address set to H's IP address, and transport protocol number set appropriately. When the request packet arrives at the transport layer in H, it gives the packet to S (assuming that there is no user at H with local port number p1, remote port number p2, remote IP address equal to G's IP address). The server S then can create another server specifically for servicing client C; this new server NS would have remote port number set to p2 and remote IP address set to G's IP address, and hence it can use local port number p1, same as S.

The following table illustrates the above example:

Host	User	Acts as	Local Port No.	Remote Port No.
H	S	Server	P1	Nil
G	C	Client	P2	P1

When sending the request packet to the Client C, the Server S creates another Server with following specification.

User	Acts as	Local Port No.	Remote Port No.
NS	New Server	P1	P2

Network Transport Service

The transport service are provided by transport protocols, which are distributed algorithms running on the hosts. The channels provided by the network layer between any two hosts can lose, duplicate and recorder messages in transit. The transport protocol is so designed such that they operate correctly inspite of unreliable network service and failure-prone networks and hosts.

The transport layer of a TCP/IP computer network, situated above the network layer and below the applications layer, provides transport service. The network layer provides unreliable packet transfer service between any two hosts. The transport layer uses this network service and provides transport services between any two applications in the network. Applications include email (SMTP), remote login (TELNET, SSH), file transfer (FTP), web browsers (HTTP), etc.

The ideal transport service is one that can transfer data packets between any two users and can do so reliably and with low-delay and low-jitter. Providing user-to-user service implies that the transport layer has to do user multiplexing at each host. Reliable data transfer means that data is delivered in the same sequence it was sent and without loss. Low-delay means that data sent is delivered within a specified (usually small ) time bound. Low jitter means that the time intervals between sending data is preserved at delivery within specified (usually small) time bounds. Achieving such ideal service requires the network to be capable of handling the worst-case load at any time, which, if the network is not to be incredibly expensive, means imposing severe restrictions on network access and data rates available to users ( as in telephony networks).

Fortunately, ideal transport service is not required for most applications. Thus the transport layer in TCP/IP networks does not strive for it. Instead it provides two separate services: a reliable service, which can suffer high delays and jitter and an unreliable service, which does no better than the network service. The reliable service, implemented by a transport protocol known as TCP, is used by applications where data integrity is essential, such as file transfer, email, remote login etc. The unreliable service, implemented by a transport protocol known as UDP, is used by applications where data loss can be tolerated but low-delay or low-jitter is desired, such as Internet telephony and voice/video streaming.

Thus reliable transport service is nothing but reliable data transfer between any two users. But reliable data transfer requires resources at the entities, such as buffers and processes for retransmitting data, reassembling data, etc. These resources typically cannot be maintained across failures. Furthermore, maintaining the resources continuously for every pair of users would be prohibitively inefficient, because only a very small fraction of user pairs in a network exchange data with any regularity, especially in a large network such as the Internet. Therefore a reliable transport service involves connection management and data transfer. Data transfer provides for the reliable exchange of data between connected users. Connection management provides for the establishment and termination of connections between users.

In general, reliable transport service (For e.g. TCP service) involves three aspects: user multiplexing, reliable connection management between users, and reliable data transfer between connected users. Unreliable transport service (For e.g. UDP service), on the other hand, involves two aspects: user multiplexing and unreliable data transfer between users.