Stop-and-Wait Flow and Error Control Protocol Simulation and Analysis

Submitted by

Suparerk Manitpornsut and Phoom Sagetong

625-02-4952 889-30-4076
Electrical Engineering, University of Southern California
Los Angeles, CA 90089-2564
Email: {manitpor, sagetong }@scf.usc.edu

To

Dr. Christos Kolias

University of Southern California
Los Angeles, CA 90089-2564
Email: kolias@usc.edu

August 5, 1999

Abstract

Stop-and-Wait Protocol provides a reliable transmission over a link with the efficiency of protocol
measured by average link utilization. This alternating-bit protocol is performed to approach this
scheme. In this report, The simulation of this protocol is implemented. Description of each
module and its procedure are explained in details. Experiment results that file size has no effect
to system efficiency (when other parameters are fixed), while the larger the packet size, the
better the average link utilization. Discussion of experiment is given as intuitive explanation.

1. Approach
Stop-and-Wait flow and error control protocol is implemented in C++ compiled by Visual C++
6.0. In this simulation, several assumptions are made. For instance, processing times for data
frame and ACK as well as ACK transmission time are ignored. Each slotted time is equal to frame
transmission time (i.e., transmission time is equal to “1” slot) and propagation delay is an
integral number of time slots which is equal to “2” slots in this simulation. ACK are always error-
free. Datalink Class is used to be the main structure of this simulation. There are several
functions (using for this protocol simulation) explained below in section 1.1 as well as how it
works in section 1.2.

1.1 Function
DataLink() and ~DataLink() are considered as the constructor and destructor, respectively.
SendFrame() performs an encapsulation of data with header, length, sequence number and
checksum as well as sends a frame into a channel. It is worth to note that temporary spool file is
considered as the communication channel. ReceiverFrame() extracts a frame from a channel and
performs decapsulation to obtain each information field from a frame. Checksum is also
performed in this function to make a decision of Acknowledgement (ACK) or Negative
Acknowledgment (NACK) needed for requesting of next frame transmission or retransmission of
previous frame, respectively. SendAck(), at destination, is for submission of a requested
sequence number for next frame into a channel. (i.e., the same as previous in case of existence
recovery of an error at destination and next sequence number for uncorrupted delivery) In the
other side, ReceiveAck(), at source, is for extracting an acknowledgement from a channel, sent
by destination. CheckSum() is as its name for computation of checksum algorithm. This algorithm
works on 16-bit integer by adding all words together using 16-bit ones complement arithmetic
and then taking the ones complement of obtained result, this is finally a checksum ! Error() is for
randomly introducing an error into a system (when probability that error occurs is 0.2) by
random function from C++ library.

1.2 Procedure
Input file, DataFile.txt, is first segmented into fragments considered as data field. Header with
any useful information, length of the data field, frame sequence number, which is 0 or 1, and
checksum computed from data field are appended to data field to be combined into a frame (i.e.,
encapsulation of data field). This frame is then transmitted into a channel, spool.txt. Destination
receives a frame from a channel and extracts each field out. Received data field is resorted to
check for existence of error by the computed checksum from itself and compared with the
received checksum. In case of error, receiver drops this damaged frame and requests for
retransmission of previous frame by transmitting ACK with damaged-frame sequence number.
While, for correct reception, the data field is decided to append into a final file at destination and
transmission of ACK with next sequence number is performed. For either case, source receives
the ACK from a channel and decides that it needs to retransmit the previous frame or it can send
the next one, by considering the sequence number that destination request to transmit next in
ACK frame. Repeat the same cycle until every frame is correctly received at destination. Then,
finally, destination assembles all pieces of data into one file, dest.txt, which is identical to the
original file. For monitoring, SW.log, is the log file for a simulation of this protocol as well as
provides the average utilization of system.

2. Experimental result and discussion

Efficiency of protocol is measured as utilization. This value is the ratio of time to send useful data
over time to send total data, transmitted in a single cycle, until the next new frame is sent out.
Note that the useful data is pure data field that is sent over a channel excluding header, while
the total data is entire data including all header and retransmissions in a single cycle. Utilization
is statistically collected from each case of different packet sizes and file sizes to see an effect of
this variable to system performance. Each case is running for ten times and takes average to be
statistical data for discussion. Table 1 represents average utilization for different file size and
packet size.

File Size ( Bytes )

Packet Size ( Bytes )
10K 20K 50K 100K
500 0.1571 0.1603 0.1616 0.1622
1000 0.1706 0.1619 0.1631 0.1630
1500 0.1763 0.1680 0.1674 0.1632
2000 0.1814 0.1735 0.1702 0.1653

Table 1: average utilization

From statistical results in a table, for fixed file size, increasing of packet size means decreasing
number of frames. That means we need smaller number of frame to complete the entire
transmission, which leads to a smaller entire number of fixed-size headers also. Intuitively,
source takes less time (not for each transmission time point of view, but overall time for
completing of operation) to waste in waiting for an acknowledgement from destination.
Therefore, it implied that link efficiency is higher. In other words, because fixed-size header is
used no matter what data size is, that means, for less number of frames, less waste of
bandwidth becomes because total header using to complete the operation is smaller which
results in decreasing the system utilization. Mathematically, from formula in class note, if frame
data size approaches infinity, utilization approaches one, which means a perfect utilization of
channel.

However, if timing is taking into account (which is not in this project), the longer the packet size,
the longer time needed to use for processing time, especially checksum algorithm. It results in
longer delay between source and destination then. Furthermore, when error rate is high, several
retransmission processes are needed and processing time is totally increasing as well. Hence, if
packet size is too small, utilization is decreasing because more number of frames is needed which
leads to more total header. However, in the other way, if packet size is too large, utilization is
also worse because transmission time is also dominated to make roundtrip delay much higher. As
mentioned before, error rate also needs to be considered as well. Therefore, packet size should
be carefully chosen to make system works at optimal operate point which yields maximum
system utilization. More realistic simulation can be obtained if number of slots represented
transmission time can be set dependently to the packet size.

For fixed packet size, there is no effect to system utilization because, in stop-and-wait algorithm,
source is able to send only one frame at that time and idle in waiting for acknowledgement from
destination. Intuitively, if required number of frame is increasing while size of data is fixed (i.e.,
fixed frame size) and with the fact that all header size is fixed, that means it is a matter about
scaling. Therefore, for a measurement in terms of ratio, this implies that the scaling is cancelled,
which leads to be approximately equality of utilization in averaging sense. However, obviously,
for large file size, complexity of system is dramatically increasing which results in more loading of
system environment because system needs to process larger information and then this takes
longer time to completely finish a transmission of entire message from source to destination. In
the other point of view, increasing a file size will make utilization better in networking view
because it keeps pipe full.