Subject: evaluation plan for OSPF MANET

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 28 Nov 2005 08:50:55 -0800

Note:  This message is intended to start new discussions.  Replies
**only** to [email-masked].

Now that we have established a list for this activity, I would like to
suggest that the first order of business should be to agree upon a fair
process whereby the OSPF WG is in a position to move forward on an OSPF
MANET design by the March meeting.    

A first step should be to agree upon what we are trying to decide.  I
believe that we are trying to decide upon whether the basis for
efficient flooding and topology control for OSPF MANET should be a
source-independent connected dominating set (specifically, Ogier's MDR
proposal) or a source-dependent connected dominating set (specifically,
Overlapping Relays with Smart Peering).  

I also believe that, unless it is proven that the two current designs
have significant performance differences in different operating
environments, we are trying to downselect to one OSPF MANET design, not
to define the operating regions most applicable to two separate designs.

A second step should be to agree on evaluation criteria and scenarios,
to address the comments at the WG meeting that the previously used
scenarios were too narrow.  This should be agreed upon within the next
month or so, based on list discussion.  The scenarios/criteria need to
be feasible to achieve in the timeframe of this evaluation.

A third step should be to allow time for the interested parties to study
the proposed approaches in light of the above criteria.  Simulation or
implementation experiments can be used to support arguments, but are not
required in any or all cases.  I will take the action item to integrate
the new Cisco code and post a new evaluation software release.

A fourth step is to have any interested party submit a short position
draft on the issue at hand.  The position draft should be page limited
(e.g., 10 pages) so that it is more accessible to a wider WG review,
although it may reference additional supporting material.  It would be
recommended but not required that any simulation or implementation
scripts used to justify the arguments be made available at this time as
well (private simulation results should probably be treated with less
confidence by the WG).  Drafts should not be allowed later than the I-D
cutoff date, and the publishing of such a draft should be required to
make a formal presentation on this topic at the Dallas meeting. 

The fifth step is to have discussion on the list between the I-D cutoff
and the meeting, and presentations and discussions at the Dallas
meeting.

Comments?

Tom

---

From: Russ White <[email-masked]>
Date: Wed, 30 Nov 2005 08:15:07 -0500

> be feasible to achieve in the timeframe of this evaluation.

This presupposes emulations are "the" way to evaulate the proposals. In 
fact, I believe we need to do more traditional work here, such as 
examining pathological cases. For instance:

o Is there a point in the mobility graph where the protocol mechanism 
simply won't converge when real rachability should be available in the 
network?

o Is there a specific event that will cause a long outage in 
reachability when physical reachability still exists?

o How much change to existing code do the proposed mechanisms cause? One 
of the reasons we're using OSPF here is to reuse as much of a known 
working protocol as possible in a different environment. If the proposed 
changes change entire sections of the OSPF code (1,000 lines sounds 
trivial, until you realize that most OSPF implementations are probably 
only 12,000 lines of code, and 1/12th doesn't sound so trivial any 
longer), then we don't want to mess with it--better to use a new protocol.

o How extensible, into the future, are the proposed changes? Are they 
currently "at the end of the line," as optimal as they will ever get, or 
are there other areas of exploration to be done? If one mechanism has 
optimized all it can, and another shows similar improvements, but has 
many more possible optimizations, it's better to go with one that can be 
further optimized.

These are the sorts of things we normally look at when examining a 
protocol change, rather than basing the change simply on simulation 
results. We all realize implementations have a huge impact on 
performance (you can implement SPF as n^2, or n(log n), for instance), 
and that you learn how to improve performance over time. Basing an 
initial modification based on simple performance in a simulator is the 
wrong way to work at the problem. Imagine the IETF choosing between 
IS-IS and OSPF based on simulation work (!).

Simulations are interesting, but they don't indicate much of anything, 
until you get to simulating on real routers, and possibly even real 
radios (although I'm not so certain about that part, for various reasons).

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone

---

From: Erblichs <[email-masked]>
Date: Wed, 30 Nov 2005 04:32:25 -0800

Interesting,

	I was thinking on the same lines. But specific items
	also come to mind.

	* negotiated initialization params to ease adj formations.
	  Ex: LDP peer negotiation. Wouldn't this allow a peer
	  to move easier from area to area with diff adj params?

	* freq (in the case of mobility) drops of pkts where a
	session / connection oriented scheme may be warranted.
	Wouldn't we want to handoff to TCP these cases for rexmits???

	* a very low overhead of periodic summation of parts of
	the LSDB so a pull method vs a push method of updates
	can  be implimneted. Would this work better in the cases
	where a small number of peers are mobile? And scale using
	multicast where a larger nbr of peers are mobile? The
	trusted mobile peers make the requests and if trusted,
	use targeted hellos or .. AND responses are either uc or mc
	depending on the nbr of outstanding reqs.
	Ex: a mix of IS-IS and partial OSPF LSDB chksums..

	* a spec'ed method to deter transit routing.

	* ??a spec'ed method to inform that a host is reaching a point
	  between two handoff routers and if possible defer delivery
	  of its pkts??

	* a spec'ed method to state that a transition from a 2G to
	a 3G type connection (or vice versa) is occuring?

	* etc..

	So, I am assuming that we are talking about a really diff
	type of envs versus current OSPF envs. Yes, I ask alot,
	but this is a new env and done right could superseed
	our current envs.

	Mitchell Erblich
	----------------------

Russ White wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop 9.0.3 (Build 2932)
> 
> iQA/AwUBQ42l4xEdu7FIVPTkEQIviQCfUjtRIXA86u/zNk3PIymj4AWWEDoAnRv2
> im5Q5RNTXluAj2My26N50mwV
> =0gOk
> -----END PGP SIGNATURE-----