STID 1103 COMPUTER APPLICATION IN MANAGEMENT (A201)

INDIVIDUAL ASSIGNMENT # 1
(WORDS PROCESSING)

Long document Formatting

Utilize word processing utilities to format long document. You could use sample given BELOW.

Due Date: 21 MAY 2021.

A QoS EVALUATION OF THE TCP CONGESTION CONTROL
ALGORITHM

A Thesis submitted to Faculty of Information Technology in partial

fulfillment of the requirements for the degree Master
(Information and Communication Technology),
Universiti Utara Malaysia

By

<your name> (matric#)

 PERMISSION TO USE

In presenting this project of the requirements for a Master of Science in Information and

Communication Technology (MSc. IC) from Universiti Utara Malaysia, I agree that the

University library may make it freely available for inspection. I further agree that

permission for copying of this project paper in any manner, in whole or in part, for

scholarly purposes may be granted by my supervisor or in their absence, by the Dean of

Graduate School. It is understood that any copying or publication or use of this project or

parts thereof for financial gain shall not be allowed without my written permission. It is

also understood that due recognition shall be given to me and to Universiti Utara

Malaysia for any scholarly use which may be made of any material from my project

paper.

Request for permission to copy or make other use of materials in this project, in whole or

in part, should be addressed to:

Dean of Graduate School

Universiti Utara Malaysia
06010 Sintok
Kedah Darul Aman
 Malaysia

ABSTRACT

Networking evaluation techniques have been carried out different procedures and

behavior for presenting the TCP/IP state over different areas. Furthermore, the rapid

growth of using quality of services technique (QoS) for measuring and monitoring the

TCP/IP state has growth rapidly due to the improvement process for presenting new

techniques over LAN. TCP congestion algorithm has been used to control and monitor

the TCP/IP state over local area network. Different difficulties have been presented the

integration or the using of first in- first out technique among router for scheduling TCP/IP

state. Hence, this study has been concerned on using the quality of service evaluation

process of the TCP cognition control algorithm and to measure the TCP cognition control

algorithm state over local area network. However, Object Oriented Approach Modified

(Hoffer, et al., 1999) has been selected for designing, development, and testing the

deployed system (QCheck) over LAN.

 ACKNOWLEDGEMENTS

Praise to Allah for his guidance and blessing for giving me the strength and perseverance

to complete this project. I would foremost like to thank my parents, for providing me

with the opportunity to pursue my goals and for their love and affection, which has

helped me through the most trying times. Equal gratitude goes out to my siblings and

brothers. I would like to thank my supervisor, Mr. A bin B for her guidance and

constant motivation that has enabled me to complete my project work. Moreover, I would

also like to thank her for the opportunities that she has made available to me.

I would like to present my thanks to all my brothers specially Cxxx and Dxxx , Also to

my wife my son Exxx, my daughters Fxxx ,Gxxx and Hxxx and all my family who has

always been there for me. Finally, I would like to express my appreciation to all my

friends, colleagues, other staff, and everyone who has helped me in this journey.
 <your name> (matric#)

TABLE OF CONTENTS

CHAPTER ONE

INTRODUCTION page Num

1. Introduction

1.1 Problem Statement

1.2 Research Question

1.3 Research Objectives

1.4 Research Scope

1.5 Research Significant

1.6 Thesis Classification

1.7 Conclusion

CHAPTER TWO

LITERATURE REVIEW page Num

1. Introduction

2.1 QoS & RED

2.2 FIFO
 2.3 MAC and TCP/IP Address

2.4 How to Deliver QoS

2.5 Related Works

2.6 Conclusion

CHAPTER THREE

RESEARCH METHODOLOGY page Num

3.1Introduction

3.1 3.1Understand the Requirements

3.2 Design

3.3 Development

3.4 Testing

3.5 Conclusion

CHAPTER FOUR

ANALYSIS AND DESIGN page Num

4.1 Requirements of QCheck System

A. QCheck Functional Requirements

B. QCheck Non-Functional Requirements

4.2 Use Case Diagram

4.3 Administrator Interface of QCheck System

 4.4 Content Design

4.5 User Screen

4.5.1 TCP Based Response Time Measurement

4.5.2 TCP Based Throughput Measurement

4.5.2 TCP Based Throughput Measurement

4.5.3 TCP Based Traceroute Measurement

4.5.4 IP Based Response Time Measurement

4.5.5 IP based Throughput Measurement

4.5.6 IP based Traceroute Measurement

4.6 Summary

CHAPTER FIVE

QCHECK EVALUATION page Num

5.1 Introduction

5.2 Use Test Case

5.2.1 TCP Based Response Time Use Test Case

5.2.2 TCP Based Throughput Use Test Case

5.2.3 TCP Based Traceroute Use Test Case

5.2.4 IP Based Response Time Use Test Case

5.2.5 IP Based Throughput Use Test Case

5.2.6 IP Based Traceroute Use Test Case

5.3 Summary

CHAPTER SIX
 CONCLUSION

6.1 Introduction

6.2 Future Studies

6.3 Conclusion

REFERENCES

LIST OF FIGURES

Figure page Num

 Figure 1.1: The Congestion Control Algorithm
Figure 2.1: First In, First out Process
Figure 2.2: Related Works Outline
Figure 2.3: The SUITED QoS and Mobile Internet Demonstrator
Figure 2.4: Analyzing the new detection algorithm behavior over Differentiated
Services
Figure 2.5: Analyze TCP behavior over Internet
Figure 3.1: Object Oriented Approach Modified (Hoffer, et al
Figure 3.2: Tentative Design for the Proposed Mechanism for TCP Evaluation

Figure 4.1: QCheck Use Case Diagram

Figure 4.2: The Administrator Side for Measuring the Client Network
Performance
Figure 4.3: QCheck System details page layout
Figure 4.4: QCheck Tree Diagram for the Navigation Structure
Figure 4.5: TCP Based Response Time Measurement Minimum Value
Figure 4.6: TCP Based Response Time Measurement Maximum Value
Figure 4.7: TCP Based Throughput Measurement
Figure 4.8: TCP Based Traceroute Measurement
Figure 4.9: IP Based Response Time Measurement
Figure 4.10: IP Based Throughput Measurement
Figure 4.11: IP Based Traceroute Measurement

List of tables
Table page Num
 Table 3.1: H/W.S/W Specifications
Table 4.1: QoS based Response Time
Table 4.2: QoS based Throughput
Table 4.3: QoS based Traceroute
Table 4.4: Non Functional requirements
Table 5.1: TCP Based Response Time Use Test Case
Table 5.2: TCP Based Throughput Use Test Case
Table 5.3: TCP Based Tracerpute Use Test Case
Table 5.4: IP Based Response Time Use Test Case
Table 5.5: IP Based Throughput Use Test Case
Table 5.6: IP Based throughput Use Test Case

CHAPTER ONE

INTRODUCTION

1. Introduction

The success of the current Internet relies to a large extent on cooperation between

the users and network. The network signals its current state to the users by marking or

dropping packets. The user then strives to maximize the sending rate without causing

network congestion. To achieve this, the users implement a flow control algorithm that

controls the rate at which data packets are sent into the Internet (Wang, Y., et al., 2007).

More specifically, the Transmission Control Protocol (TCP) is used by the users to adjust
the sending rate in response to changing network conditions. In a network the computers

communicates with the help of IP-address. In an organization the transmission of data has

to be very much secured (Hayder, N., et al., 2008). The organizations may use Dynamic

IP addressing (Mohd D., Nurhayati A., 2006), to reduce the conflict that occurs between

the computers by giving them different IP address such that the data reaches to the

destination (Mohamed G., Chin T., 2003). On the Dynamic network the IP address of the

client machine keeps on changing. So, it’s difficult that data packets reach the correct

destination (Ramachandran, V., and Nandi, S., 2005); (Johnson, J. Z., 1998).
1.1 Problem Statements

There are two packet scheduling algorithms at the router, the first one is FIFO

(First in First Out, or Drop- Tail), which is widely used in the current Internet routers.

The second is RED (Random Early Detection), which drops incoming packets at a certain

probability

The problem of this study consider as:

 Hard to measure the degree of fairness provided to TCP connections during

measuring the network signals state.

 The difficulty to measure the network signals state using FIFO, because of a

bursty nature of packet losses.

 The difficulty to measure the network signals state using RED, because of it’s

cannot keep a good fairness when the capacity of shared link becomes small

compared with the total input link capacity.

1.2 Research Question

There are two questions taken in account:

 How to identify the network requirements?

 How to measure the signal state?

1.3 Research Objectives

This study aims to:

 Identify the network requirements for using the packet scheduling

algorithms and TCP versions that will use in this study.

 Model the proposed technique for measuring and analyzing the network

TCP state.

 Test the proposed system in order.

1.4 Research Scope

This study aims to evaluate the TCP performance over local area network based

on FIFO and RED mechanism. This study also will be employed a QoS mechanism for

measuring the application performance. Furthermore, Figure 1.1 shows the work flow of

TCP cognition control algorithm between clients over local area network (LAN).
 Computer 1 Computer 1
user

Computer 2 Policy Computer 2

user

Computer 3 Computer 3

user

TCP CONGESTION CONTROL ALGORITHM

Figure 1.1: The Congestion Control Algorithm

1.5 Research Significant

A review on the literature will be helped in identifying the importance and a host

of benefits of implementing a like mechanism for evaluation the TCP performance over

Local Area Network. Some of these benefits are:

A) Identify the TCP performance by elaborate the capacity of using different application

over local area network.

B) Moreover, designing the system also help to minimize the mistakes that may be detect

by using certain applications.

1.6 Thesis Classifications

The classification of this study will be concerned on five chapters which begin

with the introduction section as the first chapter. An overview of the content of the

following chapters is as follows:

 Chapter one: This chapter will gives a background, necessary for

understanding of the concept that will be used in the coming chapters and

overview of the research.

 Chapter two: This chapter will discuss about literature reviews, previous

related work and challenges, and more information to understand the research

components.

 Chapter three: This chapter discusses the methodology that will be used in this

research, this methodology contains four phases understand the requirements,

design, development, and test.

  Chapter four: This chapter discusses analysis and develops the proposed

system.

 Chapter five: This chapter discusses conclusion and recommendations,

moreover, future works also will discuss.

1.7 Conclusion

This chapter concerned on describing and explaining the study factors that lead to

the selection of the area studied. It also explains the objectives of conducting the study, as

well as its significances to the real world situation. These elements are important as it

ignites the implementation of the project. The next chapter deals with the literature

review which elaborates on related works that have been established in the same field.

CHAPTER TWO

LITERATURE REVIEW

2. Introduction

There are a number of advantages of using of a network evaluation mechanism. If

a cable is unplugged, an alarm can be triggered in the network operations center. Some

network evaluation mechanism allows work orders to be signed off and documentation

on the physical layer to be updated automatically (Bahl, P. and Padmanabhan, V., 2000).

However, a network tracking tools can help technicians resolve hardware problems by
identifying the location in the physical layer where trouble occurs by maintaining

comprehensive records of all MACs (Xiao, B. and Gao, C., 2006).

2.1 QoS & RED

Today’s, the evaluations process of the TCP performance in determining its status

among local area network have been brought different types and patterns for measuring

this status. Furthermore, TCP evaluation methods and tools such as Quality of Service

(QoS) for measuring the TCP quality based on the level of predictability and

manageability of the services supplied by one or more service providers for determining

TCP performance (Andreieux, 2005).

Different studies have focused on measuring and evaluation TCP QoS in provide

a particular importance which give inherent shared nature of Grid services and to the

limited capabilities based on hardware and software tools that are typically available to

satisfy a client's request. Moreover, online environments need always to measure its QoS

for measuring the client’s satisfaction on the online environments such as e-Business and

e-Science environments. The complexity of the web over local area network has been

produced different patters to measure and elaborate the business logic of the application.

QoS in multiple environments will reflect, to a large extent (Orge, et al., 2004).

The meaning of the TCP congestion is an avoidance mechanism to deal with

congestion situations in a growing Internet (Stevens, 1997). Routers and local area
networks require an active buffer management to facilitate and enhance the exhibit

phenomenon (Braden, 1998). Additionally, high buffer occupation entails loss of packet

bursts, that are characteristic for TCP/IP traffic; the ’Lock-Out’ phenomenon able to

deploy unfairness between different ports and TCP connections among local area

network. The Random Early Detection (RED) algorithm is currently the most using in

providing the TP/IP with the clear performance, which it has been recommended as a

useful solution for the addressed issues (Floyd, & Jacobson, 1993).

Moreover, Random Early Detection algorithm works as active queue management

for the mutely services (Heinanen, 1998), that supports relevant service classes, which

focus on minimize long-term congestion while allowing short-term congestion resulting

from bursts.

2.2 FIFO
 Figure 2.1: First In, First out Process

Figure 2.1 shows the FIFO process, which presents an acronym for First In, First

Out. This illustration of the different behaviors presents the principle of a queue or first

come, it’s an criteria for processing different behaviors based on what comes in first is

handled first, what comes in next waits until the first is finished, etc (Losk, 2003).

However, this presentation of the behaviors is analogous of the person behavior

"standing in a line" or "queuing", where the persons leave the queue in the order they

arrive.

The FIFO presentation unable to describe the variation process, the reason back to

the FIFO is not accurately descriptive of the different patterns and behaviors among local

area network. Different researchers have been suggested the using of queuing theory

which provide general determination of the more concept of queue, moreover, it’s

provide interaction between strict-FIFO queues.

First in, first out queuing is a useful acronym in providing the general behavior by

scheduling the evaluation process (Kohler, E., et al., 2006). In FIFO queuing, all packets

are treated equally by placing them into a single queue, and then servicing them in the

same order that they were placed into the queue. FIFO queuing is also referred to as First
come, first served (FCFS) queuing. The using of FIFO queuing provide different benefits

among local area network such as.

A) the using of FIFO queue in designing the software patterns based routers by providing

an extremely low computational load during the processing of routers, this processing

work on scheduling the entire signals and organizing them with more elaborate queue

disciplines.

B) Its elaborate they require size for placing signals p which make it more predictable.

The measurements of the entire packets among routers in local area network are not

organized and the maximum delay is determined by the maximum depth of the queue.

C) As long as the queue depth remains short, FIFO queuing provides simple contention

resolution for network resources without adding significantly to the queuing delay

experienced at each hop (Jourjon, G., et al., 2006).

2.3 MAC and TCP/IP Address

Every network interface has a MAC address (Media Access Controller) also

known as the physical address. This is the actual hardware address that the lowest level of

the network users to communicate (Batten, K., 2001). The physical address is an 8 byte

number such as "08:00:20:9A:38:34" On Windows it will sometimes be represented with

dashes between the numbers (Elnahrawy, E., et al., 2004).

 An IP-address (Internet Protocol Address) is 32 bits wide. It is expressed as four

decimal numbers separated by periods, such as "200.1.2.3" representing the decimal

value of each of the four bytes. Valid addresses thus range from 0.0.0.0 to

255.255.255.255 (Cox and Noble, 2002).

The global meaning of TCP is a connection-oriented, end-to-end reliable-byte-

stream transport-layer protocol (Stevens, W., 1994). It is widely used on the Internet and

in the Web. This section defines TCP terminology relevant for understanding this paper.

More detail on HTTP TCP behavior appears in (Barford, & Crovella, 2000). The

fundamental unit of data transfer in TCP is a byte (i.e., for sequence numbering, control,

and error Control purposes). However, TCP implementations generally work with a

larger logical unit size called a segment when transmitting packets across an IP

internetwork. The Maximum Segment Size (MSS) is a settable parameter for a TCP

transfer (Floyd, S., et al., 2006).

2.4 How to deliver QoS?

A QoS enabled network must be able to handle different traffic streams in different

ways. (Comer, C., & Douglas, E., 2006). This necessitates categorizing traffic into types

or classes and defining how each type is handled. All the following aspects could be

considered within the scope of QoS (Geoff, H., 2000):

  Differentiation of traffic (Classification)

 Admission control

 Queuing

 Congestion management

2.5 Related Works

Nowadays, the multiple using of the Internet applications have been modified the

way to treat different services and explorer the abilities to enhance and develop these

services based on clients requirements, for evaluation the application performance,

different evaluation tools and methods have been built for this purposes such as QoS

(Vincenzo, 2001). Currently, the QoS is determined by network capacity rather than by

declared QoS requirements.

Figure 2.2 shows a brief description for the related works which highlighted study

overview/problem, solution, and comment.

 Author OverView/Problem
Vincenzo, M., Andrea, V., & Alenia, S. (2001). A This study aimed to define Internet QoS Requirements
Framework for Internet QoS Requirements Definition and and to evaluate them; the twofold approach has been
Evaluation: an experimental approach. University of Rome conceived in this study to carry out a quantitative
“La Sapienza”/ Etnoteam S.p.A. (theoretical) evaluation along with a quantitative
(experimental) evaluation in a QoS-Enabled Internet
Infrastructure.
The main problem of this study present the difficulties to
control QoS mechanisms and monitor the emerging and
network response.
Solution
The study has been determined the SUITED QoS
Internet demonstrator to control and monitor the
emerging and network response based QoS
mechanisms.
Comment
My comment regarding Vincenzo paper concerns on the
proposed SUITED QoS mechanism for controlling the
network response, the study has been succeed to
overcome the controlling difficulties among network
response. But, different controlling techniques based QoS
mechanism has not been used in order to measure the
network response.

Hayder, J., Zuriati Z , Mohamed, O. (2009). Fairness of This study described the effectiveness of using cognition This study has been deployed AIMD mechanism This study described the main issues of deploying AIMD
the tcp-based new aimd congestion Control algorithm. control on reduce the performance of the network. to reduce the network performance which reflects good to enhance the network performance. Otherwise, AIMD
Journal of Theoretical and Applied Information efficiency as well as good fairnessevaluation process mechanism can also be replaced with more useful
Technology. The study has been identified the problem of using based on multi flows, which start at the same time and mechanism for increase the network performance.
AIMD (Additive Increase Multiplicative Decrease) in a also by considering each flow start at a different time in
set of liner algorithms. other way.

Emmanuel, L., Laurent, D., and Guillaume, J. (2007).
gTFRC, a TCP friendly QoS-aware Rate Control for
DiffServ Assured Service. National ICT Australia Ltd,
Australia, 2 ENSICA - LAAS/CNRS, France.
The study described the end-to-end congestion control The study has been explored a new pattern for Emmanuel, el al. modified the existing approach (TFRC)
sup-port over the different servers and Assured describing the new end-to-end mechanism for to take into account the QoS negotiated. The study was
Forwarding (AF) class. continuous transfer based on TCP-Friendly Rate Control applicable to use another approaches to be integrated
(TFRC). with QoS negotiated.
This study faced different difficulties to exame the
cognition control over TCP.

Stefan, K., Michael, M., & Norbert, V. (2001). Analytic
Performance Evaluation of the RED Algorithm for QoS in
TCP/IP Networks. 9th IFIP Conference on Performance
Modeling And Evaluation Of ATM & IP Networks 2001,
Budapest.
This study investigated the new detection algorithm
behavior randomly for Differentiated Services to cope
with feedback oriented traffic like TCP.
Moreover, the study has identified the existing detection
problem to cope with TCP traffic.
The study has been deployed a new detection algorithm The study showed the success process for analyzing the
behavior over Differentiated Services based RED new detection algorithm behavior over Differentiated
mechanism to cope with the TCP traffic. Services. Relevant suggestions can also take in account
by integrating other existing behavior and measure the
detection performance for TCP traffic.
 Figure 2.2: Related Works Outline

However, the purpose of using QoS mechanisms back to the ability of this

mechanism to control and monitor the emerging and network response. The study aimed

to define Internet QoS Requirements and to evaluate them; the twofold approach is

conceived to carry out a quantitative (theoretical) evaluation along with a quantitative

(experimental) evaluation in a QoS-Enabled Internet Infrastructure, which has been

described in figure 2.3 (Mascolo, 2003).

Figure 2.3: The SUITED QoS and Mobile Internet Demonstrator

According to Hayder et al. (2009) reported the TCP measurement techniques

among local area network, also measure the effectiveness of using round time trip (RTT)
algorithm based on two flows or more than that. The study has shown the effectiveness of

using cognition control on reduce the performance of the network. Furthermore, AIMD

(Additive Increase Multiplicative Decrease) is an established algorithm in a set of liner

algorithms that it reflects good efficiency as well as good fairness. Hence, the study has

been proposed “evaluation method of fairness for New AIMD congestion control

algorithm”. Moreover, the study has been done the evaluation process based on multi

flows, which start at the same time and also by considering each flow start at a different

time in other way.

Another study by Emmanue, et al. (2007) which described the end-to-end

congestion control sup-port over the different servers and Assured Forwarding (AF)

class. However, the study has been used and examined the cognition control based on

Assured Service (AS) which provides a minimum level of throughput guarantee. Based

on these services provided, the study has explored a new pattern for describing the new

end-to-end mechanism for continuous transfer based on TCP-Friendly Rate Control

(TFRC). Moreover, the study modified the existing approach (TFRC) to take into account

the QoS negotiated. The result of this new pattern named as gTFRC, the ability of this

pattern can be presented by reach the minimum throughput guarantee whatever the flow’s

RTT and target rate. Finally, QoS has been used in order to measure and implement the

proposed pattern over-provisioned or exactly-provisioned network.

 According to Stefan, et al. (2001) investigated the new detection algorithm

behavior randomly for Differentiated Services to cope with feedback oriented traffic like

TCP. Additionally, this paper has been modeled the features of TCP and RED and

evaluate the model using a discrete-time analysis. The importance of using these tools for

the evaluation process is to compose model, i.e., TCP feedback traffic over a RED queue

(Geoff, H., 2000). Deriving not only mean values but also distributions for the

performance measures, we obtain insights of the behavior of TCP under RED. Figure 2.4

shows the evaluation process for analyzing the new detection algorithm behavior over

Differentiated Services.

Figure 2.4: Analyzing the new detection algorithm behavior over Differentiated Services
 Other researchers such as Mascolo, Grieco, Ferorelli, Camarda, & Piscitelli,

(2003) improved the work flow of the TCP cognition control over LAN by enhancing the

sender side based on the classic Tahoe/Reno TCP that has been recently proposed to

improve fairness and efficiency of TCP. Moreover, this research has performed the end-

to-end estimate of the available bandwidth by properly counting and filtering the stream

of ACK packets over local area network for multi servers. The proposed technique work

also on enhances the cognition window and reduces the threshold after a congestion

episode (Chen, Z., et al., 2004).

Hence, the TCP cognition control will be able to manipulate the TCP paradigm

with the adaptive decrease paradigm. In addition, the proposed technique has been tested

on Linux 2.2.20 of Westwood+, Westwood+ and Reno TCP to “ftp data over emulated

WAN and over Internet connections spanning continental and intercontinental distances”

(Bustos, M., et L., 2003). The result that has been obtained showed the implementation

result of employed the bandwidth estimation algorithm by Westwood+ and nicely, that

monitors the available bandwidth, whereas the TCP Westwood bandwidth estimation

algorithm greatly overestimates the available bandwidth because of ACK compression

(Mascolo, 2003).

However, a study by Martin &Carey (2004) described the internet packet traffic

and analyze its behavior over the internet. Moreover, this study shown that around 15-

25% of TCP connections have at least one TCP RST (reset). Also relevant result has been
observed by measuring the internet links over Internet. The study has been tested over

reset connections arise from local events such as network outages, attacks, or

reconfigurations, as well as from global trends in TCP usage. Additionally, the study

described the behaviors level in the global trend in reset TCP connections (Ankur, C.,

2004). It’s shown that, most prevalent anomaly is the absence of the normal FIN

handshake for connection termination. Instead, connections are often reset by the client.

Furthermore, figure 2.5 shows the output of analyzing the TCP/IP behavior over Internet,

which classified to six levels.

Figure 2.5: Analyze TCP behavior over Internet

2.6 Conclusion

This chapter focused on two sections, the first section concerned on describe and

explain the issue of TCP/IP, QoS, RED, FIFO, and other relevant subjects. Moreover, the

second section concerned on the related and previous work on integrating and analyzing

the TCP, IP behavior over Local Area Network, and Internet. Finally, the research

methodology which is adapted by Hoffer et al. (1999) to this study in order to achieve the
objective will be discussed in the next chapter. This methodology has been carefully

chosen to make sure that it is suitable for developing the proposed system.

CHAPTER THREE

RESEARCH METHODOLOGY

3. Introductions

Research Methodology is more than just collections of method to perform a

research project; it is a systematic way to solve the research problem. The research

methods refer to the methods and techniques used by the researcher in performing the

research. This study will be used Object Oriented Approach (OOA) that adopted by

Hoffer, et al. (1999). This methodology has been modified to fit the study purpose.

Moreover, Hoffer, et al. (1999) has been stated in his book that a system or software

development methodology is a series of step-by-step processes that can lead to the

accomplishment of a system and application development. The processes describe how

works has to be carried out in order to achieve the objective or goal of the system

development. The processes involve are also bounded with rules that has to be followed

to ensure that the application developed is in line with the original predetermined

requirements.
 1.Understand
4.Test
Requirement

3.Development 2. Design

Figure 3.1: Object Oriented Approach Modified (Hoffer, et al., 1999)

3.1 Understand the Requirements

As explained by Hoffer, et al. (1999) describes the need to apply or develop an

information system in an organization or any particular situation is depending on several

conditions as follows:

 The requests to deal with problems occurred in current procedures practiced by the

organization or any situation that gives problem to the social environment.

 The desire to gain better solution by performing probable additional tasks.

 The realization of the capability of an information system to capitalize on an existing

opportunity.

Furthermore, implementing the project requires a proper Local Area Network (LAN)

to work on. Moreover, FIFO technique will be used in order in the cognitive control

based on the Quality of Service evaluation (QoS). Thus a work plan will be generated to

make sure that the end product meets the requirements. Planning a project also involve

the process of defining user and system’s requirements.

3.2 Design

This phase involves the process of designing the system which in the case of this

design is a QoS evaluation of the TCP congestion control algorithm. However, designing

the system involves two main processes that are categorized into logical design and

physical design. Additionally, during this phase, the descriptions for the proposed

alternatives produced in the previous phase were converted into logical and physical
specifications. Theoretically, designing the system involves two main processes that are

categorized into logical design and physical design.

A) Logical Design

Hoffer, et al. (1999) explained that logical design is the phase where all functional

features that have been chosen for the development of the system are described without

regard of any computer platform.

Object Oriented offers conceptual structures of the system to assist in

understanding the whole system’s functions especially during implementation or writing

programs. Moreover, FIFO and RED mechanism will be used to evaluate the TCP

congestion control algorithm. Figure 3.2 below shows the tentative design for the

proposed mechanism of evaluation the TCP performance based on the client connection

with the cognition control algorithm over LAN.

Furthermore, Object Oriented offers conceptual structures of the system to assist

in understanding the whole system’s functions especially during implementation or

writing programs. For this project, Unified Modeling Language (UML) will be used as

the techniques of notation to represent the system’s requirements. With UML, the

researcher will be produced use case diagram to represent the whole functions available

in the propose system. Other than that, sequence diagram will be also generated to
visualize the structure of the system’s flows. All of these diagrams will be produced

using the Rational Rose 2000 Enterprise Edition’s software. It is a simple, easy yet the

best tools for structuring system’s requirements.

Client PC

TCP-A- TCP-A-
TCP-A A A-A

TCP-A-B TCP-A-B-A
Policy

TCP CONGESTION TCP-B

CONTROL ALGORITHM

TCP-B-A
Firewall

TCP-N
 Figure 3.2: Tentative Design for the Proposed Mechanism for TCP Evaluation

B) Physical Design

However, physical design deals with the process of converting the logical design

into a more technical specification of the system development. In designing the physical

part of the system, all diagrams of data sources, data flows and data processing that were

produced in the logical design will be turned into a structured systems design. During

physical design, the researcher will be determined which evaluation mechanism will be

used during the development process, as well as the study will identify which platform

will be used, operating system and network environment the system will run under. Table

3.1 shows the physical design requirements.

Table 3.1: H/W.S/W Specifications

Purpose H/W.S/W Requirements

Hypertext Preprocessor (PHP) &MySql

Programming Language

Microsoft Windows Operating System

Operating System (Win95/Win98,Windows2000,WindowsME,

Windows Vista), QCheck Software.

Hardware Monitor, CPU, RAM (16MB and above),

Disk Space (minimum 12MB)

 The programming part of the project was dependent on the result from the

designing process which include the system’s functions, entities involve, hardware and

operating system determined. After everything was designed, the physical system

specifications were ready to be turned over to programmers for the next phase which is

the development phase.

3.3 Development

During the development phase, the requirements and systems specifications from

the System design step will be translated into machine readable computer code. This is

the critical phase in the implementation of this study (Kwok, et al, 2004). The system will

be developed using different evaluation mechanism such as FIFO and RED technology.

During coding, the programs will be written that constructed the system. There are

different steps require to follow during the development phase, these steps involves the

creation of the system software. Requirements and systems specifications from the

system design step are translated into machine readable computer code. This is the

critical phase in the implementation of this project. In the case of this project, the
proposed TCP analyzing system base FIFO and RED will show its capability as a PHP

language designed specifically for specifying and displaying content over Internet.

3.4 Testing

This phase will follow the development phase after the system will be coded, it

will be tested in order to find any error that may occurs and correct them. The testing will

also took place to ensure that it will provide the most liable services to users (client)

before the installation. Thus the testing include both software and hardware configuration

for the system. The study will present the use case test technique to evaluate and test

during this phase.

3.5 Conclusion

This chapter focused on four phases such as (Understand requirements, design,

development, and test) which applied for the proposed TCP analyzing system. Moreover,

this chapter has been deployed the Object – Oriented approach (OOA) from Hoffer, et al.

(1999) which has been adapted as a guide throughout the project. OOA is the most

common structured systems development phases being used in many project and

organizations. As proposed by Hoffer, et al. (1999), the OOA consists of six phases. But
the study has been modified this phases based on the study requirements. Finally, in the

next chapter, it will come out with finding and result.

CHAPTER FOUR

ANALYSIS AND DESIGN

This chapter briefly discusses the deployed system that used in order to fist the

study goals for measuring the network performance in UUM environment. The results of

the study bring together the functionalities, interface, and generalized design principles

for deploying IQ system.

4.1 Requirements of QCheck System

Identifying the requirements for any system supports the implementation steps

(Bahrami, 1999; Bennett, 2002; Dennis, 2005). Listed below are the functional and non-
functional requirements of the system. In the priority column, the following short hands

are used:

 M – Mandatory requirements (something the system must do)

 D – Desirable requirements (something the system preferably should do)

 O – Optional requirements (something the system may do)

A. QCheck Functional Requirements

Table 4.1: QoS based Response Time

Requirement ID Requirement Description Priority

QCHECK_01 QoS based Response Time

QCHECK_01_01  Administrator will be able to view the O

response time performance of client PC

based TCP/IP protocol.

QCHECK_01_02  Administrator will be able to view the O

response time performance of client PC

based UPX protocol.

QCHECK_01_03  Administrator will be able to view the O

response time performance of client PC

 based IPX protocol.

QCHECK_01_04  Administrator will be able to view the O

response time performance of client PC

based UDP protocol.

Table 4.2: QoS based Throughput

QCHECK_02 QoS based Throughput

QCHECK_02_01  Administrator will be able to view the O

throughput performance of client PC based

TCP/IP protocol.

QCHECK_02_02  Administrator will be able to view the O

throughput performance of client PC based

UPX protocol.

QCHECK_02_03  Administrator will be able to view the O

throughput performance of client PC based

IPX protocol.

QCHECK_02_04  Administrator will be able to view the O

throughput performance of client PC based

UDP protocol.
 Table 4.3: QoS based Traceroute

QCHECK_03 QoS based Traceroute

QCHECK_03_01  Administrator will be able to view the O

traceroute performance of client PC based

TCP/IP protocol.

QCHECK_03_02  Administrator will be able to view the O

 traceroute performance of client PC based

UPX protocol.

QCHECK_03_03  Administrator will be able to view the O

traceroute performance of client PC based

IPX protocol.

QCHECK_03_04  Administrator will be able to view the O

traceroute performance of client PC based

UDP protocol.

B. Non-Functional Requirements

Table 4.4: Non Functional requirements

QCHECK_4 Requirement for Performance

QCHECK_4_01  The QCheck performs according to hardware & M

 software used.

QCHECK_5 Performance issues

QCHECK_5_01  The QCheck should response in an optimal time, O

without any delay or non-consistency in

database.

4.2 Use Case Diagram

The use case is made up of a set of possible sequences of interactions between

systems and clients in a particular environment related to a particular goal (Eriksson,

1998; Hoffer, 1999). Furthermore, use case diagrams (a) organize functional

requirements of QCheck system (b) model the goals of system/actor (user) interactions

for QCheck system, (c) record paths from trigger events to goals that QCheck is aimed to

and (d) describe main flow of events and the contents actions (Hoffer, 2002; Jacobson,

2004; Schmuller, 2002). Figure 4.1 shows the deployed QCheck system over LAN, the
functionality of the system presents two sides, administrator for controlling the measuring

options, and client side.

TCP

Response Time

UDP
Administrator
QoS Through Put Client

SPX
Traceroute

IPX

Figure 4.1: QCheck Use Case Diagram

4.3 Administrator Interface of QCheck System

The page layout for the cover page and subsequent pages differs. The cover page

layout was split into four sections (Silva, P., & Paton, N., 2003). These are:

 Header

This section contains the titles of the QCheck and a welcome message to measure the

network performance over TCP/IP protocols and specify contents of the results.
 Cover display

The QCheck system cover provided recognition of the system title, which would be

updated, based on every issue subscribed. There were two options: either to go to the

details screen after run the system or use the direct hyperlink which locates in the temp

folder.

 Headlines

This part presents QCheck system information to enable user (administrator) to

decide quickly whether the selected protocol is appropriate for measuring the client

network performance. This service could help the administrator of the system to pick the

specify the require options.

 Menu

This part display two sprit table of contents of the QCheck system. A list view of the

QCheck selections and quick links for these contents are indicated with appropriate

buttons. Buttons are more visible to select options (protocols and details) than the direct

hyperlinks. A separator was inserted to show the division of the screen.

 Appropriate font sizes, color texts and backgrounds were selected based on the

ergonomic requirements. Figure 4.2, shows the QCheck system of the administrator side

for measuring the client network performance.

Check Time
Result

Check Based
TCP Protocol

Throughput

Check Based
UDP Protocol

Traceroute

Check Based
SPX Protocol

Iterations
number
Check Based
IPX Protocol
Data Size per
100 bytes

Run the
System after
Specification

View Result
Details

Figure 4.2: The Administrator Side for Measuring the Client Network Performance
 Setting Menu
for QCheck
QCheck based
Response Time

From
TCP/
IP

To
TCP/
IP

TCP/
IP

Minimum EndPoint
Result Details
Avarage
Max
Result

Figure 4.3: QCheck System details page layout

4.4 Content Design

The contents of the QCheck system play a crucial role in providing user

(administrator) with the useful and appropriate functions for measuring the client

network. Therefore, administrator in this QCheck system had to be allowed to navigate or

move around in multiple ways using the keyboard or mouse

(Atanas, R, & Miriam, R., 2006). The content requirements were divided into two

sections:
(a) Content display

 The contents of the QCheck system provide the network administrator to control

and manage the measurement result based the selected protocol.

 The QCheck system contents support the multi protocol such as (TCP, SPX,

UDP, and IPX).

 Also, the QCheck system result details content supports the network administrator

to specify the measurement techniques such as (Response time, throughput, and

traceroute).

(b) The navigational structure

The structural content assisted new users (Network administrator) when he/she want

to optimize any available function to be measured based on the selected protocol and

allow administrator to view their own functions for measuring network performance

(Atle, R., 2008). However the available functions provided as a two set to obtain a better

controlling of protocol and measurement result through the quick accessing to the

existing content that QCheck system provides. Figure 4.4 depicts the navigational

structure of the QCheck system.

 Admin

Identify
Protocol

TCP UPD SPX IPX

Specify Result
Details

Resopns Throughp Tracerout

e Time ut e

Measure the
Client
Performance

Client PC

Figure 4.4: QCheck Tree Diagram for the Navigation Structure

4.5 User Screen

4.5.1 TCP based Response Time measurement

Figure 4.5 shows the administrator screen for measuring the response time of the client IP

over LAN. Moreover, the figure below presents one for both iterations and data size as a

minimum value.

Figure 4.5: TCP Based Response Time Measurement Minimum Value

 Figure 4.5 shows the measurement process for client IP under minimum value for

iteration and data size. However, figure 4.6 presents the client IP measurement for response time

under value 10 for iteration and 32000 for data size.

Figure 4.6: TCP Based Response Time Measurement Maximum Value

4.5.2 TCP based Throughput measurement

Figure 4.7 shows the cline IP performance measurement based the throughput

function. The throughput for 1000 data size produced 94.118 Mbps.

Figure 4.7: TCP Based Throughput Measurement

4.5.3 TCP based Traceroute Measurement

Figure 4.8 presents the client IP measurements based tracerpute function.

Administrator able to display the client TCP or UDP.

Figure 4.8: TCP Based Traceroute Measurement

4.5.4 IP based Response Time Measurement

Figure 4.9 shows the measurement process for the client IP based response time

function. Administrator able to insert his IP addresses as an endpoint to measure the client IP

address.

Figure 4.9: IP Based Response Time Measurement

4.5.5 IP based Throughput Measurement

Figure 4.10 shows the measurement process for the client IP based thorughput function.

Administrator able to insert his IP addresses as an endpoint to measure the client IP address.

Figure 4.10: IP Based Throughput Measurement

4.5.6 IP based Traceroute Measurement

Figure 4.11 shows the measurement process for the client IP based traceroute function.

Administrator able to insert his IP addresses as an endpoint to measure the client IP address.

Figure 4.11: IP Based Traceroute Measurement

4.6 Summary

This chapter presents the overview process for the deployed QCheck system for

measuring the network client performance based response time, throughput, and traceroute

functions. The UML diagrams are used to model the design view of the deployed system. The

design of the interface and content of the QCheck system for measuring the client protocol

performance are also elaborated in order, use case diagram has been used to present the system

functionality phase of QCheck system.

CHAPTER FIVE

QCHECK EVALUATION

5.1 Introduction

This study focused on deploying and analyzing a QCheck system for providing and

supporting the network administrator with the ability to measure the quality of service (QoS) of

the client network over different protocols. Although QCheck system became the most useful

methods for measuring the network quality which obtains multi functions to be deployed by the

administrator. The evaluation was concerning on two computers one for the administrator for

specifying the require protocols and the other one for the client side.
 5.2 Use Test Case

System testing performs testing on interaction of entire dialog components when all the

components are combined for the first time. According to Booch et aJ. (2001), they explained

that use cases could be used as the basis of test cases for these elements as they evolve during

deploying and developing phase, and it also can be excellent sources of system tests. Collard

(1999) strengthens above point by explaining that if the use cases for a system are complete and

accurate, the process of deriving the test cases is straightforward. Otherwise, the attempt to

derive test cases will help to debug the use cases.

This study has employed the test design guideline from Collard (1999) who has

demonstrated the development of test cases that is used in testing use case's event. Six use case

processes have been identified such as; TCP based response time, TCP based throughput, TCP

based throughput, IP based response time, IP based throughput, and IP based throughput.

Implementation of Use case testing consists of generating the normal test case and negative test

case, show the normal test case used to test against each normal mainstream process of use case.

5.2.1 TCP Based Response Time Use Test Case

Table 5.1: TCP Based Response Time Use Test Case

1 Test Data Expected Observed / Date And Severity Allocated To

Input Actual Results Time

Results (h-high,

m-medium, l-
 low)

TCP based Iteration and Display Network 20 Sep 2009 M Administrator

Response client
Data size Disconnect 3:30 PM
Time TCP

Response

Time

5.2.2 TCP Based Throughput Use Test Case

Table 5.2: TCP Based Throughput Use Test Case

2 Test Data Expected Observed / Date And Severity Allocated To

Input Actual Results Time

Results (h-high,

m-medium, l-

low)

TCP based Data size Display Network 20 Sep 2009 M Administrator

Throughput client Disconnect 3:40 PM

TCP

Throughput
 Value

5.2.3 TCP Based Tracerpute Use Test Case

Table 5.3: TCP Based Tracerpute Use Test Case

3 Test Data Expected Observed / Date And Severity Allocated To

Input Actual Results Time

Results (h-high,

m-medium, l-

low)

TCP based Non Display Network 20 Sep 2009 M Administrator

Tracerpute client Disconnect 3:50 PM

TCP

Tracerpute
 value

5.2.4 IP Based Response Time Use Test Case

Table 5.4: IP Based Response Time Use Test Case

4 Test Data Expected Observed / Date And Severity Allocated To

Input Actual Results Time

Results (h-high,

m-medium, l-

low)

IP based Iteration and Display Network 20 Sep 2009 M Administrator

Response client
Data size Disconnect 3:60 PM
Time IP Response
 Time

5.2.5 IP Based Throughput Use Test Case

Table 5.5: IP Based Throughput Use Test Case

5 Test Data Expected Observed / Date And Severity Allocated To

Input Actual Results Time

Results (h-high,

m-medium, l-

low)

IP based Data size Display Network 20 Sep 2009 M Administrator

Throughput client
 IP Disconnect 4:00 PM

Throughput

value

5.2.6 IP Based Throughput Use Test Case

Table 5.6: IP Based throughput Use Test Case

6 Test Data Expected Observed / Date And Severity Allocated To

Input Actual Results Time

Results (h-high,

m-medium, l-

low)

IP based Non Display Network 20 Sep 2009 M Administrator

Tracerpute client Disconnect 4:10 PM

 IP

Tracerpute

value

5.3 Summary

The evaluation phase of the deployed QCheck system presented during this phase by

carrying out the use test case for six network measurement (TCP based response time, TCP

based throughput, TCP based throughput, IP based response time, IP based throughput, and IP

based throughput). Moreover, this chapter presented the result based administrator selection for

client protocol and measurement results. Deploying of QCheck system will bring the usefulness

to measure and identify the network quality over clients. It is hoped that this project will be part

of a more promising growth of information technology in Malaysia.

 CHAPTER SIX

CONCLUSION

Nowadays, the using of networking tools such as Quality of Service for measuring and

identifying the available services over LAN has been rapidly growth due to the improvement in

system evaluation technique. Furthermore, administrators start to look on other alternative ways

to identify network performance based TCP and IP protocol. This study has been emphasized the

direction for future works on QCheck system.

6.1 Introduction

As discussed in Chapter one, this study achieves the following objectives:

 Identify the network requirements for using the packet scheduling algorithms and

TCP versions that will use in this study.

 Model the proposed technique for measuring and analyzing the network TCP

state.

 Test the proposed system in order.

The outcome of the first objective has been discussed in chapter 4, where the main

functionality, actors and use case of the QCheck system are described by presented the

administrator and client side among QCheck system. Then, screen design and description has

been illustrated in order.

To support the final objectives, the evaluation of the prototype system was conducted by

optimizing use test case for six cases (TCP based response time, TCP based throughput, TCP

based throughput, IP based response time, IP based throughput, and IP based throughput).

Moreover, the main definition for the QCheck system tools has been perceived and used

by administrator side. Though absolute attributes are important, it is how those attributes are

perceived, now and in the future, that defines network requirements. Furthermore, identifying
quality of service involves two stages: (a) highlighting which attributes are important and (b)

determining how these attributes affect on the network performance.

6.2 Future Studies

The deployed QCheck system optimized and tested based two endpoint, which presents

administrator and client. Thus, the evaluation of its true performance cannot be conducted due to

limited financial budget to use real connection services with multi clients that show the real

performance of the deployed system among different protocols. There are several

recommendations on the study as follows:

1. The deployed QCheck system should be upgraded with more useful and beneficial

functions for browsing the available networks information in order to satisfy with the

quality measuring needs.

2. Evaluation should be a comprehensive process with a larger number of network clients

and based different protocols. However, in this study, due to limit time and resources,

only two devices QCheck have been integrated to. A future study should take into

account more respondents to evaluate the system performance among those clients.
 3. Identify the available techniques for maximizing the efficient use of the functions that

provided in this service.

4. Develop the security system to secure and safe the information about the client

information.

6.3 Conclusion

The deploying of QCheck system has been described and the results of that deploying

have been collected based use test case technique. The primary aim of the experiment was to

evaluate the interface and content of the system in supporting the administrator to measure the

client network performance over LAN. It is inappropriate to generalize the findings as only two

devices, but it has been demonstrated that the QChceck system is well accepted.
 Moreover, the chapter proposed recommendation to support efficiency, effectiveness and

satisfaction system to obtain for administrator to do their measuring to the network performance

over LAN.
 REFERENCE

Andreieux, A. (2005). Web Services Agreement Specification (WS-Agreement), work n

progress, Grid Allocation and Agreement Protocol WG, GGF.

Batten, K. Saraf, A., and Treptin, S. (2001). A secure peer-to-peer backup system, December.

Bahl, P. and Padmanabhan, V. (2000). Radar: An in-building rfbased user location and tracking
system, in Proceedings of the IEEE International Conference on Computer Communications
(INFOCOM), pp. 775–784.

Cox and Noble (2002). Pastiche: Making backup cheap and easy. In In Proceedings of Fifth
Usenix Symposium on Operating Systems Design and Implementation.

Elnahrawy, E., Li, X. and Martin, R. (2004). The limits of localization using signal strength: A
comparative study,” in Proceedings of the First IEEE International Conference on Sensor and
Ad hoc Communcations and Networks (SECON 2004), pp. 406–414.

Losk, V. (2003). First In First Out. Dax Networks. 1 -800-4255-Dax. From

(http://daxnewsletters.com/unsubscribe.php?n=TD).

Hoffer, J. (1999). Modern Systems Analysis & Design. MA: Addison-Wesley.

Jorge Cardoso; Amit Sheth; John Miller; Jonathan Arnold; Krys Kochut (2004). Quality of
Service for Workflows and Web Service Processes, 004,
(http://lsdis.cs.uga.edu/library/download/CSM+QoS-WebSemantics.pdf).

Johnson, J. (1998). Network Security Programs: Process and Metrics for the Real-World, White
paper, Internet Security Systems, Inc.
Kwok, T., Nguyen, T., Lam, L., & Roy, K. (2004). An Efficient and Systematic Method to
Generate XSLT Stylesheets for Different Wireless Pervasive Devices, ACM 1-58113-912-8,
New York, USA.

Krishnan, R., Allman, M., Partridge, C., & Sterbenz, J. (2002). Explicit transport error
notification (ETEN) for error prone wireless and satellite networks. Technical Report 8333,
BBN Technologies.

Mascolo, S., Grieco, A., Ferorelli, R., Camarda, P., & Piscitelli, G. (2003). Performance
Evaluation of Westwood TCP Congestion Control. Preprint submitted to Elsevier Science.

Mohd D., Nurhayati A. (2006). Performance Evaluation Of TCP/IP Protocol for Mobile Ad Hoc
Network. WSEAS Transactions on Computers, Vol.5, No.7, pp. 1481-1486.

Ramachandran, V., and Nandi, S. (2005). Detecting ARP spoofing: An active technique, Lecture
Notes in COMPUTER SCIENCE 3803, pp.239-250.

Vincenzo, M., Andrea, V., & Alenia, S. (2001). A Framework for Internet QoS Requirements
Definition and Evaluation: an experimental approach. University of Rome “La Sapienza”/
Etnoteam S.p.A.

Xiao, B. and Gao, C. (2006). Detection and localization of sybil nodes in vanets, in Proceedings
of the Workshop on Dependability Issues in Wireless Ad Hoc Networks and Sensor
Networks (DIWANS).

Hayder, J., Zuriati Z , Mohamed, O. (2009). Fairness of the tcp-based new aimd congestion
Control algorithm. Journal of Theoretical and Applied Information Technology.

Emmanuel, L., Laurent, D., and Guillaume, J. (2007). gTFRC, a TCP friendly QoS-aware Rate
Control for DiffServ Assured Service. National ICT Australia Ltd, Australia, 2 ENSICA -
LAAS/CNRS, France.
Stefan, K., Michael, M., & Norbert, V. (2001). Analytic Performance Evaluation of the RED
Algorithm for QoS in TCP/IP Networks. 9th IFIP Conference on Performance Modeling And
Evaluation Of ATM & IP Networks 2001, Budapest.

Mascolo, S., Grieco, A., Ferorelli, R., Camarda, P., & Piscitelli, G. (2003). Performance
Evaluation of Westwood+ TCP Congestion Control. Preprint submitted to Elsevier Science.
2003.

Stevens, W. (1997). “RFC2001: TCP slow start, congestion avoidance, fast retransmit, and fast
recoveryalgorithms.” http://www.ietf.org/rfc/rfc2001.txt, Jan. 1997.

Braden, B., Clark, D., & Crowcroft J. (1998). RFC2309: Recommendations on queue
management and congestion avoidance in the internet. http://www.ietf.org/rfc/rfc2309.txt,
Apr.1998.

Floyd, S., & Jacobson, V. (1993). Random early detection gateways for congestion avoidance,”
IEEE/ACM Transactions on Networking, vol. 1, pp. 397–413, Aug. 1993.

Heinanen, J., Baker, F., Weiss, W., & Wroclawski, J. (1997). RFC2597: Assured forwarding
PHB group.” http://www.ietf.org/rfc/rfc2597.txt, Jan. 1997.

Martin, A. & Carey, W. (2004).An Analysis of TCP Reset Behaviour on the Internet.
Department of Computer Science University of Calgary Calgary, AB, Canada, T2N 1N4.

Barford, P., & Crovella, M. (2000). Critical Path Analysis of TCP Transactions", Proceedings of
ACM SIGCOMM, September 2000.

Stevens, W. (1994). TCP/IP Illustrated, Volume 1, Addison-Wesley, New York, 1994.

Chen, Z., Liang-Tien, C., & Bu-Sung L. (2004). DAML-QoS Ontology for Web Services.
ICWS, pp472- 479, 2004.
Bustos, M., Van, H., & Kaeo, M. (2003). Terminology for Benchmarking IPSec Devices", IETF
draft-ietf-bmwg-ipsec-term-02.txt, November 2003.

Ankur, C. (2004). Quality of Service Testing Methodology. B.E., University of Bombay

(Mumbai).

Geoff, H., (2000). Internet Performance Survival Guide QoS strategies for Multi-service
Networks, Wiley Computer Publishings, 2000.

Kohler, E., Handley, M., & Floyd, S. (2006). Datagram Congestion Control Protocol (DCCP).
Request for Comments 4340, IETF.

Jourjon, G., Lochin, E., Dairaine, L., Senac, P., Moors, T., & Seneviratne, A. (2006).
Implementation and performance analysis of a QoS-aware TFRC mechanism. In: Proc. of
IEEE ICON, Singapore.

Floyd, S., Kohler, E., & Padhye, J. (2006). Profile for DCCP Congestion Control ID 3: TRFC
Congestion Control. Request for Comments 4342, IETF.
Comer, C., & Douglas, E. (2006). Internetworking with TCP/IP, 5E, Prentice Hall: Upper Saddle
River, NJ.

Wang, Y., Chou, L., & Lin, C. (2007). The design and implementation of the NCTUns network
simulation engine. Science Direct, Simulation Modeling Practice and Theory, 2007, 57-81.

Hayder, N., Zuriati, A., Mohamed, O., & Shamala, S. (2008). The TCPBased New AIMD
Congestion Control Algorithm, International Journal of Computer Science and Network
Security, VOL.8 No.10, 2008, 331-338.

Bahrami, A. (1999). Object Oriented System Development, McGraw-Hill, United States of

America.

Bennett, S., McRobb, S., & farmer, R. (2002). Object-oriented System Analysis and Design 2nd
Edition. UK, McGraw Hill.
Dennis, A., Wixom, B.H., & Tegarden, D. (2005). System analysis and design with UML
version 2.0: an object-oriented approach with UML, 2nd edition. Hoboken, NJ: John Wiley
and Sons, Inc.

Eriksson, H., & Penker, M. (1998). UML Toolkit. USA, John Wiley & Sons, Inc.

Hoffer, J. A., George, J. F & Valacich, J. S. (2002). Modern Systems Analysis and Design (3rd
Edition). Upper Saddle River, New Jersey: Prentice Hall.

Jacobson, I., Christerson, M., Johnsson, P. & Overgaars, G. (2004). Object-oriented Software
Engineering: A Use Case Driven Approach (revised). Harlow, England: Addison-Wesley.

Silva, P.P.D. & Paton, N.W. (2003). UML: The Unified Modeling Language for Interactive
Applications. Retrieved from: http://scholar.google.com/scholar?q=UMLi:%20The
%20Unified%20Modeling%20Language%20for%20Interactive
%20Applications&hl=en&lr=&oi=scholart.

Atanas, R, & Miriam, R. (2006). Static control-flow analysis for reverse engineering of UML
sequence diagrams. 31(1): 96 – 102.

Atle, R. (2008). Extending UML Sequence Diagrams to Model Trust- dependent Behavior with
the Aim to Support Risk Analysis. 197(2): 15-29.

Schmuller, J. (2002). SAMS Teach Yourself UML in Hours . SAMS Publishing, Indiana.