From ospf-manet-bounces@ietf.org Tue Jan 02 15:56:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qgL-0003g2-3U; Tue, 02 Jan 2007 15:56:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H1qgI-0003fY-NC for ospf-manet@ietf.org; Tue, 02 Jan 2007 15:56:22 -0500 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H1qfm-0004zn-Pw for ospf-manet@ietf.org; Tue, 02 Jan 2007 15:56:22 -0500 Received: from dialup-4.243.134.93.dial1.sanfrancisco1.level3.net ([4.243.134.93] helo=earthlink.net) by pop-savannah.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1H1qfi-0002jp-00 for ospf-manet@ietf.org; Tue, 02 Jan 2007 15:55:46 -0500 Message-ID: <459AC6CE.5060009@earthlink.net> Date: Tue, 02 Jan 2007 12:55:42 -0800 From: Richard Ogier 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: ospf-manet@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Subject: [Ospf-manet] Simulation results for MPR adjacency reduction X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org All, Since I was curious about the performance of INRIA's solution with MPR adjacency reduction (in addition to MPR LSA reduction), I decided to modify the GTNetS code (the version INRIA released) to implement this, and run some simulations. The GTNetS code I used can be downloaded at: http://home.earthlink.net/~ogier/ospf6d_mpr_adj.tar.gz I include only the directory ospf6d, since everything else is the same as INRIA's release, except that the following line should be uncommented in the Makefile so that MDR can also be run: CFLAGS += -DOSPF6_MANET_MDR_FLOOD The results below give an idea of how MPR-based adjacencies perform based on INRIA's current draft specification. INRIA can probably improve the performance, e.g., by selecting MPRs more persistently, but until that happens, I wanted to see how it performs based on the current specification. The results for 20, 40, and 60 nodes are summarized below, followed by a summary of the code changes. Detailed results for 60 nodes and the parameters values are are given at the end of this message. For INRIA's solution (which is a modification of OR), I used the parameter values recommended by the Cisco OR/SP team and used in Boeing's simulations. As in OR/SP, for both INRIA and MDR, an adjacency is never torn down as long as the neighbor is bidirectional, to reduce the rate at which new adjacencies are formed. Results for MDR with 1-connected adjacencies and min-cost LSAs: 20 nodes 40 nodes 60 nodes -------- -------- -------- Total Overhead (kbps) 21.52 79.08 164.32 LSU overhead (kbps) 5.21 18.05 33.67 DD overhead (kbps) 4.08 18.54 36.28 Adjacencies/node 3.30 3.02 2.88 Adj changes/node/sec 0.04 0.04 0.04 Delivery ratio 0.966 0.951 0.953 Results for MPR-based LSAs and adjacency reduction: 20 nodes 40 nodes 60 nodes -------- -------- -------- Total Overhead (kbps) 48.20 234.12 588.43 LSU overhead (kbps) 10.32 40.08 72.33 DD overhead (kbps) 18.40 119.92 352.89 Adjacencies/node 8.58 15.93 21.93 Adj changes/node/sec 0.15 0.27 0.36 Delivery ratio 0.918 0.924 0.920 Notice that adjacency changes/node/sec stays constant at .04 for MDR, but increases approximately linearly for INRIA. This clearly shows that MPR adjacency reduction is not scalable. The DD overhead is 4.5 times greater for INRIA for 20 nodes, 6.5 times greater for 40 nodes, and 9.7 times greater for 60 nodes (notice the trend). Also notice that for INRIA the DD overhead becomes much greater than LSU overhead for 60 nodes, but for MDR the DD overhead is about the same as the LSU overhead for 20, 40, and 60 nodes. The delivery ratio is significantly greater for MDR than for INRIA. This could be partly due to the lower path/LSA stability of INRIA, since MPRs are not selected persistently (while min-cost LSAs are designed to be persistent), and partly due to the delay in updating MPRs following a link failure (as has been discussed). Code changes: I found the following bugs in INRIA's code: 1. An LSA was originated only when a neighbor goes to/from Full (same as for OR), but with MPR-based LSA reduction, an LSA should be originated whenever the set of MPRs or the set of MPR selectors changes. This problem went away with MPR-based adjacency reduction, since a neighbor becomes Full only after it becomes an MPR or MPR selector (or the router or neighbor is a sync node). 2. In the SPF calculation, the backlink check was not done for MPR-based LSA reduction. The backlink must always be checked for compatibility with OSPFv3 (i.e., the link from node w back to node v must exist). (Let me know if this has somehow changed.) 3. The code was written so that OSPF6_MANET_MDR_FLOOD and OSPF6_MANET_MPR_TOPO_REDUC could not both be defined, i.e., the code had to be compiled separately for the two protocols. Summary of changes: 1. The code was fixed so that OSPF6_MANET_MDR_FLOOD and OSPF6_MANET_MPR_TOPO_REDUC can both be defined, without the code for one protocol interfering with the other protocol. 2. The backlink check is always done. 3. The code now does MPR adjacency reduction, as follows: (a) need_adjacency() was modified so that an adjacency is needed only if the neighbor is an MPR or MPR selector, or the router or neighbor is a sync node. (b) A node determines that it is a sync node if it has a larger RID than all neighbors. This is updated whenever the set of neighbors changes, and is indicated in Hellos by setting the DR field equal to the router's own RID. (A detail not specified in the draft.) (c) Adjacencies are updated whenever the set of MPRs or MPR selectors changes, and whenever the set of neighbors changes. (d) MPRs are no longer required to be Full neighbors, and 2-hop neighbors are no longer required to be Full neighbors of 1-hop neighbors. Note that the modified code cannot run MPR LSA reduction without MPR adjacency reduction, since that would require even more work :-). Richard -------------------------------------- Detailed results for MDR for 60 nodes: ./random_waypoint_manet-opt seed=8 num_nodes=60 pktrate=10 wireless_interface=2 wireless_flooding=2 velocity=10 radio_range=250 alpha=0.5 pause_time=40 HelloInterval=2 RxmtInterval=7 DeadInterval=6 AckInterval=1000 BackupWaitInterval=500 TwoHopRefresh=3 AdjConnectivity=1 LSAFullness=1 start_time=1800 stop_time=2700 Neighbor statistics (at physical layer): -------------------------------------------------- Number of nodes: 60 Neighbor threshold distance (m): 250.00 Average neighbor density (neighbors/# of nodes): 0.63 Average neighbor changes/time (changes/sec/node): 0.30 OSPFv3 Statistics | Packets Bytes Kbps ---------------------------------------------------- Hello | 27000 5849812 52.00 LSAck | 38145 4753120 42.25 LSR | 246 13128 0.12 DBDESC | 4911 4081624 36.28 LSU | 18728 3787764 33.67 LSUfld | 15147 3078988 27.37 LSUuni | 3581 708776 6.30 LSUcol | 7 3704 0.03 LSUrxmt | 3307 655336 5.83 LSUdbex | 243 44928 0.40 LSUstale| 24 4808 0.04 | Total | 89030 18485448 164.32 OSPF Network Characteristics -------------------------------------------------- OSPF 2way_neighbors/node: 37.15 OSPF 2way_neighbor_changes/node/sec: 0.66 avg_sec/OSPF 2way neighbor_life: 121.12 OSPF adjacencies/node: 2.88 OSPF adjacency_changes/node/sec: 0.04 avg_LSAsOutSync: 0.12 Secs per router-LSA origination: 15.81 Router-LSA hopcount/Router-LSA installs: 2.61 Route changes/node/sec: 4.54 Accumulated adjacencies/node: -0.10 Flooding Statistics -------------------------------------------------- relaysel/node: 3.70 avg_sec/relaysel_life: 44.23 suppressed_LSAs: 165040 relay_flood_LSAs: 19259 nonrelay_flood_LSAs: 958 Topology Reduction Statistics -------------------------------------------------- Advertized neighbors: 20752 Total FULL neighbors: 113259 User Traffic Analysis -------------------------------------------------- UDP sends: 8951 pkts, 608668 bytes UDP receives: 8529 pkts, 579972 bytes UDP forwards: 3748 pkts, 254864 bytes Delivery Ratio: 0.953 ------------------------------------------ Detailed results for INRIA for 60 nodes: ./random_waypoint_manet-opt seed=8 num_nodes=60 pktrate=10 wireless_interface=2 wireless_flooding=1 velocity=10 radio_range=250 HelloInterval=2 RxmtInterval=9 DeadInterval=6 PushbackInterval=7000 AckInterval=500 MinLSInterval=5 velocity=10 start_time=1800 stop_time=2700 TopoReduc Neighbor statistics (at physical layer): -------------------------------------------------- Number of nodes: 60 Neighbor threshold distance (m): 250.00 Average neighbor density (neighbors/# of nodes): 0.63 Average neighbor changes/time (changes/sec/node): 0.30 OSPFv3 Statistics | Packets Bytes Kbps ---------------------------------------------------- Hello | 27000 6109348 54.31 LSAck | 85432 12017232 106.82 LSR | 4147 234588 2.09 DBDESC | 51672 39700376 352.89 LSU | 61758 8137020 72.33 LSUfld | 50603 6587356 58.55 LSUuni | 11155 1549664 13.77 LSUcol | 112 27252 0.24 LSUrxmt | 4953 502816 4.47 LSUdbex | 3929 795020 7.07 LSUstale| 2161 224576 2.00 | Total | 230009 66198564 588.43 OSPF Network Characteristics -------------------------------------------------- OSPF 2way_neighbors/node: 37.06 OSPF 2way_neighbor_changes/node/sec: 0.71 avg_sec/OSPF 2way neighbor_life: 111.63 OSPF adjacencies/node: 21.93 OSPF adjacency_changes/node/sec: 0.36 avg_LSAsOutSync: 0.27 Secs per router-LSA origination: 5.66 Router-LSA hopcount/Router-LSA installs: 2.15 Route changes/node/sec: 13.33 Accumulated adjacencies/node: 0.57 Flooding Statistics -------------------------------------------------- relaysel/node: 2.87 avg_sec/relaysel_life: 12.06 suppressed_LSAs: 439557 relay_flood_LSAs: 34974 nonrelay_flood_LSAs: 24216 Topology Reduction Statistics -------------------------------------------------- Advertized neighbors: 37634 Total FULL neighbors: 357653 User Traffic Analysis -------------------------------------------------- UDP sends: 8951 pkts, 608668 bytes UDP receives: 8237 pkts, 560116 bytes UDP forwards: 3105 pkts, 211140 bytes Delivery Ratio: 0.920 ----------------------- _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Mon Jan 08 09:07:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3v9d-0000Fz-KY; Mon, 08 Jan 2007 09:07:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H3v9b-0000Fs-Ty for ospf-manet@ietf.org; Mon, 08 Jan 2007 09:07:11 -0500 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H3v9a-0003Dp-GA for ospf-manet@ietf.org; Mon, 08 Jan 2007 09:07:11 -0500 Received: from [192.168.112.199] (sphinx.lix.polytechnique.fr [129.104.11.1]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l08E74wf008055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 8 Jan 2007 15:07:05 +0100 Message-ID: <45A25007.8030100@inria.fr> Date: Mon, 08 Jan 2007 15:07:03 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: ospf-manet@ietf.org Subject: Re: [Ospf-manet] Simulation results for MPR adjacency reduction References: <459AC6CE.5060009@earthlink.net> In-Reply-To: <459AC6CE.5060009@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45A25009.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Dear Richard, all, Happy new year to you and yours. Thanks for your contribution to the MPR-OSPF code. We already knew that the MPR-OSPF draft is simple to understand and to implement, but you were really very fast. Congratulations. However, we did not find exactly the same results as the ones you mentionned, we will release soon the results we got. In particular our simulation results show that MPR-based topology reduction and multicast outperforms MDR and OR performance reported by Boeing at the IETF. Here is an update to the MPR-OSPF code that implements multicast transmissions http://ndquan.free.fr/GTNetS/gtnets-LSAreduc-Mcast.tar.bz2 The use of multicast is now implemented in addition to MPR topology reduction, which provides a simple and robust solution ensuring that while the overhead is drastically reduced, every advertized link is still symmetric and synchronized. The available code for MPR-OSPF actually outperforms both OR and MDR (full LSA) simulated with the same parameters, based on the reports of Boeing that were presented at the IETF. We will release a report about these results soon. This confirms that topology reduction on its own is very efficient, apparently more than adjacency reduction. We would nevertheless like to stress the fact that the simulation scenarios and parameters that are used in the Boeing reports are quite restrictive. In particular, we think the values of parameters such as Retransmit time and min LSA interval are not in tune at all with high mobility, and that the 2x2 scenario with almost mesh connectivity is too specific. We think that it is essential to simulate other scenarios and other parameters. Concerning bugs in the code, we also found some of them that we want to share with you: for instance, it seems that an old Ack can somehow replace a newer Ack in the database and therefore create problems regarding retransmissions. Did you notice such a behaviour? We had to fix this. We have moreover fixed the bug you have mentionned concerning the conflicting flags OSPF6_MANET_MDR_FLOOD and OSPF6_MANET_MPR_TOPO_REDUC that can now be compiled together. Regards, Emmanuel _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Tue Jan 09 11:00:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JOf-0000ZL-GT; Tue, 09 Jan 2007 11:00:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4JOd-0000Wg-Oz for ospf-manet@ietf.org; Tue, 09 Jan 2007 11:00:19 -0500 Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4JOO-0006Qg-9f for ospf-manet@ietf.org; Tue, 09 Jan 2007 11:00:19 -0500 Received: from dialup-4.243.134.227.dial1.sanfrancisco1.level3.net ([4.243.134.227] helo=earthlink.net) by pop-tawny.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1H4JOL-0002i5-00; Tue, 09 Jan 2007 11:00:01 -0500 Message-ID: <45A3BC00.1050902@earthlink.net> Date: Tue, 09 Jan 2007 08:00:00 -0800 From: Richard Ogier 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 Subject: Re: [Ospf-manet] Simulation results for MPR adjacency reduction References: <459AC6CE.5060009@earthlink.net> <45A25007.8030100@inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ospf-manet@ietf.org X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Emmanuel, For MDR, the number of adjacency changes/node/sec is constant as the number of nodes increases. I.e., the number of synchronizations per second is linear in the the number of nodes. This is not true for MPR adjacencies (as my results show), and I don't think it is possible as long as each router must become adjacent with each of its MPRs and MPR selectors. Let me know if you are somehow avoiding this consequence. Maybe your results look OK for certain scenarios with a limited number of nodes, but how scalable is your solution? For example, how does it perform in dense networks with 100 or more nodes? Regarding multicasting retransmitted LSAs, you are simply requiring that every transmitted or retransmitted LSA be be Acked by every adjacent neighbor. This technique can be applied to any of the proposals, including MDR. One of the rules the design team discussed (more than a year ago) for a fair simulation comparison is the following: If a technique is used by protocol A, then it should also be used by protocol B if it improves performance for that protocol. Note that retransmitting LSAs as multicasts was considered in version 00 of the MDR draft. It was later removed partly to minimize changes to OSPF and partly because it did not appear to reduce overhead much when adjacency reduction is used. However, it can easily be allowed as an option if it is found to improve performance in some scenarios. I noticed that your code still does not do the backlink check in the SPF calculation when OSPF6_MANET_HELLO_OSPF_MPR is defined (this also affects the MDR code). Do you understand why this is not compatible with OSPFv3? For example, a MANET router could have a non-MANET neighbor, which performs the backlink check and therefore does not compute the shortest-path tree based on the same topology, possibly resulting in routing loops. In addition, an adjacency is not fully synchronized until the state is Full at BOTH endpoints. I took a quick look at the bug you mentioned where an old Ack can replace a newer Ack. I think you are correct, since in the function ospf6_store_mack(), if an Ack already exists in the mack list (even if it is newer), the sequence number of the stored Ack is set to the sequence number of the received Ack, even if the received Ack is older. Richard Emmanuel Baccelli wrote: > Dear Richard, all, > > Happy new year to you and yours. Thanks for your contribution to the > MPR-OSPF code. We already knew that the MPR-OSPF draft is simple to > understand and to implement, but you were really very fast. > Congratulations. > > However, we did not find exactly the same results as the ones you > mentionned, we will release soon the results we got. In particular our > simulation results show that MPR-based topology reduction and > multicast outperforms MDR and OR performance reported by Boeing at the > IETF. > > Here is an update to the MPR-OSPF code that implements multicast > transmissions http://ndquan.free.fr/GTNetS/gtnets-LSAreduc-Mcast.tar.bz2 > The use of multicast is now implemented in addition to MPR topology > reduction, which provides a simple and robust solution ensuring that > while the overhead is drastically reduced, every advertized link is > still symmetric and synchronized. > > The available code for MPR-OSPF actually outperforms both OR and MDR > (full LSA) simulated with the same parameters, based on the reports of > Boeing that were presented at the IETF. We will release > a report about these results soon. This confirms that topology > reduction on its own is very efficient, apparently more than adjacency > reduction. > > We would nevertheless like to stress the fact that the simulation > scenarios and parameters that are used in the Boeing reports are quite > restrictive. In particular, we think the values of parameters such as > Retransmit time and min LSA interval are not in tune at all with high > mobility, and that the 2x2 scenario with almost mesh connectivity is > too specific. We think that it is essential to simulate other > scenarios and other parameters. > > Concerning bugs in the code, we also found some of them that we want > to share with you: for instance, it seems that an old Ack can somehow > replace a newer Ack in the database and therefore create problems > regarding retransmissions. Did you notice such a behaviour? We had to > fix this. We have moreover fixed the bug you have mentionned > concerning the conflicting flags OSPF6_MANET_MDR_FLOOD and > OSPF6_MANET_MPR_TOPO_REDUC that can now be compiled together. > > Regards, > Emmanuel > > > > > _______________________________________________ > Ospf-manet mailing list > Ospf-manet@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-manet > > _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Tue Jan 09 20:05:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4RuM-0007iL-Vs; Tue, 09 Jan 2007 20:05:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4RuL-0007iG-Uo for ospf-manet@ietf.org; Tue, 09 Jan 2007 20:05:37 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4RuI-0003ca-3L for ospf-manet@ietf.org; Tue, 09 Jan 2007 20:05:37 -0500 Received: from [192.168.0.5] (ras75-3-82-226-221-97.fbx.proxad.net [82.226.221.97]) (authenticated bits=0) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0A15PUt030179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Jan 2007 02:05:26 +0100 Message-ID: <45A43BD4.5090609@inria.fr> Date: Wed, 10 Jan 2007 02:05:24 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: ospf-manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 45A43BD5.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ospf-manet] MPR-OSPF GTNetS simulations report X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Dear all, here is a report containing the GTNetS simulation results for the MPR-OSPF code : http://self.d.free.fr/MPR-OSPF/mpr-ospf-simulations-report.pdf Regards, Emmanuel _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Wed Jan 10 09:58:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4eu3-0000Kf-27; Wed, 10 Jan 2007 09:58:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4eu2-0000KZ-0Y for ospf-manet@ietf.org; Wed, 10 Jan 2007 09:58:10 -0500 Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4eu0-0003vt-Mt for ospf-manet@ietf.org; Wed, 10 Jan 2007 09:58:09 -0500 Received: from wtn12131.opnet.com (wtn12131.opnet.com [172.16.12.131]) by enterprise58.opnet.com (8.13.6/8.12.10) with ESMTP id l0AEuJW7020713 for ; Wed, 10 Jan 2007 09:56:19 -0500 Message-Id: <6.2.3.4.2.20070110094029.02891730@mailserver.opnet.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 10 Jan 2007 09:57:58 -0500 To: ospf-manet@ietf.org From: Aniket Desai In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OPNET-MailScanner: Found to be clean X-MailScanner-From: adesai@opnet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [Ospf-manet] Re: Ospf-manet Digest, Vol 13, Issue 1 X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org > >------------------------------ > >Message: 6 >Date: Wed, 10 Jan 2007 02:05:24 +0100 >From: Emmanuel Baccelli >Subject: [Ospf-manet] MPR-OSPF GTNetS simulations report >To: ospf-manet@ietf.org >Message-ID: <45A43BD4.5090609@inria.fr> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >Dear all, > >here is a report containing the GTNetS simulation results for the >MPR-OSPF code : >http://self.d.free.fr/MPR-OSPF/mpr-ospf-simulations-report.pdf > >Regards, >Emmanuel > > > >------------------------------ > >_______________________________________________ >Ospf-manet mailing list >Ospf-manet@ietf.org >https://www1.ietf.org/mailman/listinfo/ospf-manet > > >End of Ospf-manet Digest, Vol 13, Issue 1 >***************************************** Hi, It would have been interesting to see these statistics corroborated against a variety of parameters. For example, one could start with physical density: # of bidirectional neighbors per interface - directly affects hello overhead. Mobility model: Rate of change of bidirectional neighbors per interface - which indirectly affects DD overhead. As a protocol characteristic, one can measure # of adjacent neighbors per interface. Then in steady state, rate of change of adjacency = (#adjacent neighbors/#bidirectional neighbors) x rate of change of bidirectional neighbors, which directly affects DD overhead. Also # adjacent neighbors directly affects LSU size if one is only advertising adjacent neighbors. This way, it is possible to corroborate - at least on a high level - major components of protocol overhead and justify the final figure. A good protocol would try to condense adjacency graph and also make it as stable as possible, which results in less overhead. One can also compare the rate of LSA origination (approximately twice the rate of change of adjacencies per interface or at most #interfaces/MinLSInterval) and rate of LSA installation (ideally rate of LSA origination x # of interfaces, but some LSA are never installed in highly dynamic situations) to estimate indirectly how effective the flooding algorithm is. It is possible to mine some more interesting details, such as average time it takes for an LSA to percolate over the entire network (which is where BMDR can play a major role). When an LSA does not make it to all interfaces, somehow the metric should account for that. Also for fair comparison, SPF timers must be fixed as well - what are typical delay and hold timers that are used? Also what is the traffic model (all to all?), how much KBPS (or MBPS) is pumped into the network? Could not figure these out from the report. Thanks, Aniket _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Wed Jan 10 12:59:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hjH-00006S-TI; Wed, 10 Jan 2007 12:59:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4hjG-00006M-Uc for ospf-manet@ietf.org; Wed, 10 Jan 2007 12:59:14 -0500 Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4hjE-0001oF-MA for ospf-manet@ietf.org; Wed, 10 Jan 2007 12:59:14 -0500 Received: from dialup-4.243.137.193.dial1.sanfrancisco1.level3.net ([4.243.137.193] helo=earthlink.net) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1H4hjC-0005kr-00; Wed, 10 Jan 2007 12:59:10 -0500 Message-ID: <45A5296C.4060805@earthlink.net> Date: Wed, 10 Jan 2007 09:59:08 -0800 From: Richard Ogier 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 Subject: Re: [Ospf-manet] MPR-OSPF GTNetS simulations report References: <45A43BD4.5090609@inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ospf-manet@ietf.org X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org I wonder how your results would change with the following two bugs corrected: 1. An LSA was originated only when a neighbor goes to/from Full (same as for OR), but with MPR-based LSA reduction, an LSA should be originated whenever the set of MPRs or the set of MPR selectors changes. 2. In the SPF calculation, the backlink check was not done for MPR-based LSA reduction. The backlink must always be checked for compatibility with OSPFv3 (i.e., the link from node w back to node v must exist). With the first bug fixed, I would expect more LSA overhead. With the second bug fixed, I noticed that delivery ratio is significantly lower. However, fixing the first bug might help increase the delivery ratio. Anyway, at some point in the future, I expect that the proposed OSPF extensions will be compared in a fair manner. Richard Emmanuel Baccelli wrote: > Dear all, > > here is a report containing the GTNetS simulation results for the > MPR-OSPF code : > http://self.d.free.fr/MPR-OSPF/mpr-ospf-simulations-report.pdf > > Regards, > Emmanuel > > _______________________________________________ > Ospf-manet mailing list > Ospf-manet@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-manet > > _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Thu Jan 11 18:18:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H59BH-0006dn-1A; Thu, 11 Jan 2007 18:17:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H59BF-0006dh-Sq for ospf-manet@ietf.org; Thu, 11 Jan 2007 18:17:57 -0500 Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H59BE-0001bv-LQ for ospf-manet@ietf.org; Thu, 11 Jan 2007 18:17:57 -0500 Received: from dialup-4.243.134.9.dial1.sanfrancisco1.level3.net ([4.243.134.9] helo=earthlink.net) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1H59B9-0006qg-00; Thu, 11 Jan 2007 18:17:52 -0500 Message-ID: <45A6C59D.1070105@earthlink.net> Date: Thu, 11 Jan 2007 15:17:49 -0800 From: Richard Ogier 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 Subject: Re: [Ospf-manet] MPR-OSPF GTNetS simulations report References: <45A43BD4.5090609@inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ospf-manet@ietf.org X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Emmanuel Baccelli wrote: > Dear all, > > here is a report containing the GTNetS simulation results for the > MPR-OSPF code : > http://self.d.free.fr/MPR-OSPF/mpr-ospf-simulations-report.pdf > > Regards, > Emmanuel > Your report compares the following: 1. OR with no adjacency reduction and with full LSAs. 2. Same as 1, but retransmitted LSAs are multicast. 3. Same as 2, but with MPR LSA reduction. The bugs I mentioned apply mostly to LSA reduction. Your results show that 2 results in significantly less overhead than 1, i.e., that it helps to multicast retransmitted LSAs when full-topology adjacencies are used (no adjacency reduction). That is an interesting result, but the technique of multicasting retransmitted LSAs can be applied to any approach, including MDRs. So it says nothing about the MPR approach versus the MDR approach. Also, your results do not consider adjacency reduction. In particular, it is not clear that multicasting retransmitted LSAs is beneficial when adjacency reduction is used. To answer this question for MDR, I plan to run simulations with multicast retransmitted LSAs, with and without adjacency reduction. As I mentioned in my post two days ago, this technique can easily be allowed as an option if it is found to improve performance in some scenarios. Also, since any method for LSA reduction can be used with any of the proposed extensions, your results for MPR LSA reduction do not say anything about the MPR approach versus the MDR approach. At some point, I would like to compare min-cost LSAs with MPR-based LSAs for MDR. Richard > > > _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Fri Jan 12 10:08:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5O0m-0000g0-Mn; Fri, 12 Jan 2007 10:08:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5O0l-0000fs-E5 for ospf-manet@ietf.org; Fri, 12 Jan 2007 10:08:07 -0500 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5O0i-0000JK-12 for ospf-manet@ietf.org; Fri, 12 Jan 2007 10:08:07 -0500 Received: from [128.93.17.56] (monteverdi.inria.fr [128.93.17.56]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0CF7uGT029160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Jan 2007 16:07:56 +0100 Message-ID: <45A7A448.4030707@inria.fr> Date: Fri, 12 Jan 2007 16:07:52 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: ospf-manet@ietf.org Subject: Re: [Ospf-manet] MPR-OSPF GTNetS simulations report References: <45A43BD4.5090609@inria.fr> <45A6C59D.1070105@earthlink.net> In-Reply-To: <45A6C59D.1070105@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 45A7A44C.002 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Hi Richard, We are happy to see that you join the consensus to push the 3 current proposals to experimental status. That way the community will gather experience by mixing the various mechanisms for flooding reduction, topology reduction and adjacency reduction. We agree that multicast decreases the impact of adjacency reduction. It is one of the factors that enables MPR-OSPF to perform that well while keeping strict OSPF adjacency mechanisms. Regards, Emmanuel _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Thu Jan 18 17:46:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7g1f-0005VT-1C; Thu, 18 Jan 2007 17:46:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7g1e-0005VO-30 for ospf-manet@ietf.org; Thu, 18 Jan 2007 17:46:30 -0500 Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7g1c-0007FC-Pv for ospf-manet@ietf.org; Thu, 18 Jan 2007 17:46:30 -0500 Received: from dialup-4.245.102.78.dial1.sanjose1.level3.net ([4.245.102.78]) by pop-sarus.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1H7g1Z-0004ZV-00; Thu, 18 Jan 2007 17:46:26 -0500 Message-ID: <45AFF8C2.3040705@earthlink.net> Date: Thu, 18 Jan 2007 14:46:26 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Ospf-manet] MPR-OSPF GTNetS simulations report References: <45A43BD4.5090609@inria.fr> <45A6C59D.1070105@earthlink.net> <45A7A448.4030707@inria.fr> In-Reply-To: <45A7A448.4030707@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ospf-manet@ietf.org X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org > Emmanuel Baccelli wrote: > Hi Richard, > > We are happy to see that you join the consensus to push the 3 current > proposals to experimental status. That way the community will gather > experience by mixing the various mechanisms for flooding reduction, > topology reduction and adjacency reduction. > > We agree that multicast decreases the impact of adjacency reduction. > It is one of the factors that enables MPR-OSPF to perform that well > while keeping strict OSPF adjacency mechanisms. > > Regards, > Emmanuel Emmanuel, (I have been away from my email for the last week.) It's amazing how you twist my words to conclude that I have joined "consensus" to push the 3 current proposals to experimental status. This twisting of words is one reason why I do NOT want to engage in arguments with INRIA for the next year or so. Another reason is that you are trying to avoid a fair comparison, which is why I had to work hard to write code for your MPR-based adjacency reduction. My points were that your main contributions - MPR-based LSA reduction and multicast retransmitted LSAs - do not by themselves constitute an OSPF extension, but are techniques that can be applied to either ORs or MDRs (and it is not yet clear that either provides any significant advantage for MDR). Also, your MPR-based adjacency reduction is simply not scalable, as was clearly shown in my simulations. I am currently running simulations for 80 and 100 nodes to add to my previous simulation results. Some may say that INRIA's solution is "good enough" to become an experimental WG draft, but I disagree with that because it does not scale to dense 100-node networks, as do the other solutions, and INRIA has not shown that it scales to such networks. If you can show that it scales as well (or almost as well) as the other two solutions, then I would agree that it can be advanced to experimental. But I don't think this is possible without major changes. And this leads to the problem that Joe Macker warned about at the last meeting, i.e., we want to avoid major changes to the drafts once they become experimental WG drafts. Otherwise, we may never converge. Since your solution is not currently as scalable as the other solutions, maybe you are planning to later to modify it later to make it more scalable, e.g., by using the database signature exchange mechanism. As Joe Macker advised, we want to avoid making such major changes later. Therefore, any major changes should be made BEFORE your draft is advanced to experimental, and simulations should be run to compare the finalized version to the other proposals. (On the other hand, using the database signature method might have the disadvantage of being too much of a change from legacy OSPFv3, but that is a different issue.) In summary, once you have finalized your draft (so that no major changes will be necessary), then let's compare it to the other two solutions. If it is almost as scalable as MDR, then I would have no objection to your draft becoming an experimental WG draft. Richard > > > _______________________________________________ > Ospf-manet mailing list > Ospf-manet@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-manet > _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Fri Jan 19 10:56:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7w6I-00044c-Ua; Fri, 19 Jan 2007 10:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7w6H-00044T-PA for ospf-manet@ietf.org; Fri, 19 Jan 2007 10:56:21 -0500 Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7w6D-0004Cf-Rf for ospf-manet@ietf.org; Fri, 19 Jan 2007 10:56:21 -0500 Received: from dialup-4.245.102.231.dial1.sanjose1.level3.net ([4.245.102.231]) by pop-altamira.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1H7w6C-0006x9-00 for ospf-manet@ietf.org; Fri, 19 Jan 2007 10:56:17 -0500 Message-ID: <45B0EA20.7000708@earthlink.net> Date: Fri, 19 Jan 2007 07:56:16 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ospf-manet@ietf.org Subject: Re: [Ospf-manet] MPR-OSPF GTNetS simulations report References: <45A43BD4.5090609@inria.fr> <45A6C59D.1070105@earthlink.net> <45A7A448.4030707@inria.fr> In-Reply-To: <45A7A448.4030707@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org All, I ran simulations for 80 nodes, to add to my previous GTNetS simulation results for 20, 40, and 60 nodes. I used the same code that I used before. INRIA's protocol used MPR-based LSA reduction and MPR-based adjacency reduction (but retransmitted LSAs were not multicast). MDR used 1-connected adjacencies and min-cost LSAs. The same trend continued, with INRIA generating 15 times as much DD overhead as MDR, and 5 times as much total overhead as MDR. LS Ack overhead (not shown below) was 204.24 kbps for INRIA and 75.14 kbps for MDR. Note that using multicast retransmitted LSAs will not affect DD overhead, and may increase LS Ack overhead (since every adjacent neighbor must Ack each multicast LSA). Parameters were given with my previous results. Summary of results: MDR 20 nodes 40 nodes 60 nodes 80 nodes --- -------- -------- -------- -------- Total Overhead (kbps) 21.52 79.08 164.32 271.00 LSU overhead (kbps) 5.21 18.05 33.67 50.56 DD overhead (kbps) 4.08 18.54 36.28 60.88 Adjacencies/node 3.30 3.02 2.88 2.84 Adj changes/node/sec 0.04 0.04 0.04 0.04 Delivery ratio 0.966 0.951 0.953 0.949 INRIA 20 nodes 40 nodes 60 nodes 80 nodes ----- -------- -------- -------- -------- Total Overhead (kbps) 48.20 234.12 588.43 1357.45 (5xMDR) LSU overhead (kbps) 10.32 40.08 72.33 127.56 DD overhead (kbps) 18.40 119.92 352.89 934.31 (15xMDR) Adjacencies/node 8.58 15.93 21.93 25.12 Adj changes/node/sec 0.15 0.27 0.36 0.53 (13xMDR) Delivery ratio 0.918 0.924 0.920 0.912 Richard _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Tue Jan 23 04:43:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9IBS-00052g-28; Tue, 23 Jan 2007 04:43:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9IBQ-00051i-9a for ospf-manet@ietf.org; Tue, 23 Jan 2007 04:43:16 -0500 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9IBO-0007k4-Jh for ospf-manet@ietf.org; Tue, 23 Jan 2007 04:43:16 -0500 Received: from [192.168.0.5] (ras75-3-82-226-221-97.fbx.proxad.net [82.226.221.97]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0N9h9iH006302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Jan 2007 10:43:09 +0100 Message-ID: <45B5D8A7.8030408@inria.fr> Date: Tue, 23 Jan 2007 10:43:03 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: ospf-manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45B5D8AD.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ospf-manet] MPR-OSPF with Adjacency Reduction GTNetS Simulation Report X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Dear all, here is a report of the GTNetS simulations we carried out with the MPR-OSPF extension together with the adjacency reduction option : http://self.d.free.fr/MPR-OSPF/MPR-OSPF-GTNetS-Simulation-Report.pdf The code is available here: http://ndquan.free.fr/GTNetS/gtnets-SyncNode-AdjLSAreduc-Mcast.tar.bz2 Best regards, Emmanuel _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Tue Jan 23 04:45:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9IDt-0006fh-OD; Tue, 23 Jan 2007 04:45:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9IDs-0006fY-By for ospf-manet@ietf.org; Tue, 23 Jan 2007 04:45:48 -0500 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9IDq-0008BC-WF for ospf-manet@ietf.org; Tue, 23 Jan 2007 04:45:48 -0500 Received: from [192.168.0.5] (ras75-3-82-226-221-97.fbx.proxad.net [82.226.221.97]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0N9jjpI006863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Jan 2007 10:45:46 +0100 Message-ID: <45B5D944.9010303@inria.fr> Date: Tue, 23 Jan 2007 10:45:40 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: ospf-manet@ietf.org Subject: Re: [Ospf-manet] MPR-OSPF GTNetS simulations report Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45B5D949.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Dear Richard, We agree that there is no need to argue. The MPR-OSPF is a consistent extension of OSPFv3 that uses flooding reduction, topology reduction and adjacency reduction based on MPR, with a stable specification ready for experimental status. You suggest that you could introduce some changes in MDR, taking advantage of the experimental status. We do not think that it is needed to introduce the major changes you mentionned (such as including MPR topology reduction or multicast) since they are already featured in the MPR-OSPF extension. However, if you think MDR needs major changes, then MDR is not ready for experimental status. Emmanuel _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Sun Jan 28 18:55:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJri-0004Gm-91; Sun, 28 Jan 2007 18:55:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBJrg-0004GB-3h for ospf-manet@ietf.org; Sun, 28 Jan 2007 18:55:16 -0500 Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBJre-00028B-RK for ospf-manet@ietf.org; Sun, 28 Jan 2007 18:55:16 -0500 Received: from dialup-4.245.101.172.dial1.sanjose1.level3.net ([4.245.101.172]) by pop-borzoi.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1HBJrc-0007eW-00; Sun, 28 Jan 2007 18:55:12 -0500 Message-ID: <45BD37DF.1050005@earthlink.net> Date: Sun, 28 Jan 2007 15:55:11 -0800 From: Richard Ogier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emmanuel Baccelli Subject: Re: [Ospf-manet] MPR-OSPF GTNetS simulations report References: <45B5D944.9010303@inria.fr> In-Reply-To: <45B5D944.9010303@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ospf-manet@ietf.org X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Emmanuel, Regarding your simulation results, it looks like using MPR adjacency reduction does not reduce overhead much, and based on the simulation results I presented recently, MDR with adjacency reduction has much lower overhead. I think you would have to make major changes to your draft before it is competitive with MDR. For example, you will at least have to select MPRs (and "path MPRs" for LSAs) to be more stable, which has not yet been described in your draft. The MDR draft does not need major changes, but I am making changes to improve readability, to simplify the BMDR algorithm, and other minor changes such as improving min-cost LSAs. This does not change the core methods for flooding and adjacency reduction, which have been stable for about two years. My point was that, since MPR adjacency reduction is not scalable, the main contributions of your draft are MPR LSA reduction and multicast retransmitted LSAs (the latter of which is not new and was considered in version 00 of the MDR draft), and that these two contributions do not by themselves constitute an OSPF extension, but are techniques that can be applied to either ORs or MDRs. I mentioned that I will experiment with multicast retransmitted LSAs to see if they improve the performance of MDRs in some scenarios, and if they do they can be included as an option. This would be a minor change to the MDR draft. After we have both finalized our drafts, we should continue our discussion then, and perform a fair simulation comparison. Until then, I suggest we take a break from this discussion. Richard Emmanuel Baccelli wrote: > Dear Richard, > > We agree that there is no need to argue. The MPR-OSPF is a consistent > extension of OSPFv3 that uses flooding reduction, topology reduction and > adjacency reduction based on MPR, with a stable specification ready for > experimental status. > > You suggest that you could introduce some changes in MDR, taking > advantage of the experimental status. We do not think that it is needed > to introduce the major changes you mentionned (such as including MPR > topology reduction or multicast) since they are already featured in the > MPR-OSPF extension. However, if you think MDR needs major changes, then > MDR is not ready for experimental status. > > Emmanuel > > > _______________________________________________ > Ospf-manet mailing list > Ospf-manet@ietf.org > https://www1.ietf.org/mailman/listinfo/ospf-manet > _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Wed Jan 31 04:48:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCC5I-00033U-Pt; Wed, 31 Jan 2007 04:48:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCC5H-00033H-Nv for ospf-manet@ietf.org; Wed, 31 Jan 2007 04:48:55 -0500 Received: from discorde.inria.fr ([192.93.2.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCC5D-00048C-AY for ospf-manet@ietf.org; Wed, 31 Jan 2007 04:48:55 -0500 Received: from [192.168.0.5] (ras75-3-82-226-221-97.fbx.proxad.net [82.226.221.97]) (authenticated bits=0) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0V9mR2d011901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Jan 2007 10:48:28 +0100 Message-ID: <45C065EA.9040906@inria.fr> Date: Wed, 31 Jan 2007 10:48:26 +0100 From: Emmanuel Baccelli User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: ospf-manet@ietf.org Subject: Re: [Ospf-manet] MPR-OSPF GTNetS simulations report Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45C065EB.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org Hi Richard, MPR-OSPF ensures that each advertized link is synchronized. This is why there is not a drastic improvement with the adjacency reduction option. We agree that enough was exchanged about the subject: it is not possible to compare the different proposals with mere simulations. In particular, we must evaluate the functions that are provided by the different mechanisms, and not only raw overhead in a single scenario. Experience must be gathered with MPR, MDR and OR in order to really compare these approaches. So let's do that! Emmanuel _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet From ospf-manet-bounces@ietf.org Wed Jan 31 17:29:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNxh-0007oL-Iv; Wed, 31 Jan 2007 17:29:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCNxf-0007mf-E2 for ospf-manet@ietf.org; Wed, 31 Jan 2007 17:29:51 -0500 Received: from enterprise58.opnet.com ([192.104.65.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCNxe-0004ey-5C for ospf-manet@ietf.org; Wed, 31 Jan 2007 17:29:51 -0500 Received: from wtn12131.opnet.com (wtn12131.opnet.com [172.16.12.131]) by enterprise58.opnet.com (8.13.6/8.12.10) with ESMTP id l0VMR7KH024948; Wed, 31 Jan 2007 17:27:08 -0500 Message-Id: <6.2.3.4.2.20070131171954.0284c1a8@mailserver.opnet.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Wed, 31 Jan 2007 17:29:38 -0500 To: ospf-manet@ietf.org, ospf-manet@ietf.org From: Aniket Desai Subject: Re: [Ospf-manet] MPR-OSPF GTNetS simulations report In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OPNET-MailScanner: Found to be clean X-MailScanner-From: adesai@opnet.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ospf-manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions of OSPFv3 extensions supporting MANET List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ospf-manet-bounces@ietf.org ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Hi Richard, MPR-OSPF ensures that each advertized link is synchronized. This is why there is not a drastic improvement with the adjacency reduction option. We agree that enough was exchanged about the subject: it is not possible to compare the different proposals with mere simulations. In particular, we must evaluate the functions that are provided by the different mechanisms, and not only raw overhead in a single scenario. Experience must be gathered with MPR, MDR and OR in order to really compare these approaches. So let's do that! Emmanuel ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Hello, From the previous emails, it seemed that Dr. Ogier suggested the use of simulations as a "tie breaker" to even administer a proposal to experimental status. Simulations may not be the most accurate representation of the reality to the last bit, but they provide sufficient framework to cheaply evaluate and compare different proposals against each other. I believe it should be possible to design a series of parametric runs (changing node density, changing mobility, changing network size, changing radio range etc etc.) to extensively compare all the proposals against each other. All the criticism about considering only a single/limited set of scenarios gets nullified when one has conducted a parametric run, and I don't see any way other than the simulations to do this. Thanks, Aniket _______________________________________________ Ospf-manet mailing list Ospf-manet@ietf.org https://www1.ietf.org/mailman/listinfo/ospf-manet