Self-Similar Traffic Generator

Linawati, I Made Suartika

SELF-SIMILAR TRAFFIC GENERATOR

Linawati, I Made Suartika

Electrical Engineering Department

Udayana University, Jimbaran, Bali, Indonesia Email: linawati@elkomunud.org

ABSTRACT

Network traffic generator can be produced using OPNET. OPNET generates the traffic as explicit traffic or background traffic. This paper demonstrates generating traffic in OPNET 7.0 as background traffic. The traffic generator that was simulated is self-similar traffic with different Hurst parameter. The simulation results proved that OPNET with background traffic function can be as a qualified self-similar traffic generator. These results can help in investigating and analysing network performance for self-similar traffic input.

Key words: traffic generator, self-similar traffic, background traffic, OPNET

  • 1.    Background Traffic

Traffic in OPNET 7.0 (Optimization Network) can be categorized as explicit traffic and background traffic. The background traffic can be distinguished as background utilization traffic and user-defined background routed traffic. The explicit traffic refers to a packet-by-packet data transfer with each transfer modeled as a discrete event. On the other hand the background traffic is modelled analytically and it can be imported directly from traffic collection tools or can be input in the form of ASCII data from a file. The ASCII format traffic files, however, must be converted to CSV format before they can be imported in OPNET. The background traffic architecture is based on the concept that a large part of the network’s activity will be characterized and simulated at a more abstract level.

The background-routed traffic is specified and generated at the network layer and based on “end-to-end” approach. End-to-end means that traffic is specified from its originating host, to its final destination.

The primary purpose of the background traffic is to model the effect of general traffic in the network on selected traffic of interest. This effect primarily takes the form of delay. In other words, the background traffic causes additional delay for explicitly modelled traffic. The background traffic also causes many other statistics. Utilization and throughput of at least some links, for example, increase with additional traffic in the network. Average buffer sizes in routers would also be expected to increase. Table 1 lists some statistics that may be useful in verifying if the configured traffic meets the expected amount.

On the other hand, simulation in OPNET 7.0 that is using the background traffic has some limitations to the model/mechanism of network and statistics of simulation results. The background traffic is IP-centric in OPNET 7.0. This means that devices

that are the sources and destinations of the background traffic must contain the IP protocol. Therefore only intermediate devices that support IP or that support IP at lower layer can be affected. Moreover the background-routed traffic only impacts the network, not the server. Generating extra in the network, by scaling the background-routed traffic for example, will not create a corresponding increase in task processing time on the server.

Table 1

Description of some statistical simulation results

Statistic Name

What it Measures

Load (bits/sec, packets/sec, bits, packets)

Refers to the total amount of traffic injected. This statistic can be collected at various levels in the protocol stack. When collected at the application layer, this must reflect the amount of explicit application traffic specified.

IP Traffic Sent/Received

This statistic reflects any background traffic that has been specified as flows between a source-destination pair. Note that this also includes explicit IP traffic.

IP Traffic Background Traffic Delay

Measured for the incoming and outgoing directions, this statistic measures the delay encountered by background traffic. When there are multiple flows in the network, this is a useful statistic to measure the delay at points in the network where many flows converge.

This is due to the fact that the background traffic system is not capable of determining how traffic correlates to processing load on servers. Another limitation is, the background traffic is transparent to certain protocol mechanisms. While many protocols are aware of the background traffic system, not all of their functionality reflects the presence of the additional traffic. For example, the weighted fair queuing mechanism of IP does not estimate background utilization contribution to queue lengths within each priority, since the background traffic does not carry priority attributes at this time. Table 2 lists statistics and models that do not account for the background traffic.

Table 2

Statistics and models that do not reflect the background traffic

Statistics that Don’t Reflect Background Utilization System

Models/Mechanisms that Don’t Account for Routed Background Utilization

1. Queue and Buffer sizes.

1. Non-LAN objects using shared Token Ring.

2. Global statistics of all types

2. Non-LAN objects using shared FDDI.

3. Server Task Load.

3. Non-LAN objects using half-duplex (shared) Ethernet.

4. Statistics in nonLAN objects using half-duplex (shared) Ethernet.

5. Statistics in nonLAN objects using shared     Token

Ring.

6. Statistics in nonLAN objects using shared FDDI.

7. Statistics of protocols at higher layers than IP (for example, TCP, UDP, Applications).

  • 2.    Importing Self-Similar Synthetic Traffic

OPNET 7.0 imports self-similar synthetic traffic as a user-defined background routed traffic. Data of the self-similar traffic is converted into CSV format and then it can be read by OPNET. The traffic flows from client as a source to server as a destination. The model

and its specifications can be seen in Figure 1, Tables 3 and 4.

Figure 1

An ATM network model

As shown in Table 4 that Traffic Scaling Factor command is used to scale the traffic and Traffic Scaling Mode command determines if only the background traffic is scaled or all traffic (the explicit and the background traffic). In most cases, scaling just the background traffic is desirable, because the traffic increase is due to more users appearing in the network, not to increase activity by individual users. The purpose of having the explicit traffic in the simulation is to represent one or more typical users accurately. Their particular traffic should be negligible when compared to the background traffic. Therefore, not scaling their contribution should not significantly dilute the selected scaling factor.

Table 3 Model specifications

Source

Switch

Destination

Model

Atm_wkst n_int

atm8_cr ossconn

Atm_server_int

ATM Switching speed

infinity

Application supported

Database (low load)

Database (low load)

IP ATM Traffic

Contract

RT-VBR

RT-VBR

IP AAL type

AAL5

AAL5

Links

ATM_OC3

Table 4 Model scenarios

Scenario:

1 1

2 I

3

4 I

5

Explicit traffic:

Database (low load)

Background traffic:

-

SS, H=0.6

SS, H=0.7

SS, H=0.8

SS, H=0.9

Traffic Scaling Mode:

Background traffic.

Traffic Scaling

Factor:

1.0

Note: SS stands for self-similar traffic.

  • 3.    Simulation Results

Figures 2 and 3 show some self-similar synthetic traffic both at client and at server after the traffic was imported as the background traffic in OPNET 7.0. The figures display the traffic with Hurst parameters 0.6 and 0.8.

(a). At client

(a). At client

(b). At server

Figure 3

Self-similar traffic as the background traffic for the Hurst parameter H = 0.8


(b). At server

Figure 2


  • 4.    Conclusion

Self-similar traffic can be generated using OPNET 7.0 in two ways, as explicit traffic and background traffic. As background traffic, the traffic has some limitations in analysing network performance. However it is capable to analyse network delay and loss due to the increasing users.

The simulation results figured that OPNET generates self-similar traffic with different statistical characteristics. Therefore it is also competent to generate any kind of network traffic.

Self-similar traffic as the background traffic for the Hurst parameter H = 0.6

REFERENCES

  • 1.    ATM Forum Technical Committee, Traffic Management Specification Version 4.1, AF-TM-0121.000, March 1999. Available: http://www.atmforum.com/

  • 2.    Leland W.E, M.S. Taqqu, W. Willinger, D.V. Wilson, “On the Self-Similar Nature of Ethernet Traffic (Extended Version)”, IEEE/ACM Transactions on Networking, Vol. 2, No.1, February 1994, 1-15.

  • 3.    Norros I., “On the Use of Fractional Brownian Motion in the Theory of Connectionless Networks”, IEEE J. on Selected Areas in Communications, Vol. 13, No. 6, August 1995, 953-962.

  • 4.    OPNET 7.0, “Representing Network Traffic”, online     documentation,      1-9. Available:

http://www.opnet.com, Hybrid Simulation – The Key to Fast and Accurate Results.

  • 5.    OPNET 7.0, “Scalability Issues-Working with Background Traffic”, on-line documentation, 628-Sim.

  • 6.    OPNET 7.0, “Importing Network Traffic”, on-line documentation, 666-Imp.

Teknologi Elektro

2 3

Vol.4 No. 1 Januari – Juni 2005