1 reliable data transfer. 2 r problem: reliability want an abstraction of a reliable link even...

48
1 Reliable Data Transfer

Post on 22-Dec-2015

215 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

1

Reliable Data Transfer

Page 2: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 3: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

3

Themes

Principles for Reliable transfer Protocols as State machines More Pipelining

Protocols ABP, Go-back N, Selective repeat

Page 4: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

4

Principles of Reliable data transfer

important in app, transport, link layers top-10 list of important networking topics!

Page 5: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

5

Reliable data transfer: getting started

sendside

receiveside

rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer

udt_send(): called by rdt,to transfer packet over unreliable channel to

receiver

rdt_rcv(): called when packet arrives on rcv-side of channel

deliver_data(): called by rdt to deliver data to

upper

Page 6: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

6

Reliable data transfer: getting started

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)

Page 7: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 8: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

8

Controlling the Flow of Data

Slow JoeFast Frank

Page 9: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 10: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 11: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

11

Flow control in the ideal network (cont’d)

Slow JoeFast Frank

Infinite bucket

Page 12: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 13: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

13

stop-and-wait operation

first packet bit transmitted, t = 0

sender receiver

RTT

last packet bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

Page 14: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

14

Performance of stop and wait

example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:

Ttransmit

= 8kb/pkt10**9 b/sec

= 8 microsec

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!

U sender

= .008

30.008 = 0.00027

microseconds

L / R

RTT + L / R =

L (packet length in bits)R (transmission rate, bps)

=

Page 15: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

15

Stop and Wait with Noiseless Channels (cont’d)

Slow JoeFast Frank

Finite bucket (once full, ball is lost)

Page 16: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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)

Page 17: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

17

Stop and Wait with Noiseless Channels (cont’d)

Data

ACK

Data

Page 18: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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.

Page 19: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 20: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 21: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

21

Loss of an ACK frame

ACK

Data

error

?

Page 22: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 23: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

23

Duplicated data frames

Data

ACK

Data

TimedOut

Duplicate data

Page 24: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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.

Page 25: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

25

Stop and Wait for Noisy Channels (cont’d)

Data

ACK

Data1

1

11

TimedOut

receiverknows to discard thisdata

1

Page 26: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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 time2. When waiting for an acknowledgement, the sender

cannot transmit any frames

Better solution? Sliding Window

Page 27: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

27

Pipelined protocols

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

Page 28: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 29: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

29

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

0

1

2

34

5

6

7

Page 30: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

30

Sliding Window example

0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7

0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7

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

Page 31: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

31

Simple Sliding Window withWindow size 1 (cont’d)

This protocol behaves identically to stop and wait for a noisy channel

Page 32: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 33: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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.

Page 34: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 35: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

35

Sender-Side Window with WS=2

0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7

0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7

(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

Page 36: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

36

PipeliningSliding window with WS > 1 is also called “pipelined” communication

A B99

data stream51 50

4910

ACK stream

By allowing several frames onto the link before receiving an acknowledgement, pipelining keeps the link from

being idle

Page 37: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

37

Pipelining Example: increased utilization

first packet bit transmitted, t = 0

sender receiver

RTT

last bit transmitted, t = L / R

first packet bit arriveslast packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

U sender

= .024

30.008 = 0.0008

microseconds

3 * L / R

RTT + L / R =

Increase utilizationby a factor of 3!

Page 38: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 39: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

39

Receiver-Side Window with WR=2

0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7

0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7 0

1

2

34

5

6

7

(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

Page 40: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 41: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

41

Pipelined protocols - how?

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

Page 42: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 43: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

43

Go Back N

Discarded byreceiver

Frame witherror

Timeout interval

AC

K 0

Time

Sender

Receiver

Maximumwindow size = 8

Maximumwindow size = 8

0

0 1

1

AC

K 1

2

E

3

D

4

D

2 3

2

AC

K 2

4 5 6

3 4 5

AC

K 3

AC

K 4

AC

K 5

6

AC

K 6

Page 44: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

44

Go-Back-N

Sender: k-bit seq # in pkt header “window” of up to N, consecutive unack’ed pkts allowed

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

Page 45: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

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

Page 46: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

46

Sliding Window with Selective RepeatThe 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.

Page 47: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

47

Selective Repeat

Buffered byreceiver

Frame witherror

Timeout interval

AC

K 0

Time

Sender

Receiver

Maximumwindow size = 8

Maximumwindow size = 8

0

0 1

1

AC

K 1

2

E

3 4 2 5

2

AC

K 4

6

5

AC

K 5

6

AC

K 6

3 4A

CK

1

AC

K 1

Page 48: 1 Reliable Data Transfer. 2 r Problem: Reliability  Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

48

Selective repeat: sender, receiver windows