doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 1 In Defense of CC/RR Date: May 13, 2002 Matthew Sherman AT&T Labs - Research 180 Park Avenue Florham Park, NJ Author:

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 2 Purpose of Document Provide additional simulation data in support of CC/RR protocol

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 3 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

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 4 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

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 5 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

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 6 Simulation Scenarios

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 7 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

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 8 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

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 9 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

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 10 Data Plots

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 11 FTP Traffic served (moving average of 240) CC/RRCFP voice only

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 12 HTTP Traffic served (moving average of 240) CFP voice onlyCC/RR

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 13 FTP download time (moving average of 10) CFP voice onlyCC/RR

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 14 HTTP Page Response Time (moving average of 10) CFP voice onlyCC/RR

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 15 HTTP Object Response Time (moving average of 10) CFP voice onlyCC/RR

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 16 FTP Traffic served (moving average of 240) CC/RRCFP voice + data Down

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 17 HTTP Traffic served (moving average of 240) CFP voice + data DownCC/RR

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 18 FTP download time (moving average of 10) CFP voice + data DownCC/RR

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 19 HTTP Page Response Time (moving average of 10) CFP voice + data DownCC/RR

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 20 HTTP Object Response Time (moving average of 10) CFP voice + data DownCC/RR

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 21 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

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 22 Summary Statistics

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 23 Averages - From 02/303 (Baseline) Voice Polling (VP) VP + DownlinkCC/RRStanding Poll Throughput (Bits per sec) Delay (Sec) Data Dropped (Bits per sec) Voice - STA 19 MAD (sec) FTP Sent (Bytes per sec) FTP Down Resp Time (Sec) FTP Rec (Bytes per sec) FTP Up Resp Time (Sec) HTTP Sent (Bytes per sec) HTTP Rec (Bytes per sec) HTTP Obj Resp (Sec) HTTP Page Resp (sec)

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 24 Averages - 1 UDS Link Voice Polling (VP) VP + DownlinkCC/RR Throughput (Bits per sec) Delay (Sec) Data Dropped (Bits per sec) Voice - STA 19 MAD (sec) FTP Sent (Bytes per sec) FTP Down Resp Time (Sec) FTP Rec (Bytes per sec) FTP Up Resp Time (Sec) HTTP Sent (Bytes per sec) HTTP Rec (Bytes per sec) HTTP Obj Resp (Sec) HTTP Page Resp (sec)

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 25 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) Delay (Sec) Data Dropped (Bits per sec) Voice - STA 19 MAD (sec) FTP Sent (Bytes per sec) FTP Down Resp Time (Sec) FTP Rec (Bytes per sec) FTP Up Resp Time (Sec) HTTP Sent (Bytes per sec) HTTP Rec (Bytes per sec) HTTP Obj Resp (Sec) HTTP Page Resp (sec)

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 26 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

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 27 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 participants have seen demo There is no complexity issue for CC/RR in e and CC/RR performance is clearly better than Philips’ suggested alternatives

doc.: IEEE /304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 28 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 e draft