Re: [Ospf-manet] Simulation results for MPR adjacency reduction

[Richard Ogier <[e-mail]>]

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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ospf-manet
>
>



_______________________________________________
Ospf-manet mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ospf-manet