Subject: [Ospf-manet] Re: Ospf-manet Digest, Vol 10, Issue 4

From: Aniket Desai <[email-masked]>
Date: Mon, 18 Sep 2006 10:02:54 -0400

Hi everyone,

I should perhaps take this opportunity to announce that OPNET now 
supports OSPFv3 MANET extensions with MDR (with some limitations, 
which hopefully will be removed soon). The implementation has been 
internally extensively validated against Dr. Ogier's published 
results. Although I am not here wearing my sales hat, I am merely 
indicating that a tool to *extensively validate* Ogier draft is 
available right now. One can definitely set up 3D simulations in 
OPNET and use all of its features to conduct any kind of simulations.

I think it is somewhat harsh to say that Ogier draft has NOT been 
evaluated enough; when on the contrary; I have never seen a single 
instance of evaluation of competing proposals. If a competing 
proposal has been evaluated, it is in a totally different context. I 
don't think OLSR evaluation counts as OSPF evaluation, because OLSR 
does not have acknowledgement/retransmissions/adjacencies, which are 
so integral to OSPF. Dr. Ogier has already published enough results 
(for 50 nodes and 100 nodes for dense and sparse networks with 
varying mobility and other controlling parameters), and the criticism 
seems to be that they are on a 2D scale. It is easy to rectify that. 
Although I happen to think that Ogier draft is superior purely on the 
basis on merit (there are many reasons for this), the fact is that it 
is the only draft, which has been written in completeness and has 
been implemented and validated by at least 2 independent sources 
(GTNets and OPNET).

Since there is no complete proposal and no open source implementation 
and/or evaluation of competing proposals (someone can correct me if I 
am wrong), I think it is only fair if we treat Ogier draft as a 
reference. If we think that it has not been evaluated enough, we have 
all means to do it any time. If we think that the draft has weakness 
in certain aspects (such as retransmissions), we should be able to 
accurately define experiments under which such weaknesses will be 
exposed. Then we should set up simulations and see if the results show it.

I think that OSPF MANET does not require multicast retransmissions as 
much as it needs *adjacency contraction* and intelligent 
acknowledgements (both of which are very integral to Ogier draft). 
This is simply because if conditions are so bad that multicast 
retransmissions are going to be a factor at all; then nothing will 
help as much as using a *no ack* option in LSA. A very simple 
algorithm for using *no ack*: If a router finds that its number of 
adjacencies are above a certain threshold, use no-ack in all LSA. 
Fancier algorithms are possible (which can keep a historical account 
of average time between 2 LSA generation etc.). In all other 
conditions, multicast retransmissions should not matter as much as 
*less and robust* adjacencies and intelligent acknowledgements. This 
design choice is much more sensible than introducing a very 
complicated multicast retransmission mechanism and breaking down 
legacy OSPF functionality.

Thanks,

Aniket

At 12:00 PM 9/17/2006, [email-masked] wrote:
>Send Ospf-manet mailing list submissions to
>         [email-masked]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>         https://www1.ietf.org/mailman/listinfo/ospf-manet
>or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
>You can reach the person managing the list at
>         [email-masked]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Ospf-manet digest..."
>
>
>Today's Topics:
>
>    1. Re: Re: Ospf-manet Digest, Vol 9, Issue 11 (Philippe Jacquet)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Sun, 17 Sep 2006 11:20:31 +0200
>From: Philippe Jacquet <[email-masked]>
>Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 9, Issue 11
>To: Richard Ogier <[email-masked]>
>Cc: [email-masked]
>Message-ID: <[email-masked]>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Dear Richard,
>
>You can imagine the largest number of scenarios in your proposal  and
>complicate it as well, the point is that we have only a very small
>feedback on real experiment or simulation. To my best  knowledge MDR
>have been evaluated only on 2x2 square with random  way point.
>
>It is the first time I see an attempt to push a proposal that has  been
>validated on such a small set of scenarios and which provide little
>improvement and in most case worse performance than a  solution that
>have been validated on a very much larger scale as  you can check on the
>web.
>
>The point on your MDR improvement seems really like an improvement
>dictated by the very specific and narrow case of the 2x2 square
>network. It does not seem to be a good way of design.
>
>Philippe
>
>Richard Ogier wrote:
>
> > Philippe Jacquet wrote:
> >
> >> Richard Ogier wrote:
> >>
> >>>
> >>>>
> >>>>
> >>>> However in a purely random network, using the dense connectivity
> >>>> parameters from Dr. Ogier's simulations (30 neighbors per router in
> >>>> 50 node network), the probability of 2 routers having the exact
> >>>> same neighborhood is small (using simple calculations, we can
> >>>> verify it to be something in between (1/3)^12 and (1/3)^13).
> >>>
> >>>
> >>>
> >>>
> >>> But the probability of one router having a neighborhood that is a
> >>> subset of
> >>> another router's neighborhood is much larger, which is more relevant.
> >>> For example, if routers are positioned randomly in a circle, then
> >>> routers
> >>> that are near the edge of the circle are more likely to have this
> >>> property.
> >>
> >>
> >>
> >>
> >> This case is strongly related to the unit disk graph model. It seems
> >> to me like an optimization specifically taylored to the intensively
> >> simulated 2x2 square where a significant number of neighborhoods are
> >> truncated by the border of the square. I don't think this would
> >> generalize very well regarding real implementations.
> >
> >
> >
> > So you are saying that the optimization is specifically tailored to
> > a unit disk or a 2x2 square (where you assume the radio range is
> > one unit).  More generally, one might say the optimization is
> > tailored to dense networks with a small diameter.
> > Such networks are important, as are sparse networks and large
> > diameter networks.  (Also, I see that Aniket explained how this
> > optimization is important in hybrid networks.)
> > You may be correct that this optimization helps performance the most
> > in dense networks with a small diameter, but since such networks can
> > occur and should be supported, I think that is enough reason to use
> > the optimization.  The goal is to achieve good performance in a wide
> > variety of scenarios, including dense networks.
> >
> > Richard
> >
> >>
> >>
> >>
> >> Best regards,
> >> Philippe
> >>
> >>>
> >>
> >>
> >>
> >
> >
> >
>
>
>
>
>------------------------------
>
>_______________________________________________
>Ospf-manet mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ospf-manet
>
>
>End of Ospf-manet Digest, Vol 10, Issue 4
>*****************************************

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