17-TL-ReliableDataTransfer - Principles of Reliable Data...

Info iconThis preview shows pages 1–8. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Principles of Reliable Data Transfer Reliable Delivery Making sure that the packets sent by the sender are correctly and reliably received by the receiver amid network errors, i.e., corrupted/lost packets Can be implemented at LL, NL or TL of the protocol stack. Totally a design choice When and why should this be used? Link Layer Rarely done over twisted-pair or fiber optic links Usually done over lossy links (wireless) for performance improvement (versus correctness) in P2P links Network/Transport Layers Necessary if the application requires the data to be reliably delivered to the receiver, e.g., file transfer Reliable Delivery: Service Model Reliable, In-order Delivery unreliable channel Reliable Data Transfer Protocol (Sender Side) Reliable Data Transfer Protocol (Receiver Side) 1 2 3 4 1 2 3 4 UDT_Send RDT_Receive Deliver_Data RDT_Send Reliable, In-order delivery Typically done when reliability is implemented at the transport layer, e.g., TCP Example application: File transfer Reliable Delivery: Assumptions Well: Consider only unidirectional data transfer A sender sending packets to a receiver Bidirectional communication is a simple extension, where there are 2 sender/receiver pairs Start with simple a protocol and make it complex as we continue RDT over Unreliable Channel Unreliable channel Reliable Data Transfer Protocol (Sender Side) Reliable Data Transfer Protocol (Receiver Side) 1 2 3 4 1 2 3 4 UDT_Send RDT_Receive Deliver_Data RDT_Send Channel may flip bits in packets/lose packets The received packet may have been corrupted during transmission, or dropped at an intermediate router due to buffer overflow The question: how to recover from errors? ACKs, NACKs, Timeouts Next RDT over Unreliable Channel Two fundamental mechanisms to accomplish reliable delivery over Unreliable Channels Acknowledgements (ACK), Negative ACK (NACK) Small control packets (header without any data) that a protocol sends back to its peer saying that it has received an earlier packet (positive ACK) or that it has not received a packet (NACK). Sent by the receiver to the sender Timeouts Set by the sender for each transmitted packet If an ACK is received before the timer expires, then the packet has made it to the receiver If the timeout occurs, the sender assumes that the packet is lost (corrupted) and retransmits the packet ARQ The general strategy of using ACKs (NACKs) and timeouts to implement reliable delivery is called Automatic Repeat reQuest (ARQ) 3 ARQ Mechanisms for Reliable Delivery Stop and Wait Concurrent Logical Channels Sliding Window Stop and Wait...
View Full Document

Page1 / 27

17-TL-ReliableDataTransfer - Principles of Reliable Data...

This preview shows document pages 1 - 8. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online