Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Project on If Networks Become Congested - Advanced Computer Networks | 4005 741, Study Guides, Projects, Research of Computer Systems Networking and Telecommunications

Material Type: Project; Class: 4005 - Adv Computer Networks; Subject: Graduate Computer Science; University: Rochester Institute of Technology; Term: Unknown 1989;

Typology: Study Guides, Projects, Research

2009/2010

Uploaded on 03/28/2010

koofers-user-r1j-1
koofers-user-r1j-1 🇺🇸

10 documents

1 / 25

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
Final Report
Team Congestion Crushers
A Research Investigation to Answer: “If a network
becomes congested, is it better to drop packets or to re-
route packets.”
Team Members
Abhijit Pillai ahp1252@rit.edu
Dhawal Parkar ddp7607@rit.edu
Nishad Patel
Rochester Institute of Technology
Advanced Computer Networks
4005-741-01
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19

Partial preview of the text

Download Project on If Networks Become Congested - Advanced Computer Networks | 4005 741 and more Study Guides, Projects, Research Computer Systems Networking and Telecommunications in PDF only on Docsity!

Final Report

Team Congestion Crushers

A Research Investigation to Answer: “ If a network

becomes congested, is it better to drop packets or to re-

route packets .”

Team Members

Abhijit Pillai ahp1252@rit.edu

Dhawal Parkar ddp7607@rit.edu

Nishad Patel

Rochester Institute of Technology

Advanced Computer Networks

Table of Contents

1. Description of Project

1.1 Hypothesis

2. Analysis of Research Papers

2.1 First Research Paper

2.2 Second Research Paper

2.3 Third Research Paper

3. Software Design

4. Manuals

4.1 Developer’s Manual

4.2 User’s Manual

5. Data Collected from Simulation

6. Analysis of Data

7. Lessons Learnt………………………………

8. Future Work…………………………………...

9. References……………………………………

2. Analysis of Research Papers:

We performed our investigation by choosing three papers which were presented at various conferences. In this section, we would be explaining the analysis of the three research papers

2.1. Analysis of Haider et al (2009)

2.1. 1. Introduction

The IP protocol suite does not guarantee Quality of Service (QoS) and prioritized transmission. However, in case of transmission of video and voice, there are constraints like delay and packetizing which need to be taken into consideration. There are several critical issues which exist for real time communication for the IP network such as reduction in bandwidth, packet delay and echo. There are various challenges that arise in real time communication over IP network. Some of them are:

  • Ease of use: This indicates the simplicity of the system to be used.
  • Scalability: This indicates that when more number of nodes are added to the system, the system should be able to deal with it
  • Interactivity: This indicates how interactive the system is (eg: GUI)
  • Standardization: This indicates that the system should be capable of running on multiple platforms.

2.1.2. Problems Addressed

The authors of the paper have proposed an idea and guarantees performance in real time video communication with error resilience. The assumptions made in the paper are as follows :

  • Any switch or gateway could be used
  • Can work on any network topology
  • Routers follow store and forward policy with minimum memory space
  • Metrics of delay and bandwidth to parameterize network performance
  • The delay here is the client specified absolute upper bound D
  • The bandwidth here is the minimum bandwidth requirements.

2.1.3. Novel Contributions

The novel contributions made by the paper are discussed in this section:

a) Channel Establishment : The channel establishment phase is used to determine if the client’s request can be accepted by the network in its current load conditions. It is achieved using Open Shortest Path First (OSPF) .The route is scrutinized to cand their heck enough resources. A channel establishment message follows a particular path and tests are performed. The results are forwarded to the destination which includes the minimum delay bound a node can offer and the buffer space the node can offer. If one of tests fails at a node, a negative reply message is sent back to the source and all the resources that are held by the node are released.

b) Backpressure Rerouting The backpressure rerouting takes place when the traffic pattern changes and during congestion. Each node (say node x) maintains information about all the intermediate nodes (source to node x) along with the successor node and their delay requirements. On receiving a backpressure packet, node x tries to find an alternative path by issuing a similar packet which was issued by the source for channel establishment. This packet contains information about the source to node x along with the delay characteristics. A neighbor table is maintained which records the delay and the expiry time for a node to reach its neighbors.

My Neighbors

Estimated Delay (ms)

Expiry Time (ms)

Node 23 17 50

Node 9 234 50

Fig 1 : Neighbor Table

The Encoder and Decoder are used for detecting errors. The Feedback loop is utilized to recover from errors. There are various video compression algorithms which are used:

  • Intra-Frame: each separately. High resistance to errors. Eg: JPEG, NITF, DPCM
  • Inter Frame: difference between frames. High compression. Eg: H.261, H.263, MPEG-1, MPEG-2.

2.1.4. Ideas Used

We have simulated a sparsely connected network. We have taken the idea of backpressure rerouting in order to perform the rerouting mechanism when congestion happens in the network. We have also implemented the rerouting mechanism with Forward Error Correction (FEC) in order to check the error resilience of the network.

2.2. Analysis of Jain et al (2004)

2.2. 1. Introduction

Routers respond to congestion by dropping packets. However, dropping the packets indiscriminately would encourage the senders to increase their sending rate due to which it becomes difficult to control congestion. Fair Queuing is one of the congestion control mechanisms which have been proposed. In this mechanism, separate queues are maintained for each source. Whenever congestion happens, the packets from the high volume sources are dropped.

2.2.2. Problems Addressed

The paper illustrates the drawbacks of the various current techniques which have been designed for performing congestion control. Some of the techniques described are:

  • FIFO with drop tail : Here, a single FIFO queue is maintained at every router and packets at the end of the queue are dropped when the buffer size exceeds during congestion.
  • Flow Random Early Drop (FRED) In this technique, the packets are dropped based on the flow of volumes of sources.
  • CHOKe In this technique, each incoming packet is checked with a randomly selected packet from the queue. If the same packet exists in the queue, then both the packets are dropped.

The above mentioned mechanisms have its own drawbacks. The techniques described drop packets at random, due to which the sender is encouraged to send more packets and thus clogging of the network takes place.

2.2.3. Novel Contributions

The paper proposes a packet dropping mechanism based on game theory. Some of the parameters used in the proposed protocol are:

  • Q: Total number of packets presently in the queue.
  • Hash Table: for each flow i having packets in the queue, a record of mi, number of packets presently in the queue from the source i
  • MAX: a pointer to the record of the source having highest number of packets
  • F- Size of buffer. H and L are markers.

Every time a packet arrives at the queue, fair congestion mechanism takes place, where the packet is scrutinized at the tail of the queue (arrival) and departure of the queue (depart).

Protocol Proposed:

The steps to be performed are as follows:

Packet Arrival

  1. Identify the source mi.
  2. a). if Q>H , stamp Drop packet. b).else if the H> =Q >L and i =MAX, stamp DROP c). else stamp it Send
  3. Packet is appended to the tail with a stamp
  4. Q and mi are incremented by 1

Packet Departure

  1. Identify the source mi.
  2. Q and mi are decremented by 1
  3. If SEND, then it is routed
  4. Else it is dropped.

2.3.2 Novel Contributions and Ideas Used

The authors then go on to discuss different packet loss patterns and the relationship between static FEC, Throughput and Utility for each of them. This helps the authors towards building their analysis which helps them to conceive the adaptive FEC approach. The authors then extrapolate a relationship between packet loss p and FEC overhead ψ. Based on this relationship they propose a simple proportional controller that adjusts ψ based on measured packet loss.

ψ i (n) = ψ i (n − Di ) + τ ( η pi (n − Di ) − ψ i (n − Di)) .........(1)

where i represents the flow number, pi(n) is the average packet loss in the ith flow during

interval n. τ is the gain parameter of the controller, and Di is the round-trip delay for flow

i. The measurement of pi is coupled with congestion control and should be provided via

the feedback loop. The authors find the controller to be stable when the condition 0 < τ <

2 is satisfied.

Now they say that suppose the probability pi(n) converges to some stationary point p*, then the overhead rate in the stationary state becomes

ψ * = η p*

Now the authors state that the task of achieving high utility becomes the matter of

selecting proper values of constant η for different values of packet loss p. This can be

achieved by deriving the relation between η and p and UT. And can be defined as

η < (1 – UT) / p + UT ..............(2)

Thus armed with the knowledge of equations (1) and (2) we can effectively achieve adaptive FEC to maintain high utility for constantly changing packet loss ratios. And this is what we use in the third facet of our project. The last part of this paper shows us the simulation results for the experiments the authors carried out. Basically they go on to prove that proper control of FEC overhead can significantly improve the utility of received video over lossy channels and have better performance than other best-effort networks with FEC-protection.

3. Software Design

In this section, the class diagrams for the simulation software are illustrated. We have designed two class diagrams: one for the Fair and Efficient dropping technique and one for the Backpressure rerouting technique. The classes in the simulation software are

  • Router.java
  • Node.java
  • Dijkstra.java
  • Packet.java
  • Host.java
  • SimulationLauncher.java
  • PacketFactory.java
  • ThroughputMeter.java

3.1 Class Diagram for the Fair and Efficient

Dropping Technique.

3.2 Class Diagram for the Fair and Efficient

Dropping Technique.

4.0 Manuals

4.1 Developer’s Manual

For Linux/MAC OS User: (Using Bash shell)

*If Required: Set the PATH and CLASSPATH to include the following from the bash command

line or add the following lines to your .bashrc file in the user's home folder.

$ export PATH=$PATH:/home/user/jdk1.5.0_16/bin

$ export CLASSPATH=.:/home/user/cscl.jar

It is expected that the user change the necessary paths to the folders and the java (jdk) version as

well

to suit his/her computer configurations. It is recommended that the Java Development Kit version be

jdk1.6.0_

Download the 2 JAR files <ccrushers.jar> and <congestionc.jar>

ccrushers.jar is the Back Pressure Rerouting Program with FEC inbuilt into it.

congestionc.jar is the Fair and Efficient Dropping Algorithm with FEC inbuilt

Move the file into the folder of your choice and unJar the file using the following

command from the bash shell.

$ jar -xvf ccrushers.jar

Then move into another folder and do the following

$ jar -xvf congestionc.jar

This will copy all the source files and configuration files into the respective folder. Now compile

the java source files in each of the folders using the following command on the bash shell.

$ javac *.java

Now all the java .class files have been created and the program is set to run.

4.2 User’s Manual

Once the class files are made available to the user the user is expected to run the programs thus:

  1. in Folder1 and in Folder2 (not needed to run together):

$ java SimulationLauncher

 seed : is the seed for the random number generators.  NetworkInputFile : is all the configurations that the program would need its format is as follows:

NOTE: DO NOT USE THIS FILE AS INPUT FOR SIMULATION

0:0 3:0 (Source Host) - Can be more

5. Data Collected From Simulation

We have collected data from the simulation by varying the arrival rate in every simulation. The

following data has been collected.

Fig 3. Data collected of Drop mechanism with FEC and without FEC