Subject: [manet] DSR and DSDV simulation problem analysis results ...

From: Shahriar Shamil Uulu <[email-masked]>
Date: Thu, 3 Mar 2005 22:10:36 -0800 (PST)

Dear All,
Just yesterday i have posted my question that DSR's
performance degrading drastically after 100 seconds. 
So i have analysed the reason why DSR drops the
packets and came to know that (-Nw from trace): 
All results based on "ns-2.1b8a-allinone" and 50 nodes
with 10 sources.
---------------------------------------------------------
For DSR the trace levels(-Nl) are mostly "IFQ": 
1.80% droped due to "IFQ" mean no buffer space in IFQ
2.15% droped due to "ARP" droped by ARP
3.and around 5% by "SAL" i think it couldnot salvage
the packet.
So how i can prevent DSR from dropping so much packets
due to the IFQ reason ? i know we can extend buffer
which i set to max 50 at ifq BUT is there any other
solutions.  
---------------------------------------------------------
For DSDV the trace levels(-Nl) are mostly "RTR"and
"IFQ":
1. 45% droped due to "CBK",
2. 40% droped due to "IFQ",
3. 15% "ARP"+others   
Any help will be greatly apperciated.
Thank in advance ... 

Shahriar Shamil Uulu 
Hyderabad Central University 
M.Tech(Computer Science)
email:[email-masked]
website: http://shamilson.narod.ru

		
__________________________________ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

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

---

From: Bryan Hogan <[email-masked]>
Date: Thu, 10 Mar 2005 13:32:07 +0000 (GMT)

Hello,

I have been following this thread and would like to add to the list of
solutions provided by David Maltz with the following

I have conducted research on congestion in DSR with the aim of
implementing a congestion control algorithm.
>From this research I found that a substantial amount of congestion
occurred as a result of the reuse and propagation of known routes, and
that this was more prevalent at low mobility rates that at high mobility
rates.

I was able to mitigate the effects of this in the following manner -
At the onset of congestion a node alerts its adjacent nodes of this by
broadcasting a prioritised congestion notification packet. These adjacent
nodes subsequently reduce the volume of data they are forwarding through
the congested node and also seek alternate routes (from its own cache)
to the destination.

Using this method I achieved improvements in packet delivery rates which
varied(between approx 3% and 8%) depending on the number of nodes, data
rates and mobility rates.

I would appreciate any comments on this solution.

Bryan Hogan

>
>--On Thursday, March 03, 2005 10:10 PM -0800 Shahriar Shamil
>Uulu <[email-masked]> wrote:
>
>Integrating information from a side conversation that Uulu and I
>have been having, I'm assuming cbr traffic sources, 512B
>packets.
>
>I think there is no simple answer --- this is a real research
>problem.
>
>[I have attached a figure produced by Uulu showing PDR as a
>function of time during his simulation.]
>
>
>>For DSR the trace levels(-Nl) [shows that dropped packets] are mostly
>"IFQ":
>> For DSDV the trace levels(-Nl) [shows that dropped packets]
>are mostly
>"RTR" and "IFQ":
>The reason DSR's PDR starts out high and then drops over the
>first 100 s is probably that the connections are starting up
>over the first 100 s, so the load
>on the network is constantly increasing over that time.
>
>Unlike TCP, CBR sources are non-conforming --- they keep pumping
>out data regardless of how congested the network is, and your
>network is pretty congested.
>With 10 sources * 4 pkts/s *  512B/pkt = 163 Kbps, that's a high
>average offered load on the network considering that: (1) max
>data rate in your simulator is
>probably 2 Mbps; (2) 802.11 reacts to collisions by backing off,
>converting what would have been a MAC layer packet loss into
>increased latency.
>Unfortunately, backing off decreases the effective throughput of
>each node, which increases the backlog of packets at each node
>and eventually converts into
>IFQ layer packet drops; (3) in a multi-hop network, each of
>those CBR packets needs to be sent multiple times, so the
>effective load is roughly (mean path
>length + 1) * offered load.
>
>If you measured Fraction Free Air Time for each of the nodes, I
>predict that you'd see that many nodes see no more capacity in
>the medium.
>
>The congestion is presumably so severe that DSDV can't even
>track routes to all destinations. That's why DSDV nodes are
>dropping packets in the RTR level (no
>route).  The surprising result is that more of the originated
>packets actually make it to their destination.  DSDV is, in
>effect, shedding enough of the
>offered load to bring the network slightly out of congestion
>collapse.
>
>Potential solutions?
>
>1) Evaluating results from experiments run on congested networks
>is very tricky as congestion effects dominate protocol
>performance.  If the IFQ drop rate is
>large, or the PDR low (less than 90 percent or so), or the FFAT
>low, then your experiment is in a congested state.  Either
>reduce the offered load, use
>conforming sources (e.g., TCP), or resign yourself to tackling
>the challenge of making a congested network run better.
>
>2) Make a congested network run better:
>- tune parameters: use shorter IFQs
>- use path/flow state, reservations, admission control, etc
>- change the MAC protocol to back off less and give up on
>packets faster in a congested situation (e.g., when FFAT goes to
>zero over some time interval, just
>drop the packet at the head of the queue)
>- implement back pressure or flow control at either the MAC or
>the RTR layer (e.g., once a data packet leaves its originating
>node, it gets preferential
>access to the media at all future forwarding nodes)
>- use power control to increase the total aggregate carrying
>capacity of the network
>- MobiCom proceedings over the past several years contain many
>additional ideas
>
>Cheers,
>-dam

---

From: Raja Sombhotla <[email-masked]>
Date: Mon, 14 Mar 2005 21:38:24 -0800 (PST)

Dear all,
 
I would like to pre-compute the shortest paths from sources to destinations in a network with randomly generated nodes using the signal-to-noise ratios and somehow feed these routes to the nodes to use to send the packets and study the performance of the network. Can anyone please tell me how I can make the nodes use these pre-computed routes for transmissions of packets in a static wireless ad hoc network? Any idea will be grately appreciated.
 
Regards,
Raj.

Bryan Hogan <[email-masked]> wrote:
Hello,

Bryan Hogan

>Uulu wrote:

---------------------------------
Do you Yahoo!?
 Yahoo! Small Business - Try our new resources site!

---

From: yingpei zeng <[email-masked]>
Date: Wed, 16 Mar 2005 01:05:13 +0800 (CST)

Hi sombhotla,
   Can't you put your pre-computed routes in you DSR route table? But maybe you should modify the DSR implement. I think pre-computing the routes maybe difficult than modification of the DSR implement.

Raja Sombhotla <[email-masked]> wrote:
Dear all,

Regards,
Raj.

Bryan Hogan

>on the network is constantly incre! asing over that time.
>
>If you measured Fraction Free Air Time ! for each of the nodes, I
>conforming sources (e.g., TCP), or res! ign yourself to tackling

---------------------------------
Do you Yahoo!?
Yahoo! Small Business - Try our new resources site! _______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
美女明星应有尽有，搜遍美图、艳图和酷图
1G就是1000兆，雅虎电邮自助扩容！

---

From: Bryan Hogan <[email-masked]>
Date: Wed, 16 Mar 2005 12:13:49 +0000 (GMT)

Should have included link to publication on this solution...

Congestion Avoidance in Source Routed Ad Hoc Networks - 13th IST Mobile
and Wireless Communications Summit, Lyon, 2004

http://www.geocities.com/b_j_hogan/files/congestion_avoidance.pdf

Bryan J. Hogan