Subject: Re: Re: [manet] 802.11 throughput analysis

From: "Peter Pham" <[email-masked]>
Date: Fri, 10 Oct 2003 13:17:04 +0950

Hi all 
Thanks for the feedbacks. 
Actually the referenced paper is very interesting. 

Can I have another question  regarding the implementation of 802.11 in ns2. 

>From what I notice, after failing to transmit RTS over a ShortRetryLimit, the MAC will drop the packet. This conforms with the 802.11 standard. However, from the trace file, I noticed that the routing layer actually "flush" the  buffer after the failure signal from the MAC. That is, deleting all the packets in the buffer. 

In heavy traffic, it actually deletes the whole 35 more more packets in the queue and start the route discovery again while it should only delete one packet. Is this the correct behaviour ? 

I may be wrong or missed out something here.
Please correct me..

This is what I get from the tracefile 

D 23.189438858 _0_ MAC  RET 0 RTS 44 [14be 1 0 0] 
D 23.189438858 _0_ RTR  CBK 435 cbr 532 [13a 1 0 800] ------- [0:0 1:0 30 1] [435] 0 0
D 23.189438858 _0_ RTR  CBK 436 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [436] 0 0
D 23.189438858 _0_ RTR  CBK 437 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [437] 0 0
D 23.189438858 _0_ RTR  CBK 438 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [438] 0 0
D 23.189438858 _0_ RTR  CBK 439 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [439] 0 0
D 23.189438858 _0_ MAC  RET 435 cbr 532 [13a 1 0 800] ------- [0:0 1:0 30 1] [435] 0 0
s 23.189438858 _0_ RTR  --- 0 AODV 32 [0 0 0 0] ------- [0:255 -1:255 1 0] [0x8 1 [1 0] 0.000000] (ERROR)
s 23.193528858 _0_ MAC  --- 0 AODV 84 [0 ffffffff 0 800] ------- [0:255 -1:255 1 0] [0x8 1 [1 0] 0.000000] (ERROR)
D 23.194201379 _1_ MAC  LPR 0 AODV 84 [0 ffffffff 0 800] ------- [0:255 -1:255 1 0] [0x8 1 [1 0] 0.000000] (ERROR)
 
And this is every worse 

D 43.579471779 _0_ MAC  RET 0 RTS 44 [14be 1 0 0] 
D 43.579471779 _0_ RTR  CBK 833 cbr 532 [13a 1 0 800] ------- [0:0 1:0 30 1] [833] 0 0
D 43.579471779 _0_ RTR  CBK 834 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [834] 0 0
D 43.579471779 _0_ RTR  CBK 835 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [835] 0 0
D 43.579471779 _0_ RTR  CBK 836 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [836] 0 0
D 43.579471779 _0_ RTR  CBK 837 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [837] 0 0
D 43.579471779 _0_ RTR  CBK 838 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [838] 0 0
D 43.579471779 _0_ RTR  CBK 839 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [839] 0 0
D 43.579471779 _0_ RTR  CBK 840 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [840] 0 0
D 43.579471779 _0_ RTR  CBK 841 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [841] 0 0
D 43.579471779 _0_ RTR  CBK 842 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [842] 0 0
D 43.579471779 _0_ RTR  CBK 843 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [843] 0 0
D 43.579471779 _0_ RTR  CBK 844 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [844] 0 0
D 43.579471779 _0_ RTR  CBK 845 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [845] 0 0
D 43.579471779 _0_ RTR  CBK 846 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [846] 0 0
D 43.579471779 _0_ RTR  CBK 847 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [847] 0 0
D 43.579471779 _0_ RTR  CBK 848 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [848] 0 0
D 43.579471779 _0_ RTR  CBK 849 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [849] 0 0
D 43.579471779 _0_ RTR  CBK 850 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [850] 0 0
D 43.579471779 _0_ RTR  CBK 851 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [851] 0 0
D 43.579471779 _0_ RTR  CBK 852 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [852] 0 0
D 43.579471779 _0_ RTR  CBK 853 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [853] 0 0
D 43.579471779 _0_ RTR  CBK 854 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [854] 0 0
D 43.579471779 _0_ RTR  CBK 855 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [855] 0 0
D 43.579471779 _0_ RTR  CBK 856 cbr 532 [0 1 0 800] ------- [0:0 1:0 30 1] [856] 0 0
D 43.579471779 _0_ MAC  RET 833 cbr 532 [13a 1 0 800] ------- [0:0 1:0 30 1] [833] 0 0
s 43.579471779 _0_ RTR  --- 0 AODV 32 [0 0 0 0] ------- [0:255 -1:255 1 0] [0x8 1 [1 0] 0.000000] (ERROR)
s 43.581908277 _0_ AGT  --- 857 cbr 512 [0 0 0 0] ------- [0:0 1:0 32 0] [857] 0 0
r 43.581908277 _0_ RTR  --- 857 cbr 512 [0 0 0 0] ------- [0:0 1:0 32 0] [857] 0 0

-----Original Message-----
From: [email-masked]
To: "Zhenqiang(Frank) Ye" <[email-masked]>
Date: Fri, 10 Oct 2003 00:07:50 +0200
Subject: Re: [manet] 802.11 throughput analysis

Quoting "Zhenqiang(Frank) Ye" <[email-masked]>:

> Hi, Peter,
>   One way to do this is changing the number of nodes (participating in
> the contention) from n to n':
>    n' = n * \lambda * T
>  where T is the transmission time of data packet (including RTS, CTS,
> DATA and ACK plus some IFSs).

I think it is not that easy, consider this:
- a network with just one node, with \lambda=1, has a total throughput = 1
- a network with two nodes, each with \lambda=0.5, has a collision
probability>0, therefore a total throughput <1

(it applies for other values of n of course)

there was a paper/poster in WiOpt last year, dealing with finite load in
analytical model for IEEE802.11 MAC, check it out:

http://www-sop.inria.fr/mistral/personnel/K.Avrachenkov/WiOpt/PDFfiles/Alizadeh50.pdf

hope this helps

imad

Peter Phuc Pham

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

---

From: "Zhenqiang(Frank) Ye" <[email-masked]>
Date: Thu, 9 Oct 2003 21:22:39 -0700 (PDT)

In AODV, it is done like what you said. If the packets in the
queue belong to the current node, this node will send a RREQ without
dropping these packets. For intermediate nodes, they may repair the route
locally without dropping packets, if the local repair fails, RRER message
will be generated and all the packets going across the broken link will
be dropped.

Frank

-- 

****************************************
Zhenqiang(Frank) Ye
Ph.D Student
Department of Electrical Engineering
University of California, Riverside
Phone: (909)-787-2434
email: [email-masked]
****************************************