It’s Worse than that Jim – Bandwidth is not equal to Link Speed either.

Posted on December 13, 2011 by Frank Puranik

In a recent blog my colleague, Phil Bull notes that there’s confusion over bandwidth and speed.  This discussion started with an article on Network World’s website where Netforecast said “No Matter What the FCC Says, Bandwidth Is Not Speed”.  Basically the FCC were bandying the term speed and bandwidth pretty interchangeably and NetForecast took umbrage to this saying that most users equate “speed” to their application’s performance i.e. Response time.  They noted, as we have pointed out many times that other factors, such as loss, re-order and latency, were just as important as bandwidth in delivering this “speed”.

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

Posted in Application Performance, Application Response Time, Bandwidth, Network Delay, Network Emulation, WAN Emulation | Tagged , , , , , , , , , , , , , , , , | Leave a comment

Confusion over Bandwidth and Speed!

Posted on November 24, 2011 by Phil Bull

It appears that even the experts can get confused over the distinction between bandwidth and speed so what chance does the ordinary “Joe” have? I recently came across an article on the Network World web site “No Matter What the FCC Says, Bandwidth Is Not Speed” in which  consultants from NetForecast were amazed that no less a body than the Federal Communications Commission (FCC), in their report “Measuring Broadband America” had followed the line adopted by ISPs and equated bandwidth with speed. As they quite rightly pointed out, this misleads users into assuming that a higher bandwidth connection (which ISPs are always more than happy to sell more of) will automatically deliver a faster user experience.

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

Posted in Application Response Time, Are You Confident It'll Work in the Network, Bandwidth, Network Emulation | Tagged , , , , , , , , , , | Leave a comment

Network Simulation vs Network Emulation

Posted on February 9, 2011 by Frank Puranik

As a developer of Network Emulators, we’ve noticed over the years that there seems to be real confusion out there about the difference between network simulators and network emulators.  Part of the issue is that the dictionary defines these words as synonyms i.e. the same thing.  In the networking industry however they’re quite different.

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.

Posted in Network Emulation, Network Simulation | Tagged , , , , | Leave a comment

Cloud Computing Ignores the Network

Posted on November 23, 2010 by Phil Bull

For any kind of “Cloud Computing” model the network is absolutely intrinsic to application delivery, and yet it’s often just an afterthought.

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”

Posted in Cloud Computing, Consolidation, Proof of Concept | Tagged , , , , , , , , , , , , , | Leave a comment

Developing software that utilizes the network

Posted on July 12, 2010 by David Skingsley

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
Posted in Application Design, Application Development, Application Performance, Application Response Time, Application Testing, Network Delay, Network Emulation, Network Simulation, WAN Emulation, WAN Simulation | Tagged , , , , , | Leave a comment

Watching the World Cup online at work may be illegal

Posted on June 7, 2010 by Phil Bull

Mind on football todayWith 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.

Posted in Application Performance, Application Response Time, Network Delay, World Cup | Tagged , , , , , , , , , , | Leave a comment

iTrinegy Joins The Cloud Computing Debate

Posted on March 19, 2010 by Frank Puranik

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.

Posted in Application Performance, Cloud Computing | Tagged , , , , , , , , , , , , , , , , , , | Leave a comment

Why Can’t Application Error Codes Be More Useful?

Posted on June 1, 2009 by David Skingsley

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.

Posted in Application Error Codes | Tagged , , , , , , | Leave a comment

iPhone Cut & Paste, Search, Battery Life, V3.0 and 3G performance

Posted on March 20, 2009 by Frank Puranik

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.

Posted in 3G Download speed, 3G Testing, Application Response Time, iPhone | Leave a comment

How do you measure Latency (RTT) in a network these days?

Posted on February 20, 2009 by Frank Puranik

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.

Posted in Application Performance, Application Response Time, Latency Measurement, Network Delay | Tagged , , , , , , , , | Leave a comment