Reliable Transport · Bill Nace. Administration •Stuﬀ is due •HW #1 was due 2 slides ago...

Material from Computer Networking: A Top Down Approach. J.F. Kurose and K.W. Ross

Reliable Transport

14-740: Fundamentals of Computer NetworksBill Nace

Administration

• Stuff 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





• Go-back-N (GBN)


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)

• After sending a segment• Wait to get an ACK/NAK• If NAK, resend the

segment

• Then go back to waiting• If ACK, great!

• When segment is received• Examine checksum• Reply with ACK for good

segment

• Deliver to App layer• NAK for corrupted ones

• Tools used: Checksum, ACK and NAK

• Protocol does not create duplicate segments

Stop-and-wait in Action

• Version 1

• Checksum: Detects

flipped bits

• ACK / NAK: Feedback

• “segment is good”

• “segment is damaged”

13

Sender Receiver

send segmentrcv segmentsend NAK

rcv NAKsend segment rcv segment

send ACK

rcv ACK

The protocol (v2)

• When sending a segment• seq # = 1 - last seq #

• Wait to get ACK/NAK• If corrupted or NAK,

resend

• Otherwise, great!

• When segment is received• Reply with ACK if good• NAK for corrupted ones• Include seq number

• If seq # is ≠ last seq #• Deliver to App Layer

• Tools used: Cksm, ACK/NAK, 1-bit seq number

• Protocol retransmits a damaged ACK/NAK• ... but it can lose a segment


• Version 2

• Checksum: Detects

flipped bits in segment or ACK / NAK

• Sequence Number: Detects duplicate segments

15

Sender Receiver

send seg0rcv seg0send NAK

rcv NAKsend seg0 rcv seg0

send ACKdeliver to App

rcv ACKsend seg1 rcv seg1

send ACKdeliver to App

rcv ACKsend seg1 rcv seg1

send ACK

rcv ACK

Duplicate! Not delivered to App layer

The protocol (v3)

• When sending a segment, set timer, include seq number

• When ACK received, remove timer and proceed with next segment

• NAK: reset timer, resend• If timer goes off, resend (and

set the timer)

• When segment is received• ACK for good segments• NAK for corrupted ones• Include seq number

• If seq # is ≠ last seq #• Deliver to App Layer

• Tools used: Cksm, ACK/NAK, seq numbers, timers

• Protocol retransmits lost segments


Lost Segment

Operation withno loss

Sender Receiver

send seg0rcv seg0send ACK0

rcv ACK0send seg1 rcv seg1

send ACK1

rcv seg0send ACK0

rcv ACK1send seg0

Sender Receiver


rcv ACK0send seg1

rcv seg1send ACK1

rcv seg0send ACK0

rcv ACK1send seg0

timeout

timeoutresend seg1

Sequence Numbers

Lost ACK

• Without sequence numbers, receiver doesn’t know if retransmitted segment is new data or old

• Lost ACK and Lost Segment are identical to sender

Sender Receiver


rcv ACK0send seg1

rcv seg1send ACK1

rcv seg0send ACK0

rcv ACK1send seg0

timeout

timeoutresend seg1

rcv seg1send ACK1

Sequence Numbers (2)

Premature Timeout

• Sender can’t distinguish first and second ACK1• Sequence number

indicates duplicate

• Sender waiting for ACK0• Does nothing on ACK1

Sender Receiver


rcv ACK0send seg1

rcv seg1send ACK1

rcv seg0send ACK0

rcv ACK1send seg0

timeout

timeoutresend seg1

rcv seg1send ACK1

rcv ACK1do nothing

Stop-and-wait has a problem

L = 1000B segmentR = 1.5MbpsRTT = 45 ms

Usender =L / R

=.0053

= 0.1059L / R + RTT .0503 Blech!

Sender Receiver

first segment bit transmitted, t=0

last segment bit transmitted, t = L / R

RTT

ACK arrives. First bit of next segment, t = RTT + L / R

first segment bit arrives

last segment bit arrives, send ACK

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 flight21

Pipelined Protocols• Pipelining: send multiple, “in-flight”, yet-

to-be-acknowledged segments

22

A stop-and-wait protocol A pipelined protocol

Data segmentData segments

ACK segments

Pipelining: Increased Utilization

23

Usender =3 x L / R

=0.016

= 0.317L / R + RTT .0503

Increased utilization by a factor of 3!

Sender Receiver

first segment bit transmitted, t=0

last segment bit transmitted, t = L / R

RTT

ACK arrives. First bit of next segment, t = RTT + L / R

first segment bit arrives

last segment bit arrives, send ACK

last bit of 2nd seg arrives, send ACK

last bit of 3rd seg arrives, send ACK





• Go-back-N (GBN)


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)


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 buffering

• Re-ACK seg with highest in-order seq#

27

• Sender variables: send_base, nextseqnum

• As segs are ACK’ed, window slides to right

• GBN is a sliding-window protocol

GBN: Windowsend_base nextseqnum

window size (N)

already ACK'ed

sent, not yet ACK'ed

usable, not yet sent not usable

• N = ?

• sendbase?

• next_seqnum?

GBN in Action

29

Sender Receiver

X

rcv seg0send ACK0

rcv seg3 (discard)send ACK1

rcv seg1send ACK1



rcv seg2 (deliver)send ACK2

rcv seg3 (deliver)send ACK3

send seg0

rcv ACK0send seg4

seg2 timeoutresend seg2

send seg1send seg2send seg3

rcv ACK1send seg5

wait

resend seg3resend seg4resend seg5

The Good, Bad, Ugly• GBN has minimal state at ends

• especially receiver

• Why discard segs received out-of-order?

• Don’t want to buffer them, going to be

re-sent anyway

• Ugly: A single segment error can cause many segments to be retransmitted

30





• Go-back-N (GBN)


31

Selective Repeat• Receiver individually ACKs all correctly

received segments

• Buffers 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: Windowssend_base nextseqnum

window size (N)

already ACK'ed


usable, not yet sent not usable

rcv_base

window size (N)

already received

acceptable (within window)

buffered and ACK'ed(out of order)

not usable

Sender

Receiver

A different view of the situation!

SR Details• Data from app-layer• if next_seqnum in window,

send segment, start timer

• else buffer• timeout (n)• resend seg n, restart timer

• ACK(n) in window• mark seg n as received• if n is smallest unACKed seg,

send_base = next unACKed seq#

• Seg(n) in receive window• send ACK(n)• if out-of-order: buffer• if in-order: deliver all buffered,

in-order segs and advance window to not-yet-received segment

• Seg(n) in [rcvbase-N, rcvbase-1]• send ACK(n)

• other pkt• ignore

Sender Receiver

SR at work Sender Receiver

X

seg0 sent0 1 2 3 4 5 6 7 0 1 2 3

seg1 sent0 1 2 3 4 5 6 7 0 1 2 3

seg2 sent0 1 2 3 4 5 6 7 0 1 2 3

seg3 sent0 1 2 3 4 5 6 7 0 1 2 3

(window full, wait)

ACK0 rcvd, seg4 sent0 1 2 3 4 5 6 7 1 2 3 4

ACK1 rcvd, seg5 sent0 1 2 3 4 5 6 7 2 3 4 5

seg2 timeout, seg2 resent0 1 2 3 4 5 6 7 2 3 4 5

ACK 3 rcvd, nothing sent0 1 2 3 4 5 6 7 2 3 4 5

seg0 rcvd, delivered, ACK0 sent0 1 2 3 4 5 6 7 8 91 2 3 4

seg1 rcvd, delivered, ACK1 sent0 1 2 3 4 5 6 7 8 92 3 4 5

seg3 rcvd, buffered, ACK3 sent0 1 2 3 4 5 6 7 8 92 3 4 5



seg2 rcvd, ACK2 sentseg2, seg3, seg4, seg5 delivered0 1 2 3 4 5 6 7 8 96 7 8 9

SR Issues• Both sides often have

varying view

• Ex: N=3 seq# 0,1,2,3

• Two scenarios

• Receiver side is same

• Will deliver duplicate

data in 1st case

• Seq# space is too small

0 1 2 3 0 1 20 1 20 1 2 3 0 1 21 2 3

0 1 2 3 0 1 22 3 0

0 1 2 3 0 1 23 0 1

0 1 2 3 0 1 20 1 2

0 1 2 3 0 1 20 1 2

0 1 2 3 0 1 20 1 2

seg0

seg1

seg2

timeoutretransmit seg0

seg0 receive segmentwith seq# 0

ACK0

ACK1

ACK2X

XX

seg3

0 1 2 3 0 1 20 1 20 1 2 3 0 1 21 2 3

0 1 2 3 0 1 22 3 0

0 1 2 3 0 1 23 0 1

0 1 2 3 0 1 20 1 2

0 1 2 3 0 1 20 1 2

0 1 2 3 0 1 22 3 0

seg0

seg1

seg2

seg0 receive segmentwith seq# 0

ACK0

ACK1

ACK2

X

0 1 2 3 0 1 21 2 3

• Seq# space (2k) must be at least twice as large as the window size

• Sender window and receiver window

must both fit in seq# space

Seq# space

m-w m-1

window (w)

already ACK'ed


not usable

m-w

window (w)

already received

acceptable (within window)

received and ACK'ed

m-1 m m+w-1

Sender

Receiver

Applets

• Play and experiment

• GBN and SR protocols

• plus others from rest of the course

• Available at textbook website:

• http://wps.pearsoned.com/

ecs_kurose_compnetw_6/216/55463/14198702.cw/content/index.html

Tools Summary

• ACK / NAK

• Provides feedback from receiver

• Can also get lost

39

Tools Summary (2)

• Retransmission Timer

• Detects loss (sent data or ACK / NAK)

• Allows for duplicate segments

40

Tools Summary (3)

• Sequence Numbers

• Allows detection of duplicate segments

• Have to be a bounded # bits

41

Tools Summary (4)

• Sliding windows

• Allow for reuse of sequence numbers

• Also allow for pipelining segments

• Some variety in how this tool is

deployed

42

Lesson Objectives• Now, you should be able to:

• describe the purpose, limitations and variations in

usage of each RDT tool—checksums, receiver feedback, retransmission, sequence numbers, timer expiration, window—as well as the network faults each is designed to overcome

• describe and analyze RDT protocols (including Stop-n-Wait, Go Back N & Selective Repeat) in order to show how each RDT tool is employed

• describe how changes to the employment scenario for a protocol affects the protocol design choices. An example is receiver-side buffering

43

Reliable Transport · Bill Nace. Administration •Stuﬀ is due •HW #1 was due 2 slides ago...

Documents

Transcript of Reliable Transport · Bill Nace. Administration •Stuﬀ is due •HW #1 was due 2 slides ago...