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

UDP Network Simulation: Analyzing Loss Rates of Different Media Sources, Study Guides, Projects, Research of Electrical and Electronics Engineering

A network simulation experiment investigating the loss rates of different media sources (high-quality video and soundtrack) under various udp packet sizes and input queue sizes. The experiment aims to understand the impact of udp packet size and input queue size on loss rates for each source.

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 08/19/2009

koofers-user-c1q-1
koofers-user-c1q-1 🇺🇸

10 documents

1 / 16

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
PROJECT REPORT
EVALUATION OF LOSS RATE
DEVIATION WITH SEVERAL
MARKOVIAN SOURCES
ECE541, Spring 2005
Submitted by: Lu Zhao, Ling Lu
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff

Partial preview of the text

Download UDP Network Simulation: Analyzing Loss Rates of Different Media Sources and more Study Guides, Projects, Research Electrical and Electronics Engineering in PDF only on Docsity!

PROJECT REPORT

EVALUATION OF LOSS RATE

DEVIATION WITH SEVERAL

MARKOVIAN SOURCES

ECE541, Spring 2005

Submitted by: Lu Zhao, Ling Lu

EXPERIMENT 1

1. OBJECTIVE

Given a network as above, calculate the loss rate of sources. The network is composed of two senders, two routers, and one receiver. The sender and receiver are the objects of same application called MmApp. Each source and receiver is attached to a UDP server. The types of these UDP servers are the same. When simulating, set network parameters as describe below:

Source: The sender type could be high video source with high quality, video source with low

quality or sound track source. The two senders could be any combination of two of them. The differences among these sources are their mean packet size and mean bit rate. Simulate both conditions when the sources are video source with high quality vs. sound source and the sources are video source with low quality vs. sound source.

Link: The link rate between router to router is determinedbytheequationC=α*(V+S).Vis

the average bit rate of the video source with high/low quality. S is the average bit rate of the sound track source. αvariesfrom 0. 5 to 2 .For other links, the rate is set to be 5 Mb. For each simulation, change the value of αtoseedifference.

Queue: The queue on the link between sender/receiver and router is Drop Tail Queue. SQF

queue is on the link between router and router. The max queue size of SQF is x. When simulating the network, different values of this queue size will be tested.

Packet: The UDP packet size and application packet size are different. The packet sizes of

application are exponential with their own mean packet size. The UDP packet size, in this simulation assignment, we test two situations, one is 1000 and another is 10000. We will see in the following section that the packet size of UDP has significant impact on the loss rate of the two sources.

Sending Interval: The sending interval Δtof application between each packet is determined

byequationΔt=application packet size / average bit rate. As indicated by equation, the interval is exponential too.

2. TOOLS INTRODUCTION

NS is an event driven network simulator. It implements network protocols such as TCP and UPD, traffic source behavior such as FTP, Telnet, Web, CBR and VBR, router queue management mechanism such as Drop Tail, RED and CBQ, routing algorithms. NS2 is written in C++ and OTcl.

Video Source High Quality

Video Source Low Quality Router^ Router^

Sink/ Receiver

Input queue

C kbps

 two sender s1, s  one receiver s

 two router r1, r

  1. Set duplex links following the network topology figure above

 Link rate: between sender/receiver and router, the link C = 5 MB. For router to router, the linkrateC=α*(V+S).

 progateion delay: 0 ms  queue type: Drop Tail Quese or SFQ

  1. Set new UDP agent

  2. Attachment UDP agent to sender/receiver node

  3. Connect UDP agent of sender to UDP agent of receiver

  4. Set UDP packet size

  5. Set up new MM application

  6. Attach these applications to the UDP agents (one to one relationship)

  7. Set mean packet size for application layer

  8. Set average bit rate for application layer

  9. Set source id for each source to distinguish them in the receiver side

  10. Set the timing for the application to start and finish

  11. Run the simulation

In“ns-defailt.tcl”,thedefaultvalueswesetareasfollows:

 Application/MmApp set pktsize_ 1000  Application/MmApp set mean_kbps_ 100mb

 Application/MmApp set mean_pktsize_ 1000  Application/MmApp set src_id_ -

 Application/MmApp set next_time_ 0.

The meaning of these variables will be explained in the next section.

4.2 C++

The C++ source files include udp-mm.h, udp-mm.cc, mm-app.h, mm-app.cc. In the following, we are going to describe what changes we have made to original file and the relationship among the functions in the class.

udp-mm.h

Inthepacketheaderstructure“hdr_mm”,add src_id filed and total_bytes filed. src_id filed is used to indicate from which source this packet is sent. total_bytes filed indicates how many bytes have

been sent by the application upon the time of sending this packet. Below is a brief view to the UDP-mm packet header structure. Note the time field record the current time.

src_id seq nbytes total_bytes time

UDP-mm packet Header Structure

mm-app.h

In this file, we add new fields for MmApp class. These fields are src_id,mean_pkt_size_, mean_kbps, sent_bytes, recv_bytes[2], loss_rate[2]. src_id__ field indicates the application source that send this packet. sent_bytes has the same meaning as total_bytes field in udp-mm.h. recv_bytes[2] is used for receiver side, it indicates how many bytes the receiver have received so far. Because now we have two sources, so we use a two dimension array, one for each source. loss_rate[2] fileds is for receiver to calculate and store the loss_rate so far for each source. This loss_rate will be calculated whenever this is a packet received.

mm-app.c

In this file, different functions are defined. In the following, we will describe each function about what functionality this function achieves and how to achieve it.

 void SendTimer::expire(Event*) When the timer expire, start to send next packet

 MmApp::MmApp() Constructor for the MmApp class

 void MmApp::init() When a new source start, it will call this function to send the packet sequence number to be 0  void MmApp::start()

In this function, it will call init(); set running to be 1 (indicate to run the program); calculate generate random seed for rand(); start sending packet by calling send_mm_pkt();  void MmApp::stop()

Set running_ to be 0 (indicate to stop the program)  void MmApp::send_mm_pkt()

Generate new packet size by call Random::exponential(mean_pktsize)_ use mean_pktsize_ as mean, this function will generate exponential packet size; record sent bytes of packets; set packet header; print out how many packet have been sent so far; send packet to UDP; schedule next sending time

 double MmApp::next_snd_time()

EXPERIMENT 2

Experiment 2 is almost the same as experiment 1 except in stead of two sources, there are 10 sources now and all of them are sound source with the same mean packet size and average bit rate. The change of files are very simple, in TCL, instead of creating two MmApp, create ten of them. Set theses source to have the same mean packet size and average bit rate. In C++ file, create a 10 dimension array to record the received bytes and loss rates for each of the 10 sources.

5. SIMULATION

EXPERIMENT 1: LOSS RATE OF TWO DIFFERENT SOURCES

In this experiment, we are expecting to analyze the behavior of loss rate of the traffic from several sources as a function of link speed (C) and size (x) of the input queue.

We calculate the bytes loss rate (per each source) by simulating a network scenario with two routers and two different sources. The configuration parameters are as follows.

Node Source Ave. packet size Ave. bit rate

S

High quality video 3830 Bytes 766 kbps Low quality video 768 Bytes 150 kbps S2 Soundtrack 80 Bytes 64 kbps

Link Bandwidth Latency Queue type Queue length S1—R1 5 Mbps 0 ms Drop Tail Default S2—R1 5 Mbps 0 ms Drop Tail Default R1—R2 C (variable) 0 ms SFQ X (variable) R2—S3 5 Mbps 0 ms Drop Tail Default

We adjust the link speed between R1 and R2 by the formula C = (V+S) to measure the traffic with different link capacity. The link speed adjust parameter, C, is set to be from 0.5 to 2.0, with step length of 0.1.

Theoretical analysis

The system in experiment 1 can be modelled as two M/M/1/B queues. Given the R1 – R2 link speed as C = (V+S), the two queues are identical in analysis of packet loss rate.

For the M/M/1/B queue, the queue parameters are:

 

 

  

8 _ _

_

ave pkt size

bit rate

Since the SFQ queue will assign one logic bucket for each flow, we have

x

B . So,

0

0

P P P

P P

P

B Loss B

i i

B

Given above formulas, we see that the theoretical loss rate is independent of the source type. In other words, all three sources, high-quality-video, low-quality-video, and soundtrack, will achieve the same loss rate in ideal situation. The theoretical results are shown as follows.

x=10 0.5079 0.4196 0.3400 0.2711 0.2134 0.1667 0.1296 0. x=15 0.5020 0.4068 0.3184 0.2403 0.1756 0.1250 0.0874 0. x=20 0.5002 0.4015 0.3061 0.2188 0.1457 0.0909 0.0540 0. x=40 0.5000 0.4000 0.3002 0.2019 0.1123 0.0476 0.0156 0.  1.3 1.4 1.5 1.6 1.7 1.8 1.9 2. x=10 0.0784 0.0613 0.0481 0.0380 0.0303 0.0242 0.0195 0. x=15 0.0419 0.0291 0.0203 0.0143 0.0102 0.0073 0.0053 0. x=20 0.0177 0.0101 0.0058 0.0034 0.0020 0.0012 0.0008 0. x=40 0.0012 0.0003 0.0001 0.0000 0.0000 0.0000 0.0000 0.

0.5 0.6 0.7 0.8 0.9 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2.

x= x= x= x=

The experiment results show the same trend of loss rate variation. Above figure has the most similaritywithscenario“UDPpacket= 10000 ,High-qualityvideo”. See data and figures below.

Part 1: High quality video and Soundtrack

In computer networks, the multi-media application data are encapsulated in UDP datagrams for transmission. In order to distinguish the influence of UDP packet size from the real parameters we are testing, we expanded the experiment into two iterations, each with a different UDP packet size, 1000 Bytes and 10000 Bytes.

A. When UDP packet size is 1000 Bytes, the simulation results are shown as follows.

B. When UDP packet size is increased to 10000 Bytes, surprisingly, we get different results from our simulation.

0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2

Video_H Sound

UDP packet=10000, Input queue size=

0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2

Video_H Sound

UDP packet=10000, Input queue size=

0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2

Video_H Sound

UDP packet=10000, Input queue size=

0.5 0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2

Video_H Sound

UDP packet=10000, Input queue size=

Above figures show the loss rates of the two sources in the same scenarios as the first iteration except for the different UDP packet size. The results indicate that, when UDP packet size is larger than both of the two sources (i.e. 80<3830<10000):

  1. The two traffics show a different performance that the loss rate of high-quality-video can be even lower than that of soundtrack when the link is full saturated (i.e. the link speed is slower whole traffic). However, when the link is not saturated (i.e. the link speed is faster than whole traffic), soundtrack traffic can benefit more from input queue size.
  2. There exists a critical point when link speed control parameter is set to be ONE. It is more distinguishable in the second iteration. In our simulation, the trend of loss rate shows a sharp drop at the point of =1.0 when the input queue size is equal to 20 and 40.

Note : As indicated before, the multi-media application data are encapsulated in UDP datagrams for transmission. So, different UDP packet sizes result in different loss behaviour with each traffic. For a better understanding, we draw the loss rate curves of four values of input queue size in the same figure (as follows).

UDP packet=1000, High-quality video

UDP packet=10000, Soundtrack

Not surprising from our expecting, these figures show the significant influence imposed by UDP packet size on data loss rate.  When UDP packet size is not large enough (i.e. larger than soundtrack but smaller than

bytes. When transmitting, UDP must divide the large video packet into several small fragments. As an unreliable communication, UDP packets get dropped randomly before reaching destination. So, a certain loss rate for UDP packets will result in a much higher loss rate for high-quality-video packets.

 When UDP packet size is large enough (i.e. larger than packets of both traffics), each packet from both sources can be encapsulated in just one UDP datagram. In other words, the application data will suffer the same loss rate as UDP datagrams. SFQ uses a fair round-robin algorithm to schedule each packet. Under such circumstance, the loss rate is determined mainly by the time for servicing each packet and the maximum number of packets residing in the input queue at any time. This is just what we could see in above

EXPERIMENT 2: LOSS RATE OF TEN IDENTICAL SOURCES

In this experiment, we are expecting to analyze the behavior of loss rate of the traffic from ten identical sources as a function of simulation time.

We calculate the bytes loss rate (per each source) by simulating the same network scenario as in experiment1 but let the ten sources start sending data each after a certain delay. The configuration parameters are as follows.

Node Source Ave. packet size Ave. bit rate Si Soundtrack 80 Bytes 64 kbps

Link Bandwidth Latency Queue type Queue length Si—R1 5 Mbps 0 ms Drop Tail Default R1—R2 C (variable) 0 ms SFQ 640 kbps R2—S3 5 Mbps 0 ms Drop Tail Default

Theoretical analysis

Experiment 2 is similar with experiment 1 except for the gradually joining sources. In each interval i (we choose i =30s in the simulation), there are exactly i sources in the system. Therefore, the whole system can be modeled as i M/M/1/B queue, each has parameters as:

8 _ _

_ _

8 _ _

_

i

ave pkt size i i

link bit rate

ave pkt size

bit rate

 

 

Similar with Experiment 1, since the SFQ queue will assign one logic bucket for each flow, we

have

i

x

B  , i  1 , 2 ,..., 10. So,

0

0

P P P

P P

P

B Loss B

i i

B

Given above formulas, we can calculate the theoretical loss rate for each independent source. In the specific scenario of Experiment 2, all sources will achieve the same loss rate during each interval (say, 30s in our simulation). In other words, the loss rate curve for each source will increase over time and finally, converge to a stable level (when all ten sources have joined the system). The theoretical results are shown as follows.

The experiment results show the same trend of loss rate variation among ten identical sources, except that our simulation achieves relatively lower loss rates than the theoretical values. The possible explanation is that we evaluated the byte loss rate in simulation but packet loss rate in theoretical analysis.

0 30 60 90 120 150 180 210 240 270 300 330 360

Source Source Source Source Source Source Source Source Source Source

In above figure, we see that the loss rate of each source is increasing, and then intend to converge into a stable value. That is because the identity of distributions among all the sources and the “fairness”characteristic of SFQ.

Increasing Whenever a new source joins, the SFQ will create a new queue for that source. Because SFQ uses fair round-robin algorithm to choose which packet is to sent next, each queue must wait until other queue have been all visited and because we have only one server, in this case, when more sources join, more queues are created thus means more waiting time for each queue. So when a new packet coming into a queue, there will be larger possibility for this packet to find the queue is already full thus lost. That is to say, the possibility of packet loss for each existing source is increasing.

Converging After all 10 sources join into the network, the loss rate for these 10 sources are balanced by maintaining the same value. That is because, as mentioned above, the SFQ uses fair queue algorithm, the possibility of being chosen is the same for each source. So the loss rate for these sources, once no more sources join, should be the same.

The number of sources to achieve an acceptable loss rate is varied with different tolerance limits of loss rate. From our simulation, if we define 5% as the tolerance limit of loss rate, up to 6 sources are acceptable. If choosing 2%, 4 sources are acceptable. If choosing 1%, then, only 2 sources are acceptable.

Lu Zhao Ling Lu Coding *** *** Experiment *** *** Report *** ***