If the network system is to provide reliable transmission, there must first be a way to detect the success or failure of delivery. We generally send a message called an acknowledgment (ACK), back to the sender to indicate successful receipt.

When a packet arrives at its destination, the recipient verifies the packet’s checksum. If the checksum fails, it discards the packet. If the packet arrives intact, the recipient transmits the ACK. For this very simple example, the recipient sends a separate ACK packet for each data packet received. FIGURE 10.9 illustrates this protocol using a sequence diagram.

In the sequence diagram, the messages flow between the two network endpoints over a period of time. We begin at the top of the diagram, with the host on the left sending a data packet containing the message “Pay $109.” Time progresses as we move downward. The arrow from left to right moving downward shows the data packet traveling to its destination. Midway, the packet arrives at the destination host, who responds with an “ACK” packet. The exchange ends at the lower left, when the ACK arrives at the sender, telling it to send the next packet.

This simple protocol ensures that the sender and recipient both understand the status of the transmission. This is a basic example of distributed processing; two computers, remote from one another, exchange information to achieve a shared goal. In this case, the goal is simple: Ensure that data moves from one computer to the other.

We make the protocol more efficient if we revise it to transmit several packets at once, without awaiting individual ACKs. We can number the individual packets, and the sender indicates the packet number when sending ACKs. The internet’s Transmission Control Protocol (TCP), uses a similar strategy. TCP numbers each byte consecutively. When sending an ACK, it transmits the number of the next byte it expects to receive. If it receives a packet out of order, it does not report its bytes as received until the earlier packets arrive. We study TCP further in Chapter 12.

When we assess the efficiency of different networks, we look at the ratio of the total number of bits the system can carry and the amount of end-user data actually carried. In packet networks, we calculate packet efficiency with the following ratio:

Packet efficiency provides a simple estimate of network efficiency. Packet headers and checksums represent networking overhead. The users choose the data to send in the data field, and the rest of the packet is required to make the network operate. Thus, we try to make the packet header as small as possible, but no smaller.

Packet efficiency isn’t the only element in network efficiency. We introduce other inefficiencies if we omit essential information. For example, we could omit the sender’s address from packets. In theory, the network only needs the recipient’s address to deliver a packet. In practice, however, it makes sense to include both addresses. Some networking hardware uses the sender’s address to ensure that responses go to the correct host. Moreover, the recipient host needs the address of the claimed sender in order to respond with an acknowledgment or with other data. If omitted from the packet header, the sending host would still need to provide the information in the data field.

Whenever a host sends a packet, it sets a deadline for receiving the corresponding ACK. If the recipient doesn’t return an ACK by then, the sender assumes the packet was lost or damaged somehow. The sender then resends the packet. This is called a timeout mechanism.

Some protocols also use a “negative ACK,” or NAK, packet. If the recipient knows that the packet should have arrived or the packet arrives with an intact header but damaged data, then the recipient may send a NAK. Most protocols rely on a timeout instead because the recipient host can’t detect all lost packets. For example, the host might not expect another packet or might not know when the next packet should arrive. If the host receives a packet with a damaged header, it won’t know what host sent the damaged packet.

Network traffic moves most efficiently if we avoid sending unnecessary packets. Even so, a recipient shouldn’t delay in sending ACKs. The recipient should process all packets it has received and try to send ACKs in a single batch. However, the recipient should never wait for “just one more” packet before sending an ACK.

As noted earlier when discussing TCP, the hosts must uniquely mark each packet to indicate the data items they contain. Ideally, the marking indicates the order in which the packets were sent. This allows the recipient to put packets in the correct order. It also allows the recipient to detect duplicate packets. An inevitable side effect of retransmission is that we will occasionally create duplicate packets.

If the ACK is delayed too long, the sender will retransmit the packet. This yields the right result if the packet was actually lost. If the ACK was lost or simply delayed, the retransmission creates a duplicate packet. The sequence diagram in FIGURE 10.10 shows how this happens.

The sending host transmits a series of packets. The sender sends packet 2, and the recipient sends the ACK in a timely manner. Unfortunately, the network delays the ACK packet for some reason. Because the sender doesn’t receive the ACK within the timeout interval, it retransmits packet 2. The recipient then receives a second copy of packet 2.

Although this may look troubling, it is exactly how the protocol should work. Each host only sees the packets it actually receives, and it can’t track the status of packets it has sent. The only way a host knows anything about its packets is if another host, or node, sends it a packet to indicate what happened. It may seem inconvenient or complicated to deal with duplicates, but it is the price we pay for reliable data transmission.

Modern networks rely on the endpoints to retransmit lost packets, but this is effective only if packets are very rarely lost. Most modern LANs provide adequate reliability and rarely need to retransmit a packet.