Table of Contents
Overview
Reliable transmission at the transport layer is about making sure that data arrives at the destination correctly, in the right order, and without being lost or duplicated, even when the underlying network is imperfect. In this chapter you will see how a transport protocol can turn an unreliable network service into something applications can trust.
We will focus on the ideas behind reliability, not on every detail of specific protocols. Later chapters about TCP and the three way handshake will connect these concepts to a real protocol.
What Can Go Wrong on the Network
Before understanding reliability, it is useful to list the typical problems that can affect packets while they travel across a network.
Packets can be lost and never reach the destination at all. This can happen due to congestion in routers, buffer overflows, or link failures.
Packets can be duplicated so that the receiver gets the same packet more than once. This can occur when acknowledgments are lost and the sender retransmits data that was actually already delivered.
Packets can arrive out of order. Different packets may take different routes or experience different delays, so packet 3 might arrive before packet 2.
Packets can be corrupted. Bits can flip due to noise, interference, or hardware problems, which changes the content of the packet.
A reliable transport protocol must detect these problems and hide them from the application. The application should see a clean stream of data, not the messy details of what the network is doing underneath.
Fundamental Ideas of Reliability
Reliable transmission is built on several core mechanisms. Different protocols may implement them in different ways, but the building blocks are the same.
First, there is sequencing. Each piece of data is given an identifier, a sequence number, so the receiver can tell where it belongs in the overall stream. With sequence numbers the receiver can reorder packets and can detect missing or duplicate ones.
Second, there is acknowledgment, often shortened to ACK. After receiving data, the receiver sends information back to the sender to confirm what has been received. This gives the sender a form of feedback from the network.
Third, there is retransmission. When the sender believes that some data did not get through, it sends it again. Detecting the need for retransmission usually depends on timeouts or on special negative signals from the receiver.
Fourth, there is error detection. Extra bits, such as checksums, are added so that the receiver can check if a packet was corrupted in transit.
Fifth, there is flow control, which limits how much data the sender pushes at once so that the receiver is not overwhelmed. Flow control is related to but distinct from reliability itself, and is covered in its own chapter, but it interacts closely with reliable transmission.
Taken together, these ideas let the transport layer provide a dependable data stream even though each individual packet can fail.
Sequence Numbers and Ordering
Sequence numbers are the backbone of reliable delivery. The transport layer at the sender breaks a large application message or byte stream into smaller segments and assigns each segment a range of sequence numbers. The receiver uses those numbers to reconstruct the original order.
Imagine the sender divides data into pieces called segments and assigns them sequence numbers 1, 2, 3, and so on. Even if segment 3 arrives before segment 2, the receiver can buffer segment 3 and wait for segment 2, then deliver the data to the application in the correct order.
Sequence numbers also help detect missing segments. If the receiver gets sequence numbers 1, 2, and 4, it can see that 3 is missing and can notify the sender indirectly through its acknowledgments.
They also help to detect duplicates. If a segment with a sequence number that has already been received appears again, the receiver knows it is a duplicate and can discard it.
In real protocols sequence numbers usually represent byte positions in a data stream, not just simple segment counters. The underlying idea, however, is the same: each piece of data has a position, and that position is used to keep everything in order.
Acknowledgments: Positive and Negative
Acknowledgments provide a way for the receiver to inform the sender about what data has arrived. How acknowledgments are structured has a major impact on performance and robustness.
The simplest idea is a positive acknowledgment for each segment. The receiver sends an ACK that says, in effect, "I got segment number $n$." If the sender does not receive an ACK for $n$ within a certain time, it assumes that segment $n$ or its ACK was lost and retransmits.
A more efficient idea is cumulative acknowledgment. Instead of acknowledging each segment individually, the receiver sends a single ACK that says, "I have received everything up to sequence number $N$." This way one acknowledgment can confirm many segments at once. If sequence numbers are byte based, the ACK often carries the next byte the receiver expects.
Some schemes also include negative acknowledgments, often called NACKs. A NACK indicates that something specific is missing or corrupted, for example, "I did not get segment number 5." NACKs can speed up recovery because the sender does not need to wait for a timeout to guess that something went wrong. Not all reliable transport protocols use explicit NACKs, but the concept is important.
A key property of reliable transmission is that every piece of data must be either acknowledged or retransmitted until acknowledged.
This does not mean acknowledgments must be one by one, but it does mean that the sender must have some way to know that each part of the data has been safely received.
Timeouts and Retransmissions
Reliability depends heavily on time. If the sender never retransmitted, a single lost packet could stall communication forever. However if the sender retransmitted too quickly, it could create unnecessary duplicates and add to congestion.
The common mechanism is a timeout. After sending a segment, the sender starts a timer. If an ACK for that data does not arrive before the timer expires, the sender assumes loss and retransmits the data.
A key quantity here is the round trip time, often abbreviated as RTT. This is the time from sending a segment until receiving its acknowledgment. The timeout value should be longer than the typical RTT, but not so long that recovery from loss is very slow.
In practice, reliable transport protocols measure the RTT over time and adjust their timeout value dynamically. If the network becomes slower, the timeout increases. If the network becomes faster, the timeout can shrink.
If the ACK arrives before the timer expires, the sender cancels the timer and often starts a new one for the next unacknowledged data. Only data that has not been acknowledged and whose timer expires is retransmitted.
Retransmission is triggered when no acknowledgment is received within a calculated timeout, not simply when the sender "feels" like resending.
This use of timers makes the protocol robust to occasional delays, but still responsive when real loss occurs.
Sliding Window and Reliability
Reliable transmission also needs to be efficient. Waiting for an ACK after every single segment would be very slow on high latency networks. To improve throughput, reliable protocols use a concept called a sliding window.
The sliding window defines how much unacknowledged data the sender is allowed to have in the network at once. Instead of sending one segment and waiting for its ACK, the sender can send several segments in a row before stopping.
Consider a window of size $W$ measured in segments for simplicity. The sender can transmit segments with sequence numbers from $n$ to $n + W - 1$ without waiting. As ACKs arrive, the window "slides" forward and allows more segments to be sent.
For example, if $W = 4$ and segments 1 to 4 are sent, the sender must then wait for ACKs. When it gets an ACK that covers up to segment 2, it can slide the window forward and send segments 5 and 6. Now segments 3 to 6 are in flight.
This is called a sliding window protocol. It combines reliability and efficiency. The sender still keeps track of which segments are unacknowledged, so it knows what to retransmit after a timeout. At the same time, multiple segments are in transit, which makes better use of the network.
Windows can be defined in bytes instead of segments. The receiver can also advertise how large a window it can handle, which connects this mechanism with flow control. That interaction belongs to the dedicated flow control chapter, but the important point here is that the sliding window is central to reliable protocols.
Handling Loss, Duplication, and Reordering
Now we can put the pieces together and see how reliable transmission deals with the problems mentioned earlier.
When a packet is lost, the sender does not receive an ACK that covers the sequence numbers in that packet. Eventually the timeout for that packet expires and the sender retransmits it. The receiver uses sequence numbers to place the retransmitted packet in the correct position and deliver a complete, ordered stream to the application.
When a packet is duplicated, both copies carry the same sequence numbers. The receiver sees that one of them has already been received and can discard the duplicate. Because acknowledgments are based on cumulative progress, a duplicate arrival does not change what the receiver reports back.
When packets arrive out of order, the receiver can use the sequence numbers to sort them. It may store later packets temporarily while waiting for earlier ones. When the missing pieces arrive, the receiver can then pass a continuous range of data up to the application. The application does not need to know that packets were out of order.
The combination of sequence numbers, acknowledgments, retransmissions, and buffering means that the transport layer can present a clean, ordered, duplicate free connection to the application even if the network path is chaotic.
Error Detection and Reliability
Reliable transmission also depends on accurate detection of bit errors. If corruption goes unnoticed, the receiver might accept incorrect data and acknowledge it, which defeats the purpose of reliability.
To detect errors, each segment usually contains an error checking field such as a checksum. A checksum is a simple arithmetic function of the data in the segment. The sender computes it and includes the result in the header. When the receiver gets the segment, it recomputes the checksum over the data and compares it with the value in the header.
If the two values differ, the receiver knows that the segment was corrupted. In that case the receiver discards the segment and does not acknowledge it. The sender will not see an ACK that covers this segment, and after a timeout, will retransmit it.
The exact mathematical formula used for a checksum can vary. For example, a common simple form is a ones complement sum of 16 bit words followed by a ones complement of the result. You do not need the full details here. The key idea is that checksums greatly reduce the chance that corruption goes unnoticed.
Reliable transport never accepts and acknowledges data that fails its error check. Corrupted data must be discarded and later retransmitted.
This rule connects error detection directly with the retransmission mechanism.
Reliability and Connection State
A reliable transport protocol must remember quite a lot of information while a communication is in progress. This set of information is called connection state.
At the sender, the state includes which sequence numbers have been sent, which have been acknowledged, the current window size, the value of the retransmission timer, and recent RTT measurements.
At the receiver, the state includes which sequence numbers have been received, which are missing, which are buffered awaiting reordering, and what the next expected sequence number is.
Maintaining this state is what allows the protocol to track what needs to be retransmitted and what has been safely delivered. It is also what differentiates connection oriented reliable protocols from connectionless unreliable ones.
The process of creating this shared state between two endpoints is called connection establishment and belongs to the three way handshake chapter. In this chapter it is enough to understand that reliable delivery requires both sides to keep synchronized views of sequence numbers and acknowledgments as long as communication continues.
Reliability vs Performance
Adding reliability costs extra overhead. Sequence numbers, acknowledgments, checksums, retransmission timers, and buffering all consume processing time and bandwidth.
If the network path is very reliable, this overhead may seem unnecessary. For some types of applications, like real time voice or video, waiting for retransmissions can be more harmful than losing a packet occasionally. These trade offs are the reason why not all transport protocols are reliable, and why there is a separate chapter on UDP and TCP vs UDP.
From a transport layer design perspective, the challenge is to provide strong reliability guarantees to applications that need them while trying to minimize performance penalties. Techniques such as cumulative ACKs, sliding windows, and adaptive timeouts are all optimizations that make reliability more efficient.
Summary
Reliable transmission at the transport layer uses a set of coordinated mechanisms to hide network imperfections from applications. Sequence numbers provide ordering and loss detection. Acknowledgments give feedback from receiver to sender. Timeouts and retransmissions repair losses. Sliding windows allow multiple unacknowledged segments in flight, which improves efficiency. Error detection ensures that only correct data is accepted and acknowledged.
Later chapters on TCP, the three way handshake, and congestion control will show how a real protocol uses these ideas together to provide the reliable, ordered byte stream that most Internet applications depend on.