White PapersA White Paper from Itheon Networks discussing why applications can behave very differently in the WAN/Wireless networks and why it is important to be able to carry out safe but realistic software performance testing in the WAN environment.
ItheonWhitePa erhe Im ortance of estin Software n ealistic etwork onditionsWhiteer from Itheon etworksdiscussing why er differentl in the WAN Wirelessnetworks and why it is important to e ableto carry out safe but realistic softwareerformance testin in the WANenvironmentUntitled Document hite P erxecutive Summar Increasingly, applications are x ected to work over Wide Area NetworksWANswireless LANs GPRS 3G or satellite networks. But softwareLocal Area Networks (LAN) of the test lab. Satisfactory applicatierformance in these conditions is no uarantee of acce table erformancein non-LAN networks. This white paper s aimed at individuals with a limited knowled e ofnetworking and aims to provide a basic introduction to the im act ofdeploying software over a WAN. It is not intended to be a com letediscussion of non-LAN application issues. It will explain some of the easons wh a lications can behave verifferentl in the WAN Wireless networks and wh testin in live networkenvironments, even in so-called off-peak times , is not really an option. Itgoes on to ex lore the methods that are available to software testers to carrout safe but realistic performance testing in the WAN environment. Itheon Networks Wentworth Lodge Great North Road Welwyn Garden City Herts. AL8 7SR tel: +44 (0)1707 336600 fax: +44 (0)1707 336622 info@itheon-networks.com www.itheon-networks.com Itheon Ltd believes that the information in this publication is accurate as of its publicationdate. Such information is subject to change without notice. Itheon Ltd is not responsible for any inadvertent errors. All names and trademarksare property of their respective companies. I h n N w rk Itheon Networks offers both portable and rack-echnoloto helor anisations address a lication res onse time issues andoptimise network utilization. theon technolocan helou reduce testin costs andtime to implementation by enabling you to safenetwork conditions as they will be expected to run in the production environment. Untitled Document ntroductionhese da s we are creatin a lications where the servers n which thereside are situated in one place and the clients e uirin access to theseapplications are remote from them. Some of the reasons for this are: " The process of server- onsolidation . Increasin lcom anies areoncentratin all their servers into a smaller number of IT centres asthe cost of managing servers in a disbursed environment has rovedtoo expensive " rovision of a lications to remote users officesreviousl onlavailable at head office " Homeworking " More and more self- ervice a lications: insurance uotes taxforms& " Making applications vailable to mobile users via GPRS or 3Gnetworks serving the Road Warrior s a result more and more a lications are bein delivered over Wide Areaetworks WANs wireless LANs GPRS or 3G networks. We ll refer to themall as WANs for simplicity from here on. nfortunatel when it comes to software erformance testin is fre uentlonducted over the sim le Local Area Networks LAN of the test lab. TheseLANs are normally very fast and reliable. The problem is that the applications will ultim tel need to run over the WANand there is a big difference between these two network environments. Welcome to the Topsy-Turvy World Of Networking If the conventional road network (local roads / motorway) behaved in the same way as a data network then all local roads would be 3-lanes wide and all inter-city routes would be single carriage ways (except if you had paid a small fortune to have it widened as some larger companies are be prepared to do). So, if you were traveling within your town (equivalent to a LAN), you could get to your destination extremely quickly on the 3-lane roads available to you. Even if there were other cars on the road, it is very unlikely that there will be any congestion due to the network capacity and the number of routes available. owever thin s wouldn t be sreat when ou wished to travel from one citto another (equivalent to a WAN). Now you would find yourself having to share a single lane with all the other cars on a relatively long road. The result would be much longer journey times and this is exactly the same experience that applications encounter when they pass from the LAN to the WAN. he LANhe WANUntitled Document Competing Traffic f course data traffic travels ver much faster than road traffic with thetrip). It is a small but significant delay and you can see th t to transfer uitelot of data as we are t icall doin we have to send it in a series ofpackets, then wait for the acknowled ements and as we wait for theseacknowledgements so the delays build up. But this waiting means the road (or network) can be em t for a lot of thetime (see TCP Windowing side bar) However there are alwa s other carsa lications waitin to fill the road. In the data network world this otherraffic could be VoIP streamin media watchin Realit TV such as BiBrother or the World Cup) and other business applications all com etinwith your a lication for s ace on the network. Sometimes it ust doesn t allfit and this is the reason that some packets never reach their destinations. Can I Carry On? ut it ets worse because of the wa TCP IP networks work. TCP IP networksbreak data down into packets (similar to cars traveling down the motorwa .owever it doesn t like to send lots ofackets beforeettinanacknowledgement back from the destination point hat the have arrivedsuccessfully (how many you may ask? - see TCP Windowing side bar) This isecause in the world of networkin all kinds of thin s can ha en to ackets(such as packet loss, errors & reordering) as they travel over the network. f our road networks o erated like TCP IP networks do then whenever wesent a few cars on a journey, we would wait for one car to drive back and thedriver to tell us that the all the other cars had arrived afel before sendinsome more vehicles to the same destination. So if it took 3.5 hours to driverom London to Leeds we would wait another 3.5 hours for our confirminar to make the return creatin a total ourne time of 7 hours beforestarting the process all over again. TCP/IP networks require acknowledgement before sending the next batch of packets TCP Windowing TCP windowing allows a set amount of data to be in flight at any time before receiving an acknowledgement. Using our road analogy this would allow for a set number of cars to be on their way at any time. However, when one or more cars arrive, a returncar can immediately be sent back to say that they got there. When it arrives, it has the effect f reducin the balance of in flight cars and so more cars can make the outward journey (up to the TCP Window limit). Assuming that the TCP window size is sufficientbig to allow a car to complete the return t not yet having achieved the quota of cars allowed on the road (i.e. 5 cars are allowed on the road but only 4 have so far been dispatched), then the data flow will never stop (because once a car has been acknowledged as having arrived at its destination, another car is allowed to go). This is unfortunately not the case for higher latency links and the sender will have to wait for an acknowledgement before more data can be sent. Untitled Document he table above rovides ome nternet dela s we observed. Your networkmay be better (or worse) check. Take a particular look at the transfer rate we experienced for a 3G card test the delay tim is close to that of a wired connection to New Zealand.herefore with mobile workforce a lications ou need to be es eciallcareful. All radio networks are generally subject to greater packet lossDownload times can also be affected by the physical location of the la toin a room because the si nal can be weakened as it travels throu h wallsetc. Table 1: Round Trip DelaysThe Greater the Distance, the Longer the Delay The network delay times sometimes described as latency- rom the UK toNew ork are in the order of 90ms round triand our a lication willrobabl be com etin with lots of other traffic. But re ardless of how bithe network pipe (bandwidth) is and how much other traffic there s bommon laws of h sics the fastest ourne time we can achieve is oin tobe 35 ms. However, due to the indirect route and he various networkdevices encountered on this journey, which ll add their own dela in theend it takes 90ms to complete a round trip. The Real-World Impact of the WAN So what does that mean in practice let s consider somethin that ou doeveryday, a file transfer. You are proberver in our com an s network. Ima ine that ou are o enin a 20mbord file which takes about 2.5 seconds to load in a LAN environment. Howon do ou think it will take to erform the same download if ou werebased in London and wished to retrieve this file from the server in Leeds? Assuming the same high bandwidth is available, which is unlikely due tocost, then typically it would take 35 seconds. So somethin that waspreviously reasonable to download over a LAN startinto looknacce tabl slow in this case 14 times slower when retrieved over aWAN. his is exactl the same thin that is oin to ha en to an a lication thatyou are developing and testing that operates over a WAN and it etsworse because some a lications need to be delivered over ver londistances around the world. Untitled Document This table shows the effect of copyshare with different latencies dela s . Notice that althou h we didn testrict the bandwidth at all our connection is 100Mb s b the time weeach 150ms London to California t e round tri s the maximumbandwi th used is ust 1.5Me abits er second. This is a case wherebuying bandwidth can t speed this transfer up. f ou think we are overstatin the case we know of several ro ectsncludin a document retrieval ro ect our Word document exam le is asim le document retrieval rocess that failed utterl in the WAN althou hit had successfully passed several LAN- ased tests. It sim lroved soslow as to be unusable. Table 2: Test of Data Transfer Times for a 62mb file using NetBIOS In all Cases Using a 100 Megabit connection Throw More Bandwidth at the Problem We all know about bandwidth at home you probably started with dial-connections to access the intewere proving too slow, moved to broadband ADSL or cable Problem solved. So why not buy more bandwidth? Beyond a certain point i does not matterhow much bandwidth you have as the transfer is limited by the nee to etn acknowled ement back from the receivin end ever time ou send acertain amount of data. So how do you test application performance over the WAN? Clearly, testing in the LAN is an essential first step. After all, if an application will not work over the internal network, it s very unlikely to perform over the WAN. However, as discussed, it does not follow that an application that performs in the LAN will necessarily perform well or in extremis even work at all in non-LAN environments. OK, so now you re (hopefully!) convinced of the importance of testing in the WAN. However, a request to conduct testing of a new and untried application in your live WAN environment carrying business-critical data is likely to be declined. A possible alternative is to confine your testing over the live WAN to out-of-office hours. The problem is that most live networks are actually busy (or even busier) at night as the company performs network back-ups etc. It is also going to be impractical to get the right people in place at the required locations in order to conduct the initial test and subsequent retesting. Untitled Document Summary " In the topsy- urv world of networks local LAN routes are fast andinter-office routes (WAN) are slow. " Even relatively modest amounts of delay (latency, loss etc can have abig impact on application performance " Satisfactory performance in LAN environmen s is no uarantee ofacceptable performance in the WAN " Testing in the live production WAN is rarely an option " WAN Emulation is the safe alternative " he abilit to test in WAN conditions will enhance the value of thesoftware tester WAN emulation the safe option he tables in this article showin the relationshi between dela times andemulation technology, namely the Itheon Network Emulator. This is a technology that beh ves like a real WAN environment but which cane de lo ed in the same room a test lab if we re bein formal as ourormal test ri . It allows ou to recreate a wide variet of different WANconditions and enables you to inexpensively ensure that softw re can betested during prototype and pre-deployment testing. ical network im airments that an emulator should be able to roduceinclude: " Bandwidth Restrictions " Delay (Latency & Jitter) " Packet Re-ordering, Packet Error & Packet Loss " Traffic Shaping and Traffic Prioritisation (QoS) A ood network emulator will also be able to recreate the followin t es ofnetwork: " High Latency WANs (National, International and Satellite) " Wireless Networks (e.g. Wi-Fi, WiMAX and 3G) " Jittery networks such as cause VoIP deployments a problem " Networks that lose and/or damage traffic " QoS type networks, including MPLS, ATM and VLANs t should also be ossible to a l different im airments to different trafficas would happen in a real WAN third wa is to create a du licate of the live network but when ouconshe chances are that such a re uest will be turned down. Furthermore au licate network will not have the com etin traffic to create the necessarrealism. WAN Simulationvs WAN Emulation WAN simulation is a technique where a program mathematically models simulat d entitiesuch as hosts and routersin order to determine their behavior under arious conditions. This issometimes mistakenly known as network emulation. The advantage of WAN emulation is allows outo apply real changes to network characteristics which, in turn affect the ctual erformance of theapplication i.e. ou et totest the application for real . The Itheon Network Emulator is available as either a portable or rack-mount solution The Impact of Errors, Loss, Reordering, etc. Itheon Network Emulator will allow the testing of all of these items. However, the discussion of their impact on lications is be ond theco e of this introductorwhite paper. Please contact Itheon Networks should you to explore this further.
