DATA LINK LAYER PROTOCOLS

Stop and WaitPAR

Go back nSelect Repeat

Project Report02/25/99

Submitted to Submitted by

Dr. Xin Yuan Gunjan Gupta Ryan G. Lane

INTRODUCTIONPurpose of the Project Exercising the flow control and error control techniques in data link layer protocols. (Major) Getting familiar with the TCP/IP programming. (Minor)

DescriptionUnreliable physical layer channel emulator has been provided. The task in the project is to build reliable, efficient, connection oriented services on top of the unreliable physical layer by incorporating flow control and error control techniques in data link layer protocols. Four data link layer protocols have been implemented in this project, Stop and Wait, PAR, Go back n(sliding window) and select repeat(sliding window) The sender program only sends data frames and receives acknowledgements and receiver program only receives data frames and sends acknowledgements. So simplex communication channels are assumed.

3

STOP AND WAITDesign and ImplementationAssumption: Error free communication channel The sender in this protocol simply retrieves a packet from the network layer, copies it into a frame, and then transmits it. After transmission, the sender busy waits until an acknowledgement is received from the receiver, then the loop starts over again.

The receiver simply busy waits until a frame is received. Once a frame is received it passes the data packet to the network layer and sends an acknowledgement for the frame it just received. It then loops back to busy waiting and the process continues until the End of File is reached.

In this protocol, there can only be one outstanding frame at a time so no sequence numbers are required and the acknowledgement the receiver sends back to the sender is nothing more than an empty frame, as there is no other possibility then acknowledging the only frame sent. Another frame will not be sent until this acknowledgement is received.

PerformanceThe Stop and Wait protocol was very easy to implement and runs very quickly and efficiently. It

solves the problem of congestion, as only one frame is outstanding at any time, frames cannot be lost due to congestion and the receiver will not be swamped by the sender.

Point of failure The problem with it is that it assumes an error free communication channel and in the real world, such a channel does not exist. It is easy to see that if a frame or an acknowledgement gets lost or damaged, a deadlock situation will occur where neither the sender or receiver can advance, and they will be thrown into infinite loops.

4

5

6

PARDesign and Implementation

The Positive Acknowledgement with Retransmission protocol (PAR) is an improvement on the Stop and Wait protocol. The sender retrieves a packet from the network layer, copies it into a frame with a sequence number, and then transmits it. After transmission, the sender attempts to retrieve an acknowledgement from the physical layer. If an acknowledgement arrives with the correct sequence number (of the next frame to send), another packet to send is retrieved, the sequence number to send next is updated, and the loop starts over. If no frame is retrieved before the function call to the physical layer times out or an acknowledgement with an incorrect sequence number arrives, then the last frame sent is retransmitted, and the loop starts over.

The receiver busy waits until ANY frame is received by the physical layer. When a frame is received, the sequence number is checked: if it is the frame expected, then the data packet is passed to the network layer, the next sequence number expected is changed, and an acknowledgement for the frame is sent to the sender for the sequence number just received. If a BADFRAME or out of sequence frame arrives, then an acknowledgement for the last correct in sequence frame is retransmitted to the sender.

Although in this protocol there is still only one outstanding frame at a time, a sequence number must be used to determine if any frames are lost or damaged. Since there is only one outstanding frame at a time, and the sequence number does not advance until a positive acknowledgement is received, only two sequence numbers are needed (it CANNOT change to the other sequence number until the correct one is received). The protocol simply uses ‘1’ and ‘0’ as sequence numbers. The acknowledgement frame sent back is marked as an acknowledgement frame and contains the sequence number being acknowledged.

PerformanceThe Positive Acknowledgement with Retransmission protocol was again fairly simply to

implement. A circular increment function was written to allow incrementing the sequence numbers in a circular fashion. This approach of using sequence numbers and transmitting an acknowledgement for the correct in sequence frame received keeps the sender and receiver synchronized with each other. The protocol also handles congestion, lost frames, and bad frames, as data frames will be re-sent until a positive acknowledgement is received. The main problem with this protocol is that it is very inefficient. As frames and acknowledgements are lost and have to be retransmitted, the number of frames sent to transfer the entire message correctly becomes very large. For example, at 65% error rates on all channels in the simulator, over 6,000 data frames and over 2,000 acknowledgement frames had to be sent just for the message of 221 packets to be received correctly. At smaller error rates, the retransmissions were not quite as bad but still about 50% more frames than the actual message had to be sent. At 10% error rates on all channels around 300 data frames and about 275 acknowledgement frames had to be sent.

This is a loss in terms of bandwidth and time.

7

8

9

SLIDING WINDOW: Go Back NDesign and Implementation

The Go Back N protocol improves on PAR by allowing the sender to have more than one outstanding frame at a time by using buffers. The sender maintains a buffer of a predetermined size. If there is room in the buffer it gets a packet, stores it in the correct empty slot (seq_nr%WINDOWSIZE), creates a frame with the correct seq_nr and transmits it. The corresponding logical timer is then reset to 0. The Upper Bound of the window is then slid up by circularly incrementing the next_frame_to_send.

At this point or if no buffers are empty, the physical layer is checked to see if an acknowledgement is there. If a goodframe is received and the acknowledgement number is within the current window then decrement the number of buffers used, reset the logical timer (to a negative value) to indicate an unused slot, and slide the Lower Bound of the window by circularly incrementing the acknowledgement number expected. This procedure runs in a loop until ack_expected equals ack_received (this clears the ack_received and the previous frames that haven’t been acknowledged yet).

After this, or if a bad frame or out of window frame arrives, the logical timers are updated. If a frame is timed out, it’s retransmitted and the timer is reset to 0. In this fashion if a frame is timed out because it was lost, no acknowledgement will arrive. So on the next iteration of the loop, the next frame will time out and will be re-sent. Thus the timed out frame and all the subsequent frames will be retransmitted, which is the definition of Go Back N.

The receiver busy waits until a frame arrives. If a badframe arrives, it goes back to busy waiting. If a good frame arrives, it checks the sequence number, if its not the sequence number expected it resends an ack for the last correct sequence number received. If it’s the sequence number expected, it passes the packet to the Network layer, updates the last correct sequence number received variable and circularly increments the next sequence number expected variable. An acknowledgement is then created and transmitted for it and then it loops back to the physical layer to retrieve the next frame..

The buffer consists of an array of packets. The size of this array in the implementation is 4, originally an array of size 8 was used but this resulted in problems. Then a buffer size of 4 was used with sequence numbers 0-3, which still caused problems. Dr. Yuan instructed the class to use a Window size of 4 and sequence numbers larger than the window. This implementation uses sequence numbers 0-7, as that’s what the textbook 1 used and the smaller range of numbers is easier to work with. The Lower Bound of the window is represented by the ack_expected and the Upper Bound by the next_frame_to_send.

The logical timer consists of an array of integers. When the value is negative the corresponding slot in the buffer is unused. Anytime after checking the physical layer a loop is run that increments the timers of all the used slots by one, it simultaneously checks if any of the timer values has reached the threshold (which is the timeout time). The value stored in the logical timer corresponding to a buffer slot is the number of times the buffered packet has iterated in the while loop.

The Main Loop consists of the while loop that gets and sends packets and checks for acknowledgements. Another loop loads all empty slots in the buffer with new packets. The acknowledgement loop clears all previous unacknowledged frames up to the acknowledgment received. The timer loop updates the timers and checks for the timeouts and retransmits.

The receiver’s Main Loop checks for frames received in the physical layer. If a frame is received then an acknowledgement is sent for the last correct in sequence frame received.

PerformanceThe Go Back N protocol is fairly tricky to implement. If the window size matches the range of

sequence numbers the protocol can break and implementation is extremely difficult. By using the range of sequence numbers greater than the window size, the receiver and the sender can be kept in synchronization even when frames and acknowledgements are lost at high rate. The Protocol easily handles congestion errors, bad frames and lost frames. Most difficult part was trying to find the optimum timeout value that provided efficient transmission for all error rates. Smaller timeout value seemed better on higher error rates

1 Computer Networks (third edition) by Andrew S Tannenbaum Upper Saddle River, NJ: Prentice Hall, 1996

10

but to optimize at lower error rates a slightly higher value of timeout was selected. For e.g., at 40% error rates on all channels, timeout value of 10 provided the best result. By going slightly lower at 8 the number of frames that had to be transmitted increased. By going slightly higher at 12, number of frames transmitted increased more rapidly.

Sample Test Results

Error Rate Timeout Value Number of frames sent40% 10 186740% 8 197040% 12 209710% 10 61710% 12 61310% 16 662

Overall a timeout of 15 was found to be the best compromise to provide efficiency over the widest

range of error rates and over the varying loads on the simulating system (performance at different times in a day). For the timeout parameter in the from_physical_layer() function call a value of 100,000 was passed which worked well for the entire range of error rates.

The high number of frames retransmitted means waste in terms of Bandwidth and a longer time to complete the transmission. This is because for every lost frame all the frames transmitted after that frame are retransmitted.

11

12

13

14

15

16

SLIDING WINDOW: Selective RepeatDesign and Implementation The SelectiveRepeat protocol improves on the Go Back N protocol by having buffers on both the sending and receiving sides. This allows the sender to have more than one outstanding frame at a time and receiver to accept out of order frames and store them in its window. Sender for Selective Repeat is only slightly modified from that for Go Back N .The Maintenance of buffers and logical timers is exactly the same. The only difference is that if a negative acknowledgement is received, the sender retransmits the corresponding frame identified by the nak. Other than this timeouts, loop iterations and retransmissions are all the same as Go Back N . This differs from Go Back N in that it retransmits only the frame for which a nak is received and not all subsequent frames. As the receiver keeps a window of frames only the timed out frame needs to be retransmitted and not the whole series.

The receiver busy waits until a frame arrives. If a timeout occurs or if a badframe arrives, or if an out of sequence frame arrives, and a nak has not been sent yet then a nak is sent for the expected sequence number. If there is room in the receiver’s buffer a packet is stored in the correct slot (sequence number%WINDOWSIZE) and the slot is flagged as used. Loop is ran starting at buffer slot for expected sequence number. If this slot is full the packet is passed to the network layer, a flag is set to send an acknowledgement, buffer slot is reset to empty, the upper bound of the window is increased, and the lower bound (frame_expected) is circularly incremented. It then loops back to check the buffer slot for expected sequence number. The loop continues till the expected slot is empty. In this manner all buffered packets are passed to the network layer in order. If the flag that indicates whether an acknowledgement has to be sent or not (send_ack) is set then an acknowledgement is sent for the last correct in sequence frame received. Then we go back to the main busy waiting loop and start over again.

The buffers on both ends consist of arrays of packets. The size of these arrays is 4, the range of sequence numbers used is 0-7. The selection criteria were the same as that used for Go Back N . The sender window’s Lower Bound is represented by the ack_expected and the Upper Bound by the next_frame_to_send. The receiver window’s Lower Bound is represented by frame_expected and the Upper Bound by too_far. The Logical Timers are implemented in the same fashion as Go Back N .

Main loop in the sender consists of while loop that gets and sends packets then checks for acknowledgements and other loop loads empty slots in the buffer with new packets. The acknowledgement loop clears all previous unacknowledged frames up to the acknowledgement received. If the frame is a nak instead of entering the loop it retransmits the requested frame. Timer loop updates the timers and checks for timeouts to retransmit.

Main Loop in the receiver consists of a busy wait loop to retrieve frames from the physical layer. Data transfer loop passes buffered packets in order to the network layer when the correct in sequence frame is received. Timeouts and badframes result in naks being sent. Otherwise an acknowledgement is sent for the last correct in sequence frame received. This is necessary to keep the sender and receiver in synchronization when frames and acknowledgements are lost.

PerformanceThe Selective Repeat protocol was difficult to implement. The sequence numbers need to be

greater than the window size so that no overlap can occur in the window. This allows receiver and sender to be kept in synchronization even when frames and acknowledgements are lost at a very high rate. The buffering and acknowledgements allow this protocol to easily handle congestion, bad frames and lost frames. It was found that a much higher timeout value is needed than in Go Back N in order to reduce the number of frames sent. A lower timeout value results in too many frames timing out and being retransmitted unnecessarily, since the receiver maintains a buffer of frames and can send a nak for exactly the frame sequence number it needs. We have chosen 25 as a timeout value, and kept the from_physical_layer parameter to 100,000 because these two values worked the best for a wide range of error rates.

17

Sample Test Results

Error Rate Timeout Value Number of frames sent65% 15 680165% 25 600910% 15 30310% 25 287

Overall this protocol made considerably better use of bandwidth and time than Go Back N. There are about 25% fewer frames sent than Go Back N. Approximately 10% fewer frames had to be sent as compared to PAR. This was the most efficient protocol amongst the ones implemented for this project.

18

19

20

21

22

23

24

25

26

PROBLEMS IN IMPLEMENTATION(Bugs resolved)

PROTOCOL: Stop and WaitPROBLEM : None encountered

PROTOCOL: PARPROBLEM : None encountered

PROTOCOL: Go Back NPROBLEM : Out put file was jumbled

First implementation of Go Back N resulted in an out of sequence output file. The cause of this problem was determined to be not sending enough acknowledgements to the sender. Initially, acknowledgements were only sent when an in sequence good frame was received, so lost frames and bad frames resulted in the sender and receiver getting out of synchronization with each other. This problem was resolved by always sending an acknowledgement for the last in sequence frame received (so even if an out of sequence frame is received, an acknowledgement is sent for the last in sequence frame received). This correction resolved the problem effectively.

PROTOCOL: Go Back NPROBLEM : Infinite loop

At some error rates (16%-20%) the protocol hung up in an infinite loop, while it worked fine for other error rates. On examining the code it was determined that this problem resulted from improper variable initialization. On these certain error rates the pseudo-random number generator caused the very first frame sent to be lost or damaged. The receiver used a variable to keep track of the last in sequence frame received. This was erroneously initialized to 0. Therefore if the first frame got lost (sequence no 0), when the receiver received the second frame (sequence number 1) it sent an acknowledgment for the last in sequence frame received, which had been initialized to 0. Therefore the sender received an acknowledgement for sequence number 0 and moved its window up accordingly. It caused everything to get out of synch, and caused the protocol to go into infinite loop. This was resolved by initializing the variable to remember the last in sequence frame received to an out of range sequence number (MAX_SEQ+1). If the remember variable is out of range then no acknowledgement is sent. This fixed the problem.

27

PROTOCOL: Selective RepeatPROBLEM : Infinite Loop

Sometimes the initial implementation hung up in an infinite loop. On examining the state while both the receiver and sender were running it was determined that they were out of synchronization. For e.g. sender’s window would be 0-3 with 4 as next sequence number to send and receiver’s window would 4-7 with 0 as too_far. Therefore the windows didn’t match and anything sent was discarded and neither could progress in this deadlock situation. The cause of this was that the acknowledgements weren’t always being sent. For e.g. if the frame received was not the expected sequence number and a nak had already been sent, nothing was being sent to the sender to let him know the status of the receiver. Therefore the code was changed to either send a nak or an acknowledgement for the last in sequence frame received. These acknowledgements were used by the sender to resynchronize to the receiver’s current status. We changed the timeout period in the sender to a larger value to reduce the total number of frames sent, due to all the extra acknowledgements. This remedied the situation.

PROTOCOL: Selective RepeatPROBLEM : Excessive Number of Frames Sent

Another problem encountered with Selective Repeat was that a very large number of frames were being transmitted which caused the performance to be worse than PAR. The cause of this error was that after sending a nak when a bad frame was received, the nak flag variable was not being set to 0. This caused many naks to be transmitted to the receiver instead of just one. Therefore the sender was transmitting more frames than necessary when these naks were received, while acknowledgements were being sent and responded to also. By setting the nak flag to 0 after sending the initial nak for a bad frame, and increasing the sender’s timeout value, the protocol was made more efficient with less frames having to be retransmitted. This improved the protocol’s performance and made more efficient use of bandwidth.

28

CONCLUSION

In conclusion, Stop and Wait protocol is easiest to implement and worked very efficiently, however it is not realistic as it assumes an error free communication channel. PAR was easy to implement too, and it worked very reliably. It was a good tradeoff between the ease of implementation and the loss in Bandwidth(the number of frames retransmitted). Overall efficiency wasn’t too bad compared to the other protocols.

Go Back N protocol required more input in terms of implementation due to buffer maintenance and keeping sender and receiver in synchronization. This protocol is the most inefficient amongst the 4 due to the large number of frames it retransmits. Whenever a frame is lost instead of retransmitting the frame it retransmits all subsequent frames also which wastes Bandwidth.

Selective Repeat only took slight modification over Go Back N and produced far more efficient results in terms of the no. of retransmissions, as it retransmits only one frames instead of the entire series. It also had better performance than PAR. So overall in a communication channel with errors Selective Repeat would be a better choice, whereas if the ease of implementation is the main selection criterion then PAR would still provide fairly acceptable results.

29