To say the situation is confusing is putting it mildly. It appears that services that were actually 3G were not displayed as 3G and new services being positioned as 4G/LTE are actually going to be 3G offerings, albeit, considerably enhanced versions.

It is not just the case of the mobile network operators using terms and definitions that can leave us mystified; the mobile device manufacturers are playing their part as well. When Apple’s iPhone currently shows that you are getting a 3G connection this could be anything from 384Kbps to 14.4Mbps. And for those of you with Android devices, if you were wondering what the H stood for, well you are getting HSPA, which goes from a few megabits a second up to a maximum of 14.4Mbps at the HSPA+ level (theoretically).

Interestingly, at the time of writing, we hear that AT&T is pushing Apple to display 4G when receiving the 14.4Mpps HSPA+ service – and while fast that’s clearly not 4G!

One thing is for certain – if you are developing or about to roll out  applications for use on mobile devices, make sure you thoroughly test them in a wide range of network conditions (bandwidth, latency etc.) because assuming 3G, 3.5G or 4G have well defined parameters cannot be taken for granted. Of course, our network emulators are ideally suited to recreating mobile network conditions.

I strongly recommend you take a look at Frank’s blog because it certainly opened my eyes.

And, that’s totally correct, but it’s not complete! It’s worse than that Jim:  Bandwidth is not equal to Link  Speed either.

So, the ISPs and FCC probably really meant “link speed” when they used the term “speed” interchangeably with bandwidth.  But when talking to customers we never do.  In fact the distinction is so profound that some time ago we suggested to our developers that our Network Emulators be very specific on the terminology within their GUIs and documentation.  I precisely define:

• Link Speed is the speed of the link
• Bandwidth is how much data you can actually transfer per second down the link

So, when the ISPs sell you a 20Mbps link they have sold you a link with a link speed of 20Mbps, but that doesn’t necessarily mean that you get 20Mbps of bandwidth.

Why?

Well we have little things like “contention”, Network QoS (Quality of Service) and Bandwidth Controls in place.

Contention: If the ISP sells links of 20Mbps to 20 people say, and these come together in a 100Mbps circuit further down the “road”.   Then it’s clear that 20×20=400Mbps and so if everyone was to use their connection to download big files at the same time the 100Mbps would be overloaded.  And that is exactly our experience.  At certain times of day everything goes really slow.  So to try make this “fair” to everybody the ISPs employ…

Network QoS: Prioritization (or de-prioritization) of certain traffic. e.g. gaming traffic or data downloads between certain hours.  If they didn’t do this you might not be able to browse the web or read your email online at certain times.  But sometimes even prioritization is not enough and they also use…

Bandwidth Control: Again at certain times certain network protocols (defined for this purpose “types of traffic”) may be given a specific restricted maximum bandwidth e.g. gaming, ftp, bittorrent so that it doesn’t overwhelm the network.

While all along your link speed remained at what they sold you, your available bandwidth did not.  And it’s your available bandwidth that together with latency, jitter, loss, reordering, errors, and of course, your application’s design, that contribute to your Quality of Experience (QoE).

See more Network and Application Performance Blogs from iTrinegy

Not so, say Netforecast, and we at iTrinegy wholeheartedly agree with them. This is something that we encounter time and again when talking to attendees at events and shows. Simply providing an application with more bandwidth in order to resolve poor performance rarely fixes the problem. Fortunately it is one of those “myths” that we are able to rapidly disprove when we use one of our network emulators to simulate an internet connection in which the available bandwidth is doubled, tripled, quadrupled etc.. It is quite illuminating to see people’s reaction when the change in bandwidth doesn’t automatically lead to a significant (if any) improvement in application performance.

As the excellent Network World article points out, bandwidth is about capacity rather than speed. We recommend you take a good look at it. Our own summary white paper “Are You Confident It’ll Work in the Network” will also explain some of the other network characteristics that impact networked application performance.

See More Network and Application Performance Blogs from iTrinegy

Using flying an aircraft as an example:

• a network simulator could calculate that if the airspeed dropped below a certain value then the plane would stall and fall from the sky
• a network emulator would allow you to pull back the throttles, watch the airspeed fall, see how the aircraft felt just before stalling, stall, and see if you could recover it

in other words, a network emulator operates in the network, like a flight simulator does for a pilot – you get to really try it out.

In network terms, this means that our Network Emulators transmit actual network traffic. They control bandwidths, set latencies, have QoS, can route, can bridge, can act as a wireless network etc. AND you get to connect equipment (PC’s, servers, switches, routers, set top boxes, games consoles)  to them and try out how they actually performs in good, bad and indifferent networks.

I hope that helps to clear up the confusion.

In the beginning the “Cloud” was the network.  Now it’s mostly IaaS or SaaS and sometimes even hosting and companies concentrate on having enough CPU, memory and diskstorage in their cloud implementation. Necessary but not sufficient!

If the network is considered at all it’s at the most basic ISP bandwidth level, with the attitude, that well you can always buy more and bandwidth is cheap.  But it’s not just about bandwidth; latency, losses and QoS are significant, in the same way that while you can build a motorway with more and more lanes you can’t change distances between cities. As well as this, the total network capability of the physical servers on which the Virtualized “Cloud” hosts are built is ignored, so one virtual host can deny sufficient network to the others.

As a company that specializes in networked application performance iTrinegy has had to help companies pick up the pieces on many an occasion where the network was just an afterthought in their Cloud or Consolidation preparations and consequently application performance was terrible.   We think it happens because compared to CPU, memory and disk sizing the network seems complex to deal with – a shame really as we have the network profiling tools, network emulation products and methods to measure and predict what’s going to be required and so de-risk the Network part of “the Cloud”

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

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.

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.

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.