Subject: Re: [manet] Error simulating with AODV, DSR and TORA

From: Casey Carter <[email-masked]>
Date: Mon, 03 Feb 2003 09:53:38 -0600

Analysis of the trace file (with mac trace on) reveals that this problem 
is due to a bug in the 802.11 mac implementation.  802.11 tries to send 
an RTS several times (7 times in ns2) before reporting failure. In the 
ns2 mac, the retry counter is reset when the mac successsfully sends or 
_receives_ a packet.  As long as node 1 in your scenario keeps receiving 
packets from node 0, before it can reach seven retries, it will not 
report failure.  My trace file shows that node 1 retries this particular 
RTS about 650 times between 25 and 33.13 seconds.

The particular culprit is in void MAC802_11::recvDATA(Packet*); the 
conditional branch that cleans up CTS packets after successful reception 
resets ssrc_, the RTS retry counter.  Anybody know why? Commenting out 
the line that reads

  ssrc_ = 0;

forces the proper behavior.

[email-masked] wrote:

>Hi,
>
>I have sent a possible bug report to the NS mailing list, but since no one was
>able to give me a reply, perhaps someone in this mailing list is interested.
>
>Results of dozens of simulations using AODV, DSR and TORA in ns2.1b9a (2.1b8
>too) show that these protocols do not behave correctly when there are 802.11
>broken links.
>
>When looking at the overall results of simulations with many nodes, the effect I
>describe is not evident. It is necessary to look at a single flow to see that  
>nodes fail to quickly detect broken links, making the re-routing process last
>too long. This effect does not exist when using other protocols like OLSR or
>Hello-driven AODV since they do not use link-layer info.
>
>The files I attach show this problem clearly in a very simple scenario
>
>Please help!
>
>Best regards, 
>
>_________________________________________________
>Carlos Miguel Tavares de Araújo Cesariny Calafate
>Polytechnic University of Valencia
>e-mail: [email-masked]
>http://reptar.grc.upv.es/~calafate/
>Tel: +34 963879703 ext. 77977
>_________________________________________________
>  
>

-- 
Casey Carter
[email-masked]
[email-masked]
AIM: cartec69

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

---

From: [email-masked]
Date: Mon, 03 Feb 2003 18:16:57 +0100 (CET)

Hi Casey,

I am happy someone really looked into the BUG I described. 
I wanted to congratulate you for your efforts since I have tested your solution
and it seems to actually solve the problem for all three protocols (DSR, AODV
and TORA). Even though it might look a small bug, it is not! This bug makes the
results achieved with these Link Level Aware protocols innacurate, since a
carefull examination of what's going on in each flow shows that what's happening
is not what is expected to happend.

If you have more information on how to correct this bug, please e-mail me.

Best regards,

Carlos Calafate
UPV 
Spain

_________________________________________________
Carlos Miguel Tavares de Araújo Cesariny Calafate
Becário de la Universidad Politécnica de Valencia
e-mail: [email-masked]
http://reptar.grc.upv.es/~calafate/
Tel: +34 963879703 ext. 77977
_________________________________________________
\\\\\\\"In an open world without walls and fences who needs Windows and
Gates?\\\\\\\"
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Alvin Valera <[email-masked]>
Date: Mon, 3 Feb 2003 18:12:48 -0800 (PST)

Hi Casey & Carlos Miguel,

I tried Carlos Miguel's test scenarios but didn't
encounter the problem of long link layer detection
delay. When I received this e-mail, it became apparent
that in my version of ns-2 (ns-2.1b8 June 6, 2001
release), the line 

    ssrc_ = 0;

is _NOT_ commented! That's why I couldn't duplicate
Carlos Miguel's results!

I find this odd. Who commented out that line in the
succeeding versions and for what reason? 

Best regards,
Alvin 

> >The files I attach show this problem clearly in a

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Ali Hamidian <[email-masked]>
Date: Tue, 04 Feb 2003 11:57:27 +0100

Hi,

Just wanted to conform what Alvin says: in my version of ns-2 
(ns-2.1b9a) the line

    ssrc_ = 0;

is NOT commented - i.e. the same as Alvin says. And that's why I told 
Carlos that the AODV code in ns-2.1b9a should be able to detect link 
breaks pretty fast.

Regards
Ali

Alvin Valera wrote:

>>>I have sent a possible bug report to the NS mailing
>>>
>>list, but since no one was
>>
>>>able to give me a reply, perhaps someone in this
>>>
>>mailing list is interested.
>>
>>>Results of dozens of simulations using AODV, DSR
>>>
>>and TORA in ns2.1b9a (2.1b8
>>
>>>too) show that these protocols do not behave
>>>
>>correctly when there are 802.11
>>
>>>broken links.
>>>
>>>When looking at the overall results of simulations
>>>
>>with many nodes, the effect I
>>
>>>describe is not evident. It is necessary to look at
>>>
>>a single flow to see that  
>>
>>>nodes fail to quickly detect broken links, making
>>>
>>the re-routing process last
>>
>>>too long. This effect does not exist when using
>>>
>>other protocols like OLSR or
>>
>>>Hello-driven AODV since they do not use link-layer
>>>
>>info.
>>
>>>The files I attach show this problem clearly in a
>>>
>>very simple scenario
>>
>>>Please help!
>>>
>>>Best regards, 
>>>

---

From: Casey Carter <[email-masked]>
Date: Tue, 04 Feb 2003 08:56:10 -0600

To clarify: I know that the line is not commented -- that is the 
problem.  To correct the problem, the line must be removed.  Consider a 
hypothetical example:

     A <====> B                  C

A and B are within range, C is far away.

B sends RTS to C, sets ssrc_ to 0.  C doesn't receive.
Loop:
B retries RTS to C, sets ssrc_ to 1.  C doesn't receive.
B retries RTS to C, sets ssrc_ to 2.  C doesn't receive.
A sends RTS to B, sets ssrc_ to 0.
B receives RTS,  sends CTS to A.
A receives CTS, sets ssrc_ to 0, sends DATA.
// Gerrit says this is a bug also: but it's not the one I refer to.

B receives DATA, sends ACK to A, sets ssrc_ to 0.
// THIS is the bug: B's ssrc_ is for the B-C exchange, it is unrelated 
to the A-B exchange.
goto Loop

In this way, B can continue retransmitting RTS for the exact same packet 
indefinitely.  That's the bug I'm talking about.

-- 
Casey Carter
[email-masked]
[email-masked]
AIM: cartec69

---

From: Alvin Valera <[email-masked]>
Date: Tue, 4 Feb 2003 18:16:00 -0800 (PST)

Hi Carlos Miguel,

The problem that you encountered seems to come from
the 11Mb/s bandwidth that you used. One other reason
why I couldn't duplicate your results was that I fixed
my bandwidth to 2Mb/s somewhere in my scripts. I tried
your scenarios but my simulations still used the
2Mb/s.

The problem, as Casey have shown in the previous
mails, is that a DATA reception clears the ssrc_. With
11Mb/s, it is possible to have an asynchronous DATA
transmissions in between RTS. With 2Mb/s, this is not
possible (at least it did not occur in any of my
simulations). One way to solve your problem, without
UNcommenting the line "ssrc_ = 0" is to adjust the
inter-frame spacing values.

Regards,
Alvin

> ATTACHMENT part 2 application/x-tcl
name=testlimit.tcl; name=testlimit.tcl

> ATTACHMENT part 3 application/octet-stream
name=scen-limit2; name=scen-limit2

---

From: [email-masked]
Date: Thu, 06 Feb 2003 11:04:16 +0100 (CET)

Hi,

I think there is some confusion concerning the error I referred to.
It is in NS2.1b9a, and commenting the line
 
>     ssrc_ = 0;

Appears to solve it.

Best regards,

\\\\\\\"In an open world without walls and fences who needs Windows and Gates?
\\\\\\\"