Download STOP AND WAIT

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