The correct way to develop software that utilizes a network still seems to be a little understood subject. The main issue seems to be that there are few people around who have the experience necessary to understand both the correct way to implement/use the necessary network protocols, as well as the implications of running the software over different networks.  This can cause issues with both development and testing: if there is a lack of understanding of the restrictions the network will place on the software then it is not possible to correctly develop or test the software, resulting in a very uncertain outcome.

The principles are pretty simple to grasp though. Essentially the network requirements are derived from performance and usability requirements. If the requirements say that the user should not have to wait for more than 10 seconds for something to happen then you have to factor in how long it will take the data to come across the network. Unfortunately, this is not so simple, as a couple of factors affect this, such as where the servers are located in relation to the user (e.g. the user could be in one city and the server in another city) and the amount of bandwidth that will be available to the user. If the user and the server are a significant distance apart then it is going to take a noticeable amount of time for the request to get to the server and then the data to come back the other way. If there is more than one request/response then this delay is multiplied and  can start to have a very significant impact on the amount of time it will take for the application to respond to the user.  If there is a bandwidth restriction (and I’m referring to the “available bandwidth” here, not the theoretical link maximum) then it is important to allow for this; if the software needs to download several megabytes and the user only has a 1mb/s available then it is going to take some time.

There are two main protocols on the internet which almost everything else is built on top of – TCP (used by HTTP – the web, FTP, etc) and UDP (used by Video/Voice streaming, DNS, etc). TCP is reliable, this means that as long as the connection is valid data will be delivered, eventually (possibly after several retries). UDP is unreliable, this mean that if the data is lost or damaged along the way, due to too much data being on the network or other issues, then the user will never receive it.  It is important that the right protocol is used for your application, typically TCP where you need to guarantee data delivery will be used but UDP can be better if the data loss can be tolerated, or retransmitting data is irrelevant as will be out of date.

One final thing to think about is how many users are going to access the server software at the same time. If there are going to be hundreds or thousands then the server application must be able to cope with this gracefully and not just assume that the computer and network resources are unlimited. The server software should then have maximum limits for each resource so that in the event of a large surge in demand the server software will not crash and will break the host computer. It should be possible to determine the amount of resource each connection is likely to use depending on the action the client has requested.  Using this data the computer and network can be correctly specified.
Below are a list of requirements/recommendations that should be incorporated into any software development and, if followed and properly tested, will help to ensure that the application is far more usable/robust:

1. Make as few requests as possible to the server.  Bunch requests together so that the server can respond to them all at the same time
   • This prevents the user having to wait due to the latency between the user and the server.
2. If more than a set amount of time goes by (say 2 to 5 seconds) and the required data has still not been fully received ensure the user is updated so that they know something is happening.
3. If there is no response from the server in a set amount of time then allow the user the chance to cancel the request
4. Be prepared for the connection to break mid way through a request and alert the user as required without crashing the software
5. Allow for the data to come in at irregular intervals.  Just because the data is coming in a 100KB/s for the last two seconds it does not mean that it will carry on (it’s the stock markets famous phrase – past performance is no indication of future returns…).
6. Do not allow the GUI to freeze just because data is being transferred across the network.
   • This is the one that bugs me the most – and ends up with MS Windows saying that the application is no longer responding
7. Place limits on what the server software can use to ensure that it does not crash and that it does not crash the host computer
8. Just because your application does not specifically use the network, if it can write to network share (e.g. gives the user a choice of where to save the file) then it has to take account of the amount of time the write (or read) could take.
9. Test how the application will perform on a variety of different network conditions – just testing locally will in no way help you to determine how it will perform when the user is in another city or working from home, or another country, or on the road, etc.
   • As you’re unlikely to be able to test in the live network, or get it to “misbehave” (have low available bandwidth, disconnect, lose data) to order, you may want to think about using a network emulator in your development and testing

With the World Cup just around the corner, you may be tempted to catch a match live while at work by watching streaming media over your computer. However, today our UK office received a letter from the TV Licensing Agency which may stop you in your tracks if your offices are located in that country.

The letter advises that “…if your staff or customers watch television programmes as they are being shown on TV, including live World Cup games, then your organization needs to be covered by a TV licence.  This is the case whether they use a laptop, computer, TV set, mobile (cell) or any other device owned by your business”.

The key phrase here is  “owned or provided by your business” as the letter goes on to advise of an exception. Apparently, if your staff watch television programmes as they’re being shown on  television USING THEIR OWN DEVICE, and they haven’t connected it to the mains or an aerial, then they’re covered by their own home TV Licence, if they have one.

A full explanation of the situation is available on the TV Licensing agency web site  http://www.tvlicensing.co.uk/check-if-you-need-one/business-and-organisations/

Of course, the quickest way to ensure your organization doesn’t fall foul of this regulation is to either buy a licence or impose a blanket ban on anyone watching TV while at work. However, for some fans it’s going to be really hard to resist just taking a quick look online using office equipment.  Alternatively, they may decide to bring in their own devices.

Either way, if you are an owner, director or manager you need to know what is being accessed over your company’s network in case, at worst, it is illegal or more innocently (but probably of greater significance) impacting the performance of other networked applications.  This is where you may find our AppQoS monitoring products useful as they can show you how the network is being used and who’s accessing what, including World Cup TV.

We really wish our team well and hope that this is the year when we bring home the World Cup, while at the same time ensuring we all stay on the right side of the regulations.

Last month, I was approached by the BCS (British Computer Society) to get involved in a televised panel session to discuss the implications of adopting a Cloud Computing strategy (SEE ”DEBATE” LINK BELOW). We spend a lot of time advising organizations that they can’t ignore the importance of how applications perform over “non-LAN” networks and “The Cloud” is certainly one of these. So, I thought this would be the perfect opportunity to raise the nature of the network in “Cloud” delivery as an issue that companies embarking on a Cloud Computing implementation need to really think about.

The debate quickly revealed that Cloud Computing really does mean different thing to different people. For some, it means Software as a Service (SaaS), where applications are hosted by the author (or hosting service on the author’s behalf). This is becoming really popular, particularly with smaller companies where the economies of scale possible for vendors like Google with Google Apps, Salesforce.com etc can make these applications hugely cost effective. Others extend the definition to include Platform as a Service (PaaS) – where you can build and host your application using the providers tools and infrastructure, like appforce.com. For some Cloud Computing is simply Infrastructure as a Service (IaaS), or even hosting! And there are even more definitions where a vendor has simply noticed that there’s a lot of “buzz” around the term Cloud and so they must use it in their marketing.

Regardless of which definition you may wish to apply, the success or otherwise of implementing a Cloud Computing model, will rely heavily on the performance of the application running over the network the user is going to use to access the Cloud Computing-based solution. Where the application is going to be hosted relative to the end-user (same country, same continent, different continent) is going to have an impact on its performance. Things such as available bandwidth, latency and loss will all influence application performance. However this, as the DEBATE shows, is something that seems to be just one of a great number of items that need to be added to the Cloud Computing checklist. However, it really is one that I believe you simply can’t ignore – you may be able to control or determine the hosts and even specify minimum performance (cpu, memory etc) on the clients but the network, particularly when public is much harder to control and the application needs to perform reasonably even when the network is under stress.

Isn’t it about time that application error codes that are not meaningful or helpful be replaced by ones that are. I have had experience recently in several different situation where I have had to spend hours trying to figure out what is going on because rather than getting a helpful message saying “Unfortunately, because folder YYYY does not have the correct permissions the installation cannot continue. To sort this issue out please see web page …”, you get a message saying “Error: not sure why but it failed, win some, lose some….”. Or worse still you just get some number such as “0x55FFe782” which when put into Google, Yahoo or some other search engine returns millions of results about something else.

For installations it is possible to run the installation in logging mode which at least gives some more information but because I don’t do it that often I spend 20 to 30 minutes looking up how to do it. For other situations this is often not possible and you are left at the mercy of Google to turn up a result that actually helps. Surely it can’t be too much to ask to figure out a way to always have something meaningful available to the end user.

Don’t get me wrong we love the iPhone here at iTrinegy, it has loads of great features and you can actually read the attachments in emails!  But I have to say that in some areas it feels like work in progress…

Astonishing: no cut & paste, no search on emails.  Vital. Just look around the forums and you’ll see the comments and how people have tried to get around this.  It even seemed like Apple was originally saying we didn’t need these features!

Well, Apple have just announced V3.0 of the iPhone software and guess what, there they are: cut & paste, search (and not just emails either) and many more features like picture MMS and emails in landscape – oh yes I had forgotten about that one – great.   It’s arriving this summer apparently – yippee.

I haven’t delved deeply into the new features but it doesn’t seem like my other big gripe has been sorted – the ability to keep background applications running – particularly important for instant messengers which go up and down like the proverbial…  Yes, I know that you can currently jailbreak the iPhone to do this but for most people there are questions of warranty and legality surrounding that. And I don’t think that PUSH is the whole answer either. Why? – read on

Now we come on to battery life.  It’s really not very good at all.  I have to charge the iPhone every day or face embarrassingly running out of power.  One thing I’ve done to greatly improve this is to disable PUSH on emails instead going to a 15 minute fetch cycle.

Lastly a gripe on 3G Internet performance on the iPhone.  I don’t think this is an Apple issue though.  The number of times the iPhone has had 3G on its display but the performance of web page download has been atrocious.  If you read my previous post on the performance of mobile 3G you’ll have my view on 3G dongles.  Watch this space as we’ll be taking measurements on the iPhone and getting back to you with some numbers in a future post.

I had a debate with one of our customers the other day on how to measure latency in their network.

You may wonder why this even matters:  Well, as I outlined in a previous blog, for almost all TCP based applications (Mail, Web, ftp, custom sockets applications…) latency matters just as much, or more, than bandwidth.  If bandwidth is the “speed of our road”, then latency is the “journey time”, which is related to “the length of the road” as well as all the “holdups” (competing traffic, delay at routers, switches, repeaters etc) along the way.  If we want to test how an application will work in a real network using a network emulator then we need to understand the latency, bandwidth etc that it will experience.

The simple and traditional answer in measuring latency is to use ping, or a tool based on ping or its underlying protocol ICMP.  These send an ICMP  packet to the destination which it turns around and sends back and the round trip time (RTT) is calculated.  But this has problems in most modern networks! 

Why?  This is due to most modern networks, the Internet, corporate WANs, and MPLS included, implementing some form of traffic prioritisation (or QoS – Quality of Service- as it’s often known).  This has been done so that important applications, such as corporate VoIP, SAP etc receive preferential handling and others, such as access to iPlayer etc receive a low priority.  The problem with Ping (ICMP) is that it receives no particular priority at all, and so is not really representatitive of a particular application. 

I don’t mean to diss ping completely – sometimes it’s all we’ve got, but the way around this is to measure the latency of “real” application traffic which is subject to the appropriate network QoS.   To do this we can take advantage of the fact that when a TCP connection is made, and before any http, ftp etc. request is made, or data is sent, a handshake (known as the three way handshake) takes place between the client and the server.  

Using some maths on this we get to see the latency for presisely that application, as the handshake packets are subject to all the QoS parameters of the rest of the TCP session.

You could therefore take the approach of trying to create a TCP session to a target server using the correct IP addresses and ports and time the handshake, but this might cause problems for the server, and as we’re unlikely to complete the transaction it could be regarded as a potential intrusion or DoS (Denial of Service) attack.

Because of this, in our INE Companion and iTrinegy AppQoS products, we provide the ability to “watch” the normal, existing  transactions taking place and time their handshakes.

Let’s face it, once Christmas is over and done with, the prospect of a long, cold (and this year very snowy) winter looms ahead which can leave us all a bit flat. So, it was great to receive notification that two of iTrinegy’s network emulators had been shortlisted as finalist in the forthcoming 2009 Network Computing Awards.

Every year, Network Computing put forward a selection of network performance and testing technologies and asks its readers to vote for the products they believe should be entered into the finals.

Well, I would like to thank all those readers whose votes mean that we have 2 network emulator products shortlisted. Our INE LCD is a finalist in the Best Testing & Monitoring Product of the Year category, while INE Ultra has been nominated as Best New Product of the Year.

We are in illustrious company as other products in the running come from the likes of Acronis, Juniper Networks, and Network Instruments. Given that our products are quite niche I think it will be “a big ask” to win, but still it’s great to think that enough people value our solutions for us to reach the finals.

If you do feel the urge to cast a vote for us (or any other products, if you must , you can do so at http://www.networkcomputingawards.co.uk/ until 5th March 2009.

Recently, I got myself a 3G “dongle” so I could connect my laptop and be on the Internet anywhere at a “reasonable” speed.  If you haven’t re-visited these gadgets recently you might not have noticed that they’re up from the old 3G speeds of 384Kbps  to 7.2Mbps.  I thought you might like to know my experiences, and of course, being me, I took some measurements…

I went for Vodafone’s 3G USB Modem and Service  which is advertised as up to 7.2Mbps (download – subject to coverage) with a 3GB monthly data limit.  Most of the providers are advertising similar speeds. I went for Vodafone because they had coverage in the areas I wanted.

You get a very neat looking device that looks like a USB memory key, made by Huawei. When I got it home and plugged it in the software installed very easily on my Vista laptop from the USB modem itself, which was also behaving as a USB memory key and a CDROM.  So no extra CDROM to load – nice – well done Vodafone. 

It connected with 2 out of 5 bars (poor – it said) of signal strength and reported a 3G+ connection.  So, better than 384Kbps, but probably not going to be up to the full 7.2Mbps with that signal.

But, I noticed on first use that it was really “sluggish” (technical term) browsing Internet pages.  Sites were taking quite a while to initially connect etc and were slow to navigate around too.  On the other hand, after I navigated (slowly) to the BBC iPlayer web pages I was able to watch an episode of  Top Gear with no pausing to refill the buffer, so the speed was OK for this purpose.  This seemed like our old friends latency and loss at work – something never mentioned in the advertising blurb, which always concentrates on maximum download speed.  This is not Vodafone bashing by the way,  I think this is par for the course for 3G from any vendor, but it proves that the headline numbers which the advertising materials concentrates on aren’t the only important performance factors.

Didn’t have much time that day but generally felt disappointed at the sluggishness, and made up my mind to do some measurements another day.

————————————————————————————–

A friend of mine came round and asked if she could borrow the 3G dongle (for a couple of weeks) last Tuesday.  But I really wanted to do some measuring first, so I said she could have it on Wednesday evening as I needed to do some testing.

————————————————————————————-

7am Wednesday I started and was immediately “disappointed” – it didn’t feel at all sluggish, as it had the other day.  No matter – I think that shows the variability of Wireless Broadband. BTW, my laptop was in the same place give or take a few inches. Here are the numbers:

Signal strength 2 bars (out of 5) – Vodafone UK 3G+

ping google.com   (at 7am) – average time over 20 pings 136ms (Min 128ms, Max 147ms, 0% loss), so way-way more than the 31ms (ish) I get from my cable broadband. A quick tracert to google.com shows that most of this delay is in the first hop i.e. the wireless part.

I was interested in what speedtest.net would say about connection speeds but it was down, so I used Broadbandspeedchecker  instead.  It gave:  Download speed 1328Kbps Upload speed 348Kbp, so no 7.2Mbps, but reasonable.

I then downloaded a file from our web site: www.itrinegy.com.  The 14.3MB file (using http protocol i.e. a standard web site download) took 1 min 53 seconds to download – i.e. 1.012Mbps

————————————————————————————-
My friend came round on Wednesday evening (8:30pm) to collect the dongle but before installing on her laptop I thought I’d have another quick look at the performance on mine.  Sluggish! (Hooray).

“Sorry you’ll have to wait a few minutes – I want to get a few measurements”…

Here are the numbers on this occasion:

Signal strength 2 bars (out of 5) – Vodafone UK 3G+

ping google.com   (at 8:35pm)  ping times were all over the place – the largest value I saw was 1400ms!  Then it settled to between 500-600ms but shortly after was up to an average of 1000ms again.  These are satellite sized round trip times!

Speeds from Broadbandspeedchecker (for a like for like comparison): Download 824Kbps, Upload 323Kbps.   Speedtest.net was working again and gave Download 1510Kbps, Upload 346Kbps (Latency 473). This could have been a difference in when the test was performed, as I said the ping times and therefore probably other performance factors (note the latency of 346 measured by speedtest) were varying greatly. (Or it could have been the method used – I’ll look at that another time).

I repeated the file download (albeit a slightly smaller file) from our web site: www.itrinegy.com.  The 12.1MB file (using http protocol i.e. a standard web site download) took 2 minutes 35 seconds to download – i.e. 624Kbps

————————————————————————————-

So the second result was much more like the experience when I first plugged in the dongle.  Sluggish. But notice that the download speed for my file (624Kbps) and the Broadbandspeedchecker.co.uk download (824Kbps) and speedtest.net (1510Kbps) are not too shabby.

So why this sluggish experience when surfing?  Well, suppose that the latency (which represents a full roundtrip) to google.com averaged 1000ms through the whole test.  That’s a whole second!  If this is the first time we’ve visited a site (so it’s not in our cache) we’ll have to look up the name and get its IP Address – minimum time 1 second, then we have the “three way handshake” to establish the connection: 1.5 seconds  but the browser could do our page request (GET http://…) after 1 second.  Minimum turnaround for the first part of the web page another second.  So we’re at 3 seconds.  If the page needs a css file, graphics etc more seconds… 

So, the conclusion is – download speed here is irrelevant it’s all about latency (delay).

If you want to know your how your applications, web sites etc. might perform in mobile broadband (3G) you can re-create them, without the dongle, using our INE for Windows product.

Happy New Year!

Just before Christmas we exhibited at the TestExpo show, which specialises in tools for testing software.

Chatting with the testers and developers during the show I’m still amazed that when testing, and during the development process itself, the effect of the network on the application being tested/built itself is rarely taken into account at all.

Now, if the application is stand alone or will only ever run in a LAN this doesn’t matter much, as the test and build environments will match the final deployed environment. But if the application is due to run in a WAN (or GPRS, 3G, ADSL, DSL, Satellite or Radio network – I’ll call these all WANs for simplicity) the network really matters, and not just because of limited bandwidth.

Taking the road network as an useful analogy, using a LAN is like having your local town, with all the roads (even your local road) being high speed, multi-lane highways with on/off ramps, no traffic lights etc: fast, capable of taking lots of traffic, unlikely to get congested with minimal delay when getting to any other place. The WAN by comparison consists of a very wide range of roads: multi-lane highways (often congested), single lane highways, lanes, tracks and even muddy fields.

You’d never find a car manufacturer only prototype and test a car on beautifully flat roads if it is intended to go off road. A normal (non 4×4) car wouldn’t get 10 yards in a muddy field!

I think by now most everyone involved in IT understands bandwidth limitations. We’re forever being sold or touted faster home Internet connections, so that we can download faster etc. What most people don’t understand is that latency (delay), loss and errors are very important factors in data transmission across networks. Just as important as bandwidth.

We can get an idea of latency by ping-ing systems both in our LAN and on the WAN e.g. Google and we’ll quickly see that the ping times are very small (<1-3ms) in the LAN and large, sometimes very large in the WAN (e.g. 90ms UK to Eastern USA , >700ms for Satellite). This is the equivalent of a WAN being a long road, with lots of traffic lights, roundabouts, stop signs, muddy even. We can buy more bandwidth (effectively more lanes on the road) but we can’t do much about latency. For TCP based protocols (ftp – file transfer, http/https – web, smtp/pop3/imap – mail transfer, Microsoft DS – Windows file sharing and most custom sockets applications) the delay really matters, as acknowledgements of successful transmission of data must comeback from the other end.

So why don’t they build and test in these WAN (or GPRS, 3G, ADSL, DSL, Satellite or Radio) environments?

One reason is lack of knowledge that it matters. My mission is to change that.

A second is that all that equipment to recreate the WAN, GPRS, 3G, ADSL etc. etc. costs loads and is unmanageable,. which is why iTrinegy exists and produces WAN Simulators/Emulators.

This is a page where some of the technical team at iTrinegy will write about all sorts of topics relating to networks and application performance in networks such as application performance testing, application usage monitoring, wan optimization, virtualization and consolidation, proof of concept testing etc, and sometimes anything else that interests or concerns them. As usual the blog will be interactive and you’re very welcome to add your comments and observations.