Transcript from TELoIP presentation at the Networking Field Day 15 event in Silicon Valley on April 6, 2016.
Jeremy: All right, perfect. So if you’re able to hear me, my name is Jeremy Milligan over here at TELoIP. I’m back in Toronto, Canada, and what I’m going show you guys today is just a, brief demo of aggregation, our pre-emptive fast failover, our quality of service bidirectionally, and also our bidirectional compression. Right after that, since I know we’re pressed for time, I’ll also see if we have time to go and take a whirl to our portal as well. So what we’re going take a look at today is, of course, the aggregation of multiple links, the failover, bandwidth, the intelligent packet steering, and our bidirectional compression, along with our quality of service.
So I’m just going give you a brief description of what we have here, the environment. So we have an Ai-600 VINO Edge CPE connected to three different circuits. Two of them are ADSL2 circuits and the third is an ADSL2+ or a fiber to the node circuit, and it’s a lot more speed as you can see. So I’m going to bounce out of the slide here and go straight into my desktop. So I know I just brought you to a new environment here. I’ll just briefly explain what you see in front of you right here. So at the top of the screen, we have prioritized traffic. Just below this traffic, we have another ping window that is a not prioritized.
Now, to the side of this, we have a speed test that I’ve just recently ran. Now, in the interest of time, I’m going to be turning on our compression. But in the meantime, I’m just going start up the speed test right now. So as we start the speed test, we can see that pure aggregation, that true aggregation of these three circuits. As we saw on the previous slide, we have a 4 meg circuit, a 9 and zero, 8 or 9 megabit circuit, and a 40 megabit circuit. You can see them all performing at subscribed speeds here.
Now, you’ll also notice that each of these three circuits has a different latency. So that third circuit, our largest circuit, has 5 milliseconds of latency. But yet, we’re still able to harness the 400 kilobits of traffic from the first two circuits and up to 4.5, all the way up to 5 megabits for that third circuit. So we ended up with an aggregated speed of 43.6 and 5.3 upload. So as Pat had stated previously, this is speed that clients can actually see when they go to speedtest.net. So now it’s time to enable our compression. I’m going turn on this bidirectional compression, and this is one of the few times that we will actually interrupt the client. So in a few moments here, you’ll see my links starting to disconnect as I turn on this compression.
Now, this compression typically yields, sometimes, 10 times the speed. Of course, with lower speed circuits, this impact can even yield higher than that 10 times figure. So as we reconnect here and we have all of our circuits reconnected, we’ll just wait for my ping window to start up again and for you guys to have an uninterrupted session there. So I’ll just wait and just watch on the other screen here. There we go. It looks like we are reconnected. So, now what I’m going do, I’m not going change servers here, I’m just going rerun this same speed test that is being run from speedtest.net.
Now, the speeds that we’ll see here are dramatically different than what we saw before. And, the speeds that we’re actually utilizing on the links, right now it looks like the speed test section is giving a little bit of trouble. I do have a backup just to the side here. So we’ll use that backup.
Pat: You might have to refresh.
Jeremy: So I’m going rerun the same speed test. And there we go. So now we’re seeing our actual compressed speeds within speedtest.net.
Pat: And it’s only consuming six meg.
Jeremy: Now, sometimes we see an excess of 200 megabits per second.
Pat: The actual consumption’s on the screen.
Phil: Oh, yeah. I see it. That’s…
Jeremy: And as you can see here, we are pretty solid at over 100 megabits per second. Now, this is not possible because we don’t have the links that are capable of this speed. We only have about 52 to 53 megabits across these three circuits. Now, sadly, the Ookla package on speed test and various other speed tests don’t have compressible upload traffic, so we don’t get to see the yields here for that upload traffic. But that traffic can be compressed. Really, anything that isn’t already encrypted or already compressed, we will compress, with the exception of voice over IP, of course.
All right, perfect. So now what we’re going to do is show our preemptive fast failover. So down below my screen here, what we have is link 1, link 2, and link number 3. So keep your eyes on those circuits as we start to failover this call. So Endre, if you could give me a count to 10. I’m going pull link number one when you count to three.
Endre: Okay, here we go. One, two, thre.. four, five, six, seven, eight, nine, ten.
Jeremy: Perfect. So we now have lost link number one. We lost a little bit of Endre’s number three there. And what I’m going do is ask Endre to just count to five. I’m going to put link number one back in and we’ll hear what a failback sounds like. So Endre, if you can give me a count to five, I’m going to put link number one back in.
Endre: Here we go. One, two, three, four, five.
Jeremy: Excellent, so that link came back in right around your four to five. I think there’s a bit of a delay between the audio and the visual that you’re seeing here. Now we’re going to do the same thing with link number two. So Endre, if you could give me a count to 10, I’m going pull link number two on your three.
Endre: One, two, three, four, five, six, seven, eight, nine, ten.
Jeremy: Perfect. So I’ve plugged link number two back in, but all we’re losing out of this voice over IP call is between 200 and 300 milliseconds of audio. We’re not even losing a full word. So now, finally, what we’re going to do is pull out the third link. So Endre, if you could give me another count to 10, I’m going to pull out link number three.
Endre: One, two… four, five, six, seven, eight, nine, ten.
Jeremy: Excellent. So I tried to pull it right at the beginning of Endre’s three there. So we lost just number three. But, of course, we never dropped the call and we only lost that 300 milliseconds or so of audio.
All right, perfect. So we failed over all three links, now what we’re going to take a look at is the QoS.
Pat: Hey, Jeremy, there was a question here. There was a question. Can you repeat what the links are, for the audience, their speeds?
Jeremy: Absolutely, absolutely. Let me just open that up for a second here. There we are. So these three circuits, they’re all DSLs. The first two, they’re ADSL2 circuits. So they’ve got, you know, 4 megs down, 8 megs down, but they’re only good for about half a megabit per second up. Now, that third circuit is an ADSL2+ circuit or a fiber to the node DSL.
Pat: Got it?
Pat: Thank you, Jeremy. Continue, please.
Jeremy: No problem, no problem. So, now what we’ll do is start putting…we’re just going to start putting a little bit of load on this line now. I’m going to download a couple of one gigabyte files here to get going in the background. Now, for those who might think we’re not actually having a real voice over IP call, what you’ll see here is a traffic dump, just for the technical audience to see that this is an internal phone that is reaching a third party PBX, so a third party voice over IP provider. And this is a call that we still have engaged with Endre.
So now what we’re going to do is do a failover test, but we’re also going put a little bit of load on the line. As you can see, we’re doing about 15 to 25 megabits per second to your download. Now, we’re going to do some more failover testing. So we’re just going to fail one link again. And I’m going to pick link number two, because it’s one of our worst. So Endre, if you can give me a count to 10, I’m going to pull out link number two on your three.
Endre: Okay. One, two, three, four, five, six, seven, eight, nine, ten.
Jeremy: Excellent. So we’ve lost link number two, and you can see as the traffic has diverted over to the two remaining circuits. As I plug this circuit back in, through an RJ45 port, we’ll see that circuit come up in just a few seconds here, and start taking on that traffic once more. So now that it’s back, it’s taking on about four to five megabits of these two downloads from HTTP.
All right, so that’s kind of our demonstration of the aggregation of our quality of service and our quality of experience there. So if we have time, Pat, let me know if yo
Pat: Actually, Jeremy, you know what, I want you to go straight to the portal. I’m not going to do the slides, so just continue, okay?
Jeremy: All right, sounds good. Now, I’ve dropped Endre off of the call here, just silently. But I’m going to jump over into the portal now. So what we have here is the dashboard. As soon as the user logs in, whether it be a customer or a carrier or a partner of ours, they’re going to be greeted with this screen.
Pat: Hey, Jeremy, one second. We’re a little behind.
Christopher: That portal looks great.
Jeremy: Okay, no problem. No problem. You can join me in two seconds here.
Christopher: I can see it.
Pat: Well, continue. You see it on your…
Christopher: I can see it on mine.
Jeremy: Excellent, excellent. So what you see here, I selected TELoIP and I’ve just…it’s an internal use here. This is, of course, not showing every single one of your clients. But what we have from here is just a view of the devices that we use internally for testing and for other employees that are traveling abroad. So what we can see from here is various points of presence that we maintain, and using the mouse over, we can always check the quality of experience for any one of these sites. Now, from Denver here, we can see out to all of our other points of presence and see the quality of experience.
Now, this quality of experience, as you can see down below here, it is very closely tied to a Mean Opinion Score. So with four to five being your excellent quality, and one to two being the poor quality. Now, what we’ll do here, is we’re going to move over to a dashboard view. So in this case, I’ve loaded up the device that we’re actually using for our testing today. And this is the device that we just performed our failover testing with, and we have these three DSL lines. And you can see here that 4 megs circuit, that 8 megs circuit, and the 45 megabit circuit. Each one has their own upload and we also have a little bit of reserved bandwidth for our voice over IP call. And as you can see, they have dramatically different latencies. We have link number two being one of the worst circuits of the three, with high jitter.
Now, down below here is where we have our quality of experience charts. Now, this helps troubleshooting immensely. It provides pretty much a reduction in troubleshooting…
Pat: Hey, Jeremy, you’re about two seconds…you got a two-second lag on us here, on this tether.
Jeremy: Okay, cool.
Pat: So keep that in mind.
Jeremy: No problem. I’m kind of watching on the other screen and it looks a little bit more than two seconds, so I’ll just give the screen time to reach there. So what you’ll see at the bottom of the screen here are three different graphs. We have our home PoP check, we have a voice over IP check in the middle, and a headquarters WAN check on the far right. So from here, we can eliminate nearly 90% of the troubleshooting time by using these graphs to determine if the Edge is healthy. So from this first graph on the far left in the bottom corner, we have our home PoP check. And this home PoP check guages the overall health of the Edge. So you can see when I was pulling out these circuits a little bit earlier today, we had a minor drop in quality of experience. And you can see that legend represented just above.
Now, if I ever want to check quality of experience directly from the site, using an in-band check, I can run the QoE check here. Now, what I’ve done already is just run a couple of example checks here, knowing that we would be a little bit pressed for time. Now, at the very top of this page, and I’ll move over to the next section here, I’ve moved into our VINO tab. And at the very top of these two pages, you’ll see system information here. And I’ll give you guys just a few seconds to get caught up, as I can see it’s just showing me the QoE check.
So once we’ve arrived to the VINO page, we have the CPE information once more, and the three link types, as well as their configuration. Now, in the top left, you have system information, the uptime of this particular hardware, you have the license and the service uptime, which is the SD-Internet that you see to the side here. Next up we’ve got our rate limit avoidance bandwidth. This is the total amount of bandwidth that the site has, and, of course, this is the combination of the three circuits down below. The compression, whether it’s been enabled for outbound or for inbound, is identified here.
Next up we’ve got our host availability. And I’ll stop here just for a second to explain that we’ve tied our portal directly into our network monitoring system. Now, in certain cases, this does away with the client’s need to monitor their own devices. In fact, they can do all their monitoring right from here. Now, this page goes into a lot of very cool details, a lot of which Pat has already been talking about with, the MDPS and the IPDE. So what we see here is the profile information. The fact that it has three links connected, our compression, our quality of experience, our keepalive, our firewall, and that capabilities, along with our rate limit avoidance on demand, and our MTU detection for lower links or underlay circuit.
Now, these underlay links and the way they’ve been configured here is shown. So we saw above the three circuits and their quality of experience and their latency and their jitter. But from here, we can see how they’re actually configured, through either DHCP client or statically. And what you see here is a private address, but it could very well be a public address. Down below here, that’s where we have our failover sensitivity for our multidirectional pathway selection. From here, we have figured 300 milliseconds for failover. Now, with circuits that have a lower latency, such as a fiber circuit, we can actually tune this down so that… a loss of a single circuit might even be indeterminable on a voice over IP call.
Down below this, we have our rate limit avoidance reservation, and our assurance. Now, I’ll turn this on for the G729 call that we’re having here today, 40 kilobits. Definitely should be enough. And we have our assurance turned on. But in the event of a link outage, we take this bandwidth that’s been reserved and spread it across our remaining links. Off to the side here we have our latency and jitter sensitivity, also known as our intelligent packet distribution engine latency and jitter avoidance. So this is the kind of backup to the multidirectional pathway selection to avoid links that may be prone to poor health or serious degradation.
So in this case, we are specifying a latency, jitter threshold that if any of these links pass this for too many times, we will time them out. We’ll push them away for 20 seconds silently and safely. We won’t actually lose a syllable or that 300 milliseconds on a voice over IP call.
Now, down below here, we have our quality of service rules and our quality of experience. From here, we configure and, monitor all of our different rules that we have setup for the client. Now, in this case, we’re providing inbound QoS by designating the host addresses for this voice over IP provider. Now, in the case of outbound, that’s very easy. We’re just performing the DSCP class prioritization here. Now, the two ping windows that I had up in the top corner, you can see how I was prioritizing that ping to the Google DNS server.
Now, at the very bottom of this page is where we have our quality of experience checks. So you saw three graphs on the previous page. This is where we can add additional checks. We can change the critical or warning thresholds for our network monitoring system directly from here, and we can add in QoE checks as we need. Now, finally, we have our overlay queue, which is off to the side. And as Pat explained already, this view of delay is of certain traffic that is not priority.
Now, next up, we’re looking at the graph. So from the graph, we have really a real time view. And I’ll wait for you guys to catch up there on the join.me view. So what we see here is usually about approximately one minute behind. What we’re actually doing, is at every single point of presence, we are bringing in Netflow traffic. So using the Netflow analyzer, we’re able to take a very neat look into how a customer uses our traffic.
Next up, we’ve got the top talkers here, as well as the top protocol reports. Just below here, we have the top ASN/BGP, and you can see the certain networks that we’ve been communicating most with here. Now, of course, we’ve been doing a lot of speed testing over to Rogers Communications here, but we also have Agnicorp, another name for TELoIP. Now, the next view we’ll look at here is a more detailed bandwidth view, and I’ll give you guys a couple of seconds just to get caught up there. On this next view, this is more for network operators, to take a look at how traffic is actually being used. But from here, we have that same bandwidth graph, and I’ll give you guys a couple of seconds just to get caught up. And just below that, we have packets per second, bytes per packet, sites and packets. It’s just different ways of looking how a customer uses their traffic.
Now, I’m going to move over to the next graph here, and just let me know if you need a few more seconds to get caught up there.
Pat: We’re good, Jeremy. Just go to the next. You got one minute…
Jeremy: Excellent, excellent. I’m sorry could you repeat that?
Pat: We’ve got about a minute left.
Jeremy: Got it, got it. I’ll speed along here. All right, so I’m going to take you straight into some of the configurable items, such as our route table, where we can add static configurations. The next view where we can completely modify all of the internal interfaces on this particular CPE. From here, we can add VLANs, we can add bridges and switches, as well as modify an internal interface.
The next view here is, of course, our advanced DHCP server. From here, we have hooked in to LLDP-MED to allow for automatic phone provisioning for a lot of our third party voice over IP provider partners. Down below here, we have the custom options and vendor devices, depending on how they setup their environment and how they deploy their voice over IP phones. As we move into the troubleshooting section within the CPE view, we have trace routing, ping functionality, amongst many other options here. We also have the ability to report voice over IP calls. We have the ability to analyze them, play them back at our heart’s content, to determine if a call was held in good quality from both ends. So if I pull up a call here, I’ve got a nice audio player down below with the quality of experience score, and I can even use Wireshark-like functionality from here to take a look at the SIP flow.
Next up, we got our speed testing functionality and our link analytics.
Pat: Hey, Jeremy…
Jeremy: From this stage, this is great for our partners because they’re able to see each individual link.
Pat: Hey, Jeremy…we’re going to pause…
Jeremy: I presume we are out of time.
Pat: Yeah, we’re out of time. We’re going to pause here. Thank you so much. You did a fantastic job. We appreciate it.
Jeremy: No problem.
Pat: Now, we have clips of all these demos, the portal and all of that available online. We’ll get them to you. And if you want us, we’d be more than happy to do another session remotely to show you any of these parts that we missed. I know we had a little bit of technical difficulties on the tether, and it took a few seconds for stuff to come in. But I think it gives you at least a starting point with TELoIP. Okay? Thank you very much, everybody. I appreciate your time.
Everybody: Thank you.
Justin: Thank you.
Pat: You’re welcome.
Tom: Any final questions?
Christopher: Yes, one quick question.
Christopher: Is compression normally not turned on?
Pat: It’s normally not turned on. You have to turn it on if you want it.
Christopher: Is there anyone who doesn’t want it?
Pat: So there is… Again, with technologies, there’s always limits, right. So, low speed, high latency…
Christopher: Certain links you might want it to be off, but other ones, you may want to turn it on.
Pat: High speed, high latency, you might not want to add it.
Christopher: Yup, perfect. Excellent, thank you.
Pat: You’re welcome.
Justin: Do you do reporting on QoS and what level of… Sorry, not QoS, compression. You’re reporting compression and how much compression you’re getting on…?
Pat: No, there’s a view where you can see the difference between the two, where we show you both the actual traffic and… Because he showed you, he logged in to the CPE because you get a more dynamic view…
Pat: But there’s also a visualization of that where you would see the actual use and then, you know, what your…the 100 meg that you saw and only 8 meg being consumed.