DATA LINK LAYER PROTOCOLS Stop and Wait PAR Go back n Select Repeat Project Report 02/25/99 Submitted to Submitted by Dr. Xin Yuan Gunjan Gupta Ryan G. Lane INTRODUCTION Purpose 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) Description Unreliable 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 WAIT Design and Implementation Assumption: 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. Performance The 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 STOP & WAIT SENDER START Get Packet from N/W Layer Create frame Send Frame Call from Physical Layer True If !Goodframe Layu e False: Get a good frame Only possibility is an ack for the One outstanding frame so loop Over. 5 STOP & WAIT RECEIVER START Call from Physical layer True If !Goodframe (timeout ) false: Get a Good frame. Only possibility is a good data frame Pass frame to N/W Layer Send Ack (empty frame) Back to sender 6 PAR Design 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. Performance The 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 PAR SENDER Get Packet from N/W Layer Create Frame Transit frame Call from Physical Layer if false Good Frame Received within timeout true if seq_nbr of ack=frame expected true correct ack f Get packet from n/w layer Increment seq_nbr circularly 8 PAR RECEIVER Call from Physical Layer If true NOFRAME function timeout keep trying until a frame false : Got a frame arrives If GOODFRAME true false badframe false If Seq_nbr= Frame expected true Pass packet to N/W Layer Circularly increment frame expected Send ack for last correct frame received 9 SLIDING WINDOW: Go Back N Design 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. Performance The 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 40% 40% 40% 10% 10% 10% Timeout Value 10 8 12 10 12 16 Number of frames sent 1867 1970 2097 617 613 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 Go Back N SENDER False If Empty buffers True available Get packet from n/w layer & store in buffer Create frame Transmit frame Set Logical Timer Circularly increment next seq_nbr to send SLIDE UB of window Call from Physical layer 12 A B false If Goodframe true If ack false Received is In window True Decrement no. of buffers used Re-set logical timer Circularly increment ack # expected(slide LB of the window) Update Logical timers Clear all previous un-acked Frames upto the ack received E A False If Timeout true Create frame from timed out packet C D 13 A D C Retransmit frame Reset logical timer If all Frames updated true false E 14 Go Back N RECEIVER Call from Physical Layer true if noframe false if false goodframe true bad frame received true Pass packet to n/w layer Update the last record variable Circularly increment the next seq_nbr expected if seq_nbr= frame expected false 15 C D B A false If Last_received var <=MAX_SEQ True Create ack_frame for last_received. Sqr_nbr Transmit ack frame 16 SLIDING WINDOW: Selective Repeat Design 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. Performance The 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 65% 65% 10% 10% Timeout Value 15 25 15 25 Number of frames sent 6801 6009 303 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 SELECTIVE REPEAT SENDER False If empty buffers available true Get Packet from n/w layer And store in buffer Increment the buffers in use Create frame Set logical timer Circularly increment next seq_nbr to send, Slide UB Call from_physical layer 19 false If Goodframe true Recd. if frame is An ack if ack_recd no. false is in window false true false if frame is a nak true if nak is in curr window false true Create frame from buffer for Required seq_nbr Retransmit frame Reset logical timer Update logical timer B Decrement # of buffers used Reset logical timers Circularly increment Ack # expected (slide LB of the window 20 B If False Timed out true Create frame from timed out packet Retransmit timed out frame only Reset logical timers If All timers Updated true false 21 SELECTIVE REPEAT RECEIVER Call from Physical Layer True false If No nak sent yet Create nak frame For seq_nbr wanted Transmit nak frame If false Noframe false if goodframe True if seq!= seq_nbr false expected AND no_nak sent yet true Create nak frame for seq_nbr wanted Transmit nak frame Flag to send ack 22 If the seq # is in curr. Window & the correct buffer slot is empty Flag position as full Store packet from buffer in frame 23 False false If buffer Slot for expected Seq# is full true Pass packet for that slot to n/w Layer If Flagged true To send An ack Flag to send ack Create an ack frame for last in seq frame received Transmit the ack frame Unflag send ack Reset buffer position as empty Circularly increase too_far variable (slide the UB of window 24 PROBLEMS IN IMPLEMENTATION (Bugs resolved) PROTOCOL: Stop and Wait PROBLEM : None encountered PROTOCOL: PAR PROBLEM : None encountered PROTOCOL: Go Back N PROBLEM : 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 N PROBLEM : 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. 25 PROTOCOL: Selective Repeat PROBLEM : 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 Repeat PROBLEM : 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. 26 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. 27