Episode #496: Why controlling quality of service controls your mobile destiny – with LiveQoS co-founder Matthew Williams

Here’s the hard truth: Mobile is a business of seconds. Load a few seconds faster and you KEEP your customers. Load a few seconds slower and you LOSE them. Plain and simple. You work very hard to build an app or a service, market it, have someone download it, register for it, launch it and then you what? Make them wait for it to load? Unfortunately in this age of choice, making people wait at the end of that long chain of asks could just be the thing that helps them give up on you and find your competitor.

The idea of controlling the network experience is not new – especially to my guest Matthew Williams, co-founder of Ottawa company LiveQoS. He’s been doing this for 10 years waiting for the world to catch up to the realization that led him down this path. Prioritizing and lessening the loss of packets needs to be on your radar as more and more of what we do and what we sell move on to the network.

Matthew and I talk about why this is becoming an issue, how to ensure high quality of service for your customers, the dirty little secrets the carriers don’t want you to know about how they manage their networks and how to build quality of service into your mobile strategy.

I’ve never met anyone who knows more about how bits move across the network or in the air than Matthew Williams.



Key takeaways from this episode. Click on the link and the video will take you to that clip

1. Why do we need to speed up the internet? 1:11
2. How important is the service level transition from big screens to mobile 3:30
3. What was the original thesis for LiveQoS 5:10
4. What did it take for your thinking to catch on? 6:30
5. What is causing the mobile bandwidth constraints? 8:25
6. How does LiveQoS help fix the impact of bandwidth constraints? 12:20
7. Are developers thinking about this problem today? 14:00
8. What are the benefits of monitoring how an application is being used over the network? 15:15
9. Why use LiveQoS? What are the benefits? How do you quantify it? 15:35
10. How has the sales process evolved over the 10 years since launching the company? 18:10
11. Why should mobile app makers consider the impact of a bad network? 19:50
12. Was RIM ahead of its time? Is their thinking still relevant today? 22:00
13. What is the difference between network capacity and the ability to move data? 24:10
14. How does quality of service play with the Internet of Things? 25:30
15. Is this prioritizing data? 27:00
16. How big is this problem as we move everything online? 28:35
17. How secure is the LiveQoS solution? 30:50
18. Do carriers care about the quality of the network? 33:00
19. Why you shouldn’t believe the data that comes from network speed test applications 34:10
20. Where should mobile application developers start with handling bandwidth constraints? 39:10

Raw Transcript

Rob: Hello everybody. Welcome to Untether.tv. I’m your host and founder, Rob Woodbridge. I love to bring Ottawa companies to the global audience. You guys are in for a treat today because, in fact, we are separated by mere kilometers between us and deep freeze in the city of Ottawa. I am joined today by the cofounder of a company called Live QoS, his name is Matt Williams. I met Matt … I think Matt, it was probably in 2003, 2004. Was it around that time?

Matt: Yeah, it was about mid-2004.

Rob: You had just ventured out, started this company in its previous incarnation. You were talking at that time about buffering videos and I looked at you like this, like, “What is the guy talking about? I got such great speed right now.” Then look, flash forward a bunch of years later, you’ve raised a bunch of money, investment, you’ve built this great company. We’re going to be talking about that, but I got to start with my first question here: Why do we need to speed up the internet? It’s pretty damn fast, isn’t it?

Matt: The internet is fast and it’s getting faster every day. What it’s not getting is better. What I mean by that is the quality of the internet, not the content but the actual delivery mechanisms of the internet, are still bad, low-quality, best effort from a technical sense. What that means is from day-to-day, the performance of your applications will vary greatly. You can pay for a fatter pipe, you can pay for … you can go to your local cable provider or DSL provider and get a really nice, fat pipe, but the actual core internet you’re going over is still the same bad quality it has always been and always will be.
Carriers want to be able to charge you if you’re an enterprise between datacenters for good networks, so therefore, the internet best-effort networks will always be poor quality. It used to be that that wasn’t so important. The applications people were using were … it’s okay if it’s a little slow now and then. It’s ok if it’s a little laggy. The applications people want now are highly interactive. They want great quality video, great quality audio, and quality is so important at the network level to delivering a great quality of experience to the end-user. The quality of a network is still poor and that’s really what Live QoS is all about, is fixing the quality issues inherent in networks.

Rob: It’s funny because a lot of people in the early days, back in those days, we were just so impressed that we were getting video on a website, that it didn’t matter the quality. People … we went through that phase where people accepted low quality but we were getting it. Are we emerging out of that now?

Matt: Absolutely. People were impressed with getting a thumbnail, a frame per second, an inch on their monitor with a gerbil dancing. That was like … or was that a hamster?

Rob: It was a hamster.

Matt: Some little rodent dancing, that was cutting-edge technology. Now people say, “If it’s not 1080p, if it’s not full HD, if I have any buffering, I’m not interested. I’m going to move on to the next content. I’m going to move onto something else.” If my user experience, my UI, lags by a second, people get frustrated. People are just used to really good experiences, and unfortunately now that people are becoming untethered on mobile networks, whether it’s Wi-Fi, 3G, 4G, whatever it is, the network they’re going over is no longer controlled in terms of quality by the application or search-delivery provider. They’re really being held hostage by the bad quality network experiences which in turn drives bad application experience. Unfortunately, the end-user experience is not just under control of the application service provider anymore, the network has such a huge impact.

Rob: I never thought about that, because the more … this has got to be a North American challenge. We got used to the big screens and the fat pipes to our house. We [inaudible: 03:45] sit back, lean- back experience called the internet, which is different from carrying a device with you, but we still have that same expectation. I’m tapping my phone like, “Come on webpage, load,” but it would always takes so long. That’s a challenge that we’ve got, we’ve got to be able to have that same experience on the device that we do on the desktop, don’t we?

Matt: If you want your users who are now moving from wired to mobile connections to stay with you, if you want to keep getting those users to use your service, you have to deliver that same experience. People who grew up with the internet are now are growing up with mobile internet, and they’re just disappointed sometimes in the end-user experience. Unfortunately, sometimes application developers, when they test it in their own environment, in a lab, in their home office, or in a basement when they’re building these apps, it works great, but distances in a network are measured in feet. When you start deploying it in the real world and your end-users are on these crazy network, satellite, mobile, 3G, 4G, Wi-Fi, you name it; it’s all bad quality and the network … and those application experience degrades every time there’s a network issue.

Rob: We’re going to come back to that because I definitely want to talk about this, because we’ve seen that certainly with the AT&T challenges in major metropolis areas around the iPhone usage and consumption of bandwidth; we’ve seen really, really, really tangible examples of this exact problem. I wanted to take a step back and talk a little bit about Live QS; its original incarnation and where are you guys ended up today. What was the original thesis? What were you trying to solve when you started this company in 2004?

Matt: It’s funny how things come full circle. Right now file sharing apps, things like DropBox, Box, ShareFile, and all these apps are becoming very popular. Go back 10 years ago, and the big bing was enterprises outsourcing some of their storage needs, so big datacenter stuff for offsite backup data replication business continuance. Those networks were very, very expensive. To get the quality performance you needed, you had to pay a lot of money for network quality. The thesis was, ‘Could you take regular over-the-top best-effort internet service and deliver a high-performance storage utility to enterprises?’ We’re talking $10,000-$15,000 a month for link and costs, which my thesis was I could do that for $1000. That was my goal in the company, was all about storage extension services.
The nice thing is storage is very sensitive to things like latency, lag, and packet loss. Those are now becoming important to modern applications. In one way, 10 years ahead of your time is a really bad thing.

Rob: It’s a bad spot to be in.

Matt: It’s a bad thing for a business. In terms of technology, it means we’ve had 10 years of experience getting it right. It’s worked out well in the end.

Rob: The transition has happened, obviously. What was the catalyst that allowed people to catch up to your thinking around this?

Matt: Really, it’s people are moving to mobile, the availability of modern technologies, the evolution of people’s expectations at home. I remember when the 1Meg modem came out, and getting a megabit to your home was, ‘What am I going to do with a megabit? That’s just silly.’

Rob: It’s just too much.

Matt: Now places like Asia, a gigabit to the home is common. Networks have gotten faster and faster. The network bottleneck is no longer just the link speed; the quality of that balance is now becoming important part of engineering equation. As well, the applications have changed. Back in 2004, people weren’t doing VOIP and video over the internet; that wasn’t a common thing to do. Things like FaceTime, Skype, and other applications, Google Hangouts; that’s now a common way of interacting. People use their … they call it a Smartphone. It’s not really a phone anymore; it’s more of a communication and network interaction device where everything is dependent upon network connectivity. Things have changed. The network’s gotten faster so quality becomes more important, and applications becoming more hungry and bandwidth-intensive.

Rob: Obviously, we rely on these things for every aspect of our life right now, don’t we?

Matt: That’s just it. I don’t go anywhere without my Smartphone. When I travel, I have 4 or 5 screens: I have a laptop, I got a tablet, I got an e-reader, I got my Smartphone. I actually have … I carry a flip phone just in case any of those other devices go away and they’re not lost for connectivity. I’m a typical high- tech traveler. Everyone has multiple devices. At the security line at the airport, you see people just continually pulling things out of their bag. It’s how people are now, always connected and always expecting that great end-user experience.

Rob: Back in the dot com days, all these telecom companies were laying cable down. Do you remember those days where they were building tunnel in anticipation of this multimedia world we were going to be living in? Things started to fizzle out there. I was always under the assumption that there was an overabundance of available band width that wasn’t lit. All of a sudden you flash forward to 2007-2008-2009, and these challenges that AT&T had when they launched the iPhone in unlimited band width; that didn’t seem like the case at that point. Everything was choked up and clogged up, and people were complaining about it. What happened?

Matt: Two things I think is what you can address that with: Number 1 is there’s a very big difference between dark fiber, fiber optic cable buried in the ground, and RF spectrum. One is a relatively infinite resource. You can lay more fiber. People were laying hundreds of pairs and using WDM techniques to lay thousands of channels on these fibers. That is no longer a constraint, but the RF spectrum was. There was still limited spectrum; the mobile technologies hadn’t advanced to use the spectrum efficiently. Now with LTE and new LTE Advanced coming out, you’re still constrained, but it’s not as bad as it was.
The real consideration was actually the business side. As I mentioned earlier, the carriers, people like Verizon, AT&T, British Telecom; around the world, it’s always the same, they’re in the business of making money, of course. From businesses point of view, they want to make the lowest quality network truly a low-quality network. Otherwise, why would you pay for a premium network? If you’re an enterprise and you have major city locations, you can actually pay for things like MPLS, private lines. You can pay a lot of money to get very good quality. If the internet and best effort was good enough, you wouldn’t pay for that anymore. Carriers need to differentiate their services.

As well, unfortunately, carriers don’t like each other very much. They’re competing for business. The internet is composed of, really, an aggregation of all these carrier ISP networks. At the peering points, we tend to constrain those artificially to introduce poor quality between networks so that you have to be on the … example, a Comcast network or we have to be on the Verizon network to deliver good quality to Verizon people. They want to get the money from both the service side and the consumption side on their own network. Again, lots of different business reasons why you need to have bad quality networks. Technically speaking, RF is still a limited resource. Things are getting better there, but it’s still a quality issue.

Rob: You’re telling me that if I am on Rogers or if I’m on AT&T, and I’m out of range of AT&T and I have to hop onto a different network, there is inherently that level or the quality of the connection will be bad. Will be worse?

Matt: It’s more about if the service you’re trying to go after, say it’s some video sharing site is hosted in a datacenter, and they’ve paid … I’m going to use these … all companies are the same, I’m going to use some names here: Comcast, as an example, again, we’re not going after Comcast here.

Rob: No.

Matt: Say I’m paying Comcast for my connectivity, but then I’m trying to service a person who’s paying AT&T for their connectivity. Both companies are trying to force their multi-homing: You pay for my [inaudible: 11:31] as well. They actually want people coming in from another … from competitor’s network to have a worse experience. One way of doing that is to artificially constrain these peering points, or these transit points between the carrier networks so that it is worse. There’s all sorts of reports you can look at online live to see between the different networks, how much packet loss is there, which is one indication of a bad network? Between different carriers even in the US, you can go to 2% to 5% packet loss; on the same network, 0%. It’s only at the peering point where they artificially introduce this loss by constraining that network. It’s a business decision. An engineer, a technologist would say, “That’s a silly thing to do.” An engineer says, “I understand why you’re doing it. Is there a way for me personally to make sure my application isn’t impacted by that?”

Rob: That’s where you guys come in, because you can understand this. If you are creating a service that is accessed exactly as Matt just explained, there’s an inherent packet loss. There could be, not because of you, but because of the relationships between the two carriers and where one person is using it and the data that they’re trying to fetch is actually living. This is where you guys come in. This is where Live QoS really shines, isn’t it?

Matt: That’s right. Packet loss, which really cues on buffering devices in the network overflow, or their policed artificially to drop packets so packets don’t always make it to the far end; typical packet loss rates, 1/2 % to 2%, pretty common around the world. Other problems that we address, though, include things like latency. Latency’s the speed of light is the speed of light. We’re working on it; haven’t quite fixed that one yet. There’s other sources of latency in the network. There’s all sorts of buffers, routing, network delays. You can get hundreds of milliseconds just from that, and that sounds like a pretty fast network, but hundreds of milliseconds can actually harm your application performance.
There’s also Wi-Fi congestion. I’m at a coffee shop, I’m in an airport, in a hotel; I’m on Wi-Fi, because it’s less expensive than mobile and carriers are pushing people to use Wi-Fi whenever possible, again, to offload that RF spectrum. When I’m in the Wi-Fi environment, I’m sharing the bandwidth with a lot of people who are also fighting for that same bandwidth. There’s lot of variable delay, there’s lots of packet loss just in that little area, as well. Things that Live QoS addresses are the 3 major issues that application developers have to think about when they’re deploying applications over these uncontrolled networks; it’s packet loss, it’s latency, and it’s Wi-Fi congestion.

Rob: Do you think that developers are thinking that way at this moment? I think that there’s probably a core that understand this challenge, but then they’re … because this democratization of entrepreneurship, because of mobile apps, we’ll say this mobile app economy, do you think that everybody is thinking about this?

Matt: Absolutely not. What they’re thinking about is ‘How do I make sure I convert as many users as possible from free to premium? How do I prevent [inaudible: 14:22]? How do I get as much revenue out of a service I’m developing as possible?’ The networks, to them, is a Cloud. If you’ve ever seen an engineering diagram, you’ll have the end device, app; they’ll have … they’ll know how the app is supposed to work, they’ll know how the server side is supposed to work. There’s a magic Cloud in the middle, which is the network. We know this, we’re network experts, that’s what we do. Very few people worry about the network because it’s normally thought of as ‘It’s the network. What am I supposed to do about it?

Rob: How do I influence that? How do I change that?

Matt: Exactly. Actually, what we developed is a software framework which is almost a plug in to an application development cycle. You plug in our SDK into your app, into your service side, and the network is now a magic Cloud. If there’s packet loss, if there’s latency, if there is Wi-Fi congestion, we’ll measure it, we’ll monitor it and then we’ll correct it for you. You get to not only have a great user experience, you get to learn about the environments your users are using your application over, allowing you to just make some engineering decisions. Maybe I should send smaller bitmaps, maybe I should buff the things [inaudible: 15:24] architect because I have a lot of customers over high latency networks. Maybe I should move service closer to that cluster of users. Not only do we fix the problem, we provide all these great metrics on ‘How am I actually … how is my application being used in the real world and what can I do to make the performance even better than it is?’

Rob: Are big companies thinking like this right now or are they emerging into this; they’re realizing this because their customers are having challenges with their products?

Matt: We’re partnering with Fortune 50s, we’re partnering with very small startup companies.

Rob: Across the spectrum.

Matt: Everyone … it’s absolutely cross-spectrum. We have millions of devices out there; we have software loaded enhancing the end- user experience. To enterprises deploying hardware in a competitive market, it’s a strong differentiator. My device, although it may look the same on the outside, performs 2 to 5 times better than everyone else’s device on the same network. That is a huge, huge benefit for a piece of software. Again, we’re a software solution. If you’re a startup, you want to make sure that yours is the fastest app, the least lag, the best performance, the fastest file sync, the fastest transfer, the shortest backup time. Whatever the number is, all those metrics are dependent on the network quality. You use our SDK, our IPQ framework and there you go, the network is a magic Cloud.

Rob: I love. How do people quantify that? You’re a part of this and you know this. How many apps do you have on your multiple devices right now? Hundreds, and hundreds, and hundreds.

Matt: Absolutely.

Rob: There are categories of applications that have thousands of apps inside of those categories and do the same thing. You’re the struggling … you’re either a large company struggling against a competitor, you’re a small company struggling against many competitors. How do you quantify that, because that’s one of the things that is going be a selling … obviously, going help sell the application or sell the service. There’s got to be something. Is this the thing that can quantify that to say, ‘These guys are slow, we’re much faster.’ Is that enough to sell a product?

Matt: We absolutely believe so. We’ve seen it. We’ve done … we go into a new market, we do an analysis of what is the performance of the Top 5, Top 10 people in that market, and then we actually surreptitiously figure out how much faster it would be if our software was there. We have a lot of experience in this proofs- of-concept, where we actually measure the performance increase we can create.

Rob: Before and after.

Matt: Then we bring that one-page glossy to any of these companies, and they are like, “You can make me 2 to 3 times faster, and I can use that as a first bullet point in marketing?” I’m going to an enterprise and I want to sell a file sync service and I can now say I’m 3 times faster than my competition. That wins deals.

Rob: No kidding.

Matt: Performance is Number 1. The quality of experience is … there are Number 1 things people look for these days.

Rob: As a business, as Live QoS, you emerged 10 years ago. While we were all satisfied, as you said, with thumbnail video and waiting forever for a low-res image to come down, but it was cool and it was fast enough for us because it was new. You wait 10 years. What has that sales cycle been like as you’ve built the expertise and you’re still ahead of everybody else but you’re trying to sell the service because you know you have to make money? What’s that been like, to sell what you guys are doing?

Matt: What we’ve learned quickly is there are obvious low-hanging fruit, you normally call it; who is hurting the most from bad networks? At first it was just that storage extension, it became more and more mainstream. Different places would say, “I want a better network.” We’d go through the process of figuring out ‘How does that application work over a bad network? What techniques can we use to improve it?’ Our framework has evolved; it’s gotten more and more capable of solving different issues for different people. We’ve evolved to a point in time where it’s almost self- serve; people can come in and say, “I have a network issue.” We’re getting cold calls; we’re getting emails coming in saying, “I heard about you guys. Can you really fix my issue?” A day later, their network issues are fixed.

Rob: It’s that fast.

Matt: The fastest we’ve done, I think, is 3 1/2 minutes for an integration. We’ve really become good at this. For certain environments, certain applications, we know exactly how they should perform, how much better we can make them, and the proof point is very quick to come to.

Rob: We are speaking with Matt Williams who is the co-founder of a company called Live QoS, at LiveQoS.com. Matt, you’ve got to understand it from a mobile standpoint really, because the audience, the folks who are listening to this and watching this right now really are diving into this from a mobile perspective. I know that you guys are emerging in this spot because everything that we do, from file transferring from some of the big guys all the way to playing video games now, and certainly watching videos, watching movies, is happening from these devices, what advice can you give the people who are listening to this, some advice to help them understand why they should be speeding their applications up and how they can do that?

Matt: Like I say, everyone is a mobile worker. Again, I have a lot of screens, a lot of devices; none of them have a wired port. Even in the office, I’m not wired to a network. In our terminology, everyone is mobile. Every single user in our company is a mobile worker. Even when I’m in the office, like I said, I still consider myself mobile. You can’t think of … you can’t ignore the problems you’re going to face by saying, “The network’s fine; it’s a Cloud I can’t touch. It is going to be what it’s going to be,” because there are people out there who have that technology who are going to be beating you hands down in the market head-to-head when people testing different apps. They test your app and it’s 5 seconds wait time, your competition’s app is 1-second wait time. Who are they going to pick?
It is such an important thing, end-user experience. People talk about user interface, which is obviously a big part of end-user experience. How big is the download? What features do I have? Is it painful to use on a real network? As I go from my home, as I drive, as I commute through different networks, go to different cities, different countries, is your application now painful to use? I will look for an alternative if I find this doesn’t meet my needs all of the time. Then of course, 90% of the time, your app may perform just fine. It’s the 10% of the time when you have a network issue where people are going to go, “That app sucks. That is a terrible app. It didn’t work for me that one time at Starbucks. No, I’m going to find something else.”

Unfortunately for app developers, a lot of these apps are … I think the term in economics is fungible. You can easily replace one app with another. I personally don’t care who is delivering the service, I want to have the best possible experience. Switching one service for another tends to be becoming easier, also to companies, also to small developers. A team of 2 or 3 can develop an enterprise-class app these days, in weeks. Your competition is coming up behind you. You have to differentiate yourself somehow, and end-user experience performance is the easiest way to do that.

Rob: It’s funny, because early on in the days … I’ve been around in the mobile space for quite some time. We talked about even in the Blackberry days, we tried to keep the downloads, not only the initial download of the application onto the device, but then the interaction, the data consumption, to a minimum. Early on in the day … we’re Canadian, we talk about Blackberry, RIM [inaudible: 22:32]. Their Number 1 selling point to the carriers was, “We, through their NOC, reduce bandwidth. We compress it down so that there’s not as much bandwidth going between the device through your networks to our NOC.” Were they ahead of their time in this, in that compression technology? Is this still relevant in a world where now it seems like bandwidth is … we’re in excess of bandwidth? Everybody wants more.

Matt: In those days, it definitely was a capacity issue. There are only so many bits I can send across that RF spectrum. Blackberry had a great story; it made a lot of sense to the carriers: I can deploy more devices on the same spectrum. Even Blackberry in their latest DB10, that’s no longer the case. You no longer use that compression technology from the server-down because it does have some engineering issues; central point of failure, things like that.

Rob: We never saw that happen. That happened all the time, their NOC’s down.

Matt: Unfortunately. When it worked, it worked well; when it didn’t work, everyone heard about it. They’ve even identified, though, that moving to a different model makes a lot more sense on modern networks because capacity isn’t the issue, again, it’s quality.

Rob: That’s interesting; capacity isn’t an issue, it’s quality. I think that that resonates. The thing that I think about is the first step is that you can’t look at the Cloud as something that you can’t touch, that you can’t augment or you can’t make better; that connection between the device and the Cloud. The quality is the key. Who cares about the network? The quality between the points is the network, or is the key to success with you guys.

Matt: Absolutely. Actually, there’s been a fair bit of work in related fields to ours that identify that you have to make things work in these networks. A lot of devices will right-size a video file. If you go to YouTube, it’ll say, ‘Can you handle a 720p or a 480? Can you go at a 1080?’ The funny thing is they’re not actually measuring your network capacity; they’re actually measuring how well it can move data across that network. It’s a subtle difference. Capacity, you think of, ‘I currently have 5- megabits connectivity, however, the packet loss on latency means I can only move about a megabit. I’m only using 20% of our network to actually move data.’ What they’re measuring is the actual ability to move data, not the raw capacity. There are actually ways even on a limited capacity network to expand usage of that channel. That’s where we come in. Again, it’s not just about packet loss and latency, it’s about you can actually get more ‘goodput’, we call it.

Rob: Goodput.

Matt: The good put out of your network. Again, the carrier may have for my … while I’m on the network, assign me 5 megabits on my mobile network. I may only be able to fill 1 to 1 1/2 of that, just because of these network quality issues. By addressing those, you actually get to free up usable capacity out of the network. It’s a lot of places where this technology fits very well, even in bandwidth-limited environments.

Rob: There’s going to be many of these places. There are corridors in our city where I don’t get connectivity, which is the frustrating thing. As we move out into these things, the devices that we wear on our wrist, on our face, and on our watch, replacing our watch not only Smartphones, and then we’re talking about connected cars now; always-on devices, mobile devices that you drive. What happens in that? All of the sudden, quality of service can’t be an issue anymore, it has to be on. Just like electricity and water, connectivity will become that important at some point, so it has to be high quality.

Matt: Absolutely, it does. For many, many applications, you have to have that great quality network. In a land environment of any enterprise, they knew about this 25 years ago. QoS has been in wired networks in small environments for a long, long time because you have to be able to the guarantee the quality for applications that need that quality. Now unfortunately, it’s very infrequently that you’re only on that one network where the QoS is respected. That’s where you need a technology like our framework which allows you to say, “I need you to protect this traffic. I need you to make sure the packet loss, latency, the congestion won’t impact my end-user experience as I go across this undetermined network.” I have no idea what that network’s going to be tomorrow. It will change in a minute. It was different a minute ago; can’t predict it. You need something that’s adaptive, like our framework. We’ll fix these issues, adaptively, proactively to make sure you get the good quality. It is becoming a requirement.

Rob: You’re starting to see this with the stuff that’s going on in the United States, around prioritization of data; Netflix and Hulu interested in creating an elite connectivity. We’re talking about that kind of relationship within your application, where you are protecting, you’re binding, and you’re giving a higher priority to that data for that application, aren’t we?

Matt: Exactly. What we provide at just the, we call ‘the edge’. We only deploy in the Smartphone and in the Cloud server, only those two points. We could provide a very similar value, but the carriers want to charge these large service providers to give prioritized service. It’s the same high-level value proposition of guaranteeing end-user experience by controlling the network, except we’re doing it just in the edge devices. What this means for an app developer is I don’t have to pay for 25 different carriers around the world to prioritize my traffic. That may make sense for someone the size of Netflix or someone the size of Google, not anyone else, because that is a … it’s almost a ridiculous statement. I need to go to every carrier in the world and ask them to prioritize my traffic. That’s just not going to fly.

Rob: No. The fascinating thing about all of this is that it’s a problem that its genesis is because of the way that we now consume this content. We believe that the airwaves are free to consume or to exchange data on, whereas 10 years ago we didn’t even think about that. We were just so impressed that we were getting and receiving email. What happens now? As we emerge into this where we’ve got this next generation of kids that are growing up with wireless devices, and always-on and always-connected devices, information at their fingertips. My kids sit with an iPad and watch old episodes of The Hulk, from our generation; the real Hulk with Lou Ferrigno and everything. They’re consuming this bandwidth like it’s just part … it’s the air that we breathe. How big a problem is this going to be if companies don’t look at this quality of service over the networks?

Matt: Networks are not … like I said, networks, from an economic point of view, will always be bad quality. The capacity is getting better and there’s all sorts of techniques carriers are trying to deploy to improve that: Next-generation LTE Advanced, Wi-Fi offloading, forcing you to use your home Wi-Fi when you’re at home, forcing you to use public Wi-Fi when it’s available to get that extra capacity. The network is always going to be bad quality as the race for who’s going to … these landgrabs for these new application markets are all going to be based on who gives the best end-user experience. If you simply say, “There’s nothing I can do about the network,” you’re going to lose that battle. There are people that know the network is a problem, and there are other ways of solving this problem. You can deploy thousands of servers as close as possible, like content distribution networks; they move the content as close as possible. That last mile still exists. That last mile gets congested and there’s packet loss and latency. It only solves all the way to the neighborhood, not all the way to the end- user.
There’s limitations in any solution. We think we’re providing that end-to-end guaranteed quality that’s … it’s not future proof. There’s definitely going to be issues that we have to evolve our solution. New things will happen. Today, we think we have a very good solution that addresses a lot of the issues people find. If application developers don’t identify this as potential problem that will bite them, it will bite them.

Rob: It becomes a retention strategy. Quality of service is, to me … the way I think about it in my head is retention. It’s ensuring that people come back and use your application or use the service through which is fed through your application, because they understand that it’s going to be consistently great. I think that that’s the big thing.
What about the balance between security? We hear horror stories about breaches in security. I don’t think that we’ve really seen a full breach of security in mobile yet. I think that there’s going to be one of these monumental Target-esque challenges that are going to impact not just 100 million people, but 800 million people at some point. How does that … do you guys wrap a layer of security around this? How does that work for you guys to ensure delivery, ensure that the data arrives at the right place at the right time for the right person?

Matt: We’re definitely looking at security as something we’re adding to our, what we think of as our product suite; all sorts of techniques you can use to protect from network sniffing and things like that, private networks. A lot of VPNs, though, have performance issues. We’re looking at figure out ‘How can I make the fastest possible mobile VPN? How can I protect always?’ Enterprises have started to do this themselves, but to the end- user, you think of what’s on your Smartphone from a personal point of view. All your personal …

Rob: Let’s not.

Matt: If I wanted to steal your identity, it’s a perfect place. If I want to get access to your back accounts, I can reset your password. I’m going to see the password reset email on your mobile device. Everything is tied to mobile device and a lot of people don’t even put PIN codes on their mobile device. There’s a lot of data there for nefarious purposes, if you want to get in and break in. Protecting that data as it moves across the network is very, very important. It is so critical to how people operate these days. People using the Smartphones as mobile wallets; it’s just so rich for stealing. We’re looking at solutions for security. Stay tuned, I guess is the best way to put it. Definitely, things are coming up soon.

Rob: Why are … it’s not in the carrier’s best interest at all to offer a high-quality network, because their whole goal … and I just want to reiterate this; their whole goal is to get as many people on their network as possible and satisfy them to a certain level, a certain network capability. Carriers still are rolling out higher-speed networks and they’re bidding on bandwidth. Does this … what happens … do we run out? What happens at that point?

Matt: More spectrum is becoming available, which is nice. Recently in the US, there was a 700 MHz auction. There is one going on in Canada right now. New spectrum does become available.

Rob: It’s a game that big guys can play in. It’s not a game that anybody who has a little bit of pocket change can get involved in.

Matt: No. It’s very, very expensive. Getting access to a spectrum is very, very hard. There are [inaudible: 33:34] better ways of using that network bandwidth, but carriers tend to look at it not as … from a marketing point of view, we give you the fastest possible download speed. In reality, though, you’re not alone on a cell tower, not alone on a mobile network. It’s really about adding capacity. If I can deliver a good enough service, say a megabit per second on average to my users and my entire network now supports 200 megabits aggregate instead of just 50, I have 4 times as many people I can sell service to without having to buy new spectrum. That’s what those technologies are really about.
It’s actually a … I don’t know how secret it is, but there’s a lot of ways that end-users think they’re testing the network. If you use apps like Speed Test or test apps where they press a button and 10 seconds later, they see exactly how fast their network goes. The funny thing is there’s very few things carriers will prioritize on their mobile networks. Speed test apps is Number 1 thing they prioritize.

Rob: They do?

Matt: They do.

Rob: They’re smart that way.

Matt: It makes sense to the end-user, ‘Look’; they compare [inaudible: 34:38] friends. ‘My network is a 10 megabit.’ ‘My phone does 20 megabits.’ Real-world traffic, non-prioritized traffic, the stuff that isn’t the speed test traffic; you won’t get anywhere near that kind of performance. That … people are aware of network performance as being important, the speed that their applications see. The real-world applications aren’t getting the benefit of the carrier saying, “Speed test to me is very important,” because that’s what people use to judge if I’m delivering what I promise.

Rob: It’s funny; it’s interesting game going on in the carriers. I sit, if something goes wrong with my connectivity, I reach out to Rogers, who is my carrier, my internet provider at home and at the office, everywhere, also who I have my mobile device with. That’s the first thing they ask me to do is logon to Speed Test. ‘We’re good. It’s not us. Connectivity, it’s a challenge in your house.’

Matt: What the testing there is ‘If we prioritize all of the traffic to your location from that server and make sure it gets Number 1 priority, what’s the theoretical maximum we can push?’ Absolutely, that looks great.

Rob: Here’s the tunnel right here. It’s perfect.

Matt: It’s like saying, ‘You want to test your car, try it on the Autobahn. Look; it can do 150 miles an hour, excellent. Now go back to your city which is where you are actually using your car.’ In the real world, you don’t drive on the Autobahn every day necessarily; you happen living in Germany and doing a long commute. In the network speak, everyone is in a congested city. Yes, I can throw that same car onto my own private highway to do a speed test; that’s going to tell me how fast my car goes, not how fast I’m going to experience my car day-to-day. That’s probably a good analogy.

Rob: That’s a great analogy.

Matt: They’re purposely showing you what it looks at the showroom. The showroom of a car; it’s all waxed nicely, there’s not a speck on it. Every couple of hours, someone’s out rubbing it down, make it look pretty. Look how pretty this car is. A day in Ottawa driving in the winter, it doesn’t look so pretty anymore.

Rob: It’s not pretty. You’ve ruined it. It’s so funny because my kids ask me this all the time; it’s like, “Dad, why are you only going 100 when it says you can 240 in your car?” That little dial, it’s exactly the same thing. It’s like …

Matt: Absolutely.

Rob: I said, “I’ve never been that fast.” “Well, do it.” I’m like, “I can’t. I’m congested in my city.” I was having this conversation with a guy just yesterday, and I was sitting there complaining that, “Every once in a while, my Wi-Fi drops out and I lose connectivity. I lose my connectivity and everything stops, and then I have to wait or I have to transfer networks.” The guy came around with his little network detector, and he said, “No, we’re getting 40 gigabytes. It’s your fault. It’s got to be the Mac,” is what he told me. “It’s the Mac’s problem. It’s this.” I’m like, “No, I’m telling you, I dropped out and it …” “No, it’s impossible because we’ve only got 8 people.”
There are the conversations that I’m having on just a little low level around this. I can’t imagine from a large enterprise, the conversation around this as well. I think that that’s why I love what you guys are doing, but I always kept on thinking, “Everybody who I talked to says, ‘Why isn’t the carrier doing that?'” Here’s the answer; that’s why the carrier … the carriers don’t care about the quality of their own work.

Matt: To the consumer level, absolutely not. You have no guarantee of quality. You may say if you look at your actual agreement, your ISP will say ‘Up to 5 megabits. Up to 10 megabits.’ What they’re telling you is ‘If we ever see you faster than that, we’re going to slow you down.’

Rob: Bring you down, that’s right.

Matt: In terms of how slow you’re going, that’s not our problem.

Rob: It’s up to that and nothing higher, but oftentimes, not that high.

Matt: Then on the enterprise side if you’re paying for good quality, they will actually put in a little, what’s called an SLA, a service- level agreement [inaudible: 38:20]; measured on a very long-term basis, you won’t get more than 1% packet loss. What that means is … one example could be 29 days out of a month, zero packet loss. For 6 hours of one day, 100% packet loss. No, that would be [inaudible: 38:36] SLA. Over the month, we didn’t drop more than 1%. During those 6 hours, though, you were a pretty unhappy customer. That’s an exaggeration. Unless you’re measuring the real application performance at a very fine level, you’re really not measuring the true quality of the network.
What we do is we’re measuring continually on these, all these application flows. If your application flow at any given time is being impacted by network quality, we’ll step in and address it. Even these SLAs from enterprises, from carriers to enterprises, they’re nice to have, but really from a day-to-day point of view, they’re not going to save your bacon if you’re an IT.

Rob: If you’re in the mobile space, Matt … last question here: If you’re in the mobile space, and you’re listening to this and you’ve come to the end of this episode … and thank you for listening; where do you start? How do you get people involved? What should be the first thing that they do when they stop listening to this and they start looking at their applications or their services that they’re bringing in through, software-as-a-service they’re bringing in through the apps through a mobile device; where should they go? What’s the first thing that they should be doing?

Matt: Our website, of course …

Rob: Of course.

Matt: … is a great resource. It’s got lots of detail on network issues, how we solve them, things like that. We actually have a neat little tool, as well. One of the things we address is latency. We actually have to have a tool you can download; you can run this tool. [inaudible: 39:53] do two file transfers concurrently to the same server in a Cloud service provider in Europe. It’s a nice long distance network, and it’s going to show you both with and without [inaudible: 40:04] technology how much better it is on a simple file transfer. Just to show you on your own machine, over your own network, how much better it could be using our technology. That’s only one of our optimizers, we call them. That one that addresses latency.
We have other ones for packet loss and Wi-Fi congestion; of course all the benefits of measuring and monitoring the visibility into where your end-users using applications. [inaudible: 40:25] is part of what we do. You can quickly see how much better it could be. With our SDK, again, it can be minutes, more likely days, but it could be minutes to integrate our technology, be up and running, and bet a much better end- user experience without having to know anything about networks.

R: That’s great.

M: I really do think that’s why we’ve had such success recently, is we’ve made it really easy to deploy for people who don’t understand networks. Again, if you draw off a magic Cloud and you can’t really explain the next layer of the onion, but you now know because of things like this interview, why the network is important. We can actually step in and take that load off your mind, move that engineering limitation, just make your … you can concentrate on application design, end-user experiences from the user interface point of view, from the services point of view. The network no longer is an issue for you.

Rob: That is so smart. I think the first thing to realize is that … the first thing to figure out is, ‘Is this having an impact on your end-user, on your customers, on your application, and what kind of impact is that?’ If you are not looking at it right now, I would implore you, please, check out LiveQoS.com and you’ll be able to figure this out. You’ll know definitively if this is having an impact on your users. Are you losing users? I keep thinking retention it is so hard to get somebody to do something like find you, download you, sign up for you, pay for you. Those are so many steps. If you’re losing people along the way, what’s the impact of that? Is the impact the reason that you’re losing them simply because the network service isn’t as good as you had hoped? What’s it going to cost you just to go and check this out?
Go to Live QoS.com, and do yourself a favor. Don’t do me a favor, don’t do Matt a favor, do yourself a favor. That’s what I’d say. LiveQS.com. Matt, thank you for doing this. I really appreciate it. I know that we covered a lot of topics here, but I think the key thing here, as always, is that don’t rely on that just drawing the network symbol. Don’t draw the Cloud and then hope it’s … have an impact on the Cloud and it’ll impact, obviously, the quality of the service that you’re giving your customers. I think that’s the key.

Matt: Excellent. Thanks for the opportunity. I appreciate it, Rob.

Rob: We have been speaking with Matt Williams, who is the Co-Founder of a company called Live QoS, Ottawa-based, that’s Ottawa Canada; Ottawa-based Live QoS. Go to Live QS.com for more information. Matt, thank you for doing this. I really appreciate your time.

Matt: Thank you.

Rob: For those of you who are listening, watching, whatever you’re doing, wherever you are; I appreciate the fact that you do it every single week with me. Please reach out if you have enjoyed this or you have any comments on this: [email protected] We’ll see you next time. Thanks, Matt.

Matt: Thank you.

Be sure to subscribe to iTunes to be notified on all future episodes: Audio or Video

About Matthew Williams
Matthew Williams LiveQoSMatt co-founded IPeak (now LiveQoS®) in 2004. He has previously held Sales, Marketing and Technical positions at Akara/Ciena and Newbridge/Alcatel. He has extensive domain experience with high performance network technology.

About the author

Rob Woodbridge

I'm Rob, the founder of UNTETHER.tv and I've spent 14 years immersed in the mobile and pervasive computing world. During this great time I've helped some of the most innovative companies grow their business through mobile. If you are in need of a mobile business advisor or coach, connect with me here to get things rolling.

/* ]]> */