330 likes | 341 Views
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.
E N D
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
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
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
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
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
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
Updated data for 02/223r1 Matthew Sherman, AT&T Labs - Research
Throughput (moving average of 240) Before After Matthew Sherman, AT&T Labs - Research
Load (moving average of 240) Before After Matthew Sherman, AT&T Labs - Research
Data Dropped AP Before After Matthew Sherman, AT&T Labs - Research
Delay (global) Before After Matthew Sherman, AT&T Labs - Research
Delay (II) (without Standing Poll) Before After Matthew Sherman, AT&T Labs - Research
Control Traffic Received at AP Before After Matthew Sherman, AT&T Labs - Research
Control Traffic sent by AP Before After Matthew Sherman, AT&T Labs - Research
Media Access Delay at Voice STA 1 Before After Matthew Sherman, AT&T Labs - Research
Media Access Delay at Voice STA #19 Before After Matthew Sherman, AT&T Labs - Research
Voice Throughput per STA Before After Matthew Sherman, AT&T Labs - Research
FTP Traffic served (moving average of 240) Before After Matthew Sherman, AT&T Labs - Research
HTTP Traffic served(moving average of 240) Before After Matthew Sherman, AT&T Labs - Research
FTP download time(moving average of 10) Before After Matthew Sherman, AT&T Labs - Research
HTTP Page Response Time(moving average of 10) Before After Matthew Sherman, AT&T Labs - Research
HTTP Object Response Time(moving average of 10) Before After Matthew Sherman, AT&T Labs - Research
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
Averages - Original Data in 02/223r1 Matthew Sherman, AT&T Labs - Research
Averages - Updated Data Matthew Sherman, AT&T Labs - Research
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
Side by Side Comparison of Data Matthew Sherman, AT&T Labs - Research
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
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
Long Updated Simulations Matthew Sherman, AT&T Labs - Research
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
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
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