Subject: [manet] Test: change in rute for an OLSR net

From: "Geir Gyland" <[email-masked]>
Date: Wed, 20 Nov 2002 13:41:41 +0100

Hi all!

We did some simple static test of route change using 4 nodes set up like
this:

      .  3   .
   .             .
1                   4
   .             .
      .  2   .

Node 1 and 4 are out of reach for each other (2 hops)

We generated CBR traffic with a speed of 11Mb/s (UDP) traffic and sent
it through the network. Initially the route was 1 - 3 - 4 then we
stopped the interface on node 3 and observed when the traffic started
passing over the route 1 - 2 - 4

I would have believed the route change to take 4 - 6 seconds (Neighbor
hold time + TC) but we observed twice as much time (between 12 and 15
sec) before the traffic was traveling over node 2.

Does anyone have an explanation to justify the time? 
 
At the moment we do not trust our results!

Additional information:
 
All nodes are laptops, running Red Hat 7.3 using the NLR (nolsrd)
modified version of the INRIA olsrd code version 1.0a9. 

OLSR parameters were set to the default values of the NRL version 
HELLO interval 0.5
HELLO multiplier 8
TC intereval 3
TC multiplier 5

-----------------------------
Geir Gyland
E-mail: [email-masked]

---
[This E-mail was scanned for viruses by Declude Virus]

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

---

From: David Young <[email-masked]>
Date: Wed, 20 Nov 2002 11:42:08 -0600

> At the moment we do not trust our results!

What do the debug outputs from OLSR say? What does tcpdump say is
happening "on the air" ?

Dave

-- 
David Young             OJC Technologies
[email-masked]      Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: David Young <[email-masked]>
Date: Wed, 20 Nov 2002 11:42:08 -0600

Dave

---

From: Henrik Lundgren <[email-masked]>
Date: Wed, 20 Nov 2002 23:14:01 +0100 (MET)

Hi,

We have the same experience; same scenario but
with OLSR from Inria with default parameters
and we experience about 10 seconds re-route time.
However, We did not investigated this further.

Henrik Lundgren
Uppsala University

---

From: Henrik Lundgren <[email-masked]>
Date: Wed, 20 Nov 2002 23:14:01 +0100 (MET)

Hi,

Henrik Lundgren
Uppsala University

---

From: John Novatnack <[email-masked]>
Date: Wed, 20 Nov 2002 18:31:27 -0500

Hi,
    We have been working with analyzing OLSR within simulations, and 
found  similar results.  To answer your question, you can trust your 
results.  We were able to draw out the events that are the cause for the 
route convergence time.  Generally, it is due to the events that must 
take place for a chain of MPRs to be setup before a topology message 
will be forwarded.  A paper on all of our findings is forthcoming.  Let 
me know if you have any more questions.

- john

-- 
John Novatnack ( [email-masked] )
Research Assistant: ITCS Laboratory - Drexel University
http://itcsl.cs.drexel.edu
http://itcsl.cs.drexel.edu/~john

---

From: John Novatnack <[email-masked]>
Date: Wed, 20 Nov 2002 18:31:27 -0500

Hi,

- john

---

From: Anis LAOUITI <[email-masked]>
Date: Thu, 21 Nov 2002 12:37:26 +0100

Hi guys,

In the OLSR draft 6, we have introduced  new mechanisms
to react fastly  to such situations. You can find all details in the
section
"2.3.9.  Advanced Topology Discovery Functioning" of the OLSR draft 7.

Anis LAOUITI

---

From: "Philippe Jacquet" <[email-masked]>
Date: Thu, 21 Nov 2002 18:24:45 +0100

But the modification in v7 is for much faster route repair (eg. via two hop
neighbor table). In the basic protocol, 15 seconds seem much too large for a
local change. The MPR set of node 4 should be changed and advertized after
4-4.5 sec after node 3 shot down. TC sent after a maximum of 3 sec (spec
suggests to send early TC). I don't understand the result. Maybe the two-hop
neighbor table of node 4 is not updated properly when node 3 disappears from
neighbor table of node 4 and an additionnal 4 sec is spent. Maybe also the
change in the routing table in node 1 is not triggered properly when the
loss of neighbor 3 happens (this may be easy to check if packet continues to
be sent to node 3 after it has been removed from neighbor table).

Philippe
----- Original Message -----
From: Anis LAOUITI <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; John Novatnack <[email-masked]>
Sent: Thursday, November 21, 2002 12:37 PM
Subject: Re: [manet] Test: change in rute for an OLSR net

---

From: "Philippe Jacquet" <[email-masked]>
Date: Thu, 21 Nov 2002 18:24:45 +0100

Philippe

---

From: Anis LAOUITI <[email-masked]>
Date: Thu, 21 Nov 2002 12:37:26 +0100

Hi guys,

Anis LAOUITI