Reliable Transport 14-740: Fundamentals of Computer Networks Bill - PowerPoint PPT Presentation

Reliable Transport 14-740: Fundamentals of Computer Networks Bill Nace Material from Computer Networking: A Top Down Approach. J.F. Kurose and K.W. Ross

Administration • Stu ff is due • HW #1 was due 2 slides ago • Lab #1 on Tuesday • Quiz #1 regrade requests due Wednesday • No class on Thursday 2

Last Lecture • Transport Layer • Mission: Logical connection, App ↔ App • Tools: {De}Multiplex ➙ Port Numbers • Segmentation • UDP • Simple segment blaster 3

traceroute • RDT Theory and Tools • Stop-and-wait Protocol • Motivates Pipelining • Sliding-window Protocols • Go-back-N (GBN) • Selective Repeat (SR) 4

RDT: Requirements • Reliable Data Transfer (RDT) • Reliable channel service abstraction • No transferred bits are corrupted • All bits are delivered (and no extras) ... • ... in the order sent • Generally bidirectional • Today, we talk about unidirectional 5

Fault Models • Network-layer may have faults • Bit-errors • Lossy: i.e. segment can go missing • Duplicate delivery • Out-of-order delivery 6

Tools • Receiver feedback • Positive acknowledgement (ACK) • Good segment received • Negative acknowledgement (NAK) • Bad segment received 7

Tools (2) • Error detection • Checksum -- Segment received, but bit errors exist • Timer expiration -- Segment or receiver feedback is lost 8

Tools (3) • Retransmission • Sender sends another copy of segment • Sequence number • Distinguish between old and new • Gaps let receiver detect lost segment • Window, pipelining • Control sending of multiple segments 9

traceroute • RDT Theory and Tools • Stop-and-wait Protocol • Motivates Pipelining • Sliding-window Protocols • Go-back-N (GBN) • Selective Repeat (SR) 10

Stop-and-wait • Simplest Protocol that will handle bit errors and segment loss • Example of how to use: • checksum • acknowledgement • sequence numbers (1 bit) • timers 11

The protocol (v1) • Tools used: Checksum, ACK and NAK • After sending a segment • When segment is received • Wait to get an ACK/NAK • Examine checksum • If NAK, resend the • Reply with ACK for good segment segment • Then go back to waiting • Deliver to App layer • If ACK, great! • NAK for corrupted ones • Protocol does not create duplicate segments

Stop-and-wait in Action • Version 1 • Checksum: Detects Sender Receiver send segment flipped bits rcv segment send NAK • ACK / NAK: Feedback rcv NAK send segment rcv segment send ACK • “segment is good” rcv ACK • “segment is damaged” 13

The protocol (v2) • Tools used: Cksm, ACK/NAK, 1-bit seq number • When sending a segment • When segment is received • seq # = 1 - last seq # • Reply with ACK if good • NAK for corrupted ones • Wait to get ACK/NAK • Include seq number • If corrupted or NAK, resend • If seq # is ≠ last seq # • Otherwise, great! • Deliver to App Layer • Protocol retransmits a damaged ACK/NAK • ... but it can lose a segment

Stop-and-wait in Action • Version 2 • Checksum: Detects Sender Receiver send seg0 flipped bits in segment rcv seg0 send NAK or ACK / NAK rcv NAK send seg0 rcv seg0 send ACK • Sequence Number: deliver to App rcv ACK send seg1 rcv seg1 Detects duplicate send ACK deliver to App rcv ACK segments send seg1 rcv seg1 send ACK rcv ACK Duplicate! Not delivered to App layer 15

The protocol (v3) • Tools used: Cksm, ACK/NAK, seq numbers, timers • When sending a segment, set • When segment is received timer, include seq number • ACK for good segments • When ACK received, remove • NAK for corrupted ones timer and proceed with next • Include seq number segment • If seq # is ≠ last seq # • NAK: reset timer, resend • Deliver to App Layer • If timer goes off, resend (and set the timer) • Protocol retransmits lost segments

Stop-and-wait in Action Sender Receiver Sender Receiver send seg0 send seg0 rcv seg0 rcv seg0 send ACK0 send ACK0 rcv ACK0 rcv ACK0 send seg1 send seg1 rcv seg1 send ACK1 timeout rcv ACK1 send seg0 rcv seg0 send ACK0 timeout resend seg1 rcv seg1 send ACK1 Operation with rcv ACK1 send seg0 rcv seg0 no loss send ACK0 Lost Segment

Sequence Numbers • Without sequence numbers, receiver doesn’t know if Sender Receiver send seg0 rcv seg0 retransmitted segment send ACK0 rcv ACK0 is new data or old send seg1 • Lost ACK and Lost rcv seg1 timeout send ACK1 Segment are identical timeout resend seg1 rcv seg1 to sender send ACK1 rcv ACK1 send seg0 rcv seg0 send ACK0 Lost ACK

Sequence Numbers (2) • Sender can’t distinguish Sender Receiver send seg0 first and second ACK1 rcv seg0 send ACK0 • Sequence number rcv ACK0 send seg1 rcv seg1 indicates duplicate send ACK1 timeout timeout resend seg1 • Sender waiting for ACK0 rcv seg1 send ACK1 rcv ACK1 • Does nothing on ACK1 send seg0 rcv ACK1 rcv seg0 do nothing send ACK0 Premature Timeout

Stop-and-wait has a problem Sender Receiver first segment bit transmitted, t=0 last segment bit transmitted, t = L / R first segment bit arrives RTT last segment bit arrives, send ACK L = 1000B segment R = 1.5Mbps ACK arrives. First bit of next segment, t = RTT + L / R RTT = 45 ms L / R = .0053 U sender = = 0.1059 L / R + RTT .0503 Blech!

How can U be One? • Bandwidth-Delay Product • Amount of data that could be in transit • Sender could pump this much data without awaiting an ACK • Example • RTT = 45ms, R = 1.5Mbps • BWxDelay = R x RTT = 67.5Kb • If L = 1KB, (i.e. 8Kb) 8 segments could be in flight 21

Pipelined Protocols • Pipelining: send multiple, “in-flight”, yet- to-be-acknowledged segments Data segments Data segment ACK segments A stop-and-wait protocol A pipelined protocol 22

Pipelining: Increased Utilization Sender Receiver first segment bit transmitted, t=0 last segment bit transmitted, t = L / R first segment bit arrives RTT last segment bit arrives, send ACK last bit of 2nd seg arrives, send ACK last bit of 3rd seg arrives, send ACK ACK arrives. First bit of next segment, t = RTT + L / R Increased utilization by a factor of 3! 3 x L / R = 0.016 U sender = = 0.317 L / R + RTT .0503 23

traceroute • RDT Theory and Tools • Stop-and-wait Protocol • Motivates Pipelining • Sliding-window Protocols • Go-back-N (GBN) • Selective Repeat (SR) 24

Sliding-window Protocols • A mechanism to control multiple, in-flight segments without overwhelming receiver • Sender is allowed to transmit N segments without waiting for an ACK • N is the window size, a range of permissible sequence numbers • Two generic forms • Go-Back-N (GBN) • Selective Repeat (SR) 25

GBN: Sender • Sender places a k-bit seq# in header • “window” of up to N, consecutive unACKed segments allowed • Sets a timer for each in-flight segment • timeout(n): retransmit segment n and all higher seq# segments in window • ACK(n): ACKs all segments up to, including seq# n • Cumulative ACK 26

GBN: Receiver • ACK-only: always send ACK for correctly-received segment with highest in-order seq# • May generate duplicate ACKs • But, only remembers expected seq# • Receipt of out-of-order segment: • Discard! No receiver side bu ff ering • Re-ACK seg with highest in-order seq# 27

GBN: Window • Sender variables: send_base, nextseqnum send_base nextseqnum window size ( N ) already sent, not usable, not not usable ACK'ed yet ACK'ed yet sent • As segs are ACK’ed, window slides to right • GBN is a sliding-window protocol

GBN in Action Sender Receiver send seg0 send seg1 rcv seg0 send seg2 send ACK0 • N = ? X send seg3 rcv seg1 send ACK1 wait • sendbase ? rcv seg3 (discard) rcv ACK0 send ACK1 send seg4 rcv seg4 (discard) • next_seqnum ? rcv ACK1 send ACK1 send seg5 rcv seg5 (discard) seg2 timeout send ACK1 resend seg2 rcv seg2 (deliver) resend seg3 send ACK2 resend seg4 rcv seg3 (deliver) resend seg5 send ACK3 29

The Good, Bad, Ugly • GBN has minimal state at ends • especially receiver • Why discard segs received out-of-order? • Don’t want to bu ff er them, going to be re-sent anyway • Ugly: A single segment error can cause many segments to be retransmitted 30

traceroute • RDT Theory and Tools • Stop-and-wait Protocol • Motivates Pipelining • Sliding-window Protocols • Go-back-N (GBN) • Selective Repeat (SR) 31

Selective Repeat • Receiver individually ACKs all correctly received segments • Bu ff ers segs for eventual in-order delivery • Sender only resends segments for which ACK not received • Sets timer for each segment • Sender window of N consecutive seq#s • Limits seq#s of sent, but unACKed segs 32

SR: Windows Sender send_base nextseqnum already sent, not ACK'ed yet ACK'ed usable, not not usable yet sent window size ( N ) Receiver already acceptable received (within window) A different buffered and not usable ACK'ed view of the (out of order) window size ( N ) situation! rcv_base