Subject: RE: [Ospf-manet] Adjacency Reduction??

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 31 Jan 2006 23:51:52 -0800

> -----Original Message-----
> From: Russ White [mailto:[email-masked]] 
> Sent: Tuesday, January 31, 2006 5:58 PM
> To: [email-masked]
> Subject: [Ospf-manet] Adjacency Reduction??
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Y'all:
> 
> I've been talking to various folks interested in actually 
> deploying OSPF MANET protocols, and I have to point to a 
> logical assumption "we've" 
> made without much considering whether it's a good assumption or not. 
> Throughout this entire discussion on simulation scenarios, 
> etc., it's always been assumed that adjacency reduction is a 
> "good thing," because it reduces overhead.

This has been pretty much unchallenged until recently, dating back to
Fred Baker's "Outsider's view of MANET" draft a few years ago.

> 
> The problem is, we're assuming that adjacency reduction is 
> the _only_ way to reduce overhead to "acceptable levels," or 
> to the "lowest levels," and--it seems--that adjacency 
> reduction is the "right way" to reduce overhead.
> 
> I would like to challenge this assumption head on. First, I 
> don't believe we should always look for the lowest possible 
> overhead in some simulation. 

Agree with you there.  Hopefully you will also agree that we should not
accept higher overhead when it doesn't appreciably improve performance.
And that you will also agree that one can often add overhead to improve
convergence or other data plane performance parameters (e.g., shorter
Hello timers), and therefore that we are really searching for the
operating point or configuration where the cost of more overhead on a
resource constrained channel no longer justifies the incremental
performance benefit.

> I have another email coming on 
> simulations, so I'll hold that for a minute, and look at this 
> from another angle.
> 
> Start with this question: Would anyone argue that OSPF, as 
> it's currently designed, uses the lowest possible overhead 
> mechanisms for any phase of its operation? If not, then what 
> was the reason some lower overhead process wasn't used? I 
> would argue lower overhead mechanisms were not used because 
> they were not as "stable," or were not verifiably correct in 
> operation. In other words, various mechanisms were analyzed 
> for correct operation and flexibility, and the method with 
> the best operational characteristics was chosen.
> 
> Now, as this applies to the MANET work specifically: A number 
> of the people I've talked to who are considering deploying 
> these solutions say that adjacency reduction is not an 
> acceptable alternative, in their opinion, simply because when 
> you reduce adjacencies, you increase convergence time, in all 
> cases. There's no way around the fact that as you reduce 
> adjacencies, you increase the time it takes for a new member 
> of the network to begin routing packets, or a member of the 
> network to recover from losing it's current adjacencies.

I really don't see how you can support such a claim about convergence in
all cases.  

> 
> Second, I don't believe that adjacency reduction is the 
> _only_ answer to reducing overhead. It's the simple/easy 
> answer, perhaps, but there is a tradeoff that's not been considered.
> 
> I would suggest, in this line, two things:
> 
> - -- First, we should consider the pros and cons of adjacency 
> reduction, from a protocol correctness perspective, rather 
> than assuming that adjacency reduction is the "right way" to 
> reduce overhead, or that the lowest possible overhead, at the 
> cost of protocol correctness, is the "right solution."
> 

What do you feel is "incorrect" about adjacency reduction?  After all,
there are many real-world adjacency reducers in practice (such as
buildings, foliage) that are not affecting correctness of the protocol.
And I assume that the OSPF broadcast interface is considered to be
correct.  

I am open to other suggestions for dealing with dense networks, but as
you stated in another email, specific suggestions are lacking.  Plus, it
is pretty well established in wireless networks that topology control is
important-- this is not a new concept.

> - -- Second, if we _insist_ on building our world around 
> simulations, we should include a scenarios where the number 
> of "backups" is increased, to the point of building full 
> adjacencies with every visible neighbor, to see how the 
> proposed algorithms work in this situation. Regardless of how 
> those in the WG feel about it, many deployments may be 
> configured to have very high "backup counts," in the real 
> world, because of real operational experence showing this is 
> required in various situations. We should know how these 
> proposed solutions react in these situations, and take it as 
> a data point.
> 

I agree that solutions should be tunable to allow the operator to trade
overhead for robustness properties.

Tom

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

---

From: Russ White <[email-masked]>
Date: Wed, 01 Feb 2006 07:05:20 -0500

> Fred Baker's "Outsider's view of MANET" draft a few years ago.

Certainly. But, the oldest. most entrenched assumptions are often the 
most fruitful when challenged, particularly in the technical arena.

> resource constrained channel no longer justifies the incremental

There are probably a range of operating points, from the most mobile 
with least mesh to the least mobile with most mesh, and all points in 
between. Up to this point, the assumption has been that the "right" 
solution is to reduce adjacencies to the minimum possible. IMHO, this is 
the wrong assumption to make for all operating environments.

We should know how these algorithms will work under all possible 
operating conditions, and, if we're going to place such a great weight 
on simulations, consider ranges of "percentages of full adjacencies." If 
one algorithm degrades some, but not completely, with a larger 
percentage of full adjacencies, and another degrades completely, then 
it's worth considering that as a decision point.

> I really don't see how you can support such a claim about convergence in

Can you support the opposite claim? Is there any situation where:

- -- You've arbitrarily decided to reduce adjacencies for optimal performance.
- -- You've lost all "fully adjacent" neighbors.
- -- Convergence is just as fast as the case when you didn't reduce 
adjacencies?

No, there's not. In fact, even in the wired world, we give up 
convergence on broadcast links for more efficiency--note the wide 
interest in being able to declare a point-to-point "broadcast type" link 
as an OSPF point-to-point link, in the interest of faster convergence, 
for instance.

DR election in the wired world is based on the logical assumption that 
movement will be rare, and device failure will be rare. We can't make 
either assumption in a mobile world.

> buildings, foliage) that are not affecting correctness of the protocol.

Your'e arguing that because adjacency counts are going to be reduced by 
mobility, it's okay to reduce them for performance gains? I would argue 
just the opposite--because we don't know what the adjacencies are going 
to do in the real world, we shouldn't count on adjacency reduction to 
reduce overhead.

> important-- this is not a new concept.

Not all mobile networks will be dense.

:-)

Russ

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