Subject: [manet] Last IETF questions (Loop Detection)

From: "Yasunori Owada" <[email-masked]>
Date: Thu, 28 Feb 2008 17:19:40 +0900

Hello all,

I presented about loop detection at last IETF meeting.
I had some questions and comments and I could not answer every questions
 at that time. So I listed these questions with answers as follows.

The draft can be found at:
http://www.ietf.org/internet-drafts/draft-mase-manet-loopdetect-00.txt

Our simulation parameters (IETF70 presentation) are:
Simulation Suite: QualNet 4.0
Routing Protocol: nOLSRv2 (Routing Parameters are Default value)
Nodes: 50 (placement random, randomway-point movement)
Simulation area: 1500m x 1500m
Applications: 5 CBR UDP (size is 512 Bytes, transmission interval is
4packets/sec)
CBR transmission start-end 60s – 660s ( < 10s random spread)
Transport protocol: UDP , Network protocol: IPv4, MAC protocol: IEEE802.11

Q1. Routing loops are "fact of life"?
A1. Yes, routing loops exist. Our research tries to minimize the
impact of these loops on surrounding traffic by suppressing the
effects of the looping packets (LS), or to correct the loop as quickly
as possible once detected (LC).

Q2. OLSRv2 should not get looping in a static topology?
A2. OLSRv2 gets loops in static mesh networks just like mobile
networks. The consequence of these loops are even more severe in mesh
networks than in networks with mobility, because the loops persist for
the full lifetime thus having a detrimental effect for a longer amount
of time, and are not broken by mobility. Furthermore, radio
environment can be dynamics without mobility (e.g. due to fading,
etc). Thus, OLSRv2 can get loops even if nodes are static.

Q3. Looping may cause congestion?
A3. Looping may act to cause congestion and early saturation of the
network as the load is increased. A packet may usually take about 3
hops to the destination in our simulation.  If the packet enters a
loop, that same packet will be retransmitted up to a maximum of 64
times limited by the TTL in the IP header, although usually less.
That is an effective 20 times increase in broadcast and radio
resources from this particular packet over the average in traveling
from the source to destination.  If 5% (1/20) of the packets end up in
loops, then there is an overall doubling of usage of the radio
resources from the unicast traffic, therefore in this scenario it is
expected that the network would become congested at half the load or
less if non-linear effects take hold.

Q4. You shouldn't treat routing control as best effort and should give
higher precedence to control messages.
A4. In our simulation, routing control messages are given priority.
(Control messages uses dedicated FIFO queue and, it means that
priority are given to control messages.)

Q5. How much jitter to add to data traffic?
A5. 250ms jitter is used on Hello Message and TC Message. Application
data isn't jittered.

Q6. Loops are initialization effects if start-up timer interval is
relatively long?
A6. Loops are not suffered initialization effects if start-up timer
intervals are relatively long. We have 2 min start-up time before
applications begin in our simulation. Hello Interval is 2s, TC
Interval is 5s. A startup time of 1min and longer than 2min was also
tested with no observable change. Changing the Hello periodic interval
and the TC periodic interval can vary the significance of the loops.
there is no relation between our simulation result and initialization
effects.

We thought that number of CBR streams (5 streams) is nowhere near
enough to see how network could be congested. we ran a set of new
simulations (2Mbps 802.11b in area of 1km x 2km) and are varying the
number of applications: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
15, nodes 60, mobility 5. In case that application is 15 and loop
detection isn't used, packet loss rate is high and throughput is low
value. But congestion still does not occur at 15 applications... We
are simulating with more applications and the results will be
announced later.

Q7. How LLN is implemented?
A7. LLN mechanisms are implemented within Niigata University's
implementation of OLSRv2 (nOLSRv2) and, it runs on Network Simulator
"QualNet 4.0". The implementation is based on olsrv2-02, nhdp-01 and
packetbb-02 drafts. Routing Parameters are default value. Note that
our LLN supports IPv4, but IPv6 isn't supported. Please see
http://www.net.ie.niigata-u.ac.jp/~yowada/v2/.
Our LLN procedure is following.
When ACK frame of data frame aren't received by transmitting node,
link breakage is notified from link layer and following procedure is
performed.
1. Next hop IP address of IP packet in queue is resolved from
destination IP address in IP header using node's forwarding table.
2. If Link Tuple existed with:
L_neighbor_iface_addr == next hop IP address
then, L_LOST_LINK_time = current time + NEIGHB_HOLD_TIME (= 6[s])
3. Any Two Hop Neighbor Tuples with
N2_local_iface_addr == local address of interface
N2_neighbor_iface_addr == next hop IP address
are removed from Two Hop Neighbor set.
4. MPRs and Routing Set are recalculated. Calculation methods are
described at Appendix of olsrv2-02 draft.

The latest internet draft (olsrv2-04) has no L_LOST_LINK_TIME entry in Link Set.
So we have to consider how link layer notification should be
implemented in our nOLSRv2 in future.

Questions and comments are welcome.
Thanks,

-- 
Assistant Professor of Natural Hazard and Disaster Recovery, Niigata
University, Japan.
Yasunori Owada <[email-masked]>
TEL: +81-25-262-7429
_______________________________________________
manet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/manet