Dynamic Management of 802.11 Based Network Buffer

Dynamic Management Of 802.11 Based Network Buffer

CHAPTER 1

INTRODUCTION

Wireless networks face a number of fundamental issues that do not arise in wired

networks. This project demonstrates that the use of fixed size buffers in 802.11 networks

inevitably leads to either undesirable channel under-utilization or unnecessary high

delays. In communication networks, buffers are used to accommodate short-term packet

bursts so as to mitigate packet drops and to maintain high link efficiency. Packets are

queued if too many packets arrive in a sufficiently short interval of time during which a

network device lacks the capacity to process all of them immediately. This project

presents two dynamic buffer sizing algorithms that achieve high throughput while

maintaining low delay across a wide range of network conditions. This project focuses on

dynamically varying the size of network buffer to achieve throughput while maintaining

low delay across the network.

Sizing wired buffers is to set buffer sizes to be the product of the bandwidth and

the average delay of the flows utilizing this link, namely the Bandwidth-Delay Product

(BDP). However, the sizing of buffers in wireless networks (especially those based on

IEEE 802.11/802.11e) appears to have received very little attention within the networking

community. In this project we consider this problem and propose solutions for it.

Consequently, the buffering requirements at each station would also differ,

depending on the number of other active stations in the WLAN. In addition to variations

in the mean service time, the distribution of packet service times is also strongly

dependent on the WLAN offered load. This directly affects the burstiness of

transmissions and hence buffering requirements. Second, wireless stations dynamically

adjust the physical transmission rate/modulation used in order to regulate noncongestive

channel losses. This rate adaptation, whereby the transmit rate may change by a factor of

50 or more (e.g. from 1 to 54 Mb/s in 802.11a/g), may induce large and rapid variations

in required buffer sizes. Third, the ongoing 802.11n standards process proposes to

improve throughput efficiency by the use of large frames formed by aggregation of

multiple packets. This acts to couple throughput efficiency and buffer sizing in a new way

Dept. of CS&E, BTLITM, Bangalore. 1


since the latter directly affects the availability of sufficient packets for aggregation into

large frames.

1.1 PURPOSE

The key consideration from the observations is that there exists no fixed buffer

size capable of ensuring both high throughput efficiency and reasonable delay across the

range of physical rates and offered loads experienced by modern WLANs.[2] Any fixed

choice of buffer size necessarily carries the cost of significantly reduced throughput

efficiency and/or excessive queuing delays. This leads naturally therefore to the

consideration of adaptive approaches to buffer sizing, which dynamically adjust the

buffer size in response to changing network conditions to ensure both high utilization of

the wireless link while avoiding unnecessarily long queuing delays.

It follows from these observations that, among other things, there does not exist a

fixed buffer size that can be used for sizing buffers in WLANs. This leads naturally to

consideration of dynamic buffer-sizing strategies that adapt to changing conditions.

1.2 SCOPE

Wireless communication in 802.11 networks is time-varying in nature, i.e., the

mean service time and the distribution of service time at a wireless station vary in time.

The variations are primarily due to (i) changes in the number of active wireless stations

and their load (i.e. offered load on the WLAN) and (ii) changes in the physical transmit

rate used (i.e. in response to changing radio channel conditions)

The following are the scope of the project.

1) Based on traffic load conditions, we propose two new algorithms and emulate

them on the LAN network;

2) Check the buffer occupancy and the throughput of the proposed solution.



1.3 ORGANISATION OF THE REPORT

Chapter 2: gives overall description of literature survey, description and flaws in

the existing system.

Chapter 3: discusses system analysis, the modules description and the system

requirements.

Chapter 4: discusses system architectures, flow chart and overall design of the

system.

Chapter 5: explains the class diagram, data flow diagram and sequence diagram

implemented.

Chapter 6: gives the details of implementation of the model designed.

Chapter 7: gives unit testing of algorithms, integration testing and the system

validation testing.

Chapter 8: gives the details of results and snapshots.

Chapter 9: finally concludes with the future enhancement by giving a brief

summary of the entire work.

CHAPTER 2



LITERATURE SURVEY

Literature survey is mainly carried out in order to analyze the background of the

current project which helps to find out flaws in the existing system & guides on which

unsolved problems we can workout. So, the following topics not only illustrate the

background of the project but also uncover the problems and flaws which motivated to

propose solutions and work on this project.

2.1 DYNAMICS OF TCP'S CONGESTION CONTROL

ALGORITHM

All Internet routers contain buffers to hold packets during times of congestion.

Today, the size of the buffers is determined by the dynamics of TCP's congestion control

algorithm. In particular, the goal is to make sure that when a link is congested, it is busy

100% of the time; which is equivalent to making sure its buffer never goes empty.

A widely used rule-of-thumb states that each link needs a buffer of size B = RTT

* C, where RTT is the average round-trip time of a flow passing across the link, and C is

the data rate of the link. For example, a 10 GB/s router line card needs approximately

250ms * 10 GB/s = 2.5Gbits of buffers; and the amount of buffering grows linearly with

the line-rate. Such large buffers are challenging for router manufacturers, who must use

large, slow, off-chip DRAMs. And queuing delays can be long, have high variance, and

may destabilize the congestion control algorithms.

The classical rule of thumb for sizing wired buffers is to set buffer sizes to be the

product of the bandwidth and the average delay of the flows utilizing this link, namely the

Bandwidth-Delay Product (BDP)[4]. Surprisingly, however the sizing of buffers in

wireless networks (especially those based on 802.11/802.11e) appears to have received

very little attention within the networking community. Exceptions include the recent work

in On Buffer Sizing for Voice in 802.11 WLANs relating to buffer sizing for voice traffic

in 802.11e WLANs, work in Understanding TCP fairness over Wireless LAN which

considers the impact of buffer sizing on TCP upload/download fairness, and work in



Impact of 802.11e EDCA on mixed TCP-based applications which is related to 802.11e

parameter settings.

2.2 DISTRIBUTED COORDINATED FUNCTION OF IEEE

802.11

IEEE 802.11a/b/g WLANs all share a common MAC algorithm called the

Distributed Coordinated Function (DCF)[3] which is a CSMA/CA based algorithm. On

detecting the wireless medium to be idle for a period DIFS, each wireless station

initializes a backoff counter to a random number selected uniformly from the interval [0,

CW-1] where CW is the contention window. Time is slotted and the backoff Counter is

decremented each slot that the medium is idle. An important feature is that the countdown

halts when the medium is detected busy and only resumes after the medium is idle again

for a period DIFS. On the counter reaching zero, a station transmits a packet. If a collision

occurs (two or more stations transmit simultaneously), CW is doubled and the process

repeated. On a successful transmission, CW is reset to the value CWmin and a new

countdown starts.

The basic 802.11 MAC layer uses the distributed coordination function (DCF) to

share the medium between multiple stations. DCF relies on CSMA/CA and optional

802.11 RTS/CTS to share the medium between stations. This has several limitations:

If many stations attempt to communicate at the same time, many collisions will

occur which will lower the available bandwidth and possibly lead to congestive

collapse.

There are no Quality of Service (QoS) guarantees. In particular, there is no notion

of high or low priority traffic.

Once a station "wins" access to the medium, it may keep the medium for as long

as it chooses.


http://en.wikipedia.org/wiki/Congestive_collapse


http://en.wikipedia.org/wiki/802.11_RTS/CTS

http://en.wikipedia.org/wiki/CSMA/CA


2.3 IEEE 802.11e ENHANCED DISTRIBUTED CHANNEL

ACCESS

The 802.11e standard extends the DCF algorithm (yielding the EDCA) by

allowing the adjustment of MAC parameters that were previously fixed. In particular, the

values of DIFS (called AIFS in 802.11e) and CWmin may be set on a per class basis for

each station. While the full 802.11e standard is not implemented in current commodity

hardware, the EDCA extensions have been widely implemented for some years. The

upcoming standard IEEE 802.11e will provide Quality of Service (QoS) support in

Wireless Local Area Network (WLAN). The contention based channel access method

called Enhanced Distributed Channel Access (EDCA) is considered as the mandatory

mode for Medium Access Control (MAC) in IEEE 802.11e. This project presents an

accurate throughput analytical model for EDCA in saturated situation. The analytical

model is suitable for both basic access and RTS/CTS access mechanisms. It considers the

features in EDCA such as different Arbitration Inter-frame Space (AIFS) and contention

window for different Access Category (AC) and virtual collision for different priority

queue in the same station; and can be easily extended to other features such as

Transmission Opportunity (TXOP), etc. The analytical model is evaluated by extensive

simulation results, and it provides deep understanding of the effect by different parameter

setting to the throughput.

2.4 UNFAIRNESS AMONG TCP FLOW

Consider a WLAN consisting of n client stations each carrying one TCP upload

flow. The TCP ACKs are transmitted by the wireless AP. In this case TCP ACK packets

can be easily queued/dropped due to the fact that the basic 802.11 DCF ensures that

stations win a roughly equal number of transmission opportunities. Namely, while the

data packets for the n flows have an aggregate n/(n + 1) share of the transmission

opportunities the TCP ACKs for the n flows have only a 1/(n+1) share. Issues of this sort

are known to lead to significant unfairness amongst TCP flows but can be readily

resolved using 802.11e functionality by treating TCP ACKs as a separate traffic class

which is assigned higher priority. With regard to throughput efficiency, the algorithms in

this project perform similarly when the DCF is used and when TCP ACKs are prioritized



using the EDCA [3]. Per flow behavior does, of course, differ due to the inherent

unfairness in the DCF and we therefore mainly present results using the EDCA to avoid

flow-level unfairness.

The rule-of-thumb comes from a desire to keep a congested link as busy as

possible, so as to maximize the throughput of the network. We are used to thinking of

sizing queues so as to prevent them from overflowing and losing packets. But TCP's “saw

tooth" congestion control algorithm is designed to fill any buffer, and deliberately causes

occasional loss to provide feedback to the sender. No matter how big we make the buffers

at a bottleneck link, TCP will cause the buyer to overflow. Router buffers are sized so that

when TCP flows pass through them, they don't underflow and lose throughput; and this is

where the rule-of-thumb comes from. The metric we will use is throughput, and our goal

is to determine the size of the buffer so as to maximize throughput of a bottleneck link.

The basic idea is that when a router has packets buffered, its outgoing link is always busy.

If the outgoing link is a bottleneck, then we want to keep it busy as much of the time as

possible, and so we just need to make sure the buffer never underflows and goes empty.

The rule-of-thumb is the amount of buffering needed by a single TCP flow, so that

the buffer at the bottleneck link never underflows, and so the router doesn't lose

throughput.

The rule-of-thumb comes from the dynamics of TCP's congestion control

algorithm. In particular, a single TCP flow passing through a bottleneck link requires a

buffer size equal to the bandwidth-delay product in order to prevent the link from going

idle and thereby losing throughput. Here, we will give a quick intuitive explanation of

where the rule of-thumb comes from in particular, why this is just the right amount of

buffering if the router carried just one long-lived TCP flow. This leads naturally to

consideration of dynamic buffer sizing strategies that adapt to changing conditions. In this

project we demonstrate the major performance costs associated with the use of fixed

buffer sizes in 802.11WLANs and present two novel dynamic buffer sizing algorithms

that achieve significant performance gains.



Figure 2.1: Single flow topology consisting of an access link of latency Lacc and link

capacity Cacc and a bottleneck link of capacity C and latency L.

Consider the simple topology in Figure in which a single TCP source sends an

infinite amount of data with packets of constant size. The flow passes through a single

router, and the sender's access link is much faster than the receiver's bottleneck link of

capacity C, causing packets to be queued at the router. The propagation time between

sender and receiver (and vice versa) is denoted by Tp. Assume that the TCP flow has

settled into the additive-increase and multiplicative-decrease (AIMD) congestion

avoidance mode.

The sender transmits a packet each time it receives an ACK, and gradually

increases the number of outstanding packets (the window size), which causes the buffer to

gradually fill up. Eventually a packet is dropped, and the sender doesn't receive an ACK.

It halves the window size and pauses. The sender now has too many packets outstanding

in the network: it sent an amount equal to the old window. But now the window size has

halved. It must therefore pause while it waits for ACKs to arrive before it can resume

transmitting.

The key to sizing the buffer is to make sure that while the sender pauses, the

router buffer doesn't go empty and force the bottleneck link to go idle. By determining the

rate at which the buffer drains, we can determine the size of the reservoir needed to

prevent it from going empty. It turns out that this is equal to the distance (in bytes)

between the peak and trough of the saw tooth representing the TCP window size. We will

show later that this corresponds to the rule-of-thumb: B = RTT*C.



This project considers the sizing of buffers in 802.11/802.11e based WLANs and

focus on single hop WLANs since these are rapidly becoming ubiquitous as the last hop

on home and office networks as well as in so called “hot spots” in airports and hotels, but

note that the proposed schemes can be easily applied in multi-hop wireless networks. The

main focus in this project is on TCP traffic since this continues to constitute the bulk of

traffic in modern networks (80–90% of current Internet traffic and also of WLAN traffic),

although this project extend consideration to UDP traffic at various points during the

discussion and also during our experimental tests. Compared to sizing buffers in wired

routers, a number of fundamental new issues arise when considering 802.11-based

networks.

Firstly, unlike wired networks, wireless transmissions are inherently broadcast in

nature which leads to the packet service times at different stations in a WLAN being

strongly coupled. For example, the basic 802.11 DCF ensures that the wireless stations in

a WLAN win a roughly equal number of transmission opportunities hence, the mean

Packet service time at a station is an order of magnitude longer when 10 other stations are

active than when only a single station is active. Consequently, the buffering requirements

at each station would also differ, depending on the number of other active stations in the

WLAN. In addition to variations in the mean service time, the distribution of packet

service times is also strongly dependent on the WLAN offered load.

This directly affects the burstiness of transmissions and so buffering required.

Secondly, wireless stations dynamically adjust the physical transmission rate/modulation

used in order to regulate non-congestive channel losses. This rate adaptation, whereby the

transmit rate may change by a factor of 50 or more (e.g. from 1Mbps to 54Mbps in

802.11a/g), may induce large and rapid variations in required buffer sizes. Thirdly, the

ongoing 802.11n standards process proposes to improve throughput efficiency by the use

of large frames formed by aggregation of multiple packets. This acts to couple throughput

efficiency and buffer sizing in a new way since the latter directly affects the availability

of sufficient packets for aggregation into large frames.



It follows from these observations that, amongst other things, there does not exist

a fixed buffer size which can be used for sizing buffers in WLANs. This leads naturally to

consideration of dynamic buffer sizing strategies that adapt to changing conditions. In this

project we demonstrate the major performance costs associated with the use of fixed

buffer sizes in 802.11WLANs and present two novel dynamic buffer sizing algorithms

that achieve significant performance gains.

The stability of the feedback loop induced by the adaptation is analyzed, including

when cascaded with the feedback loop created by TCP congestion control action. The

proposed dynamic buffer sizing algorithms are computationally cheap and suited to

implementation on standard hardware. In this project, we present experimental

measurements demonstrating the utility of the proposed algorithms in a testbed located in

office environment and with realistic traffic. This latter includes a mix of TCP and UDP

traffic, a mix of uploads and downloads, and a mix of connection sizes.

2.5 PROBLEM DEFINITION AND PROPOSED SYSTEM

2.5.1 PROBLEMS WITH EXISTING BASIC 802.11

The basic 802.11 MAC layer uses the distributed coordination function (DCF) to

share the medium between multiple stations. DCF relies on CSMA/CA and optional

802.11 RTS/CTS to share the medium between stations.

This has several limitations:

If many stations attempt to communicate at the same time, many collisions will

occur which will lower the available bandwidth and possibly lead to congestive

collapse.

There are no Quality of Service (QoS) guarantees. In particular, there is no notion

of high or low priority traffic.

Once a station "wins" access to the medium, it may keep the medium for as long

as it chooses.

The original 802.11 MAC defines another coordination function called the point

coordination function (PCF). This is available only in "infrastructure" mode, where

stations are connected to the network through an Access Point (AP). This mode is

optional and only very few APs or Wi-Fi adapters actually implement it. APs send beacon


http://en.wikipedia.org/wiki/Electric_beacon#Wi-Fi

http://en.wikipedia.org/wiki/Wireless_access_point



http://en.wikipedia.org/wiki/802.11_RTS/CTS

http://en.wikipedia.org/wiki/CSMA/CA


frames at regular intervals (usually every 0.1 second). Between these beacon frames, PCF

defines two periods: the Contention Free Period (CFP) and the Contention Period (CP). In

the CP, DCF is used. In the CFP, the AP sends Contention-Free-Poll (CF-Poll) packets to

each station, one at a time, to give them the right to send a packet. The AP is the

coordinator. Although this allows for a better management of QoS, PCF does not define

classes of traffic as is common with other QoS systems.

The 802.11e enhances the DCF and the PCF, through a new coordination

function: the hybrid coordination function (HCF). Within the HCF, there are two methods

of channel access, similar to those defined in the legacy 802.11 MAC: HCF Controlled

Channel Access (HCCA) and Enhanced Distributed Channel Access (EDCA). Both

EDCA and HCCA define Traffic Categories (TC). For example, emails could be assigned

to a low priority class, and Voice over Wireless LAN (VoWLAN) could be assigned to a

high priority class.

With EDCA, high priority traffic has a higher chance of being sent than low

priority traffic: a station with high priority traffic waits a little less before it sends its

packet, on average, than a station with low priority traffic. This is accomplished by using

a shorter contention window (CW) and shorter arbitration inter-frame space (AIFS) for

higher priority packets. In addition, EDCA provides contention-free access to the channel

for a period called a Transmit Opportunity (TXOP). A TXOP is a bounded time interval

during which a station can send as many frames as possible (as long as the duration of the

transmissions does not extend beyond the maximum duration of the TXOP). If a frame is

too large to be transmitted in a single TXOP, it should be fragmented into smaller frames.

The use of TXOPs reduces the problem of low rate stations gaining an inordinate amount

of channel time in the legacy 802.11 DCF MAC. A TXOP time interval of 0 means it is

limited to a single MAC service data unit (MSDU) or MAC management protocol data

unit (MMPDU).

The sizing Internet router buffers is the BDP rule proposed in “High Performance

TCP in ANSNET” Recently, in Sizing Router Buffers it is argued that the BDP rule may

be overly conservative on links shared by a large number of flows. In this case, it is


http://en.wikipedia.org/wiki/MAC_service_data_unit

http://en.wikipedia.org/wiki/Distributed_Coordination_Function

http://en.wikipedia.org/wiki/802.11

http://en.wikipedia.org/wiki/Arbitration_inter-frame_space

http://en.wikipedia.org/wiki/Email


unlikely that TCP congestion window sizes evolve synchronously, and due to statistical

multiplexing of cwnd backoff, the combined buffer requirement can be considerably less

than the BDP. The analysis in Sizing Router Buffers suggests that it may be sufficient to

size buffers as BDP/sqrt (n). This work is extended and considered the performance of

TCP congestion control with many connections under the assumption of small, medium,

and large buffer sizes. Several authors have pointed out that the value can be difficult to

determine for realistic traffic patterns, which not only include a mix of connections sizes

and RTTs, but can also be strongly time-varying. It is observed from measurements on a

production link that traffic patterns vary significantly over time and may contain a

complex mix of flow connection lengths and RTTs. It is demonstrated that the use of very

small buffers can lead to an excessive loss rate. Motivated by these observations, in

Sizing Internet Router Buffers and Adaptive Tuning of Drop-Tail Buffers for Reducing

Queuing Delays, a measurement-based adaptive buffer-size tuning method is proposed.

2.5.2 PROPOSED SOLUTION & ADVANTAGES

In this project we design and implement the solutions for sizing of buffers in

802.11 networks. We demonstrate that the use of fixed-size buffers in 802.11 networks

inevitably leads to either undesirable channel underutilization or unnecessary high delays.

We present two novel dynamic buffer-sizing algorithms that achieve high throughput

while maintaining low delay across a wide range of network conditions. Compared to

sizing buffers in wired routers, a number of fundamental new issues arise when

considering 802.11-based networks. First, unlike wired networks, wireless transmissions

are inherently broadcast in nature, which leads to the packet service times at different

stations in a WLAN being strongly coupled. For example, the basic 802.11 DCF ensures

that the wireless stations in a WLAN win a roughly equal number of transmission

opportunities, hence the mean packet service time at a station is an order of magnitude

longer when 10 other stations are active than when only a single station is active.



CHAPTER 3

SYSTEM ANALYSIS

3.1 MODULE DESCRIPTION

The system modules categorized into two main sub components, Packet Generator

and the Router. Packet Generator component will generate packets and sends to the

Router component using the wireless network. Router component process the packets

coming from the wireless network and write all packets to a file. There exist size varying

buffer at router component that ensure both high utilization of the wireless link while

avoiding unnecessarily long queuing delays.

The router system modules categorized into four main sub components

Packet Listener

Packet Queue

Packet Processor

Packet Queue Controller

3.2 SYSTEM REQUIREMENT SPECIFICATIONS

System requirement Specification is a fundamental document, which forms the

foundation of the software development process. It not only lists the requirements of a

system but also has a description of its major feature. An SRS is basically an

organization's understanding (in writing) of a customer or potential client's system

requirements and dependencies at a particular point in time (usually) prior to any actual

design or development work. It's a two-way insurance policy that assures that both the

client and the organization understand the other's requirements from that perspective at a

given point in time. The SRS also functions as a blueprint for completing a project with

as little cost growth as possible.

The SRS is often referred to as the "parent" document because all subsequent

project management documents, such as design specifications, statements of work,

software architecture specifications, testing and validation plans, and documentation



plans, are related to it. It is important to note that an SRS contains functional and

nonfunctional requirements only; it doesn't offer design suggestions, possible solutions to

technology or business issues, or any other information other than what the development

team understands the customer's system requirements to be.

3.2.1 HARDWARE REQUIREMENTS

Processors: Pentium IV or higher version.

RAM: 64 MB or higher.

Storage: 20GB or higher.

3.2. 2 SOFTWARE REQUIREMENTS

Platform: Windows XP.

Language: Jdk 1.6.

Visual Interface: Swing & Awt.

IDE/tool: Netbean IDE 6.9.1

3.2.3 FUNCTIONAL REQUIREMENTS

Functional Requirement defines a function of a software system and how the

system must behave when presented with specific inputs or conditions. These may

include calculations, data manipulation and processing and other specific functionality. In

this system following are the functional requirements:-

Simulate Buffer occupancy problem in a test bed environment.

Implement eBDP algorithm in the router in the test bed environment.

Implement the ALT algorithm in the router in the test bed environment.

Compare the performance of the algorithm.



3.2.4 NON-FUNCTIONAL REQUIREMENTS

Non functional requirements are the requirements which are not directly

concerned with the specific function delivered by the system. They specify the criteria

that can be used to judge the operation of a system rather than specific behaviors. They

may relate to emergent system properties such as reliability, response time and store

occupancy. Non functional requirements arise through the user needs, because of budget

constraints, organizational policies, the need for interoperability with other software and

hardware systems or because of external factors such as:-

Product Requirements

Organizational Requirements

User Requirements

Basic Operational Requirements

Performance Analysis module will be implemented to analyze the newly developed

system.



CHAPTER 4

SYSTEM DESIGN

The Design Process is nothing but the representation of the system, or is a process

of producing a model, which will be used to develop or build the system. The input for

the design process is the SRS and output is “the design of the proposed system”. While

the SRS is entirely in problem domain, design is the first step in moving from the

problem domain to solution domain. Design is essentially a bridge between the

representation and final solution for satisfying the requirements. Thus, it is essentially a

blueprint for a solution for the system.

The software design sits at the technical kernel of the software engineering

process and it is applied regardless of the development that is used. Once the software

requirements are specified, the software design is the first step of three technical

activities. They are Design, Coding and Testing.

The design process for software system often has two levels. At first level, the

focus is on deciding which modules are needed for the system, the specifications of these

modules and how the modules will be interconnected. This is what is called “Top Level

Design” and the name christened as “System Design”.

Systems design is the process of defining the architecture, components, modules,

interfaces, and data for a system to satisfy specified requirements. One could see it as the

application of systems theory to product development. There is some overlap with the

disciplines of systems analysis, systems architecture and systems engineering.

4.1 DESIGN METHODOLOGY

System development method is a process through which a product will get

completed or a product gets rid from any problem. Software development process is

described as a number of phases, procedures and steps that gives the complete software. It

follows series of steps which is used for product progress. The development method

followed in this project is waterfall model.



Figure 4.1: Waterfall model

4.1.1 MODEL PHASES

The waterfall model is a sequential software development process, in which

progress is seen as flowing steadily downwards (like a waterfall) through the phases of

Requirement initiation, Analysis, Design, Implementation, Testing and maintenance.

Requirement Analysis: This phase is concerned about collection of requirement of the

system. This process involves generating document and requirement review.

System Design: Keeping the requirements in mind the system specifications are

translated in to a software representation. In this phase the designer emphasizes on:-

algorithm, data structure, software architecture etc.

Coding: In this phase programmer starts his coding in order to give a full sketch of

product. In other words system specifications are only converted in to machine readable

compute code.



Implementation: The implementation phase involves the actual coding or programming

of the software. The output of this phase is typically the library, executables, user

manuals and additional software documentation

Testing: In this phase all programs (models) are integrated and tested to ensure that the

complete system meets the software requirements. The testing is concerned with

verification and validation.

Maintenance: The maintenance phase is the longest phase in which the software is

updated to fulfill the changing customer need, adapt to accommodate change in the

external environment, correct errors and oversights previously undetected in the testing

phase, enhance the efficiency of the software.

4.1.2 REASON FOR CHOOSING WATERFALL MODEL

Clear project objectives.

Stable project requirements.

Progress of system is measurable.

Strict sign-off requirements.

Helps you to be perfect.

Logic of software development is clearly understood.

Production of a formal specification

Better resource allocation.

Improves quality. The emphasis on requirements and design before writing a

single line of code ensures minimal wastage of time and effort and reduces the

risk of schedule slippage.

Less human resources required as once one phase is finished those people can

start working on to the next phase.



4.2 SYSTEM ARCHITECTURE

The system architecture of the test bed environment is given below

Figure 4.2: system architecture

The system architecture consists of two sub components, Packet Generator and the

Router.

Packet Generator component will generate packets and sends to the Router

component using the wireless network.

Router component process the packets coming from the wireless network and

write all packets to a file. There exist size varying buffer at router component that ensure

both high utilization of the wireless link while avoiding unnecessarily long queuing

delays.



4.3 SYSTEM FLOWCHART

A flowchart is a common type of diagram, which represents an algorithm or

process, shows the flow of control through an algorithm, allowing a reader to determine

what operations will be performed, in what order, and under what circumstances, but not

what kinds of data will be input to and output from the system, nor where the data will

come from and go to, nor where the data will be stored (all of which are shown on a

DFD).

The system flow is described below:

1) User starts the Router in one of algorithm mode

2) Send Data packets to the Router

3) Check the buffer occupancy.

4) Check the throughput of the system.

The router’s listening port, bandwidth, average delay values must be entered to

initially configure the router. The configuration settings are used to select one of the three

algorithms to start the router. This project consists of one static algorithm BDP for

demonstrating the buffer problem in the router for wired local area network buffers, to set

buffer sizes to be the product of the bandwidth and the average delay of the flows

utilizing the link, namely the Bandwidth-Delay Product (BDP). The project also consists

of two dynamic algorithms eBDP and ALT for solving the buffer problem in the wireless

network. The data sender module continuously sends the data packet chunks to the router.

The router starts processing each incoming packets at the router port in the mean while if

the processing unit is busy, it stores the incoming packet in the buffer. So the packet

dropped packets and throughput is measured. The system flow chart is shown below.


http://en.wikipedia.org/wiki/Process

http://en.wikipedia.org/wiki/Algorithm

http://en.wikipedia.org/wiki/Diagram


Figure 4.3: system flow chart.


START

Configure Router Bandwidth and Delay

Start in Router in either of BDP, eBDP or ALT mode

Send Data Packet from Data Sender

Check Buffer Occupancy, Throughput

END


CHAPTER 5

DETAILED DESIGN

Detailed design is the process of defining the components, modules, interfaces,

and data for a system to satisfy specified requirements. System model is a phase where an

internal logic of each of these modules specified in high-level design is decided. In this

phase, further details and algorithmic design of each of these modules is specified. Other

low-level components and subcomponents are also described as well. This chapter also

discusses about the control flow in the software with much more detail about software

modules by clarifying the details about each function with functionality, purpose, input

and output.

5.1 ARCHITECTURE OF ROUTER COMPONENT

The architecture of the router component is given below

Figure 5.1: Architecture of router component.



The router consists of following components.

Packet Listener: This module listens for packet from network and sends to

PacketQueue. If the space is not there in the packet queue, the packet is dropped.

Packet Queue: Packet Queue is just a storage space for the packets.

Packet Processor: This module removes the packet one by one from the queue

and processes them by writing to file.

Packet Queue Controller: This module controls the Packet queue size ,it uses 3

different algorithm engines, BDP , eBDP and ALT to determine the packet size.

Packet Queue controller also stores essential performance statistics like packet

dropped etc.

5.2 DATA FLOW DIAGRAM OF THE SYSTEM

A data-flow diagram (DFD) is a graphical representation of the "flow" of data

through an information system. DFDs can also be used for the visualization of data

processing (structured design). On a DFD, data items flow from an external data source or

an internal data store to an internal data store or an external data sink, via an internal

process.

5.2.1 LEVEL 0 DATA FLOW DIAGRAM

A context-level or level 0 data flow diagram shows the interaction between the

system and external agents which act as data sources and data sinks. On the context

diagram (also known as the Level 0 DFD) the system's interactions with the outside world

are modeled purely in terms of data flows across the system boundary. The context

diagram shows the entire system as a single process, and gives no clues as to its internal

organization



Figure 5.2: A context-level interaction between the system and external agents.

Packet generator generates packets and forwards via router to the Packet consumer.

5.2.2 LEVEL 1 DATA FLOW DIAGRAM

The Level 1 DFD shows how the system is divided into sub-systems (processes),

each of which deals with one or more of the data flows to or from an external agent, and

which together provide all of the functionality of the system as a whole. It also identifies

internal data stores that must be present in order for the system to do its job, and shows

the flow of data between the various parts of the system.

The routing process is further split into sub process and mentioned in the project.

Figure 5.3: A context-level routing process split into sub process.



Packet generator generates data and pumps to Router. The Router module accepts

packets, queue it in the buffer. The buffer size is adjusted by buffer size adjustor. The

queued packets are taken and sent to packet consumers,

5.3 USE CASE DIAGRAM

A use case diagram is a type of behavioral diagram created from a Use-case

analysis. Its purpose is to present a graphical overview of the functionality provided by a

system in terms of actors, their goals (represented as use cases), and any dependencies

between those use cases. The use case of the proposed system is given below

Figure 5.4: use case diagram of the proposed system.


http://en.wikipedia.org/wiki/Use_case

http://en.wikipedia.org/wiki/Actor_(UML)

http://en.wikipedia.org/wiki/Use-case_analysis

http://en.wikipedia.org/wiki/Use-case_analysis


The use case involves two users. User can create test bed environment and check the

performance of the router buffer sizing in terms of buffer occupancy and the throughput

of the system.

5.4 CLASS DIAGRAM

A class diagram in the Unified Modeling Language (UML) is a type of static structure

diagram that describes the structure of a system by showing the system's classes, their

attributes, and the relationships between the classes. The class diagram of the system is

given below

Figure 5.5: class diagram of the system.

5.5 SEQUENCE DIAGRAM OF SYSTEM OPERATION


http://en.wikipedia.org/wiki/Class_(computer_science)

http://en.wikipedia.org/wiki/Unified_Modeling_Language


A sequence diagram in Unified Modeling Language (UML) is a kind of

interaction diagram that shows how processes operate with one another and in what order.

It is a construct of a Message Sequence Chart.

Figure 5.6: Router Start up Sequence.

Figure 5.7: Router Behavior on incoming packet for BDP module.


http://en.wikipedia.org/wiki/Message_Sequence_Chart

http://en.wikipedia.org/wiki/Interaction_diagram

http://en.wikipedia.org/wiki/Unified_Modeling_Language


Figure 5.8: Router Behavior on incoming packet for eBDP module.

Figure 5.9: Router Behavior on incoming packet for ALT module.

CHAPTER 6



SYSTEM IMPLEMENTATION

The purpose of this chapter is to give a brief description about the various

implementation tools like the programming language, details of each module

implementation. The goal of the implementation phase is to translate the design of the

system produced during the design phase into code in a given programming language; it

also focuses on the modules used for the implementation. This involves the details of the

methods and interfaces used and their integration. Implementation of any software is

always preceded by important decisions regarding selection of the platform, the language

used etc. These decisions are often influenced by several factors such as the real

environment in which the system works the speed that is required, security concerns,

other implementation specific details etc

6.1 TECHNOLOGY USED

6.1.1 NETBEAN IDE 6.9.1

Netbean is a multi-language software development environment comprising an

integrated development environment (IDE) and an extensible plug-in system. It is written

primarily in Java and can be used to develop applications in Java and, by means of the

various plug-ins, in other languages as well, including C, C++, COBOL, Python, Perl,

PHP, and others. Netbean employs plug-ins in order to provide all of its functionality on

top of (and including) the runtime system, in contrast to some other applications where

functionality is typically hard coded.

The Netbean SDK includes the Netbean java development tools (JDT), offering an

IDE with a built-in incremental Java compiler and a full model of the Java source files.

This allows for advanced refactoring techniques and code analysis. The IDE also makes

use of a workspace, in this case a set of metadata over a flat file space allowing external

file modifications as long as the corresponding workspace "resource" is refreshed

afterwards.

6.1.2 SWING


http://en.wikipedia.org/wiki/Metadata

http://en.wikipedia.org/wiki/Refactor

http://en.wikipedia.org/wiki/Incremental_compiler

http://en.wikipedia.org/wiki/Hard_code

http://en.wikipedia.org/wiki/PHP

http://en.wikipedia.org/wiki/Perl

http://en.wikipedia.org/wiki/Python_(programming_language)

http://en.wikipedia.org/wiki/COBOL

http://en.wikipedia.org/wiki/C%2B%2B

http://en.wikipedia.org/wiki/C_(programming_language)

http://en.wikipedia.org/wiki/Programming_language

http://en.wikipedia.org/wiki/Java_(programming_language)

http://en.wikipedia.org/wiki/Plug-in_(computing)

http://en.wikipedia.org/wiki/Integrated_development_environment

http://en.wikipedia.org/wiki/Integrated_development_environment

http://en.wikipedia.org/wiki/Software_development_environment


The Java Foundation Classes (JFC) consists of five major parts: AWT, Swing, and

Accessibility, Java 2D, and Drag and Drop. Java 2D has become an integral part of AWT,

Swing is built on top of AWT, and Accessibility support is built into Swing. The five parts

of JFC are certainly not mutually exclusive, and Swing is expected to merge more deeply

with AWT in future versions of Java. Swing is a set of classes that provides more

powerful and flexible components than are possible with the AWT. In addition to the

familiar components, Swing supplies tabbed panes, scroll panes, trees, and tables. It

provides a single API capable of supporting multiple look-and feels so that developers and

end-users are not locked into a single platform’s look-and-feel. The Swing library makes

heavy use of the MVC software design pattern, which conceptually decouples the data

being viewed from the user interface controls through which it is viewed. Swing possesses

several traits such as.

Platform-independence

Extensibility

Component-oriented

Customizable

Configurable

Platform independence both in terms of its expression and its implementation,

extensibility which allows for the "plugging" of various custom implementations of

specified framework interfaces Users can provide their own custom implementation of

these components to override the default implementations. Component-orientation allows

responding to a well-known set of commands specific to the component. Specifically,

Swing components are Java Beans components, compliant with the Java Beans

Component Architecture specifications. Through customizable feature users will

programmatically customize a standard Swing component by assigning specific borders,

colors, backgrounds, opacities, etc, configurable that allows Swing to respond at runtime

to fundamental changes in its settings. Finally look and feel allows one to specialize the

look and feel of widgets, by modifying the default via runtime parameters deriving from

an existing one, by creating one from scratch, or, beginning with J2SE 5.0, by using the

Look and Feel which is configured with an XML property file.


http://en.wikipedia.org/wiki/XML

http://en.wikipedia.org/wiki/Synth_Look_and_Feel

http://en.wikipedia.org/wiki/Widget_(computing)

http://en.wikipedia.org/wiki/Look_and_feel#Look_and_Feel_in_Widget_Toolkits

http://en.wikipedia.org/wiki/Java_Beans


6.2 PROPOSED ALGORITHMS

This project consists of two dynamic algorithms eBDP and ALT for solving the

buffer problem in the router.

6.2.1 eBDP ALGORITHM

In eBDP algorithm, for each outgoing packet, the service time Tserv is calculated as

follows at the wireless router.

Algorithm 2: MAC operation of the eBDP algorithm.

1. Set the averaging parameter W.

2. for each outgoing packet p do

3. Record service start time ts for p.

4. Wait until receive MAC ACK for p, record service end time te.

5. Calculate service time of p:

6. Tserv = (1-W) tserv + W (te-ts).

7. end for.

By recording the time between a packet arriving at the head of the network

interface queue and being successfully transmitted. Note that this measurement can be

readily implemented in real devices, e.g. by asking the hardware to raise an interrupt on

receipt of a MAC ACK, and incurs only a minor computational burden. Averaging these

per packet service times yields the mean service time Tserv. Based on the Tserv, buffer

size is calculated dynamically as follows

Algorithm 1: Drop tail operation of the eBDP algorithm.



1. Set the target queuing delay Tmax.

2. Set the overprovision parameter c.

3. for each incoming packet p do

4. Calculate QeBDP = min(Tmax/Tserv + c, QeBDPmax),

5. Where Tserv is from MAC algorithm 2.

6. if current queue occupancy < QeBDP , then

7. Put p into queue.

8. else

9. Drop p.

10. end if.

11. end for.

The buffer size increases or decreases dynamically based on the load. For each outgoing

packet, the service time Tserv is calculated and used by the above algorithm.

6.2.2 ALT ALGORITHM

The ALT (Adaptive Limit Tuning) Algorithm is explained below

Algorithm 3: The ALT (Adaptive Limit Tuning) algorithm.

1. Set the initial Queue size, the maximum buffers size Qmax and the minimum

buffer size Qmin.

2. Set the increase step size a1 and decrease step size b1.

3. for every t seconds do

4. Measure the idle time ti.

5. QALT = QALT + a1 (ti) – b1 (t-ti).



6. QALT = min[max(QALT,Qmin),Qmax]

7. end for.

Based on the idle time of queue, the buffer size is varied. If idle time is larger the

buffer size is increased, if idle time is smaller, the buffer size is decreased.

Algorithm begins by considering a simple adaptive algorithm based on the

classical BDP rule. Although this algorithm cannot take advantage of statistical

multiplexing opportunities, it is of interest both for its simplicity and because it will play

a role in the more sophisticated algorithm developed in the next section. As noted

previously, and in contrast to wired networks, in 802.11 WLANs the mean service time is

generally time varying (dependent on WLAN load and the physical transmit rate selected

by a station). Consequently, there does not exist a fixed BDP value.

However, note that a wireless station can measure its own packet service times by

direct observation, i.e., by recording the time between a packet arriving at the head of the

network interface queue ts and being successfully transmitted te (which is indicated by

receiving correctly the corresponding MAC ACK). Note that this measurement can be

readily implemented in real devices, e.g. by asking the hardware to raise an interrupt on

receipt of a MAC ACK, and incurs only a minor computational burden. Averaging these

per packet service times yields the mean service time Tserv. To accommodate the time-

varying nature of the mean service time, this average can be taken over a sliding window.

Consider the use of exponential smoothing Tserv (k + 1) = (1 − W) Tserv (k) + W (te −

ts) to calculate a running average since this has the merit of simplicity and statistical

robustness (by central limit arguments). The choice of smoothing parameterW involves a

trade-off between accommodating time variations and ensuring the accuracy of the

estimate.

While the eBDP algorithm is simple and effective, it is unable to take advantage

of the statistical multiplexing of TCP cwnd backoffs when multiple flows share the same

link. For example, it can be seen that while a buffer size of 338 packets is needed to

maximize throughput with a single download flow, this falls to around 100 packets when

10 download flows share the link.



However, in both cases the eBDP algorithm selects a buffer size of approximately

350 the potential exists to lower the buffer size without loss of throughput. This section

considers the design of a measurement based algorithm (the ALT algorithm) that is

capable of taking advantage of such statistical multiplexing opportunities. However, using

large buffers can lead to high queuing delays, and to ensure low delays the buffer should

be as small as possible. We would therefore like to operate with the smallest buffer size

that ensures sufficiently high link utilization. This intuition suggests the following

approach. We observe the buffer occupancy over an interval of time. If the buffer rarely

empties, we decrease the buffer size.

If the buffer is observed to be empty for too long, we increase the buffer size. Of

course, further work is required to convert this basic intuition into a well-behaved

algorithm suited to practical implementation. Not only do the terms “rarely”, “too long”

etc need to be made precise, but we note that an inner feedback loop is created whereby

buffer size is adjusted depending on the measured link utilization, which in turn depends

on the buffer size. This new feedback loop is in addition to the existing outer feedback

loop created by TCP congestion control, whereby the offered load is adjusted based on

the packet loss rate, which in turn is dependent on buffer size.

Stability analysis of these cascaded loops is therefore essential it introduces the

following Adaptive Limit Tuning (ALT) algorithm. The dynamics and stability of this

algorithm will then be analyzed in later sections. Define a queue occupancy threshold qthr

and let ti(k) (referred to as the idle time) be the duration of time that the queue spends at

or below this threshold in a fixed observation interval t, and tb(k) (referred to as the busy

time) be the corresponding duration spent above the threshold. Note that t = ti(k)+tb(k)

and the aggregate amount of idle/busy time ti and tb over an interval can be readily

observed by a station. Also, the link utilization is lower bounded by tb/(tb + ti). Let q(k)

denote the buffer size during the k-th observation interval. The buffer size is then updated

according to q(k + 1) = q(k) + a1ti(k) − b1tb(k).

Where a1 and b1 are design parameters. Pseudo-code for this ALT algorithm is given in

Algorithm 3. This algorithm seeks to maintain a balance between the time ti that the

queue is idle and the time tb that the queue is busy. That is, it can be seen that when

a1ti(k) = b1tb(k), the buffer size is kept unchanged. When the idle time is larger so that



a1ti(k) > b1tb(k), then the buffer size is increased. Conversely, when the busy time is

large enough that a1ti(k) < b1tb(k), then the buffer size is decreased.

Define a congestion event as an event where the sum of all senders’ TCP cwnd

decreases. This cwnd decrease can be caused by the response of TCP congestion control

to a single packet loss, or multiple packet losses that are lumped together in one RTT.

Define a congestion epoch as the duration between two adjacent congestion events. Let

Q(k) denote the buffer size at the k-th congestion event. (k + 1) = Q(k) + aTI(k) − bTB(k)

Where TI is the “idle” time, i.e., the duration in seconds when the queue occupancy is

below qthr during the k-th congestion epoch, and TB the “busy” time, i.e., the duration

when the queue occupancy is above qthr for the case of a single TCP flow. Notice that a =

a1 and b = b1 where a1 and b1 are parameters used in the ALT algorithm. In the

remainder of this section investigates conditions to guarantee convergence and stability of

the buffer dynamics with TCP traffic, which naturally lead to guidelines for the selection

of a1 and b1. First define some TCP related quantities before proceeding. Consider the

case where TCP flows may have different round-trip times and drops need not be

synchronized.

The proposed buffer sizing algorithms are still valid for DCF since link utilization

and delay considerations remain applicable, as is the availability of service time (for the

eBDP algorithm) and idle/busy time measurements (for the ALT algorithm). In particular,

if the considered buffer is heavily backlogged, to ensure low delays, the buffer size

should be reduced. If otherwise the buffer lies empty, it may be due to that the current

buffer size is too small which causes the TCP source backs off after buffer overflow. To

accommodate more future packets, the buffer size can be increased. Note that increasing

buffer sizes in this case would not lead to high delays but has the potential to improve

throughput. This tradeoff between the throughput and the delays thus holds for both

EDCA and DCF. However, the DCF allocates roughly equal numbers of transmission

opportunities to stations. A consequence of using DCF is thus that when the number of

upload flows increases the uploads may produce enough TCP ACK packets to keep the

AP’s queue saturated.

In fact, once there are two upload flows, TCP becomes unstable due to repeated

timeouts. Therefore, results for up to two uploads, as this is the greatest number of upload



flows where TCP with DCF can exhibit stable behavior using both fixed size buffers and

the A* algorithm. Note that in this case using the A* algorithm on upload stations can

also decrease the delays and maintain high throughput efficiency if their buffers are

frequently backlogged. Also results when there are download flows only (so the

unfairness issue does not exist). Illustrates the throughput and delay performance

achieved using the A* algorithm and fixed 400-packet buffers. As in the EDCA cases, we

can see that the A* algorithm is able to maintain a high throughput efficiency with

comparatively low delays.

6.3 STEPS TO RUN PROJECT

6.3.1 STEPS TO RUN ROUTER

Step 1: Open Netbeans IDE, click on project tab and run the project “Router”.

Step 2: The Router Configuration window is opened, click on Router config tab.

Step 3: Input the appropriate Router configuration values-router listening port,

bandwidth, average delay.

Step 4: Select required radio buttons in the configuration tab to choose one of the three

algorithms to start the router.

Step 5: click on start button to start the router with selected algorithm. The router

graphical user interface is as shown in the snapshot.

6.3.2 STEPS TO RUN DATASENDER

Step 1: click on project tab of Netbeans IDE and run the project “DataSender”.

Step 2: The DataSender Configuration window is opened, click on Router config tab.



Step 3: Input the appropriate DataSender configuration values-Listen port, router port and

the router IP address.

Step 4: Click on config button to configure the DataSender module with the entered

values.

Step 5: click on Start Data Transfer button to start the router for data transfer. The Data

sender graphical user interface is as shown in the snapshot.

.

CHAPTER 7

TESTING

7.1 INTRODUCTION



Software testing is an investigation conducted to provide stakeholders with

information about the quality of the product or service under test. Software Testing also

provides an objective, independent view of the software to allow the business to

appreciate and understand the risks at implementation of the software. Test techniques

include, but are not limited to, the process of executing a program or application with the

intent of finding software bugs.

Software Testing can also be stated as the process of validating and verifying that

a software program/application/product:

1. Meets the business and technical requirements that guided its design and

development;

2. works as expected; and

3. Can be implemented with the same characteristics.

4. To provide operational reliability of the system.

5. To affirm the quality of the project.

Software Testing, depending on the testing method employed can be implemented

at any time in the development process. However, most of the test effort occurs after the

requirements have been defined and the coding process has been completed. As such, the

methodology of the test is governed by the Software Development methodology adopted.

Different software development models will focus the test effort at different points in the

development process. Newer development models, such as Agile, often employ test

driven development and place an increased portion of the testing in the hands of the

developer, before it reaches a formal team of testers. In a more traditional model, most of

the test execution occurs after the requirements have been defined and the coding process

has been completed.

Usability testing is a technique used to evaluate a product by testing it on users.

This can be seen as an irreplaceable usability practice, since it gives direct input on how

real users use the system. This is in contrast with usability inspection methods where

experts use different methods to evaluate a user interface without involving users.

Usability testing focuses on measuring a human-made product’s capacity to meet its



intended purposes. Usability testing is a black-box testing technique. The aim is to

observe people using the product to discover errors and areas of improvement.

7.2 TYPES OF TESTING

7.2.1 UNIT TESTING

Here each module that comprises the overall system is tested individually. Unit

testing focuses verification efforts even in the smallest unit of software design in each

module. This is also known as “Module Testing”. The modules of the system are tested

separately. This testing is carried out in the programming style itself. Unit testing

exercises specific paths in a module’s control structure to ensure complete coverage and

maximum error detection. This test focuses on each module individually, ensuring that it

functions properly as a unit. Hence, the naming is Unit Testing. In this step each module

is found to work satisfactorily as regard to the expected output from the module. This

testing is done to check for the individual block codes for their working. It is done so that

when we carry out functional testing then the units which are part of these functionalities

should have been tested for working.

7.2.2 INTEGRATION TESTING

After successful completion of unit testing or module testing, individual functions

are integrated into classes. Again integration of different classes takes into place and

finally integration of front-end with back-end occurs.

Integration of functions into classes

At the start of coding phase only the functions required in different parts of the

program are developed. Each of the functions is coded and tested independently.

After verification of correctness of the different functions, they are integrated into

their respective classes.

Integration of different classes



Here the different classes are tested independently for their functionality. After

verification of correctness of outputs after testing each class, they are integrated

together and tested again.

Integration of front-end with back-end

The front-end of the project is developed in Java Swing environment. The user

interface is designed to facilitate the user to input various commands to the system

and view the system’s normal and faulty behavior and its outputs. The back-end

code is then integrated with the GUI and tested.

7.2.3 VALIDATION TESTING

At the culmination of integration testing, software is completed and assembled as

a package. Interfacing errors are uncovered and corrected. Validation testing can be

defined in many ways.

7.2.4 OUTPUT TESTING

After performing the validation testing, the next step is output testing of the

proposed system, since no system could be useful if it does not produce the required

output in the specified format. Therefore the output testing involves first of all asking the

users about the format required by them and then to test the output generated or displayed

by the system under consideration. The output format is considered in 2 ways: –

(1) On screen.

(2) Printed format.

7.2.5 USER ACCEPTANCE TESTING

User Acceptance of a system is the key factor to the success of any system.

Performance of an acceptance test is actually the user’s show. User motivation and

knowledge are critical for the successful performance of the system.

The system under consideration is tested for user acceptance by constantly in

touch with the prospective system users at time of developing and making changes

wherever required in regard to the following point:



Input Screen design

Output Screen design

Menu driven system

7.3 TEST CASES FOR SYSTEM TESTING

7.3.1 UNIT TESTING

The following unit testing table shows the functions that were tested at the time of

programming. The first column lists all the functions which were tested and the second

column gives the description of the tests done.

Table 7.1: Unit testing for network listener module

Test case ID 1

Description NetworkListener.start

Input 5060 is configured as listen port

Expected Output Network Listener should starts listening at the listen port

5060

Actual Output Network Listener starts listening at the listen port 5060

Result PASS

Table 7.2: Unit testing for BDPProcessor module



Test case ID 2

Description Calling handlePacket on the BDPProcessor

Input Create a Packet and call handlePacket on the BDPProcessor

Expected Output The buffer occupany must be given as ouput

Actual Output The buffer occupancy is given as output

Result PASS

Table 7.3: Unit testing for eBDPProcessor module

Test case ID 3

Description Calling handlePacket on the eBDPProcessor

Input Create a Packet and call handlePacket on the eBDPProcessor

Expected Output The buffer occupany must be given as ouput


Result PASS

Table 7.4: Unit testing for ALTProcessor module



Test case ID 4

Description Calling handlePacket on the ALTProcessor

Input Create a Packet and call handlePacket on the ALTProcessor

Expected Output The buffer occupancy must be given as output


Result PASS

Table 7.5: Unit testing for datasender module

Test case ID 5

Description Calling DataSender.sendPacket

Input Create a Packet and call sendPacket with the remote ip address

and port

Expected Output The Packet must be sent to the remote ip and port

Actual Output The Packet is sent to remote ip and port

Result PASS

7.3.2 INTEGRATION TESTING



The following integration testing table shows the functions that were combined

into different classes and the class as a whole tested for its functionality. This is important

to check for error-free interaction between various classes, and maintenance of data

integrity.

Following classes was integrated into one component in the server and tested.

1. RouterGUI.

2. BDPProcessor.

3. eBDPProcessor.

4. ALTProcessor.

Table 7.6: Integration test of RouterGUI.start for BDP

Test case ID 6

Description Calling RouterGUI.start

Input Listen port is 5000 and algorithm choose BDP

Expected Output BDP processor is to be started

Actual Output BDP Processor is started.

Result PASS

Table 7.7: Integration test of RouterGUI.start for eBDP

Test case ID 7


Input Listen port is 5000 and algorithm choose eBDP

Expected Output eBDP processor is to be started

Actual Output eBDP Processor is started.

Result PASS



Table 7.8: Integration test of RouterGUI.start for ALT

Test case ID 8


Input Listen port is 5000 and algorithm choosed ALT

Expected Output ALT processor is to be started

Actual Output ALT Processor is started.

Result PASS

Table 7.9: Integration test of NetworkListener.onRecivePacket configured for BDP

Test case ID 9

Description Calling NetworkListener.onRecivePacket

Input Packet sent to listening port and algorithm configured is BDP

Expected Output handlePacket on BDPProcessor with Packet must be called

Actual Output handlePacket on BDPProcessor with Packet is called

Result PASS



Table 7.10: Integration test of NetworkListener.onRecivePacket configured for

eBDP

Test case ID 10


Input Packet sent to listening port and algorithm configured is

eBDP

Expected Output handlePacket on eBDPProcessor with Packet must be called

Actual Output handlePacket on eBDPProcessor with Packet is called

Result PASS

Table 7.11: Integration test of NetworkListener.onRecivePacket configured for ALT

Test case ID 11


Input Packet sent to listening port and algorithm configured is

ALT

Expected Output handlePacket on ALT with Packet must be called

Actual Output handlePacket on ALT with Packet is called

Result PASS

7.3.3 VALIDATION TESTING

Here the testing validates the software function in a manner that is reasonably

expected by the customer.



Table 7.12: Validation testing of buffer usage and packet lost for BDP configuration

Test case ID 12

Description Testing BDP

Input From Data sender send 100 packets and in router BDP is

configured

Expected Output The buffer usage at every time and the packet lost must be

displayed

Actual Output The buffer usage at every time and the packet lost is

displayed

Result PASS

Table 7.13: Validation testing of buffer usage and packet lost for eBDP

configuration

Test case ID 13

Description Testing eBDP

Input From Data sender send 100 packets and in router eBDP is

configured


displayed


displayed

Result PASS



Table 7.14: Validation testing of buffer usage and packet lost for ALT configuration

Test case ID 14

Description Testing ALT

Input From Data sender send 100 packets and in router ALT is

configured


displayed


displayed

Result PASS



CHAPTER 8

RESULTS AND SNAPSHOTS

8.1 BDP ALGORITHM

8.1.1 ROUTER GUI

Figure 8.1: Router starting GUI with BDP selected.

This router GUI snapshot consists of four main tabs

Router Configuration

View Statistics

Router Log

Buffer Occupancy



In the above router configuration tab initial router configuring values should be

given to start the router. The router listening port, bandwidth, average delay values must

be entered to initially configure the router. The radio buttons in the configuration tab are

used to select one of the three algorithms to start the router. This project consists of one

static algorithm BDP for demonstrating the buffer problem in the router for wired local

area network buffers, to set buffer sizes to be the product of the bandwidth and the

average delay of the flows utilizing the link, namely the Bandwidth-Delay Product

(BDP). The project also consists of two dynamic algorithms eBDP and ALT for solving

the buffer problem in the wireless network.

8.1.2 ROUTER LOG FOR BDP ALGORITHM

Figure 8.2: Router log for BDP algorithm.

When the Bandwidth-Delay Product (BDP) algorithm is selected, the above router log tab

initially displays the size of the network buffer. Since the values are 1MB bandwidth and

average delay is 2s the Bandwidth-Delay Product algorithms queue size is 20. When the



router is started with the configuration values, the router starts and it starts waiting for

packets from the sender as shown in the above snapshot.

8.1.3 DATA SENDERS GUI

Figure 8.3: Data senders GUI showing configuration.

The data sender GUI consists of two main tabs

Sender configuration tab.

Sender’s log.

The sender configuration tab consists of three text box input entries i.e. Listen

port, router port and the router IP address. It also consists of three GUI buttons one is for

configuring the data sender with IP address, receiving and sending ports. And other two

button for start data transfer and stop data transfer.



8.1.4 ROUTER GUI SHOWING STATISTICS

Figure 8.4: Router GUI showing statistics.

The View Statistics tab of the router GUI is shown in the above snapshot. This tab

consists of view stat button to display the statistics of

number of packets received

number of packets dropped

In this project, the data sender module continuously sends the data packet chunks

to the router. The router starts processing each incoming packets at the router port in the

mean while if the processing unit is busy, it stores the incoming packet in the buffer. In

the above snapshot since Bandwidth-Delay Product (BDP) algorithm is selected so the

buffer size is set to 20 and the buffer size is fixed. So the packet dropped increases and

the RTTs reported by the program were hugely increased as shown in the above snapshot.



8.1.5 ROUTER GUI SHOWING DROPPED PACKETS

Figure 8.5: Router GUI showing dropped packets.

In the above View Statistics tab of the router GUI the packet drop increased

gradually. As the number of packets received increased, number of packets dropped also

increased. Since the above snap shot is running with BDP algorithm, the buffer size is not

varied so the packet drop is high. So the packet dropped increases and the RTTs reported

by the program were hugely increased as shown in the above snapshot. Also the total

throughput of overall wireless transmission decreased.



8.1.6 ROUTER’S VIEW STAT SHOWING DROPPED PACKETS

Figure 8.6: Router’s view stat showing dropped packets.

When more than one data sender module continuously sends the data packet to the

router. The router starts processing each incoming packets at the router port in the mean

while if the processing unit is busy, it stores the incoming packet in the buffer. In the

above snapshot the router receiving data chunk from three simultaneous sending data

sender systems so the packet loss gradually increasing.



8.1.7 BUFFER OCCUPANCY FOR BDP ALGORITHM

Figure 8.7: Router’s buffer occupancy for BDP algorithm.

The Buffer occupancy tab of the router GUI is shown in the above snapshot. This

tab consists of view occupancy button to display buffer occupancy in graphical

representation. The buffer occupancy graph considers the value of buffer size versus time

to plot the graph. When the Bandwidth-Delay Product (BDP) algorithm is selected the

size of buffer is constant always. When more than one data senders starts sending the

data, the buffer occupancy will be always high i.e. 20 as shown in the above graphical

representation. When number of data senders increases, the buffer will be always full and

the packet dropped increases and the RTTs reported by the program were hugely

increases.



8.2 eBDP ALGORITHM

8.2.1 ROUTER STARTING GUI WITH eBDP SELECTED

Figure 8.8: Router starting GUI with eBDP selected.

In the above router configuration tab initial router configuring values should be

given to start the router. The radio buttons in the configuration tab are used to select one

of the three algorithms. To test the buffer occupancy eBDP is selected and the router is

started with the configuration values. The eBDP algorithm selects a buffer size of

approximate potential exists to lower the buffer size without loss of throughput. However,

using large buffers can lead to high queuing delays, and to ensure low delays the buffer

should be as small as possible. We would therefore like to operate with the smallest

buffer size that ensures sufficiently high link utilization.



8.2.2 QUEUE SIZE FOR eBDP

Figure 8.9: Router GUI showing queue size for eBDP.

In eBDP algorithm, for each outgoing packet, the service time Tserv is calculated

according to the Tserv, buffer size is calculated dynamically as shown in the above snap

shot. In the above queue size log initially queue size is set to 30, if the service time for

each processed packet is increased the queue size starts increasing. Dynamically

calculating buffer size Based on the Tserv overcomes packet drops and increases the

overall performance of wireless LAN networks.



8.2.3 DROPPED PACKETS FOR eBDP

Figure 8.10: Router GUI showing dropped packets for eBDP.

Initially the queue size is set to 30, if the service time for each processed packet is

increased the queue size starts increasing. Dynamically calculating buffer size Based on

the Tserv overcomes packet drops and increases the overall performance of wireless LAN

networks. In the above snapshot the number of packets dropped become very less

compared to the packet drop of BDP algorithm as shown in the above snap shot.



8.2.4 DROPPED PACKETS FOR eBDP

Figure 8.11: Router GUI showing dropped packets for eBDP with minimum packet

loss.

In the BDP algorithm when 16000 packets are received it dropped nearly 300

packets which drop off overall performance of wireless LAN networks. But when

compared to BDP, the eBDP algorithm when 16000 packets are received it dropped

nearly 20 packets hence dynamically calculating buffer size Based on the Tserv

overcomes packet drops and increases the overall performance of wireless LAN

networks.



8.2.5 BUFFER OCCUPANCY FOR eBDP

Figure 8.12: Router’s buffer occupancy for eBDP algorithm.

The Buffer occupancy tab of the router GUI is shown in the above snapshot. This

tab consists of view occupancy button to display buffer occupancy in graphical

representation. The buffer occupancy graph considers the value of buffer size versus time

to plot the graph. When eBDP algorithm is selected the size of buffer varies according to

the load. When more than one data senders starts sending the data, the buffer occupancy

will continuously change according to the no of transmitters. When number of data

senders increases, the buffer size dynamically varied.



8.3 ALT (ADAPTIVE LIMIT TUNING) ALGORITHM

8.3.1 ROUTER STARTING GUI WITH ALT SELECTED

Figure 8.13: Router starting GUI with ALT selected

In the above snapshot the ALT algorithm is selected, using of large buffers can

lead to high queuing delays, and to ensure low delays the buffer should be as small as

possible. Therefore to operate with the smallest buffer size that ensures sufficiently high

link utilization. By observing the buffer occupancy over an interval of time. If the buffer

rarely empties, decrease the buffer size. This algorithm uses some minimum and

maximum range value for buffer size. Based on the network load the algorithm

dynamically sets the size between min and max value. The router GUI is shown above

and started with ALT algorithm.



8.3.2 QUEUE SIZE FOR ALT ALGORITHM

Figure 8.14: Router GUI showing queue size for ALT algorithm.

Using large buffers can lead to high queuing delays, and to ensure low delays the

buffer should be as small as possible. Therefore to operate with the smallest buffer size

that ensures sufficiently high link utilization the ALT is used. In above cases of ALT

algorithm buffer maximum size is taken. If the data is not received at the router module

the buffer size decreases which potentially improves the throughput. ALT algorithm

chooses some minimum and maximum values. If there are more data senders sending data

chunk continuously, the buffer size increases if not it keep on decreasing. It decreases and

increases based on data packets.



8.3.3 PACKETS DROPPED NIL FOR ALT

Figure 8.15: Router GUI showing dropped packets nil for ALT.

The View Statistics tab of the router GUI initiated with ALT algorithm is shown

in the above snapshot. The view stat button display the number of packets received and

number of packets dropped for ALT algorithm. The router starts processing each

incoming packets at the router port in the mean while if the processing unit is busy, it

varies the size of the buffer and stores the incoming packet in the buffer..The ALT

algorithm moderates packet drops and maintains high link efficiency across the wireless

network. In the above snapshot using ALT algorithm packets are not dropped and high

throughput is achieved.



8.3.4 BUFFER OCCUPANCY FOR ALT ALGORITHM

Figure 8.16: Router’s buffer occupancy for ALT algorithm.

In ALT algorithm initially the buffer size is set to some value. In the above

snapshot the value is 50. The maximum size of the buffer was initially 50; when data

sender is idle the buffer size starts decreasing to reduce high queuing delay. Up to

sometime very less data is received at the router so the buffer size decreases, after that

when too many data senders starts sending data packets the size of the buffer increases.

Here the number of packets dropped is very less. The buffer occupancy shown above is

observed when more data senders sending the packets.



8.4 THROUGHPUT

Figure 8.17: Throughput of all the three algorithms.

In the Buffer occupancy tab of the router GUI throughput button is to display

buffer occupancy in graphical representation. The throughput graph considers the value of

throughput versus pause time to plot the graph. When router is stopped, it considers the

overall parameters for the entire three algorithms and displays the throughput. When

more than one data sender starts sending the data, the buffer occupancy will continuously

change and the throughput of ALT algorithm is superior compared to other two

algorithms.



CHAPTER 9

CONCLUSION AND FUTURE WORK

9.1 CONCLUSION

The key conclusion from these observations is that there exists no fixed buffer

size capable of ensuring both high throughput efficiency and reasonable delay across the

range of physical rates and offered loads experienced by modern WLANs. Any fixed

choice of buffer size necessarily carries the cost of significantly reduced throughput

efficiency and/or excessive queuing delays.

This leads naturally therefore to the consideration of adaptive approaches to buffer

sizing, which dynamically adjust the buffer size in response to changing network

conditions to ensure both high utilization of the wireless link while avoiding

unnecessarily long queuing delays.

9.2 FUTURE ENHANCEMENTS

Currently we treat all the packets belong to same QOS. But in real time some

packets are of much importance indicated by the QOS marker in the IP header. So we

have to fine tune our algorithms for the packets coming with different QOS requirements.



REFERENCES

[1] A. Lakshmikantha, R. Srikant, and C. Beck, “Impact of File Arrivals and Departures on Buffer Sizing in Core Routers,” in Proc. of Infocom, Apr. 2008..

[2] A. Dhamdher and C. Dovrolis, “Open Issues in Router Buffer Sizing,” in Computer Communication Review, Jan. 2006.

[3] M. Thottan, and M. C. Weigle, “Impact of 802.11e EDCA on mixed TCP-based applications,” in Proc. of IEEE WICON 2006 [4] Online, madwifi-project.org.

[4] R. Prasad, C. Dovrolis, and M. Thottan, “Router Buffer Sizing Revisited: The role of the input/output capacity ratio,” IEEE/ACM Transactions on Networking, to appear.

[5] T. Li and D. Leith, “Adaptive Buffer Sizing for TCP Flows in 802.11e WLANs,” Chinacom 2008..

[6] S. Pilosof, et. al., “Understanding TCP fairness over Wireless LAN,” in Proc. of IEEE INFOCOM 2003..

[7] M. Enachescu, Y. Ganjali, A. Goel, N. McKeown, and T. Roughgarden, “Routers with Very Small Buffers,” in Proc. of INFOCOM, Dec. 2006.

[8] D. Y. Eun and X. Wang, “Achieving 100% Throughput in TCP/AQM Under Aggressive Packet Marking With Small Buffer,” IEEE/ACM Transactions on Networking, vol. 16, no. 4, pp. 945 - 956, Aug. 2008.

[9] C. Kellett, R. Shorten, and D. Leith, “Sizing Internet Router Buffers, Active Queue Management, and the Lur’e Problem,” in Proc. of IEEE CDC, 2006.



APPENDIX-A

GLOSSARY

BDP Bandwidth-Delay Product

DCF Distributed Coordinated Function

EDCA Enhanced Distributed Channel Access

MAC Medium Access Control

TXOP Transmission Opportunity

AIFS Arbitration Inter-frame Space

AC Access Category

AP Access Point

AIMD Additive-increase and multiplicative-decrease

ALT Adaptive Limit Tuning

WLAN Wireless local area network



APPENDIX-B

PAPER PRESENTATION


Documents

Dynamic Management of 802.11 Based Network Buffer