Reliable Data Transfer

Reliable Data Transfer
In order to have a reliable data transfer protocol, we must be able to deal with bit errors and packet loss. Reliable data transfer can be implemented at different layers, and the difficulty often comes from the fact that the layer below might be unreliable (as is the case for TCP/IP.)

rdt1.0 - Reliable Data Transfer over a Perfectly Reliable Channel
If the underlying layer is already reliable, then the layer above may simply make use of the reliable service and not worry about reliability itself. A protocol simply receiving packets from the underlying

rdt2.0 - Reliable Data Transfer over a Channel with Bit Errors
Physical components of a network may corrupt individual bits in a packet. To deal with this, we need mechanisms to detect errors and provide feedback, as well as support for retransmitting erroneous packets. This type of protocol is known as an ARQ (Automatic Repeat reQuest) protocol.

Error detection
Errors are usually detected by verifying a checksum.

Receiver feedback
Acknowledging received packets with either positive (ACK) or negative (NAK) acknowledgement replies, based on whether or not a received packet is error-free.

Retransmission
Erroneous packets are retransmitted by the sender.

rdt3.0 – Reliable Data Transfer over a Lossy Channel with Bit Errors
With a lossy channel, a reliable data transfer protocol must detect packet loss and retransmit lost packets.

Detecting packet loss
The sender considers a sent packet to be lost when it does not receive an ACK within a set amount of time. The packet is then retransmitted. Determining how long the sender should wait for an ACK can be difficult. If the network is congested then it might be that the packet hasn’t been dropped at all, but the packet itself or the ACK reply is delayed long enough to cause the timeout. This introduces the possibility of duplicate data packets, as the packet is retransmitted.

Go-Back-N (GBN)
Instead of waiting for ACKs for each sent packet, the Go-Back-N protocol can transmit N packets (when available) without waiting. This is commonly known as the window size.

The receiver expects packets in order, refusing packets that don’t have the next expected sequence number. When the sender detects a loss, it will go back to the first unacknowledged packet and retransmit all packets since.

Note that the receiver actually discards out-of-order packets, which simplifies ordered buffering of received packets, but could mean that many packets are retransmitted unnecessarily.

Selective Repeat (SR)
SR protocols avoid unnecessary retransmissions by having the sender only retransmit packets that are actually lost.