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

[Acee Lindem <acee at cisco.com>]

Phil,
See inline.

Spagnolo, Phillip A wrote:

> 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:acee at cisco.com] 
> > Sent: Friday, November 04, 2005 12:53 PM
> > To: ospf-wireless-design at ietf.org
> > 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?
>  
Today there are no constraints so the smart peering could be improved.

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

We can try.

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

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


> 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
Ospf-wireless-design at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design