doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide Link Layer Performance Test Date: Authors:

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 2 NOTE PLEASE GO THRU THIS PRESENTATION IN MICROSOFT POWERPOINT “SLIDESHOW MODE” –FOR THE ANIMATION TO SHOW PROPERLY

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 3 Abstract This is a proposal to enable an on demand, throughput test on a link, with no dependence on higher layer protocols.

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 4 Problem Statement Imagine a large university or enterprise User trying to download or upload a file or transfer data. –Throughput is low –Complains to IT –Usually immediate assumption…Wireless is the problem –Reality – a lot of other factors affect performance and it is important to be able to prove eliminate or identify Wireless is or is not the problem as soon as possible. Network managers routinely get questions like this on the throughput performance of the wireless links

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 5 Typical Enterprise or Campus Network WLAN Management Server Wireless LAN Controller Building 1Building 2 Building 3 Redundant Wireless LAN Controller Redundant WLAN Management Server

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 6 WLAN Management Server Wireless LAN Controller Typical Enterprise or Campus Network IT Manager located in a central location needs to figure out where the problem is Building 1 Building 2Building 3 User complains file downloads/ uploads are slow…. Probable causes… Wireless could in fact be the problem OR User laptop has an issue Wired network in his building has an issue. Core network has an issue File server has an issue Application being used by the user has a problem..etc etc.. Most likely blame… Wireless doesn’t work Redundant Wireless LAN Controller Redundant WLAN Management Server

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 7 Problem Statement (contd) No current standards based mechanism –To measure the current achievable throughput across an link without including Layer 3 or other higher layers on the end devices. –To simply run a L2 only test to quickly eliminate/establish wireless as the problem –In most cases IT administrators don’t have access to the laptop (to run, iperf or FTP tests) and so requires significant time to get access to the end devices setup in exactly the same setup and retest. It costs time and money!

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 8 Current Approaches to this problem RF Ping/RF Link Test –Send either ping packets or some L2 frames and measure the RSSI on the response. –This doesn’t truly indicate the current achievable throughput. Check the noise floor and other RF characteristics –Mostly everything looks good. Run proprietary software on both the client and server to test performance Get a wireless trace and/or a wired trace –This is where the problem is –This is time and money –IT has to ‘teach’ users to do this or IT has to do this –This usually doesn’t yield everything that is needed to debug the problem Or dismiss the problem as subjective user perception

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 9 Case Study 1 – Service Provider/Consumer Scenario WAN/Internet HOME Home Router Service Provider Network Center Server/Home PC Step 1: User calls Service Provider downloads / uploads from home PC or other nodes in the home are SLOW Step 2: Without access to user laptop, Service provide today has no easy way to turn a throughput test remotely to find out if the problem is wireless interference or some other configuration on the user side. All current methods needs a proprietary software installed on the client side.

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 10 Case Study 1 Service providers that sell Wi-Fi to end customers –They need an install time throughput test to measure the achievable throughput from the Wireless CPE is good. –Rolling a truck at a later stage to find out there is a 2.4Ghz phone on the same channel or something else on the same channel is expensive –At install time, run the test, prove wireless works great! Done! –Later if the user ever calls the service provider saying wireless throughput isnt good Remotely run a link layer throughput test and assess quickly if Wireless is the problem or the problem is elsewhere. Today no such tool is available without access to the end user’s laptop.

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 11 Case Study 2 IEEE Interim session Jacksonville, May 2008 –After initial wireless deployment Ran some tests on the wireless deployment Run throughput test on 1 AP –Total Aggregate thrpt: 25Mbps Run throughput test on two APs on different channels –Total Aggregate thrpt: 25Mbps Run throughput test on N APs on different channels –Total Aggregate thrpt: 25Mbps Question why is the throughput from one AP and N APs the same –After a bunch of investigation, it was found out that there was a wired firewall whose limit was 25Mbps –The problem had nothing to do with Wireless

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 12 Case Study 3 Mesh link Installation –Two APs X miles apart with highly directional antennae. –RSSI between two APs excellent –Throughput test is failing! –After weeks of debugging… With wireless traces Wired traces Backend debugging…. – Acknowledgement timeout was found to be too short, in comparison to the propagation delay! A simple link layer throughput test at installation would have helped tremendously. Relying on RSSI was misleading

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 13 Proposed Solution We are proposing an L2 throughput test that could be run between any two STA’s that can be run without the need for higher layer protocols. This enables on-demand L2 throughput test, for network administrators and installers to test network quality and throughput with a simple only setup This enables radio compatibility tests. This takes all L3 and other layer factors out of the equation

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 14 Proposal An ability for an STA to start an L2 throughput test with another STA with some or all of the following parameters configurable via the MLME layer –Number of Packets –Length of the packets –Time of test –Directionality (upstream/downstream/bi-directional) –Prioritization –Security –Aggregation –Channel width –Data rate –Power Save –Vendor Extensions –Any other avalibale and supported options

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 15 Proposal A method to signal establishment and tear down of a throughput test among two STA’s A method to run the throughput test between two STA’s

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 16 Simplistic Math STA1 sends X number of packets to STA2 with length Y bytes. STA2 returns a result of test to STA1 saying, Z packets received each with Y bytes in T seconds Current Throughput = Z * Y * 8 / T (bps) Packets Lost = X – Z STA1 and STA2 can be AP, Mesh AP, STA or any other STA.

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 17 Example transaction Access Point Step 2: Station Acknowledges and get’s ready for thrpt test Step 3.1: AP sends a start of test pkt to STA (this help the station recognize the test started) Step 6: AP sends throughput report to STA Step 5: STA sends Y packets to AP (with all appropriate signaling like in the previous case) with start and stop frames Step 7: AP sends both the throughput reports via MLME to IT manager Step 0: User requests an on demand throughput test between AP and client device Step 1: AP signals to station that it needs to run a throughput test to the STA Step 4: STA sends throughput report to AP Step 3.2: AP sends the rest of the test packets to STA Step 3.2: AP sends a end of test pkt to the STA, indicating the test is over, send me the report.

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 18 Forms of Usage Run the L2 link throughput test, with no changes to the current operational parameters of the STA –Example if it is currently using the a config don’t change it Ie, STA currently is associated with clear encryption, with 40Mhz channels and no aggregation enabled, then run the test with those parameter. This helps in problem diagnosis. Because you don’t want to change the operational state of the sytem under analysis. Run L2 link throughput test with changes to current operation parameters of the STA [within the capabilities of the station] –Even if the client is currently using only 20Mhz channels, run the test as 40Mhz channel width (if the client is capable of it), just to make sure both the primary and secondary channels are working fine –This is useful in case of an installer. –Client connects in whatever config, but the installer wants to prove that his install meets the SLA he gauranteed. So needs to run a max performance throughput test, not just in the current operational condition.

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 19 How does this proposal solve Service Provider Problem

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 20 Case Study 1 – Service Provider/Consumer Scenario -- SOLUTION WAN/Internet HOME Home Router Service Provider Network Center Server/Home PC Step 1: User calls Service Provider downloads / uploads from home PC or other nodes in the home are SLOW Step 2: Without access to user laptop, Service provide today has no easy way to turn a throughput test remotely to find out if the problem is wireless interference or some other configuration on the user side. All current methods needs a proprietary software installed on the client side. Step 3: Tech Support from Service Provider issues a command for the Router to run a throughput test between Router and the associated station Wireless Throughput test

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 21 Case Study 1 – Service Provider/Consumer Scenario -- SOLUTION Now Tech support has the following option based on the result of the test –Result is positive – Wireless throughput is good Focus the debugging on wired side or laptop or application or server or any number of other things. –Result is negative – Wireless throughput is infact bad Focus the debugging further on the Wireless

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 22 Questions and Answers Are we duplicating the L3 functionality in L2 –Absolutely not. –This is not about running a TCP style test. –No state is requested to be kept. –This mechanism will be a really simplistic measure of packets transmitted and packets received and the time in which they were received. And all associated statistics with the test. Will this test be accurate enough –Given that L2 times are far more accurate than L3 and higher layer timing, that wouldn’t be an issue What about interference and how it affects the test –That is the point of this test. –If there is interference we want to find out –Packet loss is key. Regular CRC checks shall apply.

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 23 Questions and Answers Does this method tell us what is the problem? –No. However it helps draw a very hard line whether Wireless is the issue or if the issue is somewhere else. –Eg: Let us say a user runs a L2 throughput test on an n AP and the result is 150Mbps. Immediately we know there isn’t an interference issue. The channel selection is not a issue. Raw channel bandwidth is not an issue. Channel contention is not an issue. There is no white noise preventing access to the medium. –On the flip side if the throughput is 2Mbps on an n AP that means, it does present a real possiblity that Wireless is infact the problem. Eg: Channel selection is bad. There is microwave or other co-channel interference..etc. –This method gives a quick and dirty opinion of where to start.

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 24 Questions and Answers What happens to the normal traffic while test is being run? –Remember the test is being run, because there is an active issue with the network. –However during the actual run of the test, all other packets from the two STA’s under test shall not interleave in the test packets. They shall be held in queues or tail dropped or purged, based on implementation. This is beyond the scope of the standard to define. –However it shall be recognized this test is a service interrupting event from a user perspective. –Other packets could interfere and eat channel time….Well exactly… and that could be what we are trying to find out.

doc.: IEEE /0844r1 Submission July/2008 Sudheer Matta, Trapeze NetworksSlide 25 Straw Poll I would like to see normative text created from /r1? –Yes 14 –No 2 –Abstain 9