Subject: [manet] doubt in OLSR duplicate set (sec 4.1)

From: manet user <[email-masked]>
Date: Tue, 21 Dec 2004 10:39:58 -0800 (PST)

Hi,
 
According to section 4.1 in OLSR RFC 3626, the message should not be 
retransmitted if D_addr, D_seq_num and D_iface_list matches.
 
Considering an example of node A -----> node B. A sending TC to node B 
at time 1sec. Both node A and B have only 1 interface. 
 
At time 1 sec, B recvs TC from node A, and suppose it is not selected 
as MPR by A at that time. So it will not forward the TC. It stores 
Duplicate Entry with D_iface_list as its intf_addr and D_rexmit as False.
 
Now this entry will be there till 31 sec (assuming 30 sec expiry for 
dup entry).
 
Somewhere between 1 and 31 sec, if node B was selected as MPR by node 
A, but node A's MPR selector set remains same, TC seq num will remain 
same.
TCs recvd by node B from A, will not be forwarded as the Duplicate 
Entry with D_addr, D_seq_num exists with D_iface_list as its intf_addr. 
This will not allow node B to forward any TC from node A till this dup 
entry expires, though it should forward those TCs.
 
 Is this correct behavior? Please help if i am missing something.
 
Thanks.

---------------------------------
Do you Yahoo!?
 The all-new My Yahoo! – What will yours do?

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

---

From: "Francisco J. Ros" <[email-masked]>
Date: Tue, 21 Dec 2004 21:52:11 +0100

Hi,

I think you are confusing Message Sequence Number (D_seq_num) with ANSN 
(Advertised Neighbor Sequence Number). So the last TC messages will be 
forwarded because Message Sequence Number is updated every time a new message 
is sent.

Regards,
Francisco J. Ros

El Martes, 21 de Diciembre de 2004 19:39, manet user escribió:
>  The all-new My Yahoo!  What will yours do?

---

From: [email-masked]
Date: Tue, 21 Dec 2004 22:02:20 +0100 (CET)

Hi :==))

> retransmitted if D_addr, D_seq_num and D_iface_list matches.

The correct section is 3.4.1 ;==)

> A, but node A's MPR selector set remains same, TC seq num will remain

No, Tc seq num is increased by 1 for each Tc generated by Node A. However,
in your case ANSN will remain the same.

> entry expires, though it should forward those TCs.

1- Before selecting node B as MPR, for each TC message sent by A (suppose
that the node A MPR selector is not empty) the node B updates the entry
for A (D_time = current time + DUP_HOLD_TIME) but D_retransmitted remains
false.

2-The next TC message sent by A after selecting node B as MPR, will have
TC-seq_num > D_seq_num. As B is an MPR of A : (i) B will forward the TC
message; (ii) B Will update the entry for A with D_retransmitted = true.

> Thanks.

Hakim ;=====)

---

From: manet user <[email-masked]>
Date: Tue, 21 Dec 2004 15:48:30 -0800 (PST)

Thanks Francisco and Hakim for clarifying the doubt. I got confused between D_seq_num and ANSN. So basically duplicate set entries are only added/updated when a packet/message is considered for forwarding (rexmitted will be true or false depending if fwding condition was met or not).
 
I observe OLSR to be way too slow for large networks (for approx 400-500 nodes placed in a grid in a simulation environment). Application traffic is not too exhaustive, but just the control overhead consumes all the bandwidth. Even without mobility, TC flooding, processing and resulting route table recalculations are too frequent and expensive. Isn't this an OLSR scalability issue? Any such experience/comments will help me better understand this behavior.
 
Thanks.

"Francisco J. Ros" <[email-masked]> wrote:
Hi,

Regards,
Francisco J. Ros

---------------------------------
Do you Yahoo!?
 Meet the all-new My Yahoo! – Try it today!

---

From: Philippe Jacquet <[email-masked]>
Date: Wed, 22 Dec 2004 03:22:07 +0100

Scalability can be an issue for mobile ad hoc routing but it has not been
included in the OLSR RFC. Originally OLSR design allows the Fisheye technique
developped by Mario Gerla of UCLA. Basically it consists to play with TC's TTL.
The same node change the TTL for any new TC, large TTL being less frequent than
short TTL. Doing so the local control traffic is much less affected by the TC's
coming from remote nodes. In theory by an appropriate scaling of frequency
versus TTL one can handle an unbounded number of nodes while keeping the local
control traffic bounded. 

Of course less frequent TC with large TTL should be send with an appropriately
larger VTime so that link information does not disappear in remote note
database before the next TC reaches it. 

We have a paper about this option in an incoming JCN special issue (december
2004).

Philippe    

Quoting manet user <[email-masked]>:

> Thanks Francisco and Hakim for clarifying the doubt. I got confused between
> D_seq_num and ANSN. So basically duplicate set entries are only added/updated
> when a packet/message is considered for forwarding (rexmitted will be true or
> false depending if fwding condition was met or not).
>  
> I observe OLSR to be way too slow for large networks (for approx 400-500
> nodes placed in a grid in a simulation environment). Application traffic is
> not too exhaustive, but just the control overhead consumes all the bandwidth.
> Even without mobility, TC flooding, processing and resulting route table
> recalculations are too frequent and expensive. Isn't this an OLSR scalability
> issue? Any such experience/comments will help me better understand this
> behavior.
>  
> Thanks.
>  
>  
> 

-- 
Philippe Jacquet
Hipercom project team leader
INRIA
tel: +33 1 39 63 52 63
fax: +33 1 39 63 55 66

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Cesar Santivanez <[email-masked]>
Date: Wed, 22 Dec 2004 15:23:18 -0500

Hi Philippe,

You just described HSLS routing, developed by BBN under the DAWN project (part of
DARPA's Glomo program). Indeed, the HSLS technique, since it only requires a modification
on the value of the TTL can be applied simultaneously with the MPR technique. They
are orthogonal and complimentary: HSLS helps you when the network diameter is large, 
and MPRs help you when the network density is high (e.g. your radios cannot do power 
control). We have combined both techniques successfully in several projects in the past.

> In theory by an appropriate scaling of frequency
Well, we wish this could be true. Unfortunately, in order to keep the control traffic bounded
as the number of nodes increases, you would have to decrease the rate of Link State Updates to 
a point when the quality of the routes would be no longer acceptable. What we discovered is that
we need to balance the overhead due to control traffic with the penalty for lower-quality
routes. For uniform traffic conditions, the best scheduled was found. This schedule (HSLS)
maintains a linear relationship between distance and link state information latency.

Thus, when using the optimal schedule, as the number of nodes increases both the control overhead and the penalty due to bad routes increases - at the same rate -- to the point that they
render the network ineffective. However, this breaking point is on the same order of magnitude
as the number of nodes that the network can handle (due to traffic starvation, i.e. the
traffic demands grow faster than available bandwidth with respect to the number of nodes)
anyway. Thus, with HSLS, routing is no longer the limiting factor on network effectiveness.

For further information, you can take a look at:
(1) Cesar Santivanez and Ram Ramanathan, "Hazy Sighted Link State (HSLS) Routing: A Scalable
Link State Algorithm," BBN Technical Memorandum No. 1301, August 31, 2001. 
http://www.ir.bbn.com/documents/techmemos/TM1301.ps
http://www.ir.bbn.com/documents/techmemos/TM1301.pdf

(2) C. Santivanez, B. McDonald, I. Stavrakakis, and R. Ramanathan, "On the Scalability of Ad Hoc Routing Protocols," Proceedings of IEEE INFOCOM'02, New York, June, 2002.
http://www.ir.bbn.com/documents/articles/infocom07.ps
http://www.ir.bbn.com/documents/articles/infocom07.pdf

Regards

Cesar

Philippe Jacquet wrote:
> > > The all-new My Yahoo! - What will yours do?
> >
> >
> >  Meet the all-new My Yahoo! - Try it today!
> 
> --
> Philippe Jacquet

-- 
Cesar Santivanez, Ph.D. <[email-masked]>
Network Scientist
Internetwork Research
BBN Technologies