[Ospf-wireless-design] Re: consensus
Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Fri, 04 November 2005 10:29 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 1EXyoz-0001nA-2W; Fri, 04 Nov 2005 05:29:21 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXyox-0001my-T1 for ospf-wireless-design@megatron.ietf.org; Fri, 04 Nov 2005 05:29:19 -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 FAA08977 for <ospf-wireless-design@ietf.org>; Fri, 4 Nov 2005 05:28:55 -0500 (EST)
Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXz3v-0001Iw-N7 for ospf-wireless-design@ietf.org; Fri, 04 Nov 2005 05:44:48 -0500
Received: from [82.226.221.97] (ras75-3-82-226-221-97.fbx.proxad.net [82.226.221.97]) (authenticated bits=0) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jA4ASo4i020852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ospf-wireless-design@ietf.org>; Fri, 4 Nov 2005 11:28:51 +0100
Message-ID: <436B37D9.3070709@inria.fr>
Date: Fri, 04 Nov 2005 11:28:41 +0100
From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ospf-wireless-design@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Miltered: at concorde with ID 436B37E2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)!
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Cc:
Subject: [Ospf-wireless-design] Re: consensus
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
Hi all, i want to point out that it could be beneficial to include Philippe Jacquet in this debate as he and Richard already had many discussions about related subjects on the MANET mailing list (and these may not be totally taken into account yet in this design). I also want to clarify my point of view, because it seems i was not clear enough. I think that flooding schemes and topology reduction schemes do not have to be tied together. In particular it may not be the best approach to evaluate a solution only based on the topology reduction performance it achieves. For example, flooding can be done with an MPR-based mechanism, while topology reduction can be done based on a CDS approach. I think we can have a flooding optimization design that is more independent from the topology reduction design than the recent discussions seem to point out. One thing that must be considered though, is the stretch factor that is implied by the topology reduction scheme going with MDRs. We are currently at INRIA running some simulations to evaluate this stretch factor. It seems it may be quite substantial, and this should be taken into account in the design, as route stretching introduces an overhead that is proportional to the data traffic. On the other hand using MPR/MPRselector adjacencies does yield more adjacencies, but no route stretching whatsoever. So here (in the topology reduction design) there is a trade-off that was not yet fully discussed in my opinion. As far as the flooding optimization design is concerned, it was not discussed so much lately, as the focus was rather on topology reduction design. It should be beneficial to continue discussing this point, and we would like to get some feedback on our report that we published this summer about the stability of CDS-based flooding schemes. It seems that when the ad hoc nodes are not static, MPR flooding performance is much steadier than CDS-based flooding which is rather fragile, especially when the CDS is reduced to the fewest nodes. ( ftp://ftp.inria.fr/INRIA/publication/publi-pdf/RR/RR-5609.pdf ) We also ran some quick simulations to evaluate the number of MPR adjacencies (for the same domain/range parameters as Richard), and we found the numbers shown below: Number Number of of nodes MPR links 10 10.50 20 32.72 30 57.56 40 84.14 50 114.56 60 143.88 70 178.64 80 211.04 90 241.80 100 273.90 We were therefore very surprised to compare these with the simulation results given by Richard, as there is a rather drastic difference? Emmanuel _______________________________________________ Ospf-wireless-design mailing list Ospf-wireless-design@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ospf-wireless-design
- [Ospf-wireless-design] Re: consensus Emmanuel Baccelli
- RE: [Ospf-wireless-design] Re: consensus Spagnolo, Phillip A
- RE: [Ospf-wireless-design] Re: consensus Joe Macker
- Re: [Ospf-wireless-design] Re: consensus Richard Ogier
- Re: [Ospf-wireless-design] Re: consensus Richard Ogier
- Re: [Ospf-wireless-design] Re: consensus Acee Lindem
- Re: [Ospf-wireless-design] Re: consensus Richard Ogier
- RE: [Ospf-wireless-design] Re: consensus Henderson, Thomas R