Subject: [Ospf-wireless-design] RE: notes from our recent IETF meeting

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 12 Nov 2004 08:52:06 -0800

As I mentioned, we are working on a combined simulator/implementation
that the design team will be free to use to evaluate the proposed
mechanisms.   

It may also be helpful if we share some thoughts on how to parameterize,
conduct, and analyze any such simulations.  To that end, I've attached a
first cut at a document that discusses these issues.  Comments welcome.

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

---

From: Richard Ogier <[email-masked]>
Date: Fri, 19 Nov 2004 09:15:33 -0800

Tom,

>first cut at a document that discusses these issues.  Comments welcome.
This combined simulator/implementation should be very helpful. I was 
thinking of porting the Zebra implementation of OSPFv3 to ns-2, but this 
will save a lot of time/effort. I have a few comments on your simulation 
parametrization and performance measures.

In Section 3.2, I am not sure whether you are saying that the bulleted 
parameters are the tuning knobs. (You say that the mobility knobs 
indirectly tune these parameters.) If they are the tuning knobs, then 
the last two bullets (number of adjacencies being formed per node per 
second, and average number of LSAs different between two neighbors 
bringing up an adjacency) should not be there since they are protocol 
dependent. For example, if adjacencies are formed only between CDS nodes 
and their neighbors, then the number of adjacencies formed depends on 
how many nodes are in the CDS. Also, the last parameter (average number 
of LSAs different) makes no sense at all as a tuning knob.

I would rather be able to control the mobility model directly (by giving 
number of nodes, dimensions of area, max speed of nodes) as in ns-2, and 
then have other dependent parameters (such as number of neighbors per 
node) be computed for me.  Otherwise, I might unintentionally get a 
scenario that is unrealistic (e.g., nodes moving 537 mph).

Also, although perhaps less important, we have discussed on the MANET 
list the disadvantage of the random waypoint model, which causes nodes 
to be concentrated toward the center of the square.  A better mobility 
model, which results in a uniform distribution of nodes, is a random 
walk model in which each node moves in a random direction at a random 
speed for some (possibly random) time interval, bouncing off walls as in 
billiards, and then stops and chooses another random direction.

Regarding performance measures, I think you should at least add average 
end-to-end delay of data packets. Also, it would be nice to measure the 
average time to recover from a single link failure. I.e., if a single 
link along a used path fails, how long does it take before packets are 
rerouted along another path.

Regarding values of parameters, I guess the WG has decided to consider 
up to 100 nodes, but for simulation purposes it would be nice to allow 
more nodes (e.g., up to 250 or 500) to see how many nodes a given 
solution can support. As for node speed, we should have a few different 
node speeds corresponding to different types of networks, perhaps up to 
about 70 mph to model moving cars (again, to see what node speeds a 
given solution can support). Keep in mind that the actual frequency of 
topology changes will also depend on obstacles and interference (which 
apparently is not modeled in the simulator), so using higher node speeds 
would be the only way to increase the frequency of topology changes.

Richard

>
>------------------------------------------------------------------------
>