Dear all, How OLSR prevents Topology Control messages from packet loss ? Since loss of TC message could lead to inconsistent problems in routing table. Cheers, Nguyen Lan. -- -- Olsr-users mailing list Olsr-users <at> lists.olsr.org http://lists.olsr.org/mailman/listinfo/olsr-users
I don't know how many of you have seen this paper from a group at UCSD (University of California at San Diego) which presents a new method of discerning which route updates to forward to a given node. http://ccr.sigcomm.org/online/files/p15-levchenko.pdf Some of the content of the paper is stating the obvious, but other parts of it are rather formal logic which I don't have the necessary skills to interpret. I am giving it a close read to see what I can learn from it. I am interested to read the opinions and reviews of some of the rest of you. Does anything presented in this paper provide anything of value for future versions of OLSR? Regards, Bob Keyes -- -- Olsr-users mailing list Olsr-users <at> lists.olsr.org http://lists.olsr.org/mailman/listinfo/olsr-users
On Mon, Sep 1, 2008 at 08:00, Nguyen Lan <nguyentienlan <at> gmail.com> wrote: > Dear all, > > How OLSR prevents Topology Control messages from packet loss ? Since > loss of TC message could lead to inconsistent problems in routing table. Retransmissions and redundant paths. TCs are flooded through the network, so if you have multiple connections to the net you have more than one chance to hear a TC. In addition to this TCs are restransmitted periodicly. Henning -- "Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt Marti) -- -- Olsr-users mailing list Olsr-users <at> lists.olsr.org http://lists.olsr.org/mailman/listinfo/olsr-users
On Mon, Sep 1, 2008 at 08:46, Bob Keyes <bob <at> xa.net> wrote: > I don't know how many of you have seen this paper from a group at UCSD > (University of California at San Diego) which presents a new method of > discerning which route updates to forward to a given node. > > http://ccr.sigcomm.org/online/files/p15-levchenko.pdf > > Some of the content of the paper is stating the obvious, but other parts > of it are rather formal logic which I don't have the necessary skills to > interpret. I am giving it a close read to see what I can learn from it. > > I am interested to read the opinions and reviews of some of the rest of > you. Does anything presented in this paper provide anything of value for > future versions of OLSR? I'm not sure if this can be translated to OLSR over WLAN (IEEE 802.11), because WLAN is a broadcast medium. At several points the paper seems to suggest that nodes have independant connections to their neighbors, which would only be true if we only use unicast in OLSR. I'm not sure if this would consume more (multiple packets, retransmissions) or less (unicast is faster than broadcast) airtime. Henning -- "Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt Marti) -- -- Olsr-users mailing list(Continue reading)
Henning Rogge wrote: > On Mon, Sep 1, 2008 at 08:00, Nguyen Lan <nguyentienlan <at> gmail.com> wrote: > >> Dear all, >> >> How OLSR prevents Topology Control messages from packet loss ? Since >> loss of TC message could lead to inconsistent problems in routing table. >> > Retransmissions and redundant paths. TCs are flooded through the > network, so if you have multiple connections to the net you have more > than one chance to hear a TC. But TCs are only forwarded by MPR nodes, so I guess it's not always true. > In addition to this TCs are > restransmitted periodicly. > Yes, I mean routing table is inconsistent at some moments Nguyen. > Henning > -- -- Olsr-users mailing list Olsr-users <at> lists.olsr.org http://lists.olsr.org/mailman/listinfo/olsr-users
On Mon, Sep 1, 2008 at 11:37, Nguyen Lan <nguyentienlan <at> gmail.com> wrote: >> Retransmissions and redundant paths. TCs are flooded through the >> network, so if you have multiple connections to the net you have more >> than one chance to hear a TC. > > But TCs are only forwarded by MPR nodes, so I guess it's not always true. Depends on the configuration of olsrd... but if MPRs are activated you might be right. Of course every MPR transmission is a broadcast, so you still have multiple chances to receive a package in a dense network >> In addition to this TCs are >> restransmitted periodicly. >> > > Yes, I mean routing table is inconsistent at some moments Difficult to say. Most times they will be slightly wrong. But the routing tables are only used to determine the next hop, so errors far away from the target should not be critical (that's the idea behind fisheye routing). Henning -- "Wo kämen wir hin, wenn alle sagten, wo kämem wir hin, und niemand ginge, um einmal zu schauen, wohin man käme, wenn man ginge." (Kurt Marti) -- --(Continue reading)
On Mon, 2008-09-01 at 18:37 +0900, Nguyen Lan wrote: > Henning Rogge wrote: > > On Mon, Sep 1, 2008 at 08:00, Nguyen Lan <nguyentienlan <at> gmail.com> wrote: [...] > >> How OLSR prevents Topology Control messages from packet loss ? Since It doesn't. > >> loss of TC message could lead to inconsistent problems in routing table. > >> > > Retransmissions and redundant paths. TCs are flooded through the > > network, so if you have multiple connections to the net you have more > > than one chance to hear a TC. > But TCs are only forwarded by MPR nodes, so I guess it's not always true. The redundant network paths step in on the next transmission (try). There is always a compromise between reliability and used bandwidth. > > In addition to this TCs are > > restransmitted periodicly. > > > Yes, I mean routing table is inconsistent at some moments Routing tables of two hosts may be inconsistent at any time. But that is not a unique "feature" of OLSR but IMHO of (almost?) all IP-routing protocols (including the "old ones" from the cable world like RIP and OSPF). In the wireless world, it is just more visible because the latency and packet loss are (much) larger than on Gbit cables.(Continue reading)
Hi, On Mittwoch 27 August 2008, you wrote: > >> My claim that there exist topologies in which average-case convergence > >> of BATMAN is exponential in the number of hops has been confirmed by > >> two of the BATMAN developers. I still believe this to be a very > >> significant flaw of BATMAN. > > > > Packet loss increases also the count of OGMs that trigger a route switch > > decreases. > > I realise that. The trouble is that the time needed to reconverge is > proportional to the product of the link qualities, and not to the sum > of the link qualities, as is the case in Babel and in OLSR. > > > Now let's come to the worst case. Again two paths that are > > non-overlapping. One is terrible, 99% loss. The other is perfect, no > > loss. > > As I mentioned in my point 3, the packet loss, as measured by BATMAN, > is not realistic in the presence of link-layer AQM. As you know, > IEEE 802.11 does perform link-layer AQM for unicast packets. AQM == Active Queueing Management ? Sorry, I did not know this. I know that 802.11 retransmits (usually up to 7 times) in case of absent ACKs and most implementation performs some non-standardized Ack-based rate control. All mesh protocols I am aware of use broadcast-based link probing for estimating the link quality. I agree that this is not very precise and also does not indicate much about the achievable bandwidth. But the alternatives are also difficult. Performing unicast measurements introduces lots of(Continue reading)
-- -- Olsr-users mailing list Olsr-users <at> lists.olsr.org http://lists.olsr.org/mailman/listinfo/olsr-users
The default interval for pings for the dyn_gw plugin is 5 seconds set by
static variable.
My first try to use this (and my first try w/ OLSR in fact!) setting
interval to 30 seconds yielded continuous pings.
I tracked it down to the fact that the plugin_parameter array in
olsrd_dyn_gw.c was using it's own set_plugin_double handler when the
check_interval parameter is actually an int. When the int passed in is
converted w/ set_plugin_double (at least on my setup that is compiled
against uclibc 0.9.29) to set the check_interval integer parameter, the
conversion must be coming out as 0 or negative.
The following patch fixes this. Even if this isn't a problem on a glibc
setup, the integer plugin parameter handler should be used for dyn gw's
"interval" as it's more correct since it's the number of whole seconds
between pings, not a floating point number (the nanosleep used to
implement it wants a struct timespec and the number of seconds is
integer and nanoseconds is set to 0L in the code).
Also -- if the set_plugin_double helper function which I believe is code
that is local to the dyn gw plugin becomes dead code w/ the patch below,
it can be removed.
With the patch applied I can leave the default and get 5 seconds ping
interval or set it to 10 seconds and see a 10 second interval instead of
continuous pings.
The ping approach is a technique I've implemented with scripts in the
past for injecting or removing default routes from OSPF setups using
zebra/quagga. The only thing I did different that might by nice in the
dyn gw plugin would be to round-robin through the list of "peers" that
get pinged so the first guy on the list doesn't take all the ICMP
traffic most of the time -- round robin for both cases of internet link
considered down and internet link considered up.
diff -urNp olsrd-0.5.6-orig/lib/dyn_gw/src/olsrd_dyn_gw.c
olsrd-0.5.6-dyn-gw-patch/lib/dyn_gw/src/olsrd_dyn_gw.c
--- olsrd-0.5.6-orig/lib/dyn_gw/src/olsrd_dyn_gw.c 2008-09-01
20:11:10.000000000 -0400
+++ olsrd-0.5.6-dyn-gw-patch/lib/dyn_gw/src/olsrd_dyn_gw.c 2008-09-01
20:11:55.000000000 -0400
<at> <at> -206,7 +206,7 <at> <at> static int set_plugin_hna(const char *va
}
static const struct olsrd_plugin_parameters plugin_parameters[] = {
- { .name = "interval", .set_plugin_parameter = &set_plugin_double,
.data = &check_interval },
+ { .name = "interval", .set_plugin_parameter = &set_plugin_int,
.data = &check_interval },
{ .name = "ping", .set_plugin_parameter = &set_plugin_ping,
.data = NULL },
{ .name = "hna", .set_plugin_parameter = &set_plugin_hna,
.data = NULL },
};
diff -urNp olsrd-0.5.6-orig/lib/dyn_gw/src/olsrd_dyn_gw.h
olsrd-0.5.6-dyn-gw-patch/lib/dyn_gw/src/olsrd_dyn_gw.h
--- olsrd-0.5.6-orig/lib/dyn_gw/src/olsrd_dyn_gw.h 2008-09-01
20:11:16.000000000 -0400
+++ olsrd-0.5.6-dyn-gw-patch/lib/dyn_gw/src/olsrd_dyn_gw.h 2008-09-01
20:12:07.000000000 -0400
<at> <at> -43,6 +43,7 <at> <at>
#define _OLSRD_PLUGIN_TEST
#include "olsrd_plugin.h"
+#include "plugin_util.h"
#define INET_NET 0
#define INET_PREFIX 0
--
--
Olsr-users mailing list
Olsr-users <at> lists.olsr.org
http://lists.olsr.org/mailman/listinfo/olsr-users
RSS Feed42 | |
|---|---|
32 | |
19 | |
52 | |
12 | |
62 | |
37 | |
23 | |
45 | |
31 | |
25 | |
17 | |
17 | |
7 | |
35 | |
67 | |
23 | |
16 | |
56 | |
10 | |
63 | |
9 | |
45 | |
101 | |
75 | |
98 | |
21 | |
93 | |
44 | |
67 | |
61 | |
87 | |
22 | |
49 | |
51 | |
43 | |
17 | |
40 | |
25 | |
107 | |
63 | |
58 | |
39 | |
63 | |
38 | |
18 | |
35 | |
43 | |
86 | |
27 | |
56 | |
141 | |
56 | |
51 | |
57 | |
126 | |
126 | |
53 | |
82 | |
88 | |
7 | |
45 | |
47 | |
24 | |
26 | |
82 | |
27 | |
17 | |
21 | |
23 | |
15 | |
39 | |
47 | |
21 | |
67 | |
65 | |
21 | |
15 | |
23 | |
23 | |
15 | |
62 | |
75 | |
41 | |
57 | |
78 | |
85 | |
28 | |
28 | |
48 | |
28 | |
3 | |
76 | |
80 | |
104 | |
67 | |
188 | |
54 | |
132 | |
93 | |
81 | |
58 | |
72 | |
25 |
