Data Link Layer Data link layer protocols Assume

Data Link Layer

Data link layer protocols • Assume that the physical layer, the data link layer, and the network layer are three processes and communicate with each other. • Assume that the sender always has enough data to send. • Assume that the machines don’t crash. • Assume that the data flows only one direction (simplex).

Protocol 1. • Your protocol really depends on the world you live in. • If (1) the link never screws up your bits, and (2) the receiver’s network layer process reads the bits infinitely fast, what should be your protocol?

Protocol 1 • Sender. 1. Grab data from the network layer. 2. Send to physical layer. Goto 1. • Receiver 1. Get data from the physical layer 2. Give it to the network layer. Goto 1.

Protocol 2 • Now remove assumption (2). The receiver’s network layer process is not infinitely fast. How to design the protocol?

Protocol 2 • The receiver must provide some kind of acknowledgements. If the receiver never tells the sender anything, the sender has no way of knowing whether this speed is too high or too low. • The simplest form of ack is the receiver sends back an ack every time he receives a frame. • The sender waits for this ack to start sending the next frame. • Called “stop and wait. ”

Protocol 2 • Sender. 1. Grab data from the network layer. 2. Send to physical layer 3. Wait for ack. Goto 1. • Receiver 1. Get data from the physical layer 2. Give it to the network layer 3. Send ack. Goto 1.

Protocol 3 • Now, let’s remove assumption (1). There is now noise in the channel and frames could be corrupted. Both the data frame and the ack frame. • How to design your protocol? What are the considerations?

Protocol 3 • So we can add a timer. If the sender does not receive the ack before the timer expires, he knows something is wrong and resend this frame. • How long should the timer be set? • Problems?

Protocol 3 • A sent B frame F. • B received the frame. Sent ack to A. Ack got lost. • A time out. Resend F. • B received F. AGAIN!

Sequence Number • Every frame has a sequence number. • Sender says I am sending the frame with sequence number m. • Receiver acks saying that I have successfully received the frame with sequence number m, please send me frame with sequence number m+1. • This will solve the duplication problem. Why?

Protocol 3 • Sender. 1. Grab data from the network layer. 2. Send to physical layer with the current sequence number m and start timer. 3. Wait for ACK. • • If got an ACKm+1, m: =m+1, repeat 1. Else, timeout, repeat 2. • Receiver 1. Get data from the physical layer 2. If it is with the expected sequence number m, give it to the network layer, m: =m+1. 3. send ACKm (expecting m). Goto 1.

Protocol 3 • Question 1. After sends frame m, will he receive Expc for lower than m? Will it receive Expc higher than m+1?

Protocol 3 • Answer. No. Because when sender sent frame m, he must have received Expc from the receiver of m. Receiver keeps the sequence number and won’t decrease it. And it will not receiver Expc higher than m+1, because m+1 has not been sent yet.

Protocol 3 • Question 2. After sending out an Expc of m+1, what are the possible frames the receiver can receive?

Protocol 3 • Answer. The only possible frames he could receive is m or m+1. • In what case he receives m? (ACKm gets lost) In what case he receives m+1 (when everything goes fine)? Why can’t he receive m -1 (Because when sender sends m, he knows that m-1 is received correctly. )? Why can’t he receive m+2 (because sender won’t send m+2 before the receiver sends ACKm+1)?

Protocol 3 • Question 3. How many bits should the sequence number have?

Protocol 3 • Answer. 1 bit. At any time, there are only two possible frames both for the sender and the receiver.

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?

Large link delays • 500 ms delay. 50 kbps. Each frame is 1000 bits. • What is the link efficiency? • The time to send 1000 bits is 1000/50, 000=20 ms. • At time 520 ms, the receiver gets the entire frame, and send ACK back. Assume ACK is small. • At time 1020 ms, the sender gets the ACK, and sends the next frame.

Solution • So, increase the window size from 1 to n. • Would want to do this whenever the bandwidth delay product is large. • Go-back –N • Selective-repeat