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

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 22 Nov 2004 15:05:28 -0800

> -----Original Message-----
> From: Richard Ogier [mailto:[email-masked]] 
> Sent: Friday, November 19, 2004 9:16 AM
> To: Henderson, Thomas R
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [Ospf-wireless-design] RE: notes from our recent 
> IETF meeting
> 
> 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.) 

I am saying that we can typically directly control things like grid size,
random waypoint mobility, velocity of nodes, pause time, etc.  These may 
vary from simulator to simulator, and can be problematic when trying to
compare simulation results in an apples to apples fashion.  Therefore,
we have sought to identify statistics that can serve to parameterize
the mobility environment regardless of what types of detailed mobility
model is underlying.  I have felt that many of the common MANET parameters
like pause time are not that relevant to the routing protocol-- what is
more relevant is how many nodes are in the simulation, how many
are reachable, and what is the rate of change of these neighbor relationships
(neighbors in the physical, RF-reachable sense).

By measuring such statistics at the OSPF layer, there is inherently some
imprecision and filtering effects (for example, being a neighbor at the
OSPF layer is not the same as being a neighbor in the RF sense, since
there is a lag time until one declares an OSPF neighbor in 2-Way or not).
However, the goal is to identify a set of statistics that is close enough,
such that if we say (number of nodes = 20, average number of neighbors = 5, 
average number of neighbor changes = 0.1 per second, etc.), one can
tune the mobility model to compare results from one simulator to another.

Along these lines, there was a paper in last year's MILCOM from NIST
that was grappling with this problem:
"A Canonical Measure of Mobility for Mobile Ad Hoc Networks" by Kwak,
Song, and Miller.
They proposed a concept of "remoteness" as a unifying parameter to
bring together different mobility models.  Perhaps we should consider
that in the future.

> 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.

They are not tuning knobs directly.  The last parameter is intended
to give some sense of the disconnectedness of the network-- do all
LSA databases generally have all of the LSAs, or are there periods
when the databases fall out of sync between groups of nodes?

> 
> 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).

Yes, that is what we do also.  However, what we are trying to perhaps
convince people to do is to report not only things like number of
nodes, dimensions of area, etc., but also some parameters that are
relevant to the routing protocol-- how much topology churn does the
mobility model generate?  And can we find protocol independent parameters
to characterize that topology churn observed at layer 3?

> 
> 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.

Agreed.  Also, in reality, there is likely more structure than completely
uncorrelated movements between nodes, whether due to terrain or
organizational constraints.

> 
> Regarding performance measures, I think you should at least 
> add average 
> end-to-end delay of data packets. 

This is pretty straightforward to add.

> 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.
> 
I think that this can be tabulated as well-- we can call it "path outage"
for example.

> 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.
> 

Thanks for all of these inputs,

Tom

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

---

From: Acee Lindem <[email-masked]>
Date: Mon, 22 Nov 2004 23:04:02 -0500

Hi,
On a related topic, I believe I have the membership list straightened 
out.  I've added
Padma, David, and Delia and removed all the users that subscribed before 
I had
approvals enabled.

Thanks,
Acee