Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.11-02/304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 1 In Defense of CC/RR Date: May 13, 2002 Matthew Sherman AT&T.

Similar presentations


Presentation on theme: "Doc.: IEEE 802.11-02/304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 1 In Defense of CC/RR Date: May 13, 2002 Matthew Sherman AT&T."— Presentation transcript:

1 doc.: IEEE 802.11-02/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 07932 973-236-6925 mjsherman@att.com Author:

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

3 doc.: IEEE 802.11-02/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

4 doc.: IEEE 802.11-02/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

5 doc.: IEEE 802.11-02/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

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

7 doc.: IEEE 802.11-02/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

8 doc.: IEEE 802.11-02/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

9 doc.: IEEE 802.11-02/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

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

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

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

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

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

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

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

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

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

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

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

21 doc.: IEEE 802.11-02/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

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

23 doc.: IEEE 802.11-02/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) 2918973288848127469662383520 Delay (Sec) 0.0198280.0238010.0120670.074504 Data Dropped (Bits per sec) 964.7390655.08434783.904 Voice - STA 19 MAD (sec) 0.0152240.0151170.0073080.014884 FTP Sent (Bytes per sec) 242121.8242815.3216786.6179474.9 FTP Down Resp Time (Sec) 10.17898.8042327.08215610.95451 FTP Rec (Bytes per sec) 239310.5229461.9220300.7171039.1 FTP Up Resp Time (Sec) 9.7650369.0031776.52860210.76688 HTTP Sent (Bytes per sec) 147.7294170.5828144.0171145.0198 HTTP Rec (Bytes per sec) 147.7294170.0889144.0171145.0198 HTTP Obj Resp (Sec) 0.2371270.1655540.0977870.078601 HTTP Page Resp (sec) 0.7011610.4664970.2868980.214539

24 doc.: IEEE 802.11-02/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) 425718040513303761679 Delay (Sec) 0.1421190.0889730.04744 Data Dropped (Bits per sec) 328442542856654640210 Voice - STA 19 MAD (sec) 0.0157870.0156830.010058 FTP Sent (Bytes per sec) 223797.3242112.5240712.0 FTP Down Resp Time (Sec) 182.183513.815698.842411 FTP Rec (Bytes per sec) 100805.3234381.6239306.4 FTP Up Resp Time (Sec) 51.2442118.044828.053641 HTTP Sent (Bytes per sec) 105.0781105.4932116.5243 HTTP Rec (Bytes per sec) 92.52786105.4932116.5243 HTTP Obj Resp (Sec) 2.6767250.1677590.145318 HTTP Page Resp (sec) 6.326470.4700630.425687

25 doc.: IEEE 802.11-02/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) 3956115357280237194533605050 Delay (Sec) 0.1514390.0807720.3134830.115176 Data Dropped (Bits per sec) 9847859100977591553092015530584 Voice - STA 19 MAD (sec) 0.0157140.0088940.0157010.011171 FTP Sent (Bytes per sec) 221706.3223820.9220278.1230855.2 FTP Down Resp Time (Sec) 17.7703510.6031843.268658.247631 FTP Rec (Bytes per sec) 217489.4222415.3187948.8228044.0 FTP Up Resp Time (Sec) 25.932878.63091162.921567.614614 HTTP Sent (Bytes per sec) 167.9553158.8238158.4977147.5668 HTTP Rec (Bytes per sec) 165.4453158.8238158.4977147.5668 HTTP Obj Resp (Sec) 0.1184990.243770.1545040.14629 HTTP Page Resp (sec) 0.3363840.7135260.5739390.425399

26 doc.: IEEE 802.11-02/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

27 doc.: IEEE 802.11-02/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 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

28 doc.: IEEE 802.11-02/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 802.11e draft


Download ppt "Doc.: IEEE 802.11-02/304r0 Submission May 2002 Matthew Sherman, AT&T Labs - ResearchSlide 1 In Defense of CC/RR Date: May 13, 2002 Matthew Sherman AT&T."

Similar presentations


Ads by Google