Subject: [Ospf-wireless-design] next steps in simulation: scenarios

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 14 Mar 2005 19:22:48 -0800

We've now had a couple of simulator releases (with some initial
results), two drafts that have been iterated multiple times, and some
good list and meeting discussion.  I'd like to next try to summarize
what I've heard recently, regarding the evaluation of different
proposals, so that we might come to an agreed-upon methodology for this
next phase of simulation.

I will divide the discussion into two parts:  scenarios, and performance
metrics (separate email).  Please chime in where I am forgetting things.

I hope to use this discussion to reorient our methodology for the
upcoming simulations.

Scenarios:
----------

- To date, we have been evaluating protocols using "random-walk" style
mobility models.  As discussed in our simulation document, the chief
parameters that we use to characterize a given simulation scenario are:
i) number of nodes
ii) neighbor density (per node)
iii) neighbor change rate
iv) radio model

The radio model, and some assumptions about it, yields the definition of
a "neighbor" in this context (not necessarily the same as an OSPF
neighbor learned via Hellos).

We haven't worried too much about the mobile topology, just using the
standard GTNetS random walk and parameterizing the velocity and pause
times to get the desired change rates for a scenario.

We also configured a very low amount of user data traffic (same
source/destination pairs) to measure data delivery ratio, but not so
much as to congest the network.

- Richard Ogier has previously suggested changing the mobility model,
but I don't recall the specifics of his proposal.

- Joe Macker made the observation last week that node failure is also
important to consider (and I agree).

- Cisco has suggested looking at three regions of mobility:  low (large
pause times), moderate mobility (with moderate pause time), and high
mobility (no pause time).

- Joe suggested that we also look at performance under high amounts of
user data traffic.  Upon considering this further, it seems like for
certain channel/MAC models, this will indeed be a consideration, since
although one can use priority scheduling on a given node to prioritize
the routing data over user data, in a distributed setting, the channel
access mechanism is not prioritized (e.g., 802.11), and uncoordinated
interference can occur (e.g., 802.11 multicast).

_______________________________________________
Ospf-wireless-design mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design

---

From: Richard Ogier <[email-masked]>
Date: Wed, 16 Mar 2005 09:06:52 -0800

I have the following comments on scenarios for now.
I will comment on performance metrics later.

First of all, I think it is very important to simulate more than
50 nodes. Scenarios with at least 100 nodes should be simulated.
Is it possible to simulate 100 nodes even for a short simulation
duration if you let the simulation run for several hours or a few days?

I don't consider pause time to be very important, since it
essentially reduces the number of mobile nodes (and the number
of nodes you can simulate is very limited anyway).
For the highest mobility scenario, I would like to see nodes moving
at a maximum speed of 30 m/s (average 15 m/s) with no pause time.
And this parameter needs to be known. (I did not see node speed
in your results because you reported only neighbor change rate.)
Since you are not modeling interference or obstacles, faster
mobility can be used to increase the neighbor change rate
that would be caused by these.

Using neighbor change rate as an independent parameter bothers
me for two reasons: I would like to know the node speed,
and using the same neighbor change rate for different numbers
of nodes implies that nodes must move more slowly when there
are more of them.  I agree that it is good to know the
neighbor change rate, but it does not make sense to me that
nodes slow down when there are more of them, so I would rather
see the neighbor change rate increase proportionally to the
number of neighbors (degree).

The largest neighbor change rate you used in your previous
results was 0.14, i.e. a new neighbor every 7 seconds.
In a network with 50 nodes and an average degree of 25, with nodes
moving an average of 15 m/s, the neighbor change rate is roughly 0.5
(assuming the transmision radius is 250m).

I will also comment on Hello Interval now. The optimal Hello Interval
can be different for different protocols, so you should let the
designers specify it. In mobile networks, the Hello Interval needs to
be relatively small to react quickly to topology changes (and to update
MPRs and DRs). And differential Hellos make a small Hello Interval
possible. If you prefer to use a consistent value for this parameter,
then I suggest 2 seconds, which is the default value for OLSR.

I will comment on performance metrics later.

Richard