[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