Home

Simulation

Software Code What to simulate? Results

Author's homepage

Simulations

OMNeT++ is the tool used to simulate the protocol.

In addition, the IP-Suite developped by the University of Karlsruhe is used to provided the necessary underlying TCP/IP protocols.

The current version of the simulation files is 0.7.
It can be downloaded Here.

See the README and INSTALL files for installation and usage help.

This section tries to summarize what aspect of the BPP protocol will be simulated in the OMNeT++ simulation.

Type of protocol to simulate.

A pricing protocol, like a routing protocol, is much different in its requirements from a transport protocol (TCP, IP, etc). Contrary e.g. to TCP, it is not interesting to simulate BPP between only two nodes: only a few messages will be exchanged, without any scaling, stability, etc problems.

It should be simulated on a big network, with many nodes having frequent configuration changes, so that we can measure the bandwidth consumed, the processing power needed, the stability of the pricing bases, etc.

Aspects of BPP to simulate.

Simulating a big Internet, with many nodes and complex routing mechanisms, is quite a difficult task, that's why the simulation tries more precisely to look at:

• Stability of pricing bases: In case of fast changing prices.
• Protocol performance when disturbing elements are present
• Scalability issues: Additional load introduced into the network due to frequent pricing requests from end users (does a request to a price base provocates a lot of other request to other bases, or can it just be answered quickly and immediately?).

Simulation output observed

Following analyses use two output produced by the OMNeT++ simulation:

• The number of Price request made to a BPP node.
• The number of TCP messages generated by this node.

Actually, we combine all price request numbers and all TCP messages numbers together, and we analyse following curves:

Total Nb of TCP msgs generated = f( Total Nb of Price request )

Following simulations are based on the simu network in the distribution.

They present the influence of Price updates, of the PI time-to-live parameter (age counter in price bases). They also highlight the instable PI problem, along with the result of the solution of the protocol to this problem.

12 simulations are made each time, with increasing number of price request (made randomly) for each.

Curves are named following the name of the data files they were produced from. E.g. the number 3 comes from the file "sca3.dat".

In X-coordinate is the number of Price request, in Y-coordinate the number of TCP messages generated.

Graph 1: Simple example of request and caching effect

Curves 3 (red) and 4 (green) are without keepalive message exchanges. Curves 5 (blue) and 6 (violet) are with keepalive. Keepalive timers values are 15s, 20s, 25s and 25s respectively for me1, me2, me3 and me4. Holdtimer is 60s.

Frequent PI updates are done. For curves 4 (green) and 5 (blue), no request are made on any of the updated PI, while for curves 3 (red) and 6 (violet), frequent request are made on the updated PI.

The PI time-to-live was 60s, ie bigger than the simu time.

It can be seen that frequent PI updates are responsible of a big part of the traffic. When prices are stable, traffic is quite limited.

Graph 2: Effect of the PI time-to-live.

PI updates are deactivated. No keepalive.

For the curve 8 (green), the PI time-to-live is bigger than the simu time (65s), PI are not deleted from the base.

For the curve 7 (red), the PI time-to-live is small, 5s. For a small number of requests, the PI have time to be deleted and next request generates again traffic on the network. For an important amount of request, PI have not time to be deleted, no network traffic is generated.

Graph 3: Highlighting of the PI instability problem.

No keepalive. Big PI time-to-live. One PI is instable (frequently modified).

For the curve 10 (green), there was one request to this PI at the beginning. Then the requester receives all subsequent PI updates, generating a lot of traffic. The curve 9 (red) shows the same configuration without that request at the beginning.

This can be seen as the PI instability problem, and a solution is proposed in the protocol as the form of the Max Number of Update optional OPEN message parameter.

Graph 4: Correction of PI instability problem.

The Max number of Update optional OPEN message parameter was added to the protocol and simulated. Here are its effects.

One PI is instable (frequently modified). The Max number of Update is set for each curves as following (the same for the whole network):

Curve	Max number of Update
11	deactivated
12	1
13	3
14	15

When the Max number of Update function is deactivated, a lot of traffic is generated due to the instability.

If only one Update is alowed to be sent (curve 12), there is even more traffic, since each request makes a update (no caching).

With a limit to the max number of update that can be sent, the traffic is limited when a PI gets instable (curves 13 and 14), with the limit of course that this PI is not asked anymore.