Tcp performance Final Report

CHAPTER 1
INTRODUCTION

Ambit lick Solutions
Mail Id : Ambitlick@gmail.com , Ambitlicksolutions@gmail.Com

1. INTRODUCTION

1.1 SYSTEM OVERVIEW
Advances in optical network technology enable fast pace increase in
physical bandwidth whose growth rate has far surpassed that of other resources
such as CPU and memory bus. This phenomenon causes network bottlenecks to
shift from bandwidth to other resources. The rise of new applications that
require in-network processing hastens this shift, too. For instance, a voice-over-
IP call made from a cell phone to a PSTN phone must go through a media
gateway that performs audio transcoding “on the fly” as the two end points
often use different audio compression standards. Examples of in-network
processing services are increasingly abundant from security, performance-
enhancing proxies (PEP), to media translation. These services add additional
loads to processing capacity in the network components. New router
technologies such as extensible routers or programmable routers also need to


deal with scheduling of CPU usage per packet as well as bandwidth usage per
packet

1.2 OBJECTIVE OF THE PROJECT
Our objective is to reduce both bandwidth and CPU Process which
can be a bottleneck for network flow

1.3 LITERATURE SURVEY
1.3.1 Existing System
In existing system conventional TCP/AQM schemes can significantly
lose throughput and suffer harmful unfairness in this environment, particularly
when CPU cycles become scarcer.

1.3.2 Proposed System
The proposed system we establish a notion of dual-resource proportional
fairness and propose an AQM scheme, called Dual-Resource Queue (DRQ),
that can closely approximate proportional fairness for TCP Reno sources with
in-network processing requirements.

1.4 ORGANISATION OF THE REPORT


The Chapter 1 presents the review of Literature. The goal tended to be
attained in the project is explained in the objectives. The problem description
tell the need for the system and its purpose for the user's community. The
Chapter 2 explains the system requirement for both by feature and by
functionality hierarchy. The Chapter 3 describes the System Design which
includes the decomposition description, dependency description and detailed
design of modules.
The Chapter 4 describes the implementation of the project, which
includes the modules and components used in this project. The Chapter 5 deals
with the test plan and testing of the project. The Chapter 6 describes the result
of the implementations. The Chapter 7 contains the conclusion of the work
done and also the extension of the work.


CHAPTER 2

SOFTWARE REQUIREMENT
SPECIFICATION


2. SOFTWARE REQUIREMENT SPECIFICATION

1.2.1 EXTERNAL INTERFACE REQUIREMENTS
2.1.1User Interfaces

The product must be usable from the text command line, particularly
under operating systems where the command line is a standard common user
interface (such as Linux). However, some guidelines do apply:

Help: Help should be available for all tools. Command – line tools should
print a helpful message (if appropriate) If invoked with no arguments (if
any command line tools are designed to accept input as a pipe, it is acceptable
to forego this rule). If multiple options are available,the product should
present a text menu detailing the probable choices rather than forcing the
user to retype everything up to that point. All command-line tools must print a
summary of use and available subcommands if invoked with invalid or
missing arguments. GUI tools must have help available from any screen, either


via a button, context-sensitive help, or a summary of help on the page (web
forms may take the latter route).

Feedback: Each tool should give feedback to the user describing the results
of their last action; in other words, issue for submissions should be a
acknowledged (with a response message from standard output, a follow-on
web page, or return email) with some positive indication of the result ("Your
issue has been reported and filed with ID 523", for example). If preconditions
for an action have not been met (an issue is filed with an invalid or
inappropriate a format, for example, or the user is not of a class allowed to
perform these actions) the feedback should indicate that the desired action has
not been accomplished & give an indication of the error and how it could be
fixed.

Command-line options: If command - line tools can accept arguments, they
will support them according to the standards laid out in the GNU coding
standards, and should support both short and long forms.

2.1.2 Hardware Interfaces

Simulation should be implemented in a hardware-independent fashion
and should not rely on any particular hardware interfaces.


2.1.3 Software Interfaces

No software interfaces except for the Python subsystem are
necessary. The issue is repository will be held on-disk in the form of XML files
stored in a directory tree. The repository will be labeled network simulation-
repository and will a hold the following subdirectories:

2.1.3.1 Awaiting - Review

This directory holds issue reports which are awaiting a review before
being added to the database proper. The awaiting-review subdirectory is
particularly useful when a repository is set up such that all issue reports must
pass through one or more issue managers before being accepted into the
database.

2.1.3.2 Network Simulation-Options

This directory holds various files meant to customize or augment the
behaviour of the product.

2.1.3.3 Templates

This directory holds the XML document type definitions (DTDs) for the
various issue types that the repository will track

2.1.4 Communications Interfaces

When the "external user" user class is included, a Network simulation
should allow submissions viastandard email and via the world wide web
( probably using CGI scripting). No other communications interfaces are
mandated.

2.2.2 SYSTEM FEATURES

The system should provide the full fill text of a submitted issue on a
request by the command network simulation cat template-name issue-id

2.2.1 Stimulus/Response Sequences

Description

The user queries the database by using the command network simulation
query issue-template match-expression; the system scan the submitted issues
under the given template and returns feedback according to the match-
expression. Match expressions will be in the format of a subset of XPath or
XQL.


Requires

An installed database with read access

Ensures

A resultant list of matching ids and feedback

Priority and Frequency of Use

The priority and frequency of use is high.

3.2.3 OTHER NONFUNCTIONAL REQUIREMENTS
3.1

3.2Performance Requirements

The system has no specific performance requirements at this time

3.3Safety Requirements

The system has no specific safety requirements at this time, except to the
extent that it is designed to run without root access.

3.4Security Requirements

The system has no specific security requirements at this time.


3.5Software Quality Attributes

No additional software quality attributes are addressed in the requirements
at this time.

3.6Business Rules

There are no explicit business rules for operation of Network simulation
at this time. All users with access to the command line tools and a copy of the
repository will be allowed to perform all actions. Additional security
measures and procedures may be added at a future date.


CHAPTER 3

SOFTWARE DESIGN
DOCUMENT


3. SOFTWARE DESIGN DOCUMENT

3.1SYSTEM ARCHITECTURE

souece

gateway

Fig 3.1 System Architecture


The architecture contains the sender , receiver connected in the network
and the service gateway in traffic engineering console . The source node
connects with the destination node. After the connecting the nodes , choose the
file to be send from source to to transfer the data and justified the best path to
send the data using red algoritham.tcp/aqm are used in the traffic network to
redused the traffic

3.1.1 Use Case Diagram

Fig 3.2: Use Case Diagram

The use case diagram gives the primary elements and the process of the
project. The primary elements are actor the “actor” and the process of the “use
case”. Use case diagram show the actor and the use case of the project
which interact with each other. The use case diagram describes the basic
process of the entire network system. In this project, userand receiver are the
major actor who performs all the actions such as connecting the node and
sending the file via the service gate way to receiver.

3.1.2 State diagram


Fig:3.3: State Diagram


The State diagram gives the information flow of the project.First the
user uploads the files and it is converted then it is stored in file system on
play option the file is fetched from the file system and played.

3.1.4 Component Diagram

Fig 3.4 : Component Diagram


The Component Diagram gives the high-level parts of the system that makes
the system. In this project the high-level parts are the interface where the sender
and receiver can interact through the system.

3.2 DECOMPOSITION DESCRIPTION
3.2.1 Module Decompostion
The various modules that are used in the project are listed below and
explained in details .the various modules are explained briefly with all applied
input got corresponding to these modules .they are
• network module
• packet scheduling
• bandwidth sharing

3.2.1.1 Network Module
Client-server computing or networking is a distributed application
architecture that partitions tasks or workloads between service providers
(servers) and service requesters, called clients. Often clients and servers operate
over a computer network on separate hardware. A server machine is a high-
performance host that is running one or more server programs which share its
resources with clients. A client also shares any of its resources; Clients
therefore initiate communication sessions with servers which await (listen to)
incoming requests.


Fig 3.5 : CPU Cycle Process

3.2.1.2 Packet Scheduling

This packet scheduling policy is simple to implement, and yields good
performance in the common case that node schedules are known, and
information about node availability is accurate. A potential drawback is that a
node crash (or other failure event) can lead to a number of wasted RTSs to the
failed node. When added across channels, the number may exceed the limit of 7
retransmission attempts allowed for a single channel in the IEEE 802.11

3.2.1.3 BANDWIDTH SHARING


Approach where each node requests and grants as much bandwidth as
possible at each turn. Additionally, we compare the RENO algorithm for packet
scheduling to a First-In-First-Out (FIFO) scheduler where all the SDUs with the
same next-hop are enqueued into the same buffer. For this purpose we simulate
a network with an increasing number of nodes, from 2 to 10, arranged in a chain
topology. Each node has one traffic flow directed to the chain end-point node,
carried with a constant bit-rate stream of 1000 bytes packets emulating infinite
bandwidth demands. Congestion control has been extensively studied for
networks running a single protocol. However, when sources sharing the same
network react to different congestion signals, the existing duality model no
longer explains the behavior of bandwidth allocation. The existence and
uniqueness properties of equilibrium in heterogeneous protocol case are
examined.

RED ALGORITHM

Calculating avg queue size
If(avg<THmin)
queue packet
Else if(THmin<=avg<=THmax)
Calculate pa
with pa


discard packet
else with probability(1- pa )
queue packet
Else if (avg>=THmax) discard packet

3.2.2 Process Decomposition
Creating a Tcp Reno Interface
This process is creating tcp reno for getting data and store the data . It
collect all send data and order wise send to receiver ma.
Selecting and placing the service Node
The gateway has been selected based on the shortest path and cost. And it
is send data to receiver.
Sending the Packet
The sender can browse any of the file from the local host . As soon as the
file has selected and it display the connect in the scrolling window and transfers
the packet to the destination.

3.2.3 Dependency Description
Inter Module Dependency
The network client in networking module is the one that dependent on
other modules. This module connects all clients and display the information
present in the modules.
Inter Process Dependency


All the processes are dependent on process . all process are started from
the gateway interface section in process 1.

3.2HUMAN INTERFACE DESIGN

3.3.1 Screen Image
The administrator can interact with the client using the interface is
created using ns 2 tools. The interface designed as by clicking the button the
information of the client is obtained in the screen of the administrator so
the user and node details of the system can be managed efficiently


Fig 3.6 :Screen Chat


CHAPTER 4

IMPLEMENTATION


4. IMPLEMENTATION

4.1 MODULE WISE IMPLEMENTATION
Congestion control in network traffic is basically implemented in
LINUX system and using ns2 transferring the data from sender to receiver.

Module 1: Network Module
a network that consists of a set of unidirectional links, Client-server computing
or networking is a distributed application architecture that partitions tasks or
workloads between service providers (servers) and service requesters, called
clients. Often clients and servers operate over a computer network on separate
hardware. A server machine is a high-performance host that is running one or
more server programs which share its resources with clients. A client also


shares any of its resources; Clients therefore initiate communication sessions
with servers which await (listen to) incoming requests

PACKET SCHEDULING

This packet scheduling policy is simple to implement, and yields good
performance in the common case that node schedules are known, and
information about node availability is accurate. A potential drawback is that a
node crash (or other failure event) can lead to a number of wasted RTSs to the
failed node. When added across channels, the number may exceed the limit of 7
retransmission attempts allowed for a single channel in the IEEE 802.11


Step 1:


Fig 4.1 : send data

This first step for the process, more sender send the data to the
receiver .


Strep 2 :

Fig 4.2 : Gateway


In this section use the gateway. It is interface between sender and
receiver the gateway are collecting the data and send to the Tcp reno.


Step 3


Fig 4.3 :Use TCP Reno

The final section is TCP reno operation it is collection of data
and order and sequence wise send data to the receiver.


CHAPTER 5
TEST PLAN AND TESTING


5. TEST PLAN AND TESTING

5.1 Testing
Testing is the process of analyzing the system for any possible errors, and
thereby providing solutions to process solutions to correct them. Inspections are
formal group of activities where participants manually examine the code for
errors. It can also be stated as the process of validating and verifying that a
software program or product meets the business and technical requirements.
This process is done by arriving at various test cases that are applied to
the system and the resulting messages being noted. This project performs
following testing:
• Unit testing


• Integration testing
• Validating testing

5.2 Testing Objectives
Testing is the process of executing a program with the intent of finding
an error. A test case is the specific scenario of transaction,queries or navigation
paths that represent typical,critical or abnormal use of the system. The test case
should be repeatable,so that it can be returned as new version of the software
are used. Test case need to determine that new software works with other
existing software with which it must share data. The successful test case is the
one which uncovers the undiscovered error.
In this system Testing is done on each smallest unit possible and the
integration Testing is done to check whether the system is capable of working
with the other dependency modules. Finally the validation testing is done for
checking whether the system satisfy the user's requirements.

5.3 UNIT TESTING
The first Testing to be performed on the system is Unit Testing. This
testing involves independent analysis of the system in parts. The main
advantage gained by performing this testing is high level of accuracy in finding
errors at each phase of the system.


The Unit Testing is performed in this system by giving input to the
smallest unit or part of the system and expect the desired output if the system
doesn't produce the Expected output then the system has fault if the expected
output is produced then the system works well.
The Unit Testing for the system is done for the following units
 Network Module
 Tcp/Aqm Module
 Conversion Module
S.N FUNCTIONS SAMPLE EXPECTED OBSERVE STATUS Error
o. INPUT RESULTS D RESULT
Messages

1 Send function Text Received Received Success Null
2 Send function Image Received Received Success Null
3 Send function Video Received Received Success Null
4 Send function Multiple Error Received Failure Invalid
concurrent Declaration
files
5 Send function Corrupt File Error Received Failure Invalid
Declaration

6 Send function Exe file Error Error Failure Null
7 Receive function File Received Received Failure Error:Invali
file d path

Table 5.1: Unit Testing on Congestion Control


5.3.1. Unit Testing on Network Module
The unit testing is performed on the upload module by uploading files of
varying size and varying type. The directory of storing the file was changed and
performed the upload operation. The testing was performed for protect function
and checked whether the the desired output is received. The Test case include
most often input scenario and the system is tested the idea behind the Unit
testing is to get the clear picture of the system functionalities. The size and the
type of file it can accept and also the constraints can be analysed in this part.

5.2 INTEGRATION TESTING
Integration testing is a phase of software testing in which individual
software modules are combined and tested as a group. Integration testing
follows unit testing.

S.No. FUNCTIO SAMPLE EXPECTE OBSERVED STATUS Error
NS INPUT D RESULT
RESULTS Messages
1 Send File Sent Sent Success Null
Function
2 Receive File Sent Sent Success Null
Function
3 Error Corrupted file Error Error message Success Null
Function message
4 Control File Warning Warning Success Null
Function message message
5 Control Corrupted Warning Controlled Failure Corupted file


Function File message not found
6 Send Unsupported file Warning File failed Failure Error: File
Function format Message content cannot
be displayed

Table 5.2: Integration Testing on Congestion Control

CHAPTER 6
RESULTS AND OBSERVATIONS


6. RESULTS AND OBSERVATIONS

The result of the project is that the congestion control for processing
constrained networks. Here reduce both bandwidth and CPU Process which
can be a bottleneck for network flow

6.1 ADVANTAGE
Advances in network technology enable fast pace increase in physical
bandwidth whose growth rate has far surpassed that of other resources such as
CPU and memory bus. This phenomenon causes network bottlenecks to shift


from bandwidth to other resources. The rise of new applications that require
in-network processing hastens this shift,too.


CHAPTER 7
CONCLUSION AND EXTENSION
OF WORK


7. CONCLUSION AND EXTENSION OF WORK
Have shown that under DRQ the average equilibrium throughput for TCP Reno
sources becomes proportionally fair in the dual-resource environment.
Moreover, such an equilibrium is unique and almost always exists, more
specifically, as long as the per-flow steady-state average TCP window size (or
per-flow bandwidth-delay product) is sustainable at a value greater than or
equal to 2 packets. DRQ significantly outperforms RED-RED scheme while
maintaining a certain level of fairness. DRQ is scalable to a large number of
flows and incrementally deployable since it does not require any change in end-
host TCP stacks and builds on an ordinary RED queue. The throughput gain
achieved by DRQ over RED-RED comes mostly from two features of its
marking scheme. The weighted marking at a CPU queue (in proportion to
processing densities of flows) yields fair sharing of CPU cycles whenever this
resource is scarce, which consequently, results in overall throughput increase.
Second, the inter-resource marking, which is a unique feature of DRQ, gives
extra penalty to flows that traverses more number of resources, which also
results in overall throughput increase. We show by simulation that even a
partial deployment of DRQ is beneficial to increasing performance when it is
implemented on a few selected locations where special innetwork processing
services (e.g., media translation, protocol conversion, security and PEP) are
enabled.

APPENDIX


Table A-1. Requirements Traceability Matrix

Functional Requirement Implemented in Tested in

CAT.FR1 ../src/cat.ns:23 test_plan.sgm:429




CGI.CHANGE-HTML- ../src/html_substitutor.ns:20 test_plan.sgm:753
TEMPLATES.FR1

TEMPLATES.FR2

TEMPLATES.FR3

TEMPLATES.FR4

CGI.EDIT.FR1 ../src/cgi_switchboard.ns:208 test_plan.sgm:998

CGI.EDIT.FR2 ../src/cgi_edit_form.ns:27 test_plan.sgm:1012


../src/cgi_edit_form.ns:34


CGI.EDIT.FR5 ../src/cgi_edit_results.ns:60 test_plan.sgm:1021

CGI.FREEQUERY.FR1 ../src/cgi_switchboard.ns:201 test_plan.sgm:853


CGI.FREEQUERY.FR3 ../src/cgi_free_query_output.ns:107 test_plan.sgm:859




CGI.LIST.FR1 ../src/cgi_switchboard.ns:24 test_plan.sgm:793

CGI.LIST.FR2 ../src/cgi_cat_output.ns:79 test_plan.sgm:799

CGI.LIST.FR3 ../src/issue_to_html_transformer.ns:54 test_plan.sgm:799

CGI.LIST.FR4 ../src/cgi_cat_output.ns:47 test_plan.sgm:818

CGI.QUERY.FR1 ../src/cgi_switchboard.ns:119 test_plan.sgm:901

CGI.QUERY.FR2 ../src/query_form_generator.ns:15 test_plan.sgm:901

CGI.QUERY.FR3 ../src/query_form_generator.ns:36 test_plan.sgm:910


REFERENCES

7. References
1. Y. Gottlieb and L. Peterson, “A comparative study of extensible
routers,” in Proc. of IEEE OpenArch, June 2002, pp. 51–62.
2. G. Memik, M. Smith, and W. Hu, “NetBench: A benchmarking
suite for network processors,” in Proc. of IEEE International
Conference on Computer-Aided Design, San Jose, CA, Nov. 2006


3. S. Chong, M. Shin, J. Mo, and H.-W. Lee, “Flow control with
processing constraint,” IEEE Commun. Lett., 2005, to be
published.


Tcp performance Final Report

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (19)

Destacado

Destacado (18)

Similar a Tcp performance Final Report

Similar a Tcp performance Final Report (20)

Más de ambitlick

Más de ambitlick (20)

Último

Último (20)

Tcp performance Final Report