Reliable Data Transfer (RDT) 2.1

RDT 2.1 protocol is the successor of RDT 2.0. While transmitting data in the transport layer, the issue of reliable transfer of data persists, the reliability issue is not only in the transport layer but also in the application layer. When a reliable protocol is used over an unreliable layer, reliability issues can raise, like TCP is a reliable protocol and it is implemented over IP which is an unreliable protocol. 

The fatal flaw of RDT 2.0 and the need for RDT 2.1

Protocol RDT 2.0 accounts for function in the channel with bit errors. It introduced positive and negative acknowledgments if the receiver receives a corrupted packet receiver sends a negative acknowledgment and vice-versa in the correct case. It fails when acknowledgment indeed was corrupted. RDT 2.1 solves this problem.

Ways to handle corrupted acknowledgments

1. The addition of extra checksum bits to detect the corrupted packet and also to recover the packet. This is good but needs extra data and processing of these packet headers.
2. Resending the data with corrupted acknowledgments by the sender, But this method introduces duplicate packets at the receiver end, This will be a flaw as there is no duplicate handling at the receiver’s side.
3. Adding an additional field that constitutes a sequence bit, and the receiver can check whether it is a duplicated packet or retransmitted one.

Method ‘3’ seems feasible which tracks duplicates and doesn’t require much data. RDT 2.1 uses this mechanism for handling duplicate packets.

Representation in Finite State Machine

Sender’s FSM:

Reliable Data Transfer (2.1): Sender FSM

How it works:

The logic of sequence number is sender sends packets with sequence numbers ‘0’ and ‘1’ alternatively as the continuous transmission of the same packet can be tracked.

State-1: In the figure top-left state called ‘Wait for 0’ is the start, Start state waits until it receives a message from the upper application layer. After it is received as the transport layer it adds a transport layer header added with sequence number ‘0’ sent into the network.

State-2: (Top-Right)After the packet is thrown into the network it moves to the next state. If the received acknowledgment is corrupt or in case of negative acknowledgment it resends the packet. Else the state moves to the next. 

State-3 and State-4 are the same as the 1 and 2 but it sends the packet with sequence number ‘1’.

Receiver’s FSM:

Reliable Data Transfer (2.1) Receiver FSM

How it works:

State-1(left): If it receives the corrupted packet it sends the negative acknowledgment for resend request. Else if it receives the non-corrupt packet with sequence number ‘1’ it sends a positive acknowledgment. Else if it receives the non-corrupt packet with sequence number ‘0’ it moves to the next state.

State-2(Right): If it receives the corrupted packet it sends the negative acknowledgment for resend request. Else if it receives the non-corrupt packet with sequence number ‘0’ it sends a positive acknowledgment. Else if it receives the non-corrupt packet with sequence number ‘1’ it moves to the next state.

Cons in RDT 2.1:

• No duplicate packet management.
• Not works in a channel with packet loss.