Reliable data transfer protocols (RDT, RDP) are algorithmic measures to provide assurances of the reliable transfer of data across a network that may be subject to data loss and\/or corruption.<\/p>\n
RDT involves sender-side and receiver-side sequences and variables to validate, acknowledge, and retransmit data when necessary. The goal of RDT protocols is to provide network and link layer service such that application and transport layer services<\/a> can make guarantees about data delivery.<\/p>\n TL;DR<\/strong>: RDP guarantees reliable <\/em>data delivery service across an unreliable<\/em> channel. The most common implementation is TCP\/IP protocol used for the majority of internet data transfer.<\/p>\n Reliable Data Transfer Protocols must address the two primary concerns of data loss<\/strong> and data corruption<\/strong>. In network communications, these types of errors generally occur on the physical network hardware during buffering, propagation, and transmission actions.<\/p>\n To address these concerns, senders and receivers need a way to communicate\u00a0indirectly<\/em> with respect to the receipt and validation of data being transmitted. In such cases where data has been lost or corrupted, RDT protocols dictate that data should be re-transmitted. At the most basic level, this introduces another concern of duplicate data<\/strong> into the mix.<\/p>\n Data loss and corruption are the two primary concerns RDT seeks to address. The concern of duplicate data only arises through actions taken to address these first two concerns. As such, considering the issues of loss and corruption is a sensible place to begin considering the underlying function of RDT.<\/p>\n Implementing RDP as a transport layer service<\/a> requires several moving parts amidst several checkpoints, so to speak<\/i>. These “checkpoints” are points during data transmission where the following actions may occur:<\/p>\n It’s important to note these four points of RDT function can be used to describe communications in either direction on a network. For example, from Host A sending a message to Host B:<\/p>\n By contrast, the same process would occur in reverse should Host B send a message to Host A (symmetrical process):<\/p>\n RDP\/RDT utilizes several common features among varying implementations. These features help assure network engineers that the guarantees made by RDP\/RDT standards are available and predictably available. Some of these features are basic while others involve much more technical complexity. Below are some of the most common features of RDP\/RDT.<\/p>\n When a network system sends data to another network system, RDT suggests that some measures be taken to ensure that data arrived successfully. One basic approach to accomplish this is to incorporate a system of acknowledgment such that a receiver can inform the sender “yes, I received your message.”<\/p>\n How does one send such an acknowledgment though? The addition of an extra bit in the data segment being transmitted accomplishes just this. A receiver can send the sender a message, now with an Protocols such as Transmission Control Protocol (TCP)<\/a> encapsulate data integrated with headers, with one header field being reserved specifically for these types of acknowledgments (ACKs). The ACK system informs a sender of data loss or corruption when a negative ACK (NAK) is received, or duplicate ACKs are received.<\/p>\n What happens is a receiver never receives a packet to ACK or NAK? Such could be the case resulting from packet loss across the network. In this scenario, a sender may be stuck waiting indefinitely for an ACK\/NAK that will never come.<\/p>\n To mitigate this case, RDT requires the introduction of a sender-side timer variable<\/strong>. When a sender transmits a data segment it starts a timer. If the timer reaches a threshold before an ACK\/NAK is received, the sender retransmits the data.<\/p>\n The addition of a timer variable helps deal with data loss but there’s still one very limiting factor: a sender is limited to sending one data segment, waiting on an ACK\/NAK\/timeout, and then sending or retransmitting another data segment.<\/p>\n To better utilize available network bandwidth there needs to be a system of sending\u00a0multiple<\/em> data segments while keeping track of which ones are received, corrupted, or lost along the way.<\/p>\n Reliable Data Protocols operate in part by detecting degraded network conditions and acting accordingly. Timeout intervals help detect these types of conditions but don’t act to address them explicitly.<\/p>\n End-to-End<\/strong>: No explicit support is provided by the network layer; end systems must rely on inferred signals indicating congestion control such as packet loss or increasing RTT times.<\/p>\n Network Assisted<\/strong>: Network layer components such as routers provide direct feedback indicating current network conditions. This is usually implemented by direct link-to-end-system communication (choke packets) or by marking packet headers appropriately.<\/p>\n As senders transmit data across the network, awaiting ACK feedback from receivers, there becomes another issue: how is a sender to know which data an ACK is referencing? For example, let’s say 3 data segments were transmitted and the sender received 2 ACKs and 1 NAK. Which segment would need to be retransmitted?<\/p>\n In a protocol limited to simple One approach to address this limiting factor is to introduce a new variable into the data segment: the sequence number (SEQ)<\/strong>. This variable, now included as a 1-bit field in TCP headers, can allow a sender to transmit multiple segments and await ACKs for each.<\/p>\nIntroduction<\/h2>\n
Four Functions of Reliable Data Transfer<\/h2>\n
\n
1. Host A RDT receives data from layer above\r\n2. Host A RDT encapsulates data\r\n3. Host A RDT sends data to Host B\r\n4. Host B RDT receives data from layer below\r\n5. Host B RDT un-encapsulates data\r\n6. Host B RDT passes data to layer above<\/pre>\n
1. Host B RDT receives data from layer above\r\n2. Host B RDT encapsulates data\r\n3. Host B RDT sends data to Host A\r\n4. Host A RDT receives data from layer below\r\n5. Host A RDT un-encapsulates data\r\n6. Host A RDT passes data to layer above<\/pre>\n
Features of Reliable Data Transfer Protocol<\/h2>\n
Acknowledgment (ACK)<\/h3>\n
1<\/code> indicating positive acknowledgment (“message received, send next message”) or 0<\/code> indicating negative acknowledgment (“the last message was corrupt, please re-send.”)<\/p>\nTimeouts<\/h3>\n
Congestion Control<\/h3>\n
Sequence Numbers (SEQ)<\/h3>\n
ACK\/NAK<\/code> there would be no way to no unless a sender was limited to sending a single data segment at a time. This approach was used in early network communications and is known as a stop-and-wait protocol<\/a>. Certainly, stop-and-wait protocols are better than nothing but they can significantly limit network throughput when implemented haphazardly.<\/p>\n