Doc.: IEEE 802.11-02/304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 1 In...

May 2002

Matthew Sherman, AT&T Labs - ResearchSlide 1

doc.: IEEE 802.11-02/304r0

Submission

In Defense of CC/RR

Date: May 13, 2002

Matthew ShermanAT&T Labs - Research

180 Park AvenueFlorham Park, NJ 07932

[email protected]

Author:

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Purpose of Document

• Provide additional simulation data in support of CC/RR protocol

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Background• 00/373 from AT&T showed legacy PCF outperforms legacy

DCF• 01/571r0 from AT&T showed CC/RR protocol outperforms

legacy PCF– Legacy PCF polls all CFP stations by AID order each polling cycle– Did not evaluated other polling strategies

• 02/223r1 from Philips argues that other polling strategies provide the same or better performance with less complexity– Philips requested removal of CC/RR protocol

• 02/303 from AT&T updates results in 02/223r1 and questions conclusions

• This contribution provides additional scenarios as evidence in dispute of Philips’ claims

May 2002


doc.: IEEE 802.11-02/304r0

Submission

The Control Problem• Key purpose of CC/RR is to take time critical control

traffic out of DCF– Cannot control sources operating in DCF– Example: Managed WLAN in Airport or conference center

• Some “visitors” set up IBSS on same frequency• Run gaming or video applications for fun• Heavy impact on traffic in DCF• No impact on traffic in PCF

• Solution to place time critical control traffic under protection of PCF– Only time critical request is to be added to polling list– Lead to CC/RR protocol

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Simulation Model / Scenarios • Used the simulation model jointly developed by

AT&T / Philips– Recent corrections / updates by AT&T (4/7/02 code)– See 02/303 for list of changes

• Scenarios same as 03/223r1 but Uncontrolled DCF Sources (UDS) added– Add up to 3 bi-directional video links to flood DCF channel

• Used direct STA to STA option under DCF with no QoS • Used OPNET Video application as UDS

– Very little video data gets through (Links not functional)• Video acts as source of uncontrolled contention on channel

– Not modeling video, just convenient way of generating contention– Models uncontrolled transmissions from inside BSS, outside BSS, or in

overlaid IBSS of any kind - not really video

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Simulation Scenarios

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Video conferencing application attributes

Application Attributes

• Up to 6 DCF video stations added– Non- pollable (DCF)

– Organized in pairs forming bi-directional links

– Direct STA to STA Tx• No relay through AP

• All other stations / parameters as in 02/223r1

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Simulation Scenarios• Only considered

– CC/RR– Voice Only in CFP (No CC/RR)– Voice + Downlink data in CFP (No CC/RR)

• Standing Poll not worth considering • Added UDS links until simulation “broke”• Started with no UDS links (baseline)

– Baseline results from 02/303

• Added up to 3 UDS links (6 stations) till strongly “degraded” performance

– CC/RR never seriously degrades

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Plots Collected• Only FTP and HTTP results shown

– Voice performance comparable to performance in 02/303 since in CFP

– Bulk WLAN statistics of no value• Skewed by Video link performance• Extreme amounts of video (UDS) traffic dropped and large delays on

video (UDS) traffic passed• Bulk WLAN statistics skewed since include video

• “Video” at end of scenario name in legend indicates UDS links are active

• Number in scenario name indicates number of active bidirectional UDS links

– If no number, one link active

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Data Plots

May 2002


doc.: IEEE 802.11-02/304r0

Submission

FTP Traffic served (moving average of 240)

CC/RRCFP voice only

May 2002


doc.: IEEE 802.11-02/304r0

Submission

HTTP Traffic served(moving average of 240)

CFP voice only CC/RR

May 2002


doc.: IEEE 802.11-02/304r0

Submission

FTP download time(moving average of 10)


May 2002


doc.: IEEE 802.11-02/304r0

Submission

HTTP Page Response Time(moving average of 10)


May 2002


doc.: IEEE 802.11-02/304r0

Submission

HTTP Object Response Time(moving average of 10)


May 2002


doc.: IEEE 802.11-02/304r0

Submission

FTP Traffic served (moving average of 240)

CC/RRCFP voice + data Down

May 2002


doc.: IEEE 802.11-02/304r0

Submission

HTTP Traffic served(moving average of 240)

CFP voice + data Down CC/RR

May 2002


doc.: IEEE 802.11-02/304r0

Submission

FTP download time(moving average of 10)


May 2002


doc.: IEEE 802.11-02/304r0

Submission

HTTP Page Response Time(moving average of 10)


May 2002


doc.: IEEE 802.11-02/304r0

Submission

HTTP Object Response Time(moving average of 10)


May 2002


doc.: IEEE 802.11-02/304r0

Submission

Data Analysis - Plots • Key differentiators are upload / download times

– Non CC/RR protocols have degraded performance in presence of Uncontrolled DCF Sources (UDS)

– Since FTP traffic dominates, FTP upload / download times most important

– Voice also important, but UDS has little effect

• As in 02/303 determining relative performance from plots imprecise

• Summary statistics for comparison also helpful– Export OPNET plot data and average in Excel– Exported same data as in 02/303– Highlighted data of greatest interest

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Summary Statistics

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Averages - From 02/303(Baseline)

Voice Polling (VP)

VP + Downlink CC/RR Standing Poll

Throughput (Bits per sec) 2918973 2888481 2746966 2383520

Delay (Sec) 0.019828 0.023801 0.012067 0.074504

Data Dropped (Bits per sec) 964.739 0 655.0843 4783.904

Voice - STA 19 MAD (sec) 0.015224 0.015117 0.007308 0.014884

FTP Sent (Bytes per sec) 242121.8 242815.3 216786.6 179474.9

FTP Down Resp Time (Sec) 10.1789 8.804232 7.082156 10.95451

FTP Rec (Bytes per sec) 239310.5 229461.9 220300.7 171039.1

FTP Up Resp Time (Sec) 9.765036 9.003177 6.528602 10.76688

HTTP Sent (Bytes per sec) 147.7294 170.5828 144.0171 145.0198

HTTP Rec (Bytes per sec) 147.7294 170.0889 144.0171 145.0198

HTTP Obj Resp (Sec) 0.237127 0.165554 0.097787 0.078601

HTTP Page Resp (sec) 0.701161 0.466497 0.286898 0.214539

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Averages - 1 UDS Link

Voice Polling (VP)

VP + Downlink CC/RR

Throughput (Bits per sec) 4257180 4051330 3761679

Delay (Sec) 0.142119 0.088973 0.04744

Data Dropped (Bits per sec) 3284425 4285665 4640210

Voice - STA 19 MAD (sec) 0.015787 0.015683 0.010058

FTP Sent (Bytes per sec) 223797.3 242112.5 240712.0

FTP Down Resp Time (Sec) 182.1835 13.81569 8.842411

FTP Rec (Bytes per sec) 100805.3 234381.6 239306.4

FTP Up Resp Time (Sec) 51.24421 18.04482 8.053641

HTTP Sent (Bytes per sec) 105.0781 105.4932 116.5243

HTTP Rec (Bytes per sec) 92.52786 105.4932 116.5243

HTTP Obj Resp (Sec) 2.676725 0.167759 0.145318

HTTP Page Resp (sec) 6.32647 0.470063 0.425687

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Avg’s - 2 & 3 Uncontrolled DCF Links VP + Downlink

2 Uncontrolled DCF links

CC/RR


VP + Downlink


CC/RR


Throughput (Bits per sec) 3956115 3572802 3719453 3605050

Delay (Sec) 0.151439 0.080772 0.313483 0.115176

Data Dropped (Bits per sec) 9847859 10097759 15530920 15530584

Voice - STA 19 MAD (sec) 0.015714 0.008894 0.015701 0.011171

FTP Sent (Bytes per sec) 221706.3 223820.9 220278.1 230855.2

FTP Down Resp Time (Sec) 17.77035 10.60318 43.26865 8.247631

FTP Rec (Bytes per sec) 217489.4 222415.3 187948.8 228044.0

FTP Up Resp Time (Sec) 25.93287 8.630911 62.92156 7.614614

HTTP Sent (Bytes per sec) 167.9553 158.8238 158.4977 147.5668

HTTP Rec (Bytes per sec) 165.4453 158.8238 158.4977 147.5668

HTTP Obj Resp (Sec) 0.118499 0.24377 0.154504 0.14629

HTTP Page Resp (sec) 0.336384 0.713526 0.573939 0.425399

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Data Analysis - Summary Statistics

• CC/RR maintains Voice Delay advantage in presence of Uncontrolled DCF Sources (UDS)

• CC/RR has >10:1 Data delay advantage on Voice Polling (VP) scenario with one UDS

• CC/RR has ~2:1 Data delay advantage on VP+Downlink scenario with one UDS– Higher advantage for uploads since favors DCF

• Greater delay advantage with more UDS – VP+Downlink starts to break with 3 UDS

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Other Information• AT&T has already implemented CC/RR protocol for

QoS service– Complexity proved to be a non-issue– Implemented in older, existing design without hardware

modification• AT&T has provided demos of Video, Telephony, and

IP applications running over CC/RR– Protocol works well and delivers performance promised

• Checks with simulation

– Many 802.11 participants have seen demo• There is no complexity issue for CC/RR in 802.11e

and CC/RR performance is clearly better than Philips’ suggested alternatives

May 2002


doc.: IEEE 802.11-02/304r0

Submission

Conclusions• Uncontrolled DCF Sources (UDS) significantly

degrade performance of Philips’ proposed CC/RR alternatives

• CC/RR is not significantly degraded by UDS• As in 02/303 CC/RR voice performance also

substantially better (Typically 2:1)• UDS are an important issue for Managed LANs• AT&T implementation of protocol shows that

CC/RR complexity is not an issue• CC/RR is critical for implementing managed

WLANS and should not be eliminated from 802.11e draft

Date post:	01-Apr-2015
Category:	Documents
Upload:	ryann-putney
View:	213 times
Download:	0 times

Doc.: IEEE 802.11-02/304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 1 In...

Documents