Re: [Ospf-wireless-design] Re: consensus

Richard Ogier <rich.ogier@earthlink.net> Fri, 04 November 2005 18:35 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 1EY6PB-0004I7-LJ; Fri, 04 Nov 2005 13:35:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY6P9-0004Hx-N1 for ospf-wireless-design@megatron.ietf.org; Fri, 04 Nov 2005 13:35:12 -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 NAA06288 for <ospf-wireless-design@ietf.org>; Fri, 4 Nov 2005 13:34:48 -0500 (EST)
Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY6eC-0006uu-Md for ospf-wireless-design@ietf.org; Fri, 04 Nov 2005 13:50:45 -0500
Received: from dialup-4.246.15.16.dial1.sanjose1.level3.net ([4.246.15.16] helo=earthlink.net) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EY6P6-0004NH-00; Fri, 04 Nov 2005 13:35:08 -0500
Message-ID: <436BA9DC.6020902@earthlink.net>
Date: Fri, 04 Nov 2005 10:35:08 -0800
From: Richard Ogier <rich.ogier@earthlink.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 (emach0202)
X-Accept-Language: en-us
MIME-Version: 1.0
To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Subject: Re: [Ospf-wireless-design] Re: consensus
References: <436B37D9.3070709@inria.fr>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.9 (++)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
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

Emmanuel,

You seem to be missing some points in the recent discussion.
Phil pointed out one of these in his email today.
Another one you seem to be missing is that adjacencies
based on MPRs (the way you select them) do not work, since they
do not guarantee the graph of adjacencies is connected.

> We were therefore very surprised to compare these with the simulation 
> results given by
> Richard, as there is a rather drastic difference? 


As I explained, the simulations I ran used a modified method of selecting
MPRs that ensures the adjacency graph is connected.  However, Phil's
simulation results show that MPRs result in many more adjacenies
than OSPF-MDR even if the usual method is used for selecting MPRs.

Regarding my discussion with Philippe Jacquet on the MANET list, it did not
go beyond what we are discussing here.  Philippe never replied after
I correctly pointed out that OSPF-MDR results in fewer adjacencies than
using MPRs.

http://www1.ietf.org/mail-archive/web/manet/current/msg07547.html

Richard



Emmanuel Baccelli wrote:

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