1 / 48

Reliable Data Transfer

Reliable Data Transfer. Reliable Data Transfer. Problem: Reliability Want an abstraction of a reliable link even though packets can be corrupted or get lost Solution: keep track of the packets Not as simple as one would expect. Themes. Principles for Reliable transfer

Télécharger la présentation

Reliable Data Transfer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Reliable Data Transfer

  2. Reliable Data Transfer • Problem: Reliability • Want an abstraction of a reliable link even though packets can be corrupted or get lost • Solution: keep track of the packets • Not as simple as one would expect

  3. Themes • Principles for Reliable transfer • Protocols as State machines • More Pipelining • Protocols • ABP, Go-back N, Selective repeat

  4. important in app, transport, link layers top-10 list of important networking topics! Principles of Reliable data transfer

  5. rdt_send():called from above, (e.g., by app.). Passed data to deliver to receiver upper layer deliver_data():called by rdt to deliver data to upper udt_send():called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv():called when packet arrives on rcv-side of channel Reliable data transfer: getting started send side receive side

  6. Consider only unidirectional data transfer but control info will flow on both directions! Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) Reliable data transfer: getting started

  7. Reliable transmission &Flow Control • What to do when there is a packet loss? • On the link (in the network) • At the receiver (buffer overflow) • Need to recoup losses • What happens if the packet is lost in the network? • A random event, retransmit • What happens if the sender tries to transmit faster than the receiver can accept? • Data will be lost unless flow control is implemented

  8. Controlling the Flow of Data Slow Joe Fast Frank

  9. Some Flow Control Algorithms • Flow control for the ideal network • Stop and Wait for noiseless channels • Stop and Wait for noisy channels • Sliding window protocols • Sliding window with error control • Go Back N • Selective Repeat

  10. Flow control in the ideal network Assumptions: Error free transmission link, Infinite buffer at the receiver No acknowledgement of frames necessary Since the data link is error-free and the receiver can buffer as many frames as it likes, no frame will ever be lost

  11. Flow control in the ideal network (cont’d) Slow Joe Fast Frank Infinite bucket

  12. Stop and Wait with Noiseless Channels Assumptions: Error free transmission link, Finite buffer at the receiver Problem of Buffer overflow at the receiver • Buffer overflow may happen at the receiver when the sending router sends frames at a rate faster than the receiving router

  13. stop-and-wait operation sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK ACK arrives, send next packet, t = RTT + L / R

  14. example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet: L (packet length in bits) 8kb/pkt T = = = 8 microsec transmit R (transmission rate, bps) 10**9 b/sec • U sender: utilization – fraction of time sender busy sending • 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link • network protocol limits use of physical resources! Performance of stop and wait

  15. Stop and Wait with Noiseless Channels (cont’d) Slow Joe Fast Frank Finite bucket (once full, ball is lost)

  16. Stop and Wait with Noiseless Channels (cont’d) • Solution: Stop-and-Wait • The receiver sends an acknowledgement frame telling the sender to transmit the next data frame. • The sender waits for the ACK, and if the ACK comes, it transmits the next data frame. • Use 0/1 as sequence numbers • Also known as Alternating bit protocol (ABP)

  17. Stop and Wait with Noiseless Channels (cont’d) Data ACK Data

  18. Stop and Wait (cont’d) • Note that we assume an error-free transmission link and therefore ACK frames will not be lost • In this flow control protocol, there are two types of frames: data frames and ACK frames. The ACK frames don’t contain any particular information, since only the arrival of the ACK frame at the sender is important.

  19. Stop and Wait for Noisy Channels Assumptions: Transmission link may cause errors in frames, Finite buffer at the receiver ACK frames may now be lost

  20. Problems introduced by a noisy line Problem 1: Loss of a data or ACK frame • Since the transmission link is not error-free, a data or ACK frame may be lost, causing the sender to wait indefinitely for an ACK

  21. Loss of an ACK frame Data ACK error ?

  22. Problems introduced by a noisy line Can we solve problem 1 by introducing a timeout period for the sender? Yes, but... Problem 2: Duplicated frames • If the ACK frame for a certain data frame is lost, the sender will retransmit the same frame after a time-out period, and the receiver will then have two copies of the same frame

  23. Duplicated data frames Data ACK Duplicate data Data Timed Out

  24. Stop and Wait for Noisy Channels (cont’d) • Solution: • The sender uses a timer to retransmit data frames when an ACK has not arrived • The sender includes a sequence number in each frame to distinguish one frame from another. This way, the receiver knows when it has received duplicate frames.

  25. Stop and Wait for Noisy Channels (cont’d) Data 1 1 ACK receiver knows to discard this data Data 1 1 Timed Out 1

  26. Is Stop and Wait the best we can do? Stop and Wait is an effective form of flow control, but… It’s not very efficient. 1. Only one data frame can be in transit on the link at a time 2. When waiting for an acknowledgement, the sender cannot transmit any frames Better solution? Sliding Window

  27. Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts Pipelined protocols

  28. Sliding Window ProtocolsDefinitions Sequence Number: Each frame is assigned a sequence number that is incremented as each frame is transmitted Sender Window: Keeps track of sequence numbers for frames that have been sent but not yet acknowledged Receiver Window: Keeps track of sequence numbers for frames the receiver is allowed to accept Maximum Sender Window size: The maximum number of frames the sender may transmit without receiving any acknowledgements Maximum Receiver Window size: The maximum number of frames the receiver may receive before returning an acknowledgement to the sender

  29. 7 0 1 6 2 5 4 3 Simple Sliding Window with Window Size of 1 A sliding window with a maximum window size of 1 frame Window for a 3-bit sequence number

  30. 7 7 7 7 0 0 0 0 6 6 6 6 1 1 1 1 5 5 5 5 2 2 2 2 3 3 3 3 4 4 4 4 7 7 7 7 0 0 0 0 6 6 6 6 1 1 1 1 5 5 5 5 2 2 2 2 3 3 3 3 4 4 4 4 Sliding Window example Sender window Receiver window (a) (b) (c) (d) (a) Initial state, no frames transmitted, receiver expects frame 0 (b) Sender transmits frame 0, receiver buffers frame 0 (c) Receiver ACKS frame 0 (d) Sender receives ACK, removes frame 0

  31. Simple Sliding Window withWindow size 1 (cont’d) This protocol behaves identically to stop and wait for a noisy channel

  32. Sliding Window ProtocolsGeneral Remarks • The sending and receiving windows do not necessarily have the same maximum size • Any frame whose sequence number falls outside the receiver window is discarded at the receiver • The sender window’s size grows and shrinks as frames are transmitted and acknowledged • Unlike the sender window, the receiver window always remains at its maximum size

  33. Sliding Window ProtocolsPiggybacking Acknowledgements Since we have full duplex transmission, we can “piggyback” an ACK onto the header of an outgoing data frame to make better use of the channel When a data frame arrives at a router, instead of immediately sending a separate ACK frame, the router waits until it is passed the next data frame to send. The acknowledgement is attached to the outgoing data frame.

  34. Sliding Window with Maximum Sender Window Size WS With a maximum window size of 1, the sender waits for an ACK before sending another frame With a maximum window size of WS, the sender can transmit up to WS frames before “being blocked” This allows the sender to transmit several frames before waiting for an acknowledgement

  35. 7 7 7 7 0 0 0 0 6 6 6 6 1 1 1 1 5 5 5 5 2 2 2 2 3 3 3 3 4 4 4 4 7 7 7 7 0 0 0 0 6 6 6 1 1 1 6 1 5 5 5 5 2 2 2 2 3 3 3 4 4 4 3 4 Sender-Side Window with WS=2 (a) (b) (c) (d) (e) (f) (g) (h) (a) Initial window state (b) Send frame 0 (c) Send frame 1 (d) ACK for frame 0 arrives (e) Send frame 2 (f ) ACK for frame 1 arrives (g) ACK for frame 2 arrives, send frame 3 (h) ACK for frame 3 arrives

  36. Pipelining Sliding window with WS > 1 is also called “pipelined” communication data stream 99 51 50 A B 0 1 49 ACK stream By allowing several frames onto the link before receiving an acknowledgement, pipelining keeps the link from being idle

  37. Pipelining Example: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R first packet bit arrives RTT last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK ACK arrives, send next packet, t = RTT + L / R Increase utilization by a factor of 3!

  38. Sliding Window with Maximum Receiver Window Size WR With a maximum window size of 1, the receiver must receive and process every frame in sequence With a maximum window size of WR, the receiver can receive and process up to WR frames before acknowledging them This is useful when frames are lost: the receiver can still accept and buffer frames after the missing frame

  39. 7 7 7 7 0 0 0 0 6 6 6 6 1 1 1 1 5 5 5 5 2 2 2 2 3 3 3 3 4 4 4 4 7 7 7 7 0 0 0 0 6 6 6 1 1 1 6 1 5 5 5 5 2 2 2 2 3 3 3 4 4 4 3 4 Receiver-Side Window with WR=2 (a) (b) (c) (d) (e) (f) (g) (h) (a) Initial window state (b) Nothing happens (c) Frame 0 arrives, ACK frame 0 (d) Nothing happens (e) Frame 1 arrives, ACK frame 1 (f) Frame 2 arrives, ACK frame 2 (g) Nothing happens (h) Frame 3 arrives, ACK frame 3

  40. What about Errors? What if a data or acknowledgement frame is lost when using a sliding window protocol? Two Solutions: Go Back N Selective Repeat

  41. Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver Two generic forms of pipelined protocols: go-Back-N, selective repeat Pipelined protocols - how?

  42. Sliding Window with Go Back N • When the receiver notices a missing or erroneous frame, it simply discards all frames with greater sequence numbers and sends no ACK • The sender will eventually time out and retransmit all the frames in its sending window

  43. Go Back N Timeout interval Sender 0 1 2 3 4 2 3 4 5 6 Maximum window size = 8 ACK 3 ACK 1 ACK 2 ACK 0 ACK 6 ACK 5 ACK 4 Receiver 0 1 E D D 2 3 4 5 6 Maximum window size = 8 Discarded by receiver Frame with error Time

  44. Sender: k-bit seq # in pkt header “window” of up to N, consecutive unack’ed pkts allowed Go-Back-N • ACK(n): ACKs all pkts up to seq # n - “cumulative ACK” • timeout(n): retransmit pkt n and all higher seq # pkts in window • One timer for all in-flight pkts

  45. Go Back N (cont’d) Go Back N can recover from erroneous or missing frames But… It is wasteful. If there are errors, the sender will spend time retransmitting frames the receiver has already seen

  46. Sliding Window with Selective Repeat The sender retransmits only the frame with errors • The receiver stores all the correct frames that arrive following the bad one. (Note that the receiver requires a frame buffer for each sequence number in its receiver window.) • When the receiver notices a skipped sequence number, it keeps acknowledging the last good sequence number • When the sender times out waiting for an acknowledgement, it just retransmits the one unacknowledged frame, not all its successors.

  47. Selective Repeat Timeout interval Sender 0 1 2 3 4 2 5 6 Maximum window size = 8 ACK 5 ACK 4 ACK 1 ACK 1 ACK 1 ACK 0 ACK 6 Receiver 0 1 E 3 4 2 5 6 Maximum window size = 8 Buffered by receiver Frame with error Time

  48. Selective repeat: sender, receiver windows

More Related