Subject: RE: [Ospf-manet] evaluation plan for OSPF MANET

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 1 Dec 2005 07:19:46 -0800

> -----Original Message-----
> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 01, 2005 6:45 AM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Ospf-manet] evaluation plan for OSPF MANET
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> >>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:
> > 
> > Russ, I don't think my message presupposed that emulations were the 
> > only criteria.  I strongly agree with you that the underlying 
> > algorithms need to be examined outside of simulation or experiments.
> > 
> > Other than the below, are there other OSPF benchmarking 
> metrics that 
> > you believe should be considered (I know that Sue Hares has 
> repeatedly 
> > suggested that we consider the work done on benchmarking)?
> 
> These two statements contradict each other (?). "We shouldn't 
> rely on benchmarking (simulations), but what benchmarks do 
> you think are important?"
> 
> We shouldn't rely on benchmarks. We should rely on analysis 
> of the changes and the protocol.

I didn't mean black box benchmarking, just whether the parameters of
interest to the benchmarking community should be considered in the
analysis and/or simulation:

5.  Basic Performance Tests.........................................5
       5.1.  Time Required to Process an LSA...........................5
       5.2.  Flooding Time.............................................6
       5.3.  Shortest Path First Computation Time......................6
   6.  Basic Intra-area OSPF Tests.....................................8
       6.1.  Forming Adjacencies on Point-to-Point Links
             (Initialization)..........................................9
       6.2.  Forming Adjacencies on Point-to-Point Links...............9
       6.3.  Forming Adjacencies with Information Already in the
             Database.................................................10
       6.4.  Designated Router Election Time on a Broadcast Network...11
       6.5.  Initial Convergence Time on a Broadcast Network,
             Test 1...................................................11
       6.6.  Initial Convergence Time on a Broadcast Network,
             Test 2...................................................12
       6.7.  Link Down with Layer Two Detection.......................12
       6.8.  Link Down with Layer Three Detection.....................13

e.g., one could run down this list and qualitatively assess how the
extensions might affect each of these measurements, or estimate it
quantitatively using simulation.

Tom

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

---

From: Russ White <[email-masked]>
Date: Thu, 01 Dec 2005 11:37:43 -0500

> quantitatively using simulation.

Certainly, but then you would miss things like:

- -- What is the complexity involved in coding the extensions? Is one a 
minor change to current OSPF mechanisms, while the other is an extensive 
recoding/replacement of current mechanisms? We hear claims about 
"natural extensions," but it's more than the concept being the same--how 
much code is actually reused, verse replaced? This is important for 
several reasons, such as the original reasoning behind using OSPF rather 
than some new protocol in the first place.

- -- Examine the corner cases--are there cases where the network just 
won't converge, based on a specific rate of mobility and specific 
meshniess? Are there pathological cases, where the suggested 
modifications actually fail to flood anything for long periods of time? 
Are there pathological cases where the suggested changes cause OSPF to 
flood constantly?

- -- Examine the possibility of future extensions. Is it possible to 
extend the proposed mechanism in other ways, to improve performance? Or 
is the proposed mechanism going to tie us into a dead end, with no 
further enhancements, protocol wise, possible?

- -- Examine the flexibility of the proposed extensions. Can the extension 
be "tuned" for different network situations?

- -- Is the extension reliant on a specific setting of timers? If so, what 
are they, and how would the extension be affected if specific timers 
were set in a different way?

I think I outlined several of these in my first email, as well. 
Benchmarks are still benchmarks, one way or the other. They are useful 
in many situations, but too dependant on the tweaks made to the 
implementation and test to actually tell you which of several possible 
protocol extensions is/are going to be useful.

:-)

Russ

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

---

From: Richard Ogier <[email-masked]>
Date: Tue, 06 Dec 2005 08:37:19 -0800

>than some new protocol in the first place.

I guess the value of being a "natural extension" depends on what is
meant by the term.  To me, a "natural extension" will automatically
have some of the properties that Russ says are important. For example,
it will minimize changes to OSPF, and the changes/extensions that are
required will maintain the same design philosophy as OSPF, and will
use similar techniques and mechanisms. This will most likely also
minimize the code changes that are required.

For example, OSPF-MDR maintains several properties of OSPF:

1. The set of MDRs in a MANET is a true generalization of the DR in
   a broadcast network, since in a fully connected MANET, both the
   DR election algorithm and the MDR selection algorithm will choose
   the same router as DR/MDR. (Similarly for Backup DR/MDR.)

2. In both cases, each DR/MDR Other is adjacent to two routers that
   are DR/MDR or Backup DR/MDR.
   - Thus, the mechanism used by OSPF-MDR to reduce the number of
     adjacencies is very similar to that used by OSPF.
     (OR/SP forms adjacencies in a more random manner.)

3. The DR and Backup DR fields of each Hello are used by each router to
   indicate its selected DR/MDR and Backup DR/MDR.
   - Thus, these fields are reused by the extension, rather than being
     wasted.

4. The Interface states in OSPF-MDR are the same as in OSPF, with
   the DR and Backup states indicating that the router is an MDR
   or Backup MDR, respectively.

5. MDRs and adjacencies are selected based only on information obtained
   from Hellos (as in OSPF), and not from LSAs (as in OR/SP).
   - This also decouples the flooding mechanism from the choice of LSAs,
     thus allowing a flexible choice of partial-topology LSAs.
   - This also provides better modularity, so that the flooding
     mechanism can also be used by another MANET application that
     does not flood LSAs.

6. OSPF-MDR requires no change whatsoever to LSAs. In OR/SP, a new
   LSA will have to be originated even if the only change is the U-bit
   for some neighbor. (Such LSAs will be disseminated unnecessarily
   to non-MANET routers.)

Richard