1 / 33

Commentary on 02/223r1 in support of CC/RR

This document provides updates and commentary from AT&T Labs on the simulations and conclusions presented in document 02/223r1. It includes updated data and analysis comparing the performance of legacy PCF, legacy DCF, and CC/RR protocol.

davisg
Télécharger la présentation

Commentary on 02/223r1 in support of CC/RR

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Commentary on 02/223r1in support of CC/RR Matthew Sherman AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932 973-236-6925 mjsherman@att.com Author: Date: May 13, 2002 Matthew Sherman, AT&T Labs - Research

  2. Purpose of Document • Provide updates to data in 02/223r1 presented by Philips in March 2002 • Provide commentary from AT&T on simulations and conclusions in 02/223r1 Matthew Sherman, AT&T Labs - Research

  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 • AT&T attempted to run additional scenarios and found that most attempts failed due to bugs in code used for 02/223r1 • Caused AT&T to question validity of data in 02/223r1 Matthew Sherman, AT&T Labs - Research

  4. Background (2) • AT&T has updated MAC model used by Philips in 02/223r1 • Fixed several errors in code • Code now runs without any known errors in wide variety of scenarios • AT&T date stamp 4/7/02 • AT&T has rerun scenarios in 02/223r1 • Updated results in this document • AT&T has considered and now disagrees with Philips’ conclusions in 02/223r1 • See comments in this document • See also 02/304 for additional scenarios Matthew Sherman, AT&T Labs - Research

  5. Simulation Model / Scenarios • Same scenarios as in 02/223r1 • Updated MAC model • Corrections to MAC code for 02/223r1 • Were need to run scenarios in 02/304 • Impact on results hard to ascertain • Random load varies with scenario configuration and MAC code • Slight change to CCI size calculation • May or may not have been improvement! • Lengthened scenarios to improve accuracy of data Matthew Sherman, AT&T Labs - Research

  6. Key Model Corrections • Added last_tx_pcf flag • Needed reference to decide if last packet retry was DCF or PCF • Added cfp_end_time • Fixed CFP overrun problem • Fixed typo in beacon processing • Fixed Beacon overrun problem • Removed timeout and unexpected_reception flags • Flag were unnecessary • Caused various problems • Removed extra PIFS wait in frame_timeout state • Unnecessary Delay • Changed bad_packet flag check sequence • Caused code to get trapped in state Matthew Sherman, AT&T Labs - Research

  7. Updated data for 02/223r1 Matthew Sherman, AT&T Labs - Research

  8. Throughput (moving average of 240) Before After Matthew Sherman, AT&T Labs - Research

  9. Load (moving average of 240) Before After Matthew Sherman, AT&T Labs - Research

  10. Data Dropped AP Before After Matthew Sherman, AT&T Labs - Research

  11. Delay (global) Before After Matthew Sherman, AT&T Labs - Research

  12. Delay (II) (without Standing Poll) Before After Matthew Sherman, AT&T Labs - Research

  13. Control Traffic Received at AP Before After Matthew Sherman, AT&T Labs - Research

  14. Control Traffic sent by AP Before After Matthew Sherman, AT&T Labs - Research

  15. Media Access Delay at Voice STA 1 Before After Matthew Sherman, AT&T Labs - Research

  16. Media Access Delay at Voice STA #19 Before After Matthew Sherman, AT&T Labs - Research

  17. Voice Throughput per STA Before After Matthew Sherman, AT&T Labs - Research

  18. FTP Traffic served (moving average of 240) Before After Matthew Sherman, AT&T Labs - Research

  19. HTTP Traffic served(moving average of 240) Before After Matthew Sherman, AT&T Labs - Research

  20. FTP download time(moving average of 10) Before After Matthew Sherman, AT&T Labs - Research

  21. HTTP Page Response Time(moving average of 10) Before After Matthew Sherman, AT&T Labs - Research

  22. HTTP Object Response Time(moving average of 10) Before After Matthew Sherman, AT&T Labs - Research

  23. Data Analysis - Plots • Extra CC/RR control traffic should not be viewed as strongly impacting data throughput • Only send CC/RR when no other known traffic • Difficult to determine relative performance from plots • Need summary statistics for comparison • Export OPNET plot data and average in Excel Matthew Sherman, AT&T Labs - Research

  24. Averages - Original Data in 02/223r1 Matthew Sherman, AT&T Labs - Research

  25. Averages - Updated Data Matthew Sherman, AT&T Labs - Research

  26. Data Analysis - Summary Statistics • Standing poll clearly under-performs in every category • Lowest throughput, highest delay, most dropped data • Others more difficult to rank • Side-by-side comparison helpful Matthew Sherman, AT&T Labs - Research

  27. Side by Side Comparison of Data Matthew Sherman, AT&T Labs - Research

  28. Data Analysis - Side-by-side • CC/RR clear winner in delay category • Wins voice by factor of 2 to 1 • Going from 7.5 to 15 msec delay may or may not be a design issue • Other two choices have slight throughput advantage • Load is random between simulations and mostly independent of MAC • Throughput difference probably due to load difference, not MAC advantage Matthew Sherman, AT&T Labs - Research

  29. Data Analysis - Side-by-side (cont.) • Original CC/RR simulations (00/571) critically load MAC • Expect occasional data drops in CC/RR • All drops are buffer overflows • VP+ Downlink drops less data with higher throughput • Load distribution random • Can’t say if load distribution or MAC advantage for reduced drop rate • Longer simulation may allow greater certainty about performance • Current simulation time 10 minutes • Increase time to 1 hour for more stable data set • About 24 hour run time per scenario on current computers Matthew Sherman, AT&T Labs - Research

  30. Long Updated Simulations Matthew Sherman, AT&T Labs - Research

  31. Data Analysis - Long Simulations • Substantial Voice delay advantage still holds for CC/RR • Delay & throughput for FTP / HTTP roughly equivalent for 3 contenders • Drop performance nearly the same for 3 contenders • VP + Downlink still drops zero • May want scenario with greater load and larger buffers to differentiate performance • Did not have time for simulations Matthew Sherman, AT&T Labs - Research

  32. Summary • Substantial Voice delay advantage for CC/RR • Other scenarios required to determine drop / load advantages • Control aspects of CC/RR not addressed • Key goal of CC/RR to make delay on control traffic independent of DCF load • Not possible to control DCF loading • IBSS may operate under managed WLAN • Say independent gamers or shared video in Airport • PCF loading well controlled • RRs protected under PCF • Need scenarios with uncontrolled loading in DCF to evaluate performance of alternatives • See separate contribution 02/304 Matthew Sherman, AT&T Labs - Research

  33. AT&T Conclusions • Philips / AT&T scenarios show performance advantage for CC/RR • Key difference voice performance • All other performance about the same • Data does not support removal of CC/RR protocol as suggested by Philips • Voice performance difference may be end-to- end implementation issue • Uncontrolled load issue not addressed • See separate contribution 02/304 Matthew Sherman, AT&T Labs - Research

More Related