The Cloud


Cloud Services don’t go down do they?

I am sure they are not sold that way, in fact, many tout 99% up time. But cloud services are no more special than your internal infrastructure and they are subject to the same outages as any network. The likes of AWS (Amazon Web Services), Google Apps and Microsoft Online Services essentially use the same technology as most organizations, albeit with a lot more redundancy than the average Enterprise Network.

Read about the 10 Biggest Cloud Outages Here. 

Of course there are service credits that you can apply for if there is an outage, but those credits often only equal 10% of your monthly fee.

Of the 720 hours available in a month, a 99% up time equates to an 8 Hour outage. Can you afford an 8 hour outage? Does the 10% cover the losses of your full work day outage?

This is not to say that you are not subject to the same outage with an internally hosted infrastructure. In some respects you have more control over your own infrastructure and if built with redundancy in mind, you can almost eliminate downtime, barring any physical disasters.

I am not necessarily advocating internal infrastructure over Cloud Services, in fact we both use and provide Cloud Services at End to End, but I do want to educate everyone on the pros and cons of each.

Maintaining your own infrastructure can be expensive and time consuming and if IT isn’t your forte, cloud services make a lot of sense.

You must have some faith in your cloud provider, faith that when, not if, there is downtime it will be minimal. Then it is your job to create enough redundancy in your own network to ensure you are always able to get to the cloud. At a minimum I would recommend two Firewalls in an Active/Passive cluster, with two small out side switches and two Service Providers, using two separate mediums (Ethernet and Wireless). Even this is not full proof, but will ensure that any number of hardware and circuit failures will still have you connected to the cloud.

If you are still unsure whether you are ready to embrace the cloud, have a close look at all of your applications, you may already be using the cloud.

Apple Vs Android


I have been reading a lot of posts lately around Apple vs Android and it strikes me as odd that there is so much anger out there.  Why can’t people like both for what they are.  I may like one over the other but I don’t really feel the need to bash one for copying the other.  Who really cares if Apple used others companies ideas, improved them and changed the market forever.  They were still the ones that did it,  and before anyone else.

My first smartphone was a HP ipaq that ran some terrible form of Windows, then I moved to the iPhone 3g.  Since then I have focused on Android, starting with the Nexus S,  then the Asus Transformer 101 tablet and now the HTC one phone…  I loved them all.

At the Cisco partner summit last week Cisco was generous enough give everyone a gift,  and we had a choice between the Samsung galaxy tab 10.1 or the Apple Ipad mini.  Since I had a 10 inch tablet already I thought I’d try the Ipad…

Smooth, easy to use, and very comfortable. I must say I like it and I use it quite often…

After my long trip home that included cancelled flights and long taxi rides,  I got home and wanted to  watch the hockey game.  I was so tired and could barely keep my eyes open so I decided to stream the game over the Internet and watch it on the Ipad in bed …

But alas, the CBC steams the game using Flash so the Ipad was useless. I booted up the old Asus TF101 and watched the hockey game until I fell asleep.

Apple have done some great things,  as has Google and Microsoft.  Long may this continue as I think it helps breed innovation, but what needs to happen next is the collaboration between all of these operating systems to take some of the incompatibilities out of it…  I call it kludgy, a word I use to describe many things in the emerging technology industry.


1. A system, especially a computer system, that is constituted of poorly matched elements or of elements originally intended for other applications.

2. A clumsy or inelegant solution to a problem.

I thought I’d see if I could get the Hockey updates on my HTC One and was surprised to discover that the HTC One does not support flash either.

The moral of my story…  They are all good,  but none are perfect.. In fact I think my next purchase may be a Windows Tablet..

A good argument on the merits of one technology other another is always healthy, and I welcome a good argument, but please people, stop hating the competition. iOS is a good OS and for the less technical out there it is probably the right choice. Android has many features and lots of customization, but needs a more savvy user, and Windows looks good and fits into many

peoples comfort zone. So let’s all embrace these Operating systems and find ways to make them all work together as opposed to crushing the other until they don’t exist. Now I didn’t mention RIM/Blackberry and that is not because I’m a hater or anything, it just didn’t cross my mind until now. What RIM did was rest on their laurels, instead of innovating or even copy catting. So they are not really top of mind for me or anyone. I guess nobody hates them because nobody cares….

In conclusion lets stop bashing the competition and support all the technologies that will help make us more efficient and bring us closer together…

VoIP – Trouble Shooting


Back in the day before the Real Time Requirements of Voice and Video all we needed to worry about was Bandwidth. If there was enough everything worked the way it should. If there wasn’t enough, you could deploy some technologies that may help prioritize data that would provide a group of users with a better user experience. And if that didn’t work you bought more bandwidth.

Enter the Unified Communications Era – Voice, Video, Data and who knows what they’ll think of next, all running over the same network.

Delay, Jitter, Packet Loss, Bandwidth and contention from other applications are all things one needs to consider when managing these new multi-service networks.

As Network Managers we have always been cognizant of the user experience. For applications like telnet the appearance that your characters were being echo’s back to you immediately was important, even if they weren’t it was the user experience that mattered.

The quality of a phone call though is something that can’t really be measured scientifically. We attempt to measure using MOS scores based on the Delay, Jitter and Packet loss, but these don’t actually measure the users experience. One person may say the call is good while another says not so good. That same person may be biased based on their mood.

Recently we have been trouble shooting a customer with Echo problems. The difficulty here is that we receive a report of an echo problem at a site with little to no information on the Called Party, Calling Party, who heard the echo, was the echo constant, was the echo loud, what type of delay in echo was experienced, was there a headset in use, was it a conference phone, speaker phone? This is not to blame anyone, as the user is not expected to know that these items are important.

I came across a really good article while searching on a solution for this issue, and while most of the information I already knew it really helped us solidify the source of the issue. I will also say that our team of technical staff did a great job in implementing echo cancellation technologies that has ultimately solved the problem – albeit by masking the echo. I’d like to share some of the highlights of this article.

Most Importantly:

Bits do not leak, so you can disqualify the digital segment of the system

As long as VoIP calls continue to be terminated in analog tails, echo will be a problem. One major obstacle to widespread VoIP implementation is that many tail circuits have preexisting delays that will become noticeable only when service providers introduce digital segments to the networks.

Because of the fundamental delays associated with VoIP technologies, existing echos will be more annoying than with TDM, and even the normal operation of an echo canceler will be more apparent. Customers of VoIP networks need to be educated to expect the standard echo canceler operation previously described so that they do not confuse these types of echos with abnormal echos. Abnormal echos persist throughout a call and do not fade.

These problems will gradually be solved as digital networks extend out toward homes and telephone endpoints. Until then, how much echo can be expected? One call in 50? 100? 1000? Even if customers are trained to complain only when an echo problem is persistent and repeatable, a service provider cannot hunt down and destroy every echo complaint. No one has sufficient resources to do this task, and hunting down an echo is a necessarily intrusive process.

The challenge is to determine when an echo complaint is both solvable and worth solving. You know that the echo source is in the destination tail circuit. For an echo problem to be solved, the tail circuit needs to be accessible.

Even after the deployment of Echo Cancellation, there is still a Echo when the call is first answered, as the Echo Cancellation Mechanism must get some real data before it is able to effectively stop the echo.

So in short the real answer is to use all digital circuits. Other echo issues are sometimes related to the phone set itself. Lower end phone sets tend to have cheaper components and are not as good at isolating the microphone from picking up sound that has leaked from the speaker.

Document Source: