Data Link Layer

Sliding window

• Think the frames the sender has to send as a continuous stream. The window contains the current frame being sent and is not acked yet. Every ack (Expc) moves the window forward one frame.

Correctness Part is Done!

• So our Protocol 3 will work without causing errors. ARQ. (automatic repeat request)

• So the next step is the optimization.• Any one sees the problem?

Optimization

• Consider an example of – 500ms delay. 50kbps. Each frame is 1000 bits.

04/24/23 02:37 PM

Large link delays

• 500ms delay. 50kbps. Each frame is 1000 bits.• What is the link efficiency? • The time to send 1000 bits is

1000/50,000=20ms.• At time 520 ms, the receiver gets the entire

frame, and send ACK back. Assume ACK is small.

• At time 1020ms, the sender gets the ACK, and sends the next frame.

Solution

• So, increase the window size from 1 to n.• Would want to have a large window size

whenever the bandwidth delay product is large. – If bandwidth is large, sending is fast– If delay is large, even a moderate bandwidth will

cause a poor efficiency

04/24/23 02:37 PM

Question

• Given link speed and link delay, how large should the window be to achieve 100% efficiency?

04/24/23 02:37 PM

Question

• Given link speed and link delay, how large should the window be to achieve 100% efficiency?

• Basically, we want to be able to keep on sending till the last frame in the window right before the first ACK is back.

04/24/23 02:37 PM

Sender window

• The sender has a window from m+1 to m+n means that – the sender has received ack from the receiver for

frame up to m, – the sender is allowed to send m+1, m+2, …, m+n.

These packets can be outstanding without ack.• Sender has to maintain the sender window (buffering all

outstanding frames), maintain timeout for all outstanding frames.

• The size of the sender window is determined by the bandwidth and link delay

04/24/23 02:37 PM

Go-Back-N

• Let’s first consider the receiver’s window size is only 1.

• This is called Go-Back-N.

04/24/23 02:37 PM

Go-Back-N (Protocol 4)Sender. while (1) {

If network layer got data, if current window not full yet, read data, send to physical layer with the frame ID. Start timer. Increment frame ID by one.

If got ACKm, if m is outside the window, don’t do anything. If m is inside the window, consider all frames in the window with frame ID no more than the m acked. Forward window to m+1.

If timeout for frame m, start to resend all frames in the window with frame ID no less than m.

}Receiver while (1){

Wait to get data from the physical layer (blocked here until data got). After getting data: (1) If the data is with the expected frame ID m, give the frame to the network layer, increment the frame ID by one; (2) Send the ACK with the current frame ID.

} • Note: assuming the sequence number is the frame ID.

04/24/23 02:37 PM

Go-Back-N

• Two new things.– Cumulative ACK– Resend every frame after the timeout frame

04/24/23 02:37 PM

Go-Back-N

04/24/23 02:37 PM

Go-Back-N

• What if ACK is lost?

04/24/23 02:37 PM

Go-Back-N

• Works fine is error is rare. Achieves full capacity.

• Else wastes bandwidth.

04/24/23 02:37 PM

Sequence Number

• If the sequence number field is large enough, just use frame ID as sequence number.

• Else, how many bits do we need?

04/24/23 02:37 PM

Sequence number

• Using the sequence number is to make sure that the receiver can be sure that a received frame is not a duplicate of some other frames.

• Using finite number of bits means that some frames will have the same sequence number.

• So, should make sure that the receiver is sure that when a frame with seq#m is received, the sender has got ACK for all previous frames with the same seq#, so the sender cannot be sending an old frame.

04/24/23 02:37 PM

Sequence Number

• Say the sequence number field is 2 bits.• Will this be true if the window size is 4?• No, because the sender may send 0,1,2,3.

Then the receiver sends ACK0,1,2,3. If one of the ACK got through, the sender will send frame 4 with seq#0. If none of the ACK got through, the sender will send frame 0 with seq#0.

04/24/23 02:37 PM

Sequence number

• Solution?• Use window size less than 4. Say, 3. • Now, if the receiver gets frame 0,1,2, it sends

ACK0,1,2. Then, if it receives a frame with seq#0 again, will it be able to tell whether it is a new frame or a retransmission?

• Yes, because the receiver will accept frame with seq#3 first. It knows that if the sender sends seq#3, it must have got ack for frame 0.

04/24/23 02:37 PM

Protocol 5 – Selective Repeat

• Further optimization. – Receiver: has a window greater than 1. Don’t

discard frames simply because some earlier frames was damaged.

– Sender: if a frame times out, only retransmit that frame.

04/24/23 02:37 PM

Protocol 5 – Selective RepeatSender. while (1) {

If network layer got data, if current window not full yet, read data, send to physical layer with the frame ID. Start timer. Increment frame ID by one.

If got ACKm, if m is outside the window, don’t do anything. If m is inside the window, consider all frames in the window with frame ID no more than the m acked. Forward window to m+1.

If timeout for frame m, resend frame m.}

Receiver while (1) {

Wait (blocked here) and get frame from the physical layer. If it is within the receiver window and hasn’t been received before, fill in the slot, and forward the beginning of the receiver window if necessary, and deliver to the network layer all frames between the beginning of the old receiver window and the new receiver window – 1, inclusive. Send ACKm (m+1= the beginning of the current receiver window).

} • Note: assuming the sequence number is the frame ID.

04/24/23 02:37 PM

The Timer

• Each packet in the sender’s window should have a timer.

• If the window contains F0,F1,F2,F3. Could it happen that the when the timer for F0 expires, the timer for F1 has not expired yet? Yes, e.g., when you paused.

• Could it happen that the timer for F1 expires but the timer for F0 has not? Yes, if F0 has been retransmitted before.

04/24/23 02:37 PM

Sequence Number

• If the sequence number field is 3 bits, how large should the sender/receiver window be?

• Should the receiver have a different window size than the sender? No, larger --- makes no sense, the sender is not going to send that many outstanding frames, smaller --- wrong, because the receiver will discard such packets.

• Window size should be 4.

04/24/23 02:37 PM

Sequence Number

• Still, should make sure that the receiver is sure that when a frame with seq#m is received, the sender has got ACK for all previous frames with the same seq#, so the sender cannot be sending an old frame.

• At the receiver: For seq# 0 to be in my window again, I must have forwarded to frame 5. When I forwarded to frame 5, I must have got frame 4. I got frame 4 because the sender sent frame 4. The sender sent frame 4 only if it got ACK for frame 0.

04/24/23 02:37 PM

Sequence NumberA proof. • Let the sequence number be log2N bits. Let the window

size be W, where W<= N/2.• Suppose the receiver gets a frame with sequence

number m. He thinks it is for frame x. Could he actually receive frame x-N (with the same seq#)?

• No. Because when x is in the receiver’s window, his window has forwarded to x-W+1, at least. So he has got x-W. The sender has sent x-W. The sender will send x-W only if it has got ACK for x-2W+1. If W<= N/2, the sender must have got ACK for x-N.

04/24/23 02:37 PM

Piggybacking

• Considered only one direction. Bidirection.• Piggybacking– Combining ACK with data– When no data?• Wait some time and ACK anyway.

• Internet. PPP.

04/24/23 02:37 PM

Problem 1

• The link delay is 270ms. Each data frame is 1000 bits. Data rate is 1Mbps. What is the link efficiency of the Stop&Wait protocol?

Problem 1

• The link delay is 270ms. Each data frame is 1000 bits. Data rate is 1Mbps. What is the link efficiency of the Stop&Wait protocol?

• Answer. – Transmission delay: 1000/1000000 = 1ms.– The last bit of the frame reaches the receiver at

time 271ms. ACK is received at the sender at 541ms. In 541ms, 1ms is used to send data. Link efficiency is 1/541.

Problem 2

• Still the Stop&Wait protocol. The link length is 200m. Signal travels at a speed of 200000000m/s. The file is 1000000 bytes. The server divides the file into frames of 500 bytes. Data rate is 10Mbps. How long does it need for the server to send the entire file? (Assuming no frame loss.)

Problem 2• Still the Stop&Wait protocol. The link length is 200m.

Signal travels at a speed of 200000000m/s. The file is 1000000 bytes. The server divides the file into frames of 500 bytes. Data rate is 10Mbps. How long does it need for the server to send the entire file? (Assuming no frame loss.)

• Answer. – Transmission delay: 500*8/10000000 = 400us.– The propagation delay is 200/200000000 = 1us.– The last bit of the frame reaches the receiver at time

401us. ACK is received at the sender at 402us. Every 402us, a data frame can sent, hence the total time is 402*2000 = 804000us.

Problem 3

• Consider a link with propagation delay of 1ms and the transmission delay of 1ms. Assume Stop&Wait is used and assume that every one of four ACKs is lost. Assume the timeout the sender uses is 3ms, defined as the time to wait AFTER the last bit is sent. What is the link efficiency?

Problem 3 • Consider a link with propagation delay of 1ms and the

transmission delay of 1ms. Assume Stop&Wait is used and assume that every one of four ACKs is lost. Assume the timeout the sender uses is 3ms, defined as the time to wait AFTER the last bit is sent. What is the link efficiency?

• Answer. The first three frames are transmitted correctly using 3*3=9ms. At time 9ms (time starts at 0), the sender started to send the fourth frame. Because the ACK was lost, the sender will timeout and retransmit at 13ms. This time it will go through. So the efficiency is 3/13, that is, every 13ms, three frames will go through.