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
- [Ospf-wireless-design] OSPF Flooding and Higher M… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- RE: [Ospf-wireless-design] OSPF Flooding and High… Spagnolo, Phillip A
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- RE: [Ospf-wireless-design] OSPF Flooding and High… Alvaro Retana
- RE: [Ospf-wireless-design] OSPF Flooding and High… Henderson, Thomas R
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- RE: [Ospf-wireless-design] OSPF Flooding and High… Henderson, Thomas R
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- Re: [Ospf-wireless-design] OSPF Flooding and High… Acee Lindem
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- Re: [Ospf-wireless-design] OSPF Flooding and High… Richard Ogier
- [Ospf-wireless-design] Smart Peering draft update Abhay Roy