Post on 01-Apr-2015
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
973-236-6925mjsherman@att.com
Author:
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 2
doc.: IEEE 802.11-02/304r0
Submission
Purpose of Document
• Provide additional simulation data in support of CC/RR protocol
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 3
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
Matthew Sherman, AT&T Labs - ResearchSlide 4
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
Matthew Sherman, AT&T Labs - ResearchSlide 5
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
Matthew Sherman, AT&T Labs - ResearchSlide 6
doc.: IEEE 802.11-02/304r0
Submission
Simulation Scenarios
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 7
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
Matthew Sherman, AT&T Labs - ResearchSlide 8
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
Matthew Sherman, AT&T Labs - ResearchSlide 9
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
Matthew Sherman, AT&T Labs - ResearchSlide 10
doc.: IEEE 802.11-02/304r0
Submission
Data Plots
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 11
doc.: IEEE 802.11-02/304r0
Submission
FTP Traffic served (moving average of 240)
CC/RRCFP voice only
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 12
doc.: IEEE 802.11-02/304r0
Submission
HTTP Traffic served(moving average of 240)
CFP voice only CC/RR
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 13
doc.: IEEE 802.11-02/304r0
Submission
FTP download time(moving average of 10)
CFP voice only CC/RR
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 14
doc.: IEEE 802.11-02/304r0
Submission
HTTP Page Response Time(moving average of 10)
CFP voice only CC/RR
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 15
doc.: IEEE 802.11-02/304r0
Submission
HTTP Object Response Time(moving average of 10)
CFP voice only CC/RR
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 16
doc.: IEEE 802.11-02/304r0
Submission
FTP Traffic served (moving average of 240)
CC/RRCFP voice + data Down
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 17
doc.: IEEE 802.11-02/304r0
Submission
HTTP Traffic served(moving average of 240)
CFP voice + data Down CC/RR
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 18
doc.: IEEE 802.11-02/304r0
Submission
FTP download time(moving average of 10)
CFP voice + data Down CC/RR
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 19
doc.: IEEE 802.11-02/304r0
Submission
HTTP Page Response Time(moving average of 10)
CFP voice + data Down CC/RR
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 20
doc.: IEEE 802.11-02/304r0
Submission
HTTP Object Response Time(moving average of 10)
CFP voice + data Down CC/RR
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 21
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
Matthew Sherman, AT&T Labs - ResearchSlide 22
doc.: IEEE 802.11-02/304r0
Submission
Summary Statistics
May 2002
Matthew Sherman, AT&T Labs - ResearchSlide 23
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
Matthew Sherman, AT&T Labs - ResearchSlide 24
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
Matthew Sherman, AT&T Labs - ResearchSlide 25
doc.: IEEE 802.11-02/304r0
Submission
Avg’s - 2 & 3 Uncontrolled DCF Links VP + Downlink
2 Uncontrolled DCF links
CC/RR
2 Uncontrolled DCF links
VP + Downlink
3 Uncontrolled DCF links
CC/RR
3 Uncontrolled DCF links
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
Matthew Sherman, AT&T Labs - ResearchSlide 26
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
Matthew Sherman, AT&T Labs - ResearchSlide 27
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
Matthew Sherman, AT&T Labs - ResearchSlide 28
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