Subject: RE: [Ospf-wireless-design] OSPF Flooding and Higher Mobility

From: "Spagnolo, Phillip A" <[email-masked]>
Date: Fri, 4 Nov 2005 14:05:39 -0800

Acee,

Thanks for presenting these results.  Your data and method will allow
for some healthy discussion and comparison.

See some initial comments and questions below.

> -----Original Message-----
> From: Acee Lindem [mailto:[email-masked]] 
> Sent: Friday, November 04, 2005 12:53 PM
> To: [email-masked]
> Subject: [Ospf-wireless-design] OSPF Flooding and Higher Mobility
> 
> 
> Based on the INRIA reports and attendant E-mail threads, we 
> (Cisco) have
> recently gone down the path of doing some simulations with 
> higher mobility.
> The attached spread sheets show the results for 16 m/sec velocity and
> varying radio range. The pause time is still 40 seconds. We 
> found the results
> to be more drastic with a smaller pause time but had some 
> problems getting
> a complete set of runs.
> 
> MPRs have the following improvements over the base provided 
> with GTNetS:
> 
>      - Smart Peering is fixed to avoid instability by running a second
>        SPF to determine if a potential peer is available via a real
>        adjacency or unsynchronized adjacency. The adjacency 
> is only suppressed
>        in the case of connectivity to the SPT via real 
> adjacencies. This
>        is discussed in the Boeing report but wasn't implemented.

Are you allowing any adjacent path or are you limiting the adjacent path
to a certain length?

> 
> Also, we have enabled promiscuous LSA caching enabled with the LSA
> cache timeout extended to 100 seconds. We are attempting to get some
> runs with this disabled as well some with a shorter pause time.

LSA caching is not exclusive to MPRs.  In order to get a fair
comparison, it should be run independently.  The strategy will work in
either method.  Can you provide results excluding the LSA caching or
using with both methods?

> 
> For MDRs we used the standard bi-connected topology.
> 
> We will provide the diffs for the code changes supporting 
> smart peering.

Can you provide the scripts you used to generate these results?  I would
like to validate your MDR results before working with MPRs.  My first
check did not match exactly, but I don't trust it because I don't know
the parameters you used.

> 
> We have also been investigating using the MDR strategy of 
> reducing adjacencies
> by taking advantage of the flooding topology. However, doing 
> this effectively
> is more complex than it first seemed.

Can you explain this comment more clearly?

Lastly, I looked at the 50 node data for MPRs and MDRs.  Why do the MPRs
have so many LSA that are out of sync between the databases?  I was
wondering if LSA caching was covering something up here?

Thanks,
Phil

> 
> Stan Ratliff, a Cisco Software Engineer, will be presenting 
> these results.
> 
> Thanks and Sorry for the Short Notice,
> Acee
> 
> 

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

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 4 Nov 2005 14:16:27 -0800 (PST)

On Fri, 4 Nov 2005, Spagnolo, Phillip A wrote:

Phil:

[Adding Stan as to the thread.]

>> We will provide the diffs for the code changes supporting smart 
>> peering.
>

As you know, we're late bloomers when it comes to GTNetS...that's why it 
took us a while to get the scenarios running and the code updated.  We 
literally finished today. =:-)

The intention is to publish more details asap.  Stan is also working on 
some slides that have more details (we'll publish them here before Monday) 
to present at the WG meeting.  As we get to the documentation we'll make 
it available.  Knowing the proximity to the meeting, we wanted to at least 
give this team a heads up right away...

Thanks!!

Alvaro.

---

From: Acee Lindem <[email-masked]>
Date: Fri, 04 Nov 2005 17:46:09 -0500

Phil,
See inline.

>Are you allowing any adjacent path or are you limiting the adjacent path
Today there are no constraints so the smart peering could be improved.

>either method.  Can you provide results excluding the LSA caching or

We can try.

>check did not match exactly, but I don't trust it because I don't know
I'll ask Stan to send you GTNetS config for at one configuration - my 
understand is that
number of nodes was the only thing varied.

>wondering if LSA caching was covering something up here?
We didn't run many simulations with this technique yet since we haven't 
tuned it to the
point where it is effective. For one thing, I believe the current 
adjacency state must
be factored into relay selection. Also, a backup must be selected to be 
compared against
MDRs.

Thanks,
Acee