The Transport Layer

UDP vs TCP#

Common:

Both take the extension of IP's delivery service between two end systems to a delivery service between two processes running on the end systems as their most fundamental responsibility. Namely, their fundamental responsibility is transport-layer multiplexing and demultiplexing.
Both provide integrity checking by including error-detection fields in their segments' headers.

While UDP does not guarantee that data sent by one process will arrive, or arrive intact, to the destination process, TCP offers

Reliable data transfer.
Congestion control.

Multiplexing and Demultiplexing#

Socket: Each processes have one or more sockets through which data passes from the network to the process, or from the process to the network. Sockets have unique identifiers.

Multiplexing: At the source host, the transport layer gather data chunks from different sockets, encapsulating each data chunk with header information to create segments, and pass the segments to the network layer. This is called multiplexing.

Demultiplexing: At the destination host, the transport layer receives segments from the network layer just below. It has the responsibility of delivering the data in these segments to the appropriate application process running in the host by referencing the header information in the segment to identify the receiving socket and direct the segment to the appropriate socket.

Port numbers#

There are two special fields in the header of a transport-layer segment: source port number field and destination port number field. These are 16-bit (0 to 65535) numbers. Ports from 0 to 1023 are called well-known port numbers and are reserved for use by well-known application protocols.

Connectionless multiplexing and demultiplexing#

For UDP sockets, a port number is bind (assigned) to the socket.

A UDP socket is fully identified by a two-tuple consisting of a destination IP address and a destination port number, hence if two UDP segments have different source IP addresses and/or source port number, but have the same destination IP addresses and destination port number, then the two segments will be directed to the same destination process via the same destination socket.

The source port number is used for “replying”.

Connection-oriented multiplexing and demultiplexing#

A TCP socket is identified by a four-tuple: (source IP address, source port number, destination IP address, destination port number). In contrast to UDP, two arriving TCP segments with different source IP addresses or souce port numbers will be directed to two different sockets.

There is first a “welcoming socket” that waits for connection establishment request in the TCP server on port number \(N\). When the host operating system of the server process receives the incomming connection-request segment with destination port \(N\), it locates the sever process, and the server process then creates a new socket that is identified by the four values (source IP address, source port number, destination IP address, destination port number); all subsequently arriving segments whose four fields match the four values will be demultiplexed to this socket.

We see that if a client and a server are using non-persistent HTTP, then a new TCP connection will be created and closed for every request/response, and hence a new socket is created and later closed for every request/response. This can severly impact the performance of a web server, which can be mitigated to some degree by a number of operating system tricks.

Reliable Data Transfer#

Over a channel with bit errors#

Suppose that the underlying channel is one in which bits in a packet may be corrupted, but that all transmitted packets are received, and in the order in which they were sent. In this case, reliable data transfer protocols are often based on control messages: positive acknowledgements, negative acknowledgments, and retransmission once a negative acknowledgement is made. Reliable data transfer protocols based on such retransmission known as ARQ (Automatic Repeat reQuest) protocols.

To be able to do this, in the presence of bit errors, ARQ protocols must be capable of

Error detection. Sometimes, correction. Usually by checksum.
Receiver feedback. Namely, to provide explicit feedback to the sender, with e.g. positive or negative acknowledgements.
Retransmission. Once a packet is received in error.

A toy model (stop and wait protocol) may be as follows:

One fatal flaw with stop-and-wait protocols is that it is possible for the ACK and NAK themselves to be corrupted. It is possible to detect whether the ACK/NAK packets are corrupted again by checksum bits, but even so the sender doesn't know whether the receiver really sent ACK or NAK.

Two solutions:

Add enough checksum bits to allow the sender not only to detect but also recover from bit errors. But this doesn't solve the problem for a channel that can lose packets.
The sender simply resend the current data packet when it receives a garbled ACK/NAK packet.

Since it is possible in general for a channel to lose packets, the second approach is taken. But now another problem is introduced: duplicate packets. A retransmitted packet cannot be known a priori to be a retransmission or a new data. This is solved by adding a sequence number into a new field of the packet header.