DOC PREVIEW
UCLA COMSCI 218 - TCP-fairness-using-NRED

This preview shows page 1-2-3-4-5 out of 14 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 14 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Slide 1MotivationTCP Unfairness in Ad Hoc NetworksSignificant TCP UnfairnessWhy RED Does Not Work?Neighborhood and Its Distributed QueueSimplified Neighborhood Queue ModelNeighborhood Random Early Detection (NRED)Neighborhood Congestion DetectionNeighborhood Congestion Notification & Distributed Neighborhood Packet DropParameter Tuning: ScenariosPerformance Evaluation: Simple ScenarioPerformance Evaluation: Multiple Congested NeighborhoodConclusionsEnhancing TCP Fairness in Ad Hoc Wireless Networks Using Neighborhood REDKaixin Xu, Mario GerlaUniversity of California, Los Angeles{xkx, gerla}@cs.ucla.eduLantao Qi, Yantai ShuTianjin University, Tianjin, China{ltqi, ytshu}@tju.edu.cn*This work was supported in part by Office of Naval Research (ONR) "MINUTEMAN“ project under contract N00014-01-C-0016 and TRW under a Graduate Student Fellowship*This research was supported in part by the National Natural Science Foundation of China (NSFC) under grant No. 90104015.2MotivationTCP is important in ad hoc network applicationsReliable transfer of data/image files and multimedia streamingCongestion protectionEfficient utilization and fair share of the resourcesHowever, TCP has shown unfair behavior in ad hoc nets3TCP Unfairness in Ad Hoc NetworksFairness index in wireless networksWeighted MaxMin Fairness IndexWeight(i) = # of flows that compete with flow i (including itself) Simulation in QualNet simulator3 TCP flows contending with each otherWeight of 3 flows, 2:3:2F T P 1F T P 2F T P 3( 1 0 0 , 1 0 0 )( 6 0 0 , 1 0 0 )( 3 5 0 , 3 5 0 )( 3 5 0 , 7 0 0 )( 0 , 7 0 0 )( 3 5 0 , 1 0 5 0 )( 1 0 0 , 1 3 0 0 )( 6 0 0 , 1 3 0 0 )( 7 0 0 , 7 0 0 )        2121,niiiniiitXtWntXtwtXF4Significant TCP Unfairness Three flow exampleFlow 2 is nearly starvedOriginal RED fails to improve the fairnessWeighted Fairness Index = 0.675Why RED Does Not Work?Why RED does not work in ad hoc networks?Congestion simultaneously affects multiple queuesQueue at a single node cannot completely reflect the stateExtend RED to the entire congested area – Neighborhood of the nodeRandom Early Detection (RED)Active queue management scheme qwavgwavgqq 1Average queue size: Drop probability: , proportional to buffer occupancythththpavgbpminmax)min(max6Neighborhood and Its Distributed QueueA node’s neighborhood consists of the node itself and the nodes which can interfere with this node’s signal1-hop neighbors directly interfere2-hop neighbors may interfereQueue size of the neighborhood reflects the degree of local network congestionA153426791 01 21 187Simplified Neighborhood Queue Model2-hop neighborhood queue model is not easy to operateToo much overhead to propagate queue values 2 hops awaySimplified modelOnly include 1-hop neighborsTwo queues at each neighbor:Outgoing queue“Incoming queue”= # CTS packets overheard by ADistributed neighborhood queue – the aggregate of these local queuesA153426O u t g o i n g Q u e u eI n c o m i n g Q u e u e9Neighborhood Random Early Detection (NRED)Extending RED to the distributed neighborhood queueKey ProblemsCounting the size of the distributed neighborhood queueCalculating proper packet drop probability at each nodeComponents of Neighborhood REDNeighborhood Congestion Detection (NCD)Neighborhood Congestion Notification (NCN)Distributed Neighborhood Packet Drop (DNPD)10Direct way: Announce queue size upon changesToo much overhead, exacerbates congestionOur method: Indirectly estimate an index of instant queue size by monitoring wireless channelNeighborhood Congestion DetectionAverage queue size is calculated using RED’s alg.Congestion: queue size exceeds the minimal thresholdervalsamplingtimebusychannelUbusyintChannel utilization ratioQueue size index , K is a constant busyUKq *A153426O u t g o i n g Q u e u eI n c o m i n g Q u e u eChannel busyCTS11Neighborhood Congestion Notification & Distributed Neighborhood Packet DropNeighborhood Congestion NotificationCongested node computes drop probability following RED’s alg.It broadcasts the drop probability to all neighborsDistributed Neighborhood Packet DropNeighborhood Drop Prob = Max of all drop probabilities heard from neighbors13Parameter Tuning: ScenariosQualNet simulatorBasic but typical scenariosHidden terminal situationsExposed terminal situationsConfiguration parametersMinimum threshold & Maximum thresholdSet to 100 and 240 based on previous experimentVary the maximum packet drop probability (maxp)F T P 21 2 3 4F T P 1( 1 0 0 , 0 )( 1 0 0 , 3 5 0 )( 1 0 0 , 7 0 0 ) ( 1 0 0 , 1 0 5 0 )F T P 21 2 3 4F T P 1( 1 0 0 , 0 )( 1 0 0 , 3 5 0 )( 1 0 0 , 7 0 0 ) ( 1 0 0 , 1 0 5 0 )Hidden TerminalExposed Terminal16Performance Evaluation: Simple ScenarioBoth long-term and short-term fairness is achievedLoss of aggregated throughputTradeoff between fairness and throughputChannel is not fully utilizedOverall ThroughputInstantaneous ThroughputF T P 1F T P 2F T P 3( 1 0 0 , 1 0 0 )( 6 0 0 , 1 0 0 )( 3 5 0 , 3 5 0 )( 3 5 0 , 7 0 0 )( 0 , 7 0 0 )( 3 5 0 , 1 0 5 0 )( 1 0 0 , 1 3 0 0 )( 6 0 0 , 1 3 0 0 )( 7 0 0 , 7 0 0 )17Performance Evaluation: Multiple Congested NeighborhoodMultiple congested neighborhoodsFTP2 & FTP 5 have more competing flows, are more likely to be starvedOverall ThroughputF T P 1 F T P 2 F T P 3F T P 4F T P 5F T P 620ConclusionsSignificant TCP unfairness has been found and reported in ad hoc networksNRED is a network layer solutionEasy to implementIncremental deploymentMajor ContributionsModel of neighborhood queueDistributed neighborhood queueNot FIFO, different and dynamic prioritiesNetwork layer solution for enhancing TCP fairness in ad hoc


View Full Document

UCLA COMSCI 218 - TCP-fairness-using-NRED

Documents in this Course
GSM

GSM

59 pages

Chord

Chord

30 pages

10_2

10_2

9 pages

13_4

13_4

10 pages

RAP

RAP

17 pages

46_4

46_4

9 pages

32_4

32_4

10 pages

umts

umts

39 pages

AdHoc-MAC

AdHoc-MAC

29 pages

rma

rma

8 pages

Lecture

Lecture

29 pages

Load more
Download TCP-fairness-using-NRED
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view TCP-fairness-using-NRED and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view TCP-fairness-using-NRED 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?