SD-WAN Chat with Pat, Episode 1 – February 2, 2017
Kevin: So, I’d like to thank everybody for joining. Today’s session, I think, could be quite interesting. We have an hour with Pat, or about 45 minutes actually is what we’ve scheduled. I have about 20 questions already teed up. I’d like to remind everybody to ask any questions that come to their mind in the chat box, and I’ll weave them into the questions that we’re going to ask Pat. So, without further ado, let me welcome Pat to the call. And Pat, let’s start with the first question.
You started TELoIP in 2002. Did you see this SD-WAN market coming? And what problems were you trying to solve?
Pat: Thank you. And welcome, everyone. Well, good question. You know, although not called SD-WAN, we did see the displacement of WAN over Internet. And since 1998 I have been pioneering the promise of Internet for business, you know, in the form of VPN, Voice over VPN. And to keep up with that, we invented our aggregated data plane, which is defined in software.
Kevin: So, what do you see coming as the next problem set?
Pat: Well, as we evolve beyond SD-WAN … and I’ll share a little bit of vision as I answer that just to sort of give you some background. Our vision is one of SDN (Software Defined Network). We started defining networks in software on the edge, and that’s our SD-Internet product, our existing product which we built on. We saw SD-WAN on the way. We adapted SD-Internet, added the control plane, and now we have SD-WAN and SD-Internet. That actually makes us unique in the marketplace, in my opinion. However, IoT’s on its way. It’s already here. We’re making room for that to deliver the full promise of software-defined networking. We do have full SDN in our roadmap.
Kevin: Okay. Great. So, we have this TELoIP cloud, the nationwide multi-tenant infrastructure.
Why is having SD-WAN as a service so different for Communication Service Providers (CSPs) and MSPs?
Pat: I’m going to answer that from our existing partner perspective. We put together a solution and a distribution network for this product as a service. And for partners, time to market is king. For our end user customers, having an all-in-one device coupled with a single-pane-of-glass orchestration and management system is also essential.
Kevin: Okay. So, within our service architecture, if we look at the CPE and the controllers, this is all built on your SDN operating system.
Why did you feel it was necessary to create an SDN operating system?
Pat: Simply put, Kevin, we needed to move beyond what was available in the market and, we’ve been doing this for 15 years. And once we surpassed the best-of-breed available technologies out in the marketplace, we began to develop our own platform, our operating system and our virtualized cloud. That was the path we chose.
Kevin: So, why not take an approach like many others have taken, just like going out and getting something like CentOS or some other off-the-shelf OS? Why go through the effort of going right down to the bare metal and starting to build an operating system that way?
Pat: Again, for what we needed, it just wasn’t there in the marketplace in the manner which we needed it delivered. Like you say, you know, there’s a lot of players in the space, and they have a lot of claims, and, you know, how would I summarize all of this stuff? Look, unlike many newcomers, we’ve been doing this for over 15 years. We’ve got 18 patents and counting, and we’re actually delivering on our claims. Things like compression for Internet and WAN traffic, you need both. Diverse carrier. Internet aggregation for you to get the red and the blue network as a single user from your desktop, from speedtest.net. And hitless failover, delivering no dropped voice calls where you may not even lose a word on link failover with our Intelligent Packet Distribution Engine.
Kevin: Okay. So, we received a question from one of the folks dialed in on the call,
“Is the appliance plug-and-play? Like there’s no user setup required except for having a DHCP server?”
Pat: I’m going to answer that in describing our evolution here as a company. You know, we needed to scale out, and there were many tools that we put together over the years. And one of the methods that we came up with several years back was the ability to take our code, once we burn it onto devices, package it up, ship it from the factory in what we call Zero Touch Provisioning mode. And that device, as you mentioned, as long as it picks up a DHCP address from anywhere, it will call home. And now it’s up and ready to be orchestrated. It’s ready to be fully provisioned. It’s ready to be swung over to the nearest point of presence, and, of course, ready for on-board tools to kick in and start calibrating for each connection.
Kevin: Okay. Great. So, I think that answers that listener’s question. Next question that came in, and this came from somebody off the email blast that we did.
“There are a lot of new companies getting into the SD-WAN space, and their claims all sound the same. How would you summarize what makes TELoIP different for a non-techie?”
Pat: I think that I kind of hinted at that already. I mean, here at TELoIP, we are a 100% channel model. We are driven by a channel. We are driven by the needs of our channel. And, these partners that make up our channel, they have different needs than your typical carrier, you know. They are all becoming Managed Service Providers in one way, shape, or form. There’s new net revenue on the table for them, and we’re here to help them get there. And I’ll just restate, I mean, unlike many of these newcomers, we’ve been doing this for many years. And with these 18 patents and counting, we’re actually delivering on these claims.
Kevin: Okay. Sounds good.
I’ve heard, you talk about MPLS being rigid in conversations with partners and customers. What do you mean by this? And where do you see MPLS in the roadmap to software-defined networking?
Pat: Well, before the business decision here at TELoIP for SD-WAN, before this SD-WAN control plane had been added to our existing system and points of entry, we did receive a patent for adding MPLS as an on-stack universal protocol to our existing system. This architecture out of that MPLS edge patent, we borrowed from it to create our SD-WAN, which is why we are much closer to an MPLS model than anyone else is. I mean, you have our CPE device and its like a CE, and we connect to the nearest point of presence, which is our point of entry (PE). And the second that the (CPE) device is connected, it’s fully meshed.
Kevin: Okay. Wow. We’ve got a bunch of questions coming in on the chat box. I think I’ll jump over to them, Pat, rather than then going through some of the other questions that we have.
So, are there different size of appliances based on service speeds being aggregated?
Pat: Yes, there certainly are. Another benefit of managing our own SDN embedded operating system is, the ability to port over the different platforms. And something we did several years back, to address the needs of some of our retail customers, and needing a low-cost footprint for CPE device, in a low-bandwidth type of scenario but at a multitude of sites, was port our code over to a MIPS implementation. And this allows us to have a unique offering in the marketplace, which I haven’t seen anything rival it yet. But in bulk, we have a sub-hundred dollar CPE device that can connect you to SD-Internet and SD-WAN. And that’s a starting point. That would be one of the units. And then you go up to a, $5,000 device, and there’s a couple in between, that can get you to a full gigabit worth of SD-WAN and SD-Internet.
Kevin: And how many WAN links can these devices support?
Pat: Today the code is set to a maximum of eight. So, you can take, whatever, really. It could be an existing MPLS connection. Because, again, with this whole SD-WAN, the promise of SD-WAN is getting you, the customer, to a broadband per-megabit price point economy. So, you start adding some broadband connections, whatever’s available. Even better if you can do a cable and a DSL. Now, you have two different connections all together. You can add 4G LTE connections. There’s something special we do there. You don’t want to consume all of the gigabyte transfer rates, or the transfer rates of that 4G LTE, so we can actually put it into this zero weight payload mode and that’s unique to us. And even if that was the last connection left while I was on a live Voice over IP call, even then, I may not lose a word. Certainly, I won’t lose the call.
Kevin: Great. I think a follow-up for that, a good one, is this other question that just came in.
Is there high availability available for the edge in the core?
Pat: Yes, we have active-active and active-passive configurations where there’s two physical CPE devices, so we’ve already mitigated the problem of multiple connections for 100% uptime at the client. But, what happens if a device goes down? Despite our very, very low failure rate, at about 1% or less, you may want to have a second CPE device in hot standby mode. And the active-active, that simply means we consume two licenses, and within 5 to 15 seconds, you’re completely switched over and alerts have been sent out. The active-passive means that you swing your license from one to the other, your hardware at the branch, and you’re back up and running within 45 seconds without any user intervention whatsoever.
Kevin: Oh, sounds like an interesting set of options for somebody, especially given the cost points that we’re talking about for SD-WAN versus MPLS. There’s another question that came out on the chat.
“Are there current security concerns” Maybe let’s talk a little bit about the security architecture. Why don’t you talk about that? And then there’s a specific question about FIPS support.
Pat: Certainly. I could break security out into several layers. Let me start with the underlay, right at the bottom. So, we’re taking multiple connections from diverse carriers. We don’t need any special permission from any of the incumbents in order to use these and connect to our points of entry because we are an overlay. Hence, VINO, Virtual Intelligence Network Overlay. That’s where we begin our security experience. Because not only do you need to protect your payload from the world and obfuscate it through encryption, you also need to protect the branch from the world on that particular connection. So, that happens in our product right out of the gate for SD-WAN.
Furthermore, once we’ve got this CPE device and connected it to our points of presence…and, in fact, Kevin, great job. You got a network map up here in the view (see Fig. 1). I’m going to use it to describe, if I may.
Fig. 1 – VINO Customer Network Diagram showing SD-WAN & SD-Internet access
Once the CPE device (let’s take one here in the Dallas area), connects to its nearest point of presence, if it’s an SD-WAN service, encryption happens on those underlays, as we transport through that with our protocol that, takes every separate packet, uses our intelligent packet distribution, and aggregates the red plus green. But now we have to get on to the full WAN customer protected route domain, and that would be yet another aspect of security. And so that happens there, and you get, I’ll call it a VRF. It’s a little bit more sophisticated than that in our implementation. But security has to hold between points of entry between PoPs in different regions as well. And the reverse happens at any of the other sites. And as you can see, the second that CPE device is connected we are fully meshed.
Okay, the last part is, well, I do have SD-Internet, and I do have SD-WAN coming out of this solution. It’s all unified. And, something interesting has happened in this market. We’re watching customer trends completely change. I mean, it’s absolutely upside down. We now see 70% Internet usage versus 30% percent WAN. It does not mean that the WAN is any less. It is growing as well. It just means that the pull on public cloud solutions is that much greater. If I were to put Office 365 on my WAN, I might bring it to a cloud. So, SD-WAN is great for that kind of stuff, but VINO WAN is even better, because now I can get an unbreakable cloud tether to and from this public infrastructure. I have bi-directional IP QoS on it. I can go to third-party hosted voice providers at any time. I can switch my voice provider tomorrow and not worry about quality because my SD-Internet component will manage that for me.
All right, well I’m on the Internet, I am now exposed. I have Internet at my branch. And so there is a full-blown firewall on each of our CPE devices. This is something we have spent quite a bit of time perfecting over the years and displacing many other technologies. You know, when we show up at a branch, the partner, or the end customer, they may choose to use that CPE as a firewall or use their existing firewall, well, in the event they want to use that CPE as a firewall, we help them consume that ecosystem at the branch for that device.
Kevin: Okay. So, if I think about recommendations from some public cloud providers, just to carry on in this security thread, Microsoft has, made a public statement that for companies that deployed Office 365, their suggestion is to set up and use direct Internet access from each branch to try to overcome some of the limitations that customers are faced when they try to run public cloud services on their MPLS network. That, to me, seems like a security nightmare.
How do you suggest that TELoIP is going to solve this and not have these hundreds of thousands of points-of-entry that all have to be protected in a security domain?
Pat: That’s a great point. Actually, you know, you’re touching on some IoT stuff as well with that. So, let me see how best to frame this. All those different layers of security that I talked about, they happen between our CPE device at the branch and a Controller at our point of entry in our model. And it’s very important that the user security experience happen as close as possible to the assets that need to be protected: the LAN and the WAN. We’ve got both.
So, this example you’re giving is a very common one. And I think earlier I mentioned that, if we were an MPLS network and we threw Office 365 onto that MPLS network, we may bring it to its knees. And not only is the traffic crawling as a result of this new application, which, hey, I’m saving money, I’m on a public hosted service, I don’t have to maintain my own emails, so on and so forth…this can go on for any – any – hosted service or cloud service. But, you know, I may be exposing myself as a branch, for example. Same could be said with IoT devices.
So, there is a firewall at each of these points. Our vision is a Software-Defined Perimeter Defense System, okay, that is in place for any one of our customers, including our SD-Internet customers only, where we are protecting assets at the branch. Now, there are customers that prefer, or already have an existing investment into a centralized firewall system, or we could do both. Not only can we add the protection at the branch, but we can also, on purpose, trombone their Internet traffic to a centralized location and allow them to practice their unified communication security as they currently do today. So, they don’t have to change that model going from an MPLS to a VINO WAN implementation.
Kevin: Okay. Great. So …
Pat: Sorry, Kevin, I answered that question from the aspect of security. But, you know, there was another connotation in the question and that was, “Okay. I’m just going to break Internet out at the branch and solve the problem,” right? Although it’s great for other SD-WAN providers possibly to send raw Internet traffic and receive Internet traffic for this Office 365 right out of the branch, right through those underlay connections, we don’t find that to be best practice. Because I can no longer manage the inbound and the outbound out of that particular underlay circuit with the intelligence of my SD-WAN traffic. They need to be put together, because the enterprise is made up of both types of traffic. Back over to you.
Kevin: That makes sense. So, thinking about this, there are a lot of compelling reasons for SMBs and enterprises to embrace SD-WAN, right? We’ve got agility, we’ve got cost efficiency, often times better management and control.
What do you hear most when you’re talking to customers and partners?
Pat: Well, compelling reasons for SD-WAN, I think, us, our competitors, the providers that run our competitors’ equipment, you know, we’re an SD-WAN as a service. They’re going to be an SD-WAN as a service eventually, or they are to the end customer anyway, regardless, a managed type of service.
The number one compelling reason is that broadband price point economy. You know, 10 times the speed for half the cost. When you’re on an MPLS-per-megabit price point, the SD-WAN economy is real.
so, that could be a starting point for most customers. It isn’t always the starting point, but it certainly is an important point.
Next, availability, always on. This is a connected world. We always have to be on no matter what time and no matter what application. So, you got to guarantee that they’re always on, even on MPLS. It’s not possible to do that unless you have diverse mediums to transport your data. And with MPLS, you could be locked into a particular carrier in order to achieve that. SD-WAN breaks you free of that. It allows you to put in any broadband, bring your own broadband, add it to that, and achieve failover at least.
We go beyond that, it’s much more than that for us. We have recognized that things have changed, that, the trend is 70% of that branch’s traffic is Internet and 30% is WAN, and that it’s all driven by cloud. And so we need to support both all the time, the combination. Our system takes all of the connections all of the time and applies our patented autonomous network aggregation technology on a per-packet basis and manages the quality of the user’s experience with our intelligent packet distribution engine. So, we can make a decision at this moment in time for this application’s packet in this direction to send or not send now on that link, or use another one, or the packet right after it. I can send it down this link. And that happens bi-directionally and has given us a leg up on the competition.
Kevin: Interesting. So, one thing that I haven’t heard you talk about here today but I have heard you often talk about,
How TELoIP is not a DMVPN. And you say it like it’s a good thing. What do you know that every other SD-WAN CTO doesn’t?
Pat: If you took a recording of me 15 years ago, I would be telling you that VPN is everything. It’s going to displace MPLS. Actually, I would’ve been saying we’re taking out frame relay even before that. And you know what? The world of IPsec VPN is real, and it’s grown, and it is part of this transition. When I look at SD-WAN, I look at the displacement of MPLS and VPN. It’s the evolution of the two in combination in a weird way. Now, it’s not that DMVPN isn’t a good technology. It’s just that DMVPN is really just an advancement of what I can now call a legacy overlay VPN, and it inherits those complexities.
We’ve done something different. And so what I really mean when I say we’re not a DMVPN is the fact that we were inspired by MPLS. We knew you needed points-of-entries. We knew you needed to deal with the long-haul aspects of aggregation over multiple carriers. We patented the proximal aggregation aspect of our technology. When we look at some tier 2 MPLS providers, I can look at them on bulk and say, “Well, they’ve probably got four points of entries, and they probably negotiated with a plethora of local loop providers, and they’re putting together MPLS services for their customers.” And that’s great, you know, at that time. Things have changed now. It doesn’t work for the Internet access side of things, it doesn’t work when you mix the two, and it doesn’t work in the world of SD-WAN.
All right. Well, now, look at the DMVPN side. I got a device at a branch, and I have to have two tunnels out of there at a minimum as a starting point, one over the red connection, one over the green connection. Yes, there is an aspect of spoke-and-hub within a DMVPN architecture, but it’s complicated. I also need branch-to-branch, so I might have to spawn some other tunnels. So, if I was to map that out on a per-tunnel basis and put it up on the screen (see Fig. 2), it would look like a huge spider web, where if you look at the diagram on this placeholder for our session here today, we don’t have that. It’s been simplified.
Fig. 2 – DMVPN Overlay Diagram showing underlying complexities
We didn’t just simplify it in an orchestration portal so that we obfuscate those complexities from the user and it’s still happening underneath. No, we actually recoded it. We came up with an innovative control plane, and we added it to our already innovative edge data plane technology. And we kind of look like MPLS under the hood. I hope that answers the question.
Kevin: It does. It probably leads to another question around, when people think about MPLS and DMVPNs and IPVPNs and managed VPNs, things of that nature.
If I’m a service provider and I’m currently selling a managed VPN service, do I need to let go of that? Or is there some transitionary approaches that maybe they should take?
Pat: You touched on a wonderful point. Look, managed VPN and MPLS, they’re both targets for SD-WAN. However, if you’re a partner and you’ve got an existing investment in managed VPN, or an end customer and you like your current VPN but you need more bandwidth, you need that high availability, you need that failover, you can simply subscribe to our SD-Internet service. The same CPE device shows up. We hand you a port. It’s Internet. But what happens behind it is all of these VINO special technologies and mechanisms, managing your packets. So, we’ll make your existing managed VPN better. In fact, we could take some competitor’s SD-WAN product, which is just a DMVPN, and we can make them better, too. Because, you see, now, you don’t have to worry about your voice over your VPN dropping when the red or the green connections go down. You don’t have to worry about your SQL server sessions terminating and having to start back up again. We’re going to make sure that it’s always there for you. Your IP address never changes. Your session never goes down. You have full experience, like hitless failover.
So, customers, partners that are in the business of managed VPN, we give them a path of full-blown SD-WAN, and they do not have to replace that customer out immediately. And the good news is, that customer’s calling in, and they’re asking, no matter what it is they’re asking for, if it’s of a network flavor of any kind, they’re talking SD-WAN. They can now answer that. And when we’re done, it’s really a push-button upgrade, and now they can use us as the SD-WAN and keep the SD-internet. You get both when you subscribe to the SD-WAN license.
Kevin: Sounds pretty good. So, you know, just sort of a little take off on that, I think.
I’ve seen some competitors put a lot of emphasis on their routing capabilities. How do our capabilities compare?
Pat: You’re going to get a different answer on the level of importance of that based on who you ask. If you’re asking a carrier, it is so important to be able to mesh into their existing MPLS network because the incumbents must stay relevant with their base. They need to support them. They need to address their need for SD-WAN. But at the same time, they need to maintain, and leverage the investment that they already have in their MPLS infrastructure. So, you’re going to get a different flavor of SD-WAN from a large carrier than what you will get for a smaller medium enterprise-type customer offering from Tier 2 partners or even Tier 3 resellers. You know, it’s a big difference.
So, routing is very important on the carrier side, because you need to mesh, not for you, Mr. Customer, for the carrier. And it’s about the customer. So, for us, probably, we’ve had discussions around the watercooler, Kevin, and I think I’ve said crazy things such as, “the MPLS conspiracy,” etc. You know how many customers have come to us and said, “We need layer 2?” And to me, I find that more of a typical play on the large carrier for the simple reason that all the MPLS networks we’ve observed to date that we’ve either turned into a hybrid, or made it one of the connections of our SD-WAN solution, or completely displaced … they’ve all been layer 3 through and through. In other words, a packet at the branch needs to traverse some type of gateway to get into another branch. That’s a layer 3 network.
So, for (the carrier), they have a different priority. For the customer, routing and integration could mean something different if you are concerned about a DMVPN. Because now, you want to be able to manage routes on the red network, you want to be able to manage routes on the green network, those two underlays, and you have to do it on a per-flow basis. So, you need to be able to adapt your routing architecture for that. And some special things have happened in competitors and how they do that. TELoIP has done it a different way from the very beginning. We completely disregard any of that underlay stuff, and we give you a brand-new experience running through our protocols in the underlays, our encapsulation, delivering you a single unified overlay, managing anything that happens underneath.
Now, we do have and can go right up to full eBGP peering out of our PoPs or out of the points-of-entries, at the customer branch, consolidating multiple SD-WANs to a partner and handing it off, having an eBGP session on a per-SD-WAN basis with them. We can do that. That’s there, it’s in our code. And we can also give you an OSPF instance to manage your own customer protected route domain if that’s what you wanted, but we don’t demand it of you. And we’re not doing it because we need to protect an infrastructure, our investment in a legacy MPLS infrastructure. We do it to support the customer needs. So, you know, that question I took long to answer it because it’s different for everybody, including the customer who’s asking it. Thank you.
Kevin: Sounds good. So, I spoke to a partner earlier this week, and they really were asking a lot of questions around how they would best move a customer from MPLS to SD-WAN.
What are the best practices that TELoIP has developed to address this common use case? …I guess what really matters is are you doing MPLS replacement or are you doing an MPLS hybrid, right? So… What are the two cases there?
Pat: Right. So, we have broken that up into two camps. I’m going to just address it as a hybrid. Because one way or another, you need to address hybrid in this scenario. So, number one, we call it SD-WAN / MPLS hybrid network. And this is the easier of the two, because, you know, I’ve got 10 new locations. I have got to bring them in on a VINO WAN service and bridge them at your headquarters, your data center, or both, and fully mesh with your routing environment. And now your existing MPLS sites can see our SD-WAN sites, and our SD-WAN sites can see your existing MPLS sites. You are now a full-blown hybrid network. You’ve got two networks.
The second is hybrid at the branch where I want to make use of the existing MPLS connection, and I want to add broadband to bring it into this new economy. And the reason I’m keeping that MPLS connection, it could be because I really like the SLA on there. I like the MTTR on there, or I got 18 months left in this contract, and I have got to use the thing. Well, we have a solution for that, too. We are able to use that MPLS connection. The only difference between us and others is we’re not going to tell you that it’s as simple as spinning up controllers in your data centers or your headquarters, because not all MPLS underlay infrastructures are created equal. They’re different.
Just the other day when we turned up a customer, and their MPLS connection to sites that are relatively near, because they were actually tromboning in the MPLS layer, not Internet, was 70 milliseconds. That provider, that they are switching off of had four points-of-entry across North America. We have nine. It just so happens that these two sites in our infrastructure over broadband Internet became 26 milliseconds. That’s a big difference, you know, for their applications. So, you have to take a lot of care in the architecture and design of this when using MPLS, but it is possible, and we do work with you to get there. Thank you.
Kevin: Thanks, Pat. I just noticed there were a couple of questions that came in on the chat that I didn’t address.
Going back to the question that was asked earlier about high availability, does the appliance support software upgrades on the fly without service interruption, or would that require an HA implementation?
Pat: Yes, we can update the unit remotely without interrupting the service. However, depending on what type of update it is, it may be consuming some bandwidth that won’t be available for you, so your traffic will have to go over a different link maybe. But yes, we can. We do not need active-active dual CPEs. It is a remote upgrade. However, we normally do this in a timed service window that we arrange with the partner and the customer anyway.
Kevin: Okay. Makes sense. Another question that I missed.
When we look at our coverage map, and we talk about our nine points of presence, is there an option for Canada-only traffic?
Pat: Well, that’s a great question. More interesting would be U.S.-only. The bulk of our business is actually in the U.S. We’ve got seven points of presence across the U.S. and two in Canada that make up our nine points-of-entry. We do not intentionally ship traffic south of the border. We do keep it north of the border for Canadian-to-Canadian East-West Coast customers. Certainly traffic does not come up to Canada for U.S.-based customers.
Kevin: Okay. So, why don’t we talk a little bit about voice and video? I mean, these are really key applications today. You look at Microsoft and the push that they’re doing on things like Skype for Business.
What secret sauce is inside the VINO WAN solution that provides hitless voice and video performance through brownouts and outages?
Pat: Quite a bit. I’ll break it up into three categories. Number one is our Autonomous Network Aggregation technology. And that was the first thing we did right out of the gate. We knew we needed a red and a blue network. It couldn’t just be a red network or a blue network if we were competing against legacy WANs. So, aggregation is key here. But that puts us into the per-packet delivery model.and we function on a per-packet basis, and it’s bi-directional.
Next was, “I’ve got my two connections, and what happens if one of them goes down?”. So, we needed a failover system that wasn’t like your typical failover system where you literally, swing from red to blue, and your IP address changes, and maybe I have some other special DNS transactions happening. And maybe they’re fast enough, and maybe then customer.com is back online rather quickly. We couldn’t go through all those maybes. What we had to do is invent and perfect what we call our Multi-Directional Pathway Selection system, MDPS, which is a preemptive fast failover system that, if need be, can function at, you know, tens of milliseconds, if those were the circuits we were dealing with.
We tune to hundreds of milliseconds today, so this is why we can failover a live Voice over IP call, or video, and you may not even lose a word. Because we’re not actually changing the IP address. None of that is happening in the overlay. It all happens in the underlay. And when that event happens, because it’s preemptive, if the CPE side of the branch sees something which is possible with this asymmetrical type of underlays, the other side will notify its peer. So, the controller might see something towards the branch, tell the branch, “Don’t use that link now.” The branch might see something, tell the controller, “Don’t use this link right now.” And that is a patented fast-failover system.
But it’s more than that. It’s more than bandwidth. It’s more than failing over. You also need quality of experience and quality of service. So, we have our bi-directional Intelligent Packet Distribution Engine, which is the third category.
So, now, I have mentioned ANA, autonomous network aggregation. I have mentioned the failover, the preemptive fast-failover, the MDPS. And now, I’m introducing IPDE, intelligent packet distribution engine. This is a bi-directional communication system that was built for the two former items that gives us this intelligent decision tree for the delivery of packets and applications based on latency, jitter, loss, application type, network cost, you name it. It is an advanced decision tree. We call it the intelligent packet distribution engine. So, not only do I failover, but I have to morph all my QoS policies over to what’s left.
Kevin: Yes, good. Okay. So, we’re actually just over time, but we started a couple of minutes late, so… I’ve got a couple of last questions here.
TELoIP has got both the technology platform, you know, all the infrastructure pieces and everything else, and this nationwide TELoIP cloud infrastructure. Why are you selling exclusively through partners rather than going and offering SD-WAN direct to end user accounts?
Pat: Again, we built these tools internally. In the very beginning, when we started off, some of our reference accounts were direct, but that’s it. And we knew that we would be creating technology for the networking needs of tomorrow almost, you know, forever. We can predict that now. In fact, that’s who we are. So, we decided to focus on our core competency, and our core competency is building and defining networks in software. We evolved from the edge, which I still believe today is the battleground. That’s where things go awry. That last mile to the branch, that’s where your problems happen. But in order to evolve with the SD-WAN needs of the marketplace, we innovated and now perfected our Point-to-Multipoint over Unicast VxLAN control plane, which now gives you even more of a simplified yet robust experience between points-of-presence and points-of-entry, and gives you that full mesh experience between branches.
And we continue to innovate. There are technologies in our roadmap that go as far as QKD (Quantum Key Distribution) where we’re taking entangled photons… well, the vision is by 2020, taking the entangled photons and use them and use that new aspect of security to secure our overlays. I mean, this is what we do, and I can talk about this stuff all day long. But you know something? The vision is one of technology and delivery of great service, quality-of-experience through our partners to end customers, and it just helps us grow in scale. It was a business decision more than anything, but that business decision was based on what we know we can do and what we can do well.
Kevin: Okay, Pat. I think that’s a good point for us to end our session today. I’d like to thank everybody for sticking around. If you have any last-minute questions, please put them in the chat box, and I’ll take a quick look and see what we can do about answering them. Otherwise, thank you very much for attending, and we’ll see you on the next one.
One final, last question, Pat. How fast is TELoIP growing?
Pat: Very fast. The tsunami of an SD-WAN market has come our way, and we’re capturing it as best as we can. It’s an exciting time for TELoIP. It’s even more exciting that, we were able to take all of the existing technologies and patents that we’ve perfected and built and use it to compete rather well in this SD-WAN space. Thank you, Kevin.
Kevin: Thanks, Pat. And thank you, everybody, for joining us. And we’ll send a link back for the podcast recording of this shortly, and look forward to the next event that we have. And we’ll see you the next time. Thank you. Bye.
Pat: Thank you. Bye-bye.