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

Acee Lindem <acee@cisco.com> Fri, 04 November 2005 22:46 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYAKG-0003hw-2p; Fri, 04 Nov 2005 17:46:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYAKE-0003ho-GG for ospf-wireless-design@megatron.ietf.org; Fri, 04 Nov 2005 17:46:22 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18679 for <ospf-wireless-design@ietf.org>; Fri, 4 Nov 2005 17:45:58 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYAZJ-0005AZ-JG for ospf-wireless-design@ietf.org; Fri, 04 Nov 2005 18:01:57 -0500
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2005 14:46:13 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA4Mk1Np028456; Fri, 4 Nov 2005 14:46:11 -0800 (PST)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 14:46:10 -0800
Received: from [10.21.90.69] ([10.21.90.69]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Nov 2005 14:46:10 -0800
Message-ID: <436BE4B1.3010606@cisco.com>
Date: Fri, 04 Nov 2005 17:46:09 -0500
From: Acee Lindem <acee@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Spagnolo, Phillip A" <phillip.a.spagnolo@boeing.com>
Subject: Re: [Ospf-wireless-design] OSPF Flooding and Higher Mobility
References: <08590A72DC26A54B85632FF97C2C22DA0D506D@XCH-NW-5V2.nw.nos.boeing.com>
In-Reply-To: <08590A72DC26A54B85632FF97C2C22DA0D506D@XCH-NW-5V2.nw.nos.boeing.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Nov 2005 22:46:10.0271 (UTC) FILETIME=[8D0A7EF0:01C5E191]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
Content-Transfer-Encoding: 7bit
Cc: ospf-wireless-design@ietf.org
X-BeenThere: ospf-wireless-design@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OSPF Wireless Design Team <ospf-wireless-design.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf-wireless-design>, <mailto:ospf-wireless-design-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/ospf-wireless-design>
List-Post: <mailto:ospf-wireless-design@lists.ietf.org>
List-Help: <mailto:ospf-wireless-design-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf-wireless-design>, <mailto:ospf-wireless-design-request@lists.ietf.org?subject=subscribe>
Sender: ospf-wireless-design-bounces@lists.ietf.org
Errors-To: ospf-wireless-design-bounces@lists.ietf.org

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@cisco.com] 
>>Sent: Friday, November 04, 2005 12:53 PM
>>To: ospf-wireless-design@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@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design