<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Henning Rogge wrote:
<blockquote cite="mid:200903242259.14310.hrogge@googlemail.com"
type="cite">
<pre wrap="">On Dienstag 24 März 2009 16:21:02 Andres Medina wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> More on the 2nd bug:
While we are not convinced which flooding techniques is better, after
considerable debate, we are fairly convinced that the RFC says that the TC
message should not be forwarded if it has ever been received over a
symmetric link.
</pre>
</blockquote>
<pre wrap=""><!---->I dont think so.
</pre>
</blockquote>
The RFC 3626 states something like this:<br>
<br>
(3.4 Processing a packet and Message Flooding):<br>
1. If there are no messages in the packet, discard<br>
2. If ttl<=0, discard<br>
3. Processing condition:<br>
...<br>
4. Forwarding Condition:<br>
(IMPORTANT STEP FOR THE ARGUMENT)
If there exist a duplicate entry D_addr=origaddr and D_seq_num=seqno.
DO NOT FORWARD.<br>
if not go to 3.4.1 <br>
<br>
(3.4.1 Default Forwarding Algorithm):<br>
1. If sender is not symetric, discard<br>
2. if there is a tuple in the dupplicate set that has D_addr=origaddr
and D_seq_num=seqno then the packet is further considered for
forwarding if D_retransmitted=false.<br>
3. Otherwise, if such an entry doesn't exist, the message is further
considered for forwarding.<br>
4. If sender is an MPR selector and ttl>1, then FORWARD<br>
5. (IMPORTANT STEP FOR THE ARGUMENT. Note that this step is executed
even if previous step 4 concluded that node is not an MPR). Create a
duplicate entry.<br>
If and only if the message will be forwarded do:<br>
6. The TTL of the message is reduced by one.<br>
7. The hop-count of the message is increased by one<br>
<br>
So, the first time the packet is received even if is not from an MPR
selector, step 5 of 3.4.1 will create the duplicate entry that will
stop from initiating the forwarding algorithm in step 4 of 3.4 the next
time this packet is received. <br>
<br>
This is all for the RFC 3626 of OLSR. In the draft of OLSR v2, the same
algorithm is described, although in my opinion much more clear to read.
<br>
<blockquote cite="mid:200903242259.14310.hrogge@googlemail.com"
type="cite">
<pre wrap=""> </pre>
<blockquote type="cite">
<pre wrap="">We ran some simulations and found that the RFC method greatly reduces the
number of nodes that forward a TC message (see attached plot). However, we
are unsure whether the RFC method would significantly reduce the
reliability of TC message flooding. Clearly, significantly unreliable TC
message flooding would be bigger problem than too much overhead. We are
studying this issue and should have a more definitive answer in the next
month or so. Perhaps this second bug should not be addressed until our
analysis is complete.
</pre>
</blockquote>
<pre wrap=""><!---->What configuration parameters did you use for your tests ?
Henning
</pre>
</blockquote>
The plot is showing a 500mx500m network with nodes ranging from 77 to
about 5000 nodes and nodes transmitting about 22 meters. However the
results are similar for smaller networks, e.g., 45 to 400 nodes in a
132m x132m space. <br>
<pre class="moz-signature" cols="72">--
Andres Medina
Department of Electrical and Computer Engineering
University Of Delaware
<a class="moz-txt-link-abbreviated" href="mailto:medina@ece.udel.edu">medina@ece.udel.edu</a></pre>
</body>
</html>