1 / 56

Primitives for Achieving Reliability

Primitives for Achieving Reliability. 3035/GZ01 Networked Systems Kyle Jamieson Lecture 7 Department of Computer Science University College London. Achieving reliability: the story so far. Apply forward error correction (FEC) at physical layer Apply error detection at higher layers.

ailish
Télécharger la présentation

Primitives for Achieving Reliability

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. Primitives for Achieving Reliability 3035/GZ01 Networked Systems Kyle Jamieson Lecture 7 Department of Computer Science University College London

  2. Achieving reliability: the story so far • Apply forward error correction (FEC) at physical layer • Apply error detection at higher layers

  3. Choosing the amount of FEC to apply • Adding parity bits: • Increases number of bit errors receiver can correct • Increases overhead • Reduces the bit error rate (BER) after error correction • Question: What BER after error correction should we target? k bits n−k bits FECS FECR Network Sender Receiver data bits parity bits

  4. How much FEC do we need to apply? FLR n = 320 (40 bytes) n = 104 (1250 bytes) Bit error rate (BER)

  5. How much FEC? (notes) • What do we really care about? Keep frame loss rate (FLR) low: ≈10-3 • Suppose after applying FEC, probability of a bit error is BER • Pr[Frame of length n bits delivered] = (1 − BER)n • Assumption: Independence between bit errors (worst case) • Frame loss rate (FLR): 1 − Pr[Frame delivered] • Add enough FEC to keep FLR below rise, but no more (wastes bits on the channel) • Where is the rise, for a given packet size? • For small x, binomial expansion of (1+x)n = 1 + nx + O(x2) ≈ 1 + nx • FLR = 1 − (1 − BER)n ≈ n × (BER), therefore goal is to keep n × (BER) < 10-3 • Therefore, for data packet of 1250 bytes (104 bits), need BER after FEC of 10-7

  6. Some errors are too severe to be corrected • No matter how many parity bits we add, the network could flip them and data bits, causing errors! • Error detection (CRC) then discards these frames How to ensure that links are reliable? FECS FECR Network Sender Receiver

  7. Reliable delivery: Plan • Goal: ensure every packet is received exactly once • Exactly-once delivery • Pipelining for performance • Handling retransmissions intelligently • Congestion in the Internet • Culmination: the Transmission Control Protocol

  8. Today • Three protocols that achieve reliability: • Designing reliable transfer from first principles: the Stop and Wait protocol • Exploiting pipelining in the network: Go Back N • Smarter error recovery: Selective Repeat

  9. Reliable transfer over an unreliable channel • Task: Design sender and receiver sides of a reliable data transfer (rdt) protocol, using unreliable data transfer (udt) protocol • Recurs at many different layers: transport/network, link/physical rdt_send(data) deliver_data(data) Reliable data transfer protocol (sender side) Reliable data transfer protocol (receiver side) udt_send(pkt) rdt_recv(pkt) Unreliable channel

  10. Approach • Let’s derive a protocol that achieves reliable transfer from first principles • Goal:exactly once, in-order delivery of every packet • Unidirectional at first; same principles can generalize to bidirectional data transfer • Starting assumptions: • Channel can not introduce bit errors into packets • Channel can not fail to deliver packets • Channel can not delay packets • Channel can not reorder packets • Gradually relax these assumptions, one by one

  11. Reliable data transfer (rdt) v1.0 • Independent state machines at sender, receiver • No need for feedback (underlying channel is reliable) • No flow control in this protocol Sender state machine: Receiver state machine:

  12. Assumptions • Channel can introduce bit errors into packets • Channel (sender to receiver) can introduce bit errors • Channel (receiver to sender) can not introduce bit errors • Channel can not fail to deliver packets • Channel can not delay packets • Channel can not reorder packets

  13. Idea: Receiver requests re-sends • Three fundamental mechanisms: • Error detection: typically a packet checksum (like the CRC) • Acknowledgements: small control frame (ACK) transmitted from the receiver back to the sender • Positive ACKs acknowledge correct receipt • Negative ACKs inform sender of incorrect receipt • Timeouts: sender waits a reasonable amount of time, then retransmits the frame • Protocols using these techniques are called automatic repeat request (ARQ) protocols • Surprisingly challenging to apply correctly! A loaf of bread, OK. A dozen eggs, Sorry? A dozen eggs,

  14. Reliable data transfer under bit errors rdt v2.0 sender state machine: rdt v2.0 receiver state machine:

  15. Reliable data transfer v2.0 analysis Sender Receiver • Stop-and-wait protocol: Sender doesn’t send more data until sure original data received • Performance depends on sender-receiver delay, and throughput • Correctness: Two cases • Data arrives okay • ACK comes back immediately • Sender sends next packet • Data arrives corrupted • NACK comes back immediately • Sender retransmits corrupted packet • Exactly once, in-order delivery IDLE ACK wait Data A ACK IDLE ACK wait Data B NACK IDLE ACK wait Data B ACK

  16. Assumptions • Channel can introduce bit errors into packets • Channel (sender to receiver) can introduce bit errors • Channel (receiver to sender) can introduce bit errors • Channel can not fail to deliver packets • Channel can not delay packets arbitrarily • Channel can not reorder packets

  17. Human approach to feedback errors • One possibility: Apply ARQ in reverse • Request retransmits of corrupted feedback • If corrupt, receiver doesn’t know if forward-link packets are data or feedback retransmit requests • Clearly heading down a difficult path! A loaf of bread, OK. Sorry? ???

  18. Idea: Add checksums to feedback rdt v2.0 (with checksums) sender state machine: rdt v2.0 (with checksums) receiver state machine:

  19. Problem for rdt v2.0: duplicates Sender Receiver • Three cases: • Data okay, ACK okay • Data corrupted • NACK comes back immediately • Sender retransmits corrupted data packet • Data okay, ACK corrupted • ACK comes back immediately • Sender retransmits an identical data packet • At least once, in-order delivery IDLE ACK wait Data B NACK IDLE ACK wait Data B ACK IDLE ACK wait Data B ACK

  20. Assumptions • Channel can introduce bit errors into packets • Channel (sender to receiver) can introduce bit errors • Channel (receiver to sender) can introduce bit errors • Channel can not fail to deliver packets • Channel can not delay packets arbitrarily • Channel can not reorder packets • Sender or channel can duplicate packets

  21. From at least once to exactly once • Idea: add sequence numbers to data packets • Sequence number allows receiver to suppress duplicates rdt v2.1 sender state machine:

  22. From at least once to exactly once • Two states at receiver: one for expecting seqno=1; the other for expecting seqno=0 rdt v2.1 receiver state machine:

  23. rdt v2.1 error-free operation • Sender: send data, wait for reply • Receiver: deliver data, send ACK • Sender: send next data, wait • Receiver: deliver data, send ACK • Sender: transition to Idle State 0 Sender state machine: Sender Receiver Data, seqno=0 I0 DW 0 AW0 DW 1 Receiver state machine: ACK I1 Data, seqno=1 AW1 DW 0 ACK I0

  24. rdt v2.1: bit errors on the forward link • Sender: send data, wait for reply • Receiver: checksum fails; NACK • Sender: resend seqno=0 data • Receiver: deliver data; send ACK • Sender: transition to Idle State 1 Sender state machine: Sender Receiver I0 DW 0 Data, seqno=0 AW0 DW 0 Receiver state machine: NACK Data, seqno=0 AW0 DW 1 ACK I1

  25. rdt v2.1: bit errors on the reverse link • Sender: send data, wait for reply • Receiver: deliver data; send ACK • Sender: resend seqno=0 data • Receiver: dup. data; resend ACK • Sender: transition to Idle State 1 Sender state machine: Sender Receiver I0 DW 0 Data, seqno=0 AW0 DW 1 Receiver state machine: ACK Data, seqno=0 AW0 DW 1 ACK I1

  26. rdt v2.2: Getting rid of NACKs • rdt v2.1 used different packets in feedback direction (ACK, NACK) • Instead, we can add sequence numbers to ACKs • Sequence number in ACK corresponds to data it acknowledges Sender state machine: Sender Receiver I0 DW 0 Data, seqno=0 AW0 DW 0 Receiver state machine: ACK 1 I1 Data, seqno=0 AW0 DW 1 ACK 0

  27. rdt v2.1: Dropped packets • Sender: transmit data, wait for a reply from the receiver • Result: Deadlock Sender state machine: Sender Receiver I0 DW 0 Data, seqno=0 AW0 Receiver state machine:

  28. Assumptions • Channel can introduce bit errors into packets • Channel (sender to receiver) can introduce bit errors • Channel (receiver to sender) can introduce bit errors • Channel can fail to deliver packets • Channel can delay packets arbitrarily • Channel can not reorder packets • Sender or channel can duplicate packets

  29. Retransmission timer breaks deadlock rdt v3.0 sender state machine: Timer start Timer stop

  30. rdt v3.0 receiver rdt v3.0 receiver state machine:

  31. rdt v3.0: recovering lost packets • Sender: send, start timer, wait/reply • Receiver: deliver; send ACK 0 (lost) • Sender: timeout, resend, start timer • Receiver: dup. data; resend ACK 0 • Sender: stop timer, go to Idle State 1 Sender state machine: Sender Receiver I0 DW 0 Data, seqno=0 AW0 DW 1 Receiver state machine: ACK 0 Timeout Data, seqno=0 AW0 DW 1 ACK 0 I1

  32. rdt v3.0: delays in the network • Sender: send, start timer, wait/reply • Receiver: deliver; send ACK (delayed) • Sender: timeout, resend, start timer • Sender: stop timer, go to Idle State 1 • Receiver: dup. data, resend ACK 0 • Sender: recv. dup. ACK 0, do nothing Sender state machine: Sender Receiver I0 DW 0 Data, seqno=0 AW0 DW 1 Receiver state machine: Timeout ACK 0 Data, seqno=0 AW0 DW 1 I1 ACK 0 I1

  33. Stop-and-wait performance Data packet size L bits, link bitrate R bits/second sender receiver First bit transmitted, t = 0 Last bit transmitted, t = L/R First bit arrives RTT Last bit arrives, send ACK ACK arrives, send next packet, t = RTT + L/R Forward link utilization:

  34. Packet size L, link bitrate R; utilization Internet e.g.: 8000 bit packet; 1 Gbit/s link, 30 ms RTT: WiFi e.g.: 8000 bit packet; 54 Mbit/s link, 100 ns RTT Performance of stop-and-wait protocols (not including other unrelated overheads) When packet time << RTT, stop-and-wait underperforms.

  35. Pipelining: sender allows multiple unacknowledged packets “in-flight” from sender to receiver Range of sequence numbers must be increased Buffering at sender and/or receiver Two generic forms of pipelined protocols: Go-Back-N, Selective Repeat Idea: Pipelined protocols

  36. Increasing utilization with pipelining sender receiver First bit sent, t = 0 Last bit sent, t = L / R RTT last bit of 1st packet, send ACK last bit of 2nd packet, send ACK last bit of 3rd packet, send ACK ACK arrives, send next packet, t = RTT + L / R

  37. The bandwidth-delay product • How many packets N should we allow “in flight” (unacknowledged) in order to get maximum link utilization? sender receiver RTT Number of bits “in flight” Delay × Bandwidth product

  38. Today • Three protocols that achieve reliability: • Designing reliable transfer from first principles: the Stop and Wait protocol • Exploiting pipelining in the network: Go Back N • Smarter error recovery: Selective Repeat

  39. Assumptions • Channel can introduce bit errors into packets • Channel (sender to receiver) can introduce bit errors • Channel (receiver to sender) can introduce bit errors • Channel can fail to deliver packets • Channel can delay packets arbitrarily • Channel can reorder packets in forward direction • Sender or channel can duplicate packets

  40. The Go-Back-N (GBN) protocol • Sender: send without waiting for an acknowledgement • Up to N unacked packets “in flight” at any time • Why limit to N? Flow control at receiver, congestion control in the network • Timer for oldest unacknowledged packet • Timer expire: retransmit all unacknowledged packets (sender can “go back” up to N packets) • Receiver: sends cumulative acknowledgement: acknowledge receipt of all packets up to and including packet n:ACK(n)

  41. GBN: at the sender rdt_send(data): if nextseqnum < send_base + N: sndpkt[nextseqnum] = make_pkt send data with nextseqnum nextseqnum++ else: (refuse data) timeout: send(sndpkt[base]) send(sndpkt[base+1]) … send(sndpkt[nextseqnum−1]) rdt_recv(ackpkt): send_base = ackpkt.seqno + 1 • GBN: A type of Sliding Window Protocol (Timer code not shown)

  42. GBN: at the receiver • Maintain expectedseqnumvariable: sequence number of the next in-order packet • send_base ≤ expectedseqnum < nextseqnum • Incoming data packet with seqno=n • n = expectedseqnum: send ACK(n), increment expectedseqnum • n <> expectedseqnum: discard packet, send ACK(expectedseqnum − 1) • Nothing more, because in the event of loss, the sender will go back to expectedseqnum! • Could buffer correctly-received out-of-order packets, but the sender will transmit them later anyway

  43. GBN (N = 4) in operation Sender Receiver Send packet 0 Receive 0; send ACK 0 Send packet 1 Receive 1; send ACK 1 Send packet 2 Send packet 3 (wait) Receive 3; discard; send ACK 1 Receive ACK 0; send 4 Receive 4; discard; send ACK 1 Receive ACK 1; send 5 (wait) Receive 5; discard; send ACK 1 Timeout; resend 2 Receive 2; send ACK 2 Resend packet 3 Receive 3; send ACK 3 Resend packet 4 Receive 4; send ACK 4 Resend packet 5 Receive 5; send ACK 5

  44. The role of the retransmission timer • Keeps track of time at sender since the oldest unacknowledged packet was sent • This is the packet at the left edge of the sender’s window • Issue: Choosing a reasonable timer value • Compare to RTT of one packet: • Too small causes unnecessary retransmissions • Too big wastes time • Later: we will see how TCP solves this problem robustly

  45. Today • Three protocols that achieve reliability: • Designing reliable transfer from first principles: the Stop and Wait protocol • Exploiting pipelining in the network: Go Back N • Smarter error recovery: Selective Repeat

  46. Selective Repeat: Introduction • Go Back N • Allows sender to fill pipeline with packets, for high channel utilization • Receiver sends cumulative acknowledgements ACK(n) acknowledging packet n and all those before • Large pipeline means that a single packet error results in many duplicate packet transmissions • Selective Repeat (SR) • Main idea: sender retransmits only packets that don’t reach the receiver correctly • Receiver individually acknowledges each packet • One retransmission timer per packet • GBN and SR are both examples of sliding window protocols

  47. Finite sequence number space • Used in practice for both GBN and SR • Sequence numbers • k-bit sequence number • Result: a sequence number space in the range [0, 2k−1] • All arithmetic is modulo 2k: wrap-around from end to beginning 1 0 2k−1 2 0 2k−1

  48. Selective Repeat: Sequence numbers Already ACKed Out of order but ACKed Usable, not yet sent Acceptable nextseqnum send_base Sender’s view: • Window size N limits number of unacked packets in pipeline • send_base: lowest unacked packet • nextseqnum: last sent packet sequence number, plus 1 • rcv_base: last frame delivered, plus 1 Sent, not yet ACKed Expected, not yet received Not usable Not usable Window size N rcv_base Receiver’s view: Window size N

  49. SR sender: Data received from above Already ACKed Out of order but ACKed Usable, not yet sent Acceptable send_base nextseqnum Sender’s view: • Sender checks nextseqnum: • If in sender window, transmit, increment nextseqnum by one • If not in sender window, refuse data from above Sent, not yet ACKed Expected, not yet received Not usable Not usable Window size N rcv_base Receiver’s view: Window size N

  50. SR sender: Timeout event Already ACKed Out of order but ACKed Usable, not yet sent Acceptable nextseqnum send_base Sender’s view: • Recall: each packet has its own retransmission timer • Only packets’ timers in send window will be active • Sender retransmits packet then restarts that packet’s timer Sent, not yet ACKed Expected, not yet received Not usable Not usable Window size N rcv_base Receiver’s view: Window size N

More Related