[Ospf-manet] Re: Ospf-manet Digest, Vol 13, Issue 1

Aniket Desai <adesai@opnet.com> Wed, 10 January 2007 14:58 UTC

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 <ospf-manet@ietf.org>; 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 <adesai@opnet.com>
In-Reply-To: <E1H4RuO-0007iv-5b@megatron.ietf.org>
References: <E1H4RuO-0007iv-5b@megatron.ietf.org>
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 <ospf-manet.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ospf-manet>, <mailto:ospf-manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ospf-manet>
List-Post: <mailto:ospf-manet@ietf.org>
List-Help: <mailto:ospf-manet-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ospf-manet>, <mailto:ospf-manet-request@ietf.org?subject=subscribe>
Errors-To: ospf-manet-bounces@ietf.org

>
>------------------------------
>
>Message: 6
>Date: Wed, 10 Jan 2007 02:05:24 +0100
>From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
>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