Lessons Learned from the Trenches Deploying O365 & SD-WAN
In this webinar, we discussed lessons learned and best practices from customers that have gone through the journey of deploying O365 and SD-WAN.
- Traditional networks significantly affect O365 performance, and how SD-WAN changes it
- Enterprises overlook the importance of strategically placing cloud gateways
- The tradeoffs among reliability, performance and user-experience when architecting the WAN for your cloud
Ramesh Prabagaran has a track record of bringing disruptive and innovative networking products to market focused on carriers and enterprises. Most recently at Juniper Networks, he was a senior product line manager establishing the product vision for enterprise and datacenter routing products, and WAN-focused solutions for Fortune 100 companies.
Lloyd heads the Global Marketing team at Viptela. He brings 20+ years of experience in technology and business practices to drive cutting-edge marketing strategies in B2B environments.
Lloyd: Thank you so much, Courtney. This is Lloyd Noronha. I head the global marketing at Viptela and we have an exciting presentation for you today. The reason why this presentation is important is we just want to go back a few months into the deployment of SD-WAN and why it’s relevant to O365. In the last 6+ months, we’ve seen and increasing amount of activity around cloud and SD-WAN. We’ve had customer after customer coming into us and saying “We want to improve our cloud and we are facing a problem doing it with our current network.”
Now, Office 365 in particular has taken a bulk share of that conversation because that’s the application that is getting to be most deployed and is facing particular performance challenges. Now, in order to dive into the issue a little more, we’ve picked up the recent Gartner report that was published two months back by Neil Rickard and Bjarne Munch covering this very specific topic, which is Office 365 and the network problems that surround it.
If you’ll peer into the paper a little bit, there are some very interesting stats that are quite representative from what we are hearing from our customers as well. the first stat is most organizations now, at least 78%, are in the process of deploying Office 365 or have already done that. The next important one are around performance. 20% of organizations are actually facing service performance challenges and a portion of them are actually facing availability challenges. Now, the paper clearly calls that both of these are very closely correlated to networking problems, so it indeed is a big concern when you have a SAS application that is being used across the organization and there is unpredictable performance or unpredictable availability. It has become a major concern.
Now, the concern is only going to get worse, because again, as the paper goes on to say, about half the global deployments will soon face a network-related problem in 2019. The reason is very simple; there is a clear correlation between the legacy network challenges that prevent cloud applications from performing well. Now, to dig into this a little deeper, I’m going to hand it over to Ramesh Prabagaran, who heads our product management team and we’re going to peer into specific reasons that we’ve heard our customers say about their Office 365 challenges. Ramesh?
Ramesh: Great. Thank you, Lloyd, and thank you for joining today, everyone. First and foremost, when we start conversations on O365 with our customers, we usually sense quite a bit of confusion. The first confusion is why is this relevant to the network? We have seen some data points in the previous slide as to why it’s relevant. The second one is just visually why is O365 and the wired area connected? Very simply, it is this. If you have skinny pipes going to your branch locations where a bulk of your employees reside, and you’re going to back‑haul traffic to a central location and then exit out to the internet, that invariably comes in the way of performance, which manifests itself as user experience issue, or some people call it the “Spinning wheel of death.”
It comes in the form of reliability issues and whatnot. Fortunately, we’ve had a few customers deploy this solution, i.e. take O365 as the anchor application to deploy SD-WAN. Here we are to talk about A; how should you be thinking about this deployment, and B; actually walk through a certain use case and an actual deployment from a very large food distributor in the US as well.
First, let’s demystify O365. If you think O365 is a single application, I’ll say we need to pause right there and start to think about the components of distribution. First off, you have Exchange, then you have SharePoint and then you have Skype and Yammer. They all provide different functionality, as we all know, but they also have very different network requirements. One of the things that you will absolutely have heard from Microsoft is you need to choose a single location, whether it’s for your mailbox or your data, if you’re an enterprise.
Even if you’re a really large global enterprise, you choose a single location where the bulk of your data resides. You need to know start to think about how am I going to access the data? For the geeky, network guy that’s inside of us, that means, “Hey, I need to architect my network so that I access that data efficiently.” What Microsoft recommends is exactly the opposite. Come into Microsoft as close as possible and I will take you to that data. So, there are some nuances in how you access the data itself that we need to be aware of. We’ll unravel this as we go. We’ll talk about the various options that you have to connect into Microsoft and hence access Office 365 as well.
The second big thing is really around latency. This is really an element that kills the experience. If you look here, across the four major applications, some are really stringent, like SharePoint requires less than 25 milliseconds of latency while some are not as much. With Yammer, that really doesn’t care so much about latency. You need to now architect the network so that it is latency-aware and latency-sensitive as well. Closely associated with that is loss. We all know TCP takes a big hit when you see a packet loss. The graph that you see here shows a dramatic change in throughput for TCP as the packet loss increases.
We see this on most TCP applications. O365 is no different either. The exception here is Skype. That inherently has [FAC] capabilities, forward data collection capabilities that can read out around packet losses and actually do some kind of [D Loop] and a bunch of other fast optimization so that the audio quality and the video quality is not affected. Once again, you need to care about data, you need to care about loss, you need to care about latency as well. One of the fundamental things that you would have heard already from Microsoft is you need to have internet access for O365.
This is required for a variety of reasons. Some for DNS, some for some of the cache content that you have, ongoing updates in the form of software downloads, and just simple access to the service itself. The big question here is really how do you architect the network? What are the requirements for the wired area so that O365 service is really, really good? Let’s do a quick poll here. We kind of want to understand where you are in your O365 journey, so we’re just going to do a very quick poll, and then we’ll be on our way.
You can see the results coming in. While we wait for that, and actually parse the information, let me know a little bit about, we talked a little bit about some of the lessons learned, as well. If you’re following the poll here, you can see many of you are already evaluating, some of you are in the pilot phase, very few are fully deployed and some not considering. This is, I would say, very typical of the set of customers that we talked to, and certainly we’ll share the results with the rest of the folks here as well.
Now, let’s get into the meat and potatoes of the session as well. First off, when you start to think of O365 and you have a traditional WAN, there are a few things you need to be aware of. This is basically a hurdle or a hindrance to deployment. The first one is cloud gateway itself. Today, you have internet gateways, but hardly anybody thinks about cloud gateways. Even though the difference may not be, just from a networking standpoint, it’s not as big, it has a big impact on the user experience.
If your internet gateway, if you’re an uber-regulated industry, if you belong in the uber-regulated industry and you have an internet exit out of your DMZ at just a couple of locations, then you possibly can get good experience if you’re accessing O365 through that. Again, there are options that you have to mitigate this, but just be aware that cloud gateways are important. Some customers have gone down the route of direct internet access straightaway from the branch, exited out. Some others, because of security reasons and compliance reasons prefer to aggregate at a certain point and then exit out of there as well.
Those are, again, some of the things that you need to be aware of. The next big thing is really about application awareness. Today, the traditional network is unaware of the application. An application here is not just a [ByTable] where you identify port and a protocol, but rather a transactional graphic. You need to know how Skype behaves, you need to know if it is Skype. Within Skype, is it audio, is it video, is it file share and is it exchange and so on and so forth? You certainly want the network to be application aware so that you can do a few things with it. As an example, many of our customers deployed policies that group applications like Skype and WebEx and whatnot and say that needs to get a less than 100 millisecond latency through the network.
Now, what that means is the LC1 infrastructure that you have can proactively measure lost latency jitter in real time and take some very interesting actions based on which applications it sees. There is an element of SD-WAN when you’re doing a pass optimization, you’re doing graphics tiering and so forth and there is also an element of application visibility that you need to be aware of. A few other things we have talked about already are really around high-latency bandwidth as well. We have seen many, many customers go down the path of deploying O365 where they have nothing but a T1 line going to the end customer location.
Now, that’s great if you have 2 to 3 people at the site. It’s not so great if you have 40 people of the site. We have run into circumstances where there were people who don’t show up to work because their email is extremely, extremely slow because everything goes over a single T-1 line. Needless to say, bandwidth is absolutely critical for you to monitor and measure and also plan for it as well. There are some tools that Microsoft gives you natively, but those are mostly around sizing to begin with. You also want to be able to get a real-time view into how that application is performing, what kind of bandwidth requirements do you see on a consistent basis and also kind of trend how this is going to grow over time as well.
Certainly, the next big one is really around regionalization and internationalization. We have seen there are some countries that have regulations around data addressed and data in motion and you want to be, certainly, conscious of that. You want to set up your cloud exit points and gateways so that you can actually conform to the client requirements posed by those countries as well. Then, as we talk about the solutions, we certainly address all of these things as well.
The one thing that we see consistently is security. Certainly at the application level, Microsoft gives you quite a bit of application-level security, role-based access control and a whole bunch of things around it. Now, from an access to the internet standpoint, that’s not a problem that Microsoft addresses. It’s actually a problem for the network to address. Certainly, again, very closely associated with where do you designate cloud, gateway or exit point, you also have to take care of security at those locations.
Once again, there are a few options that you have there. You have a cloud-based security solution, you can have a long-term solution. We’ll talk about those things as well. Finally, you need to be aware of how you want to consume this, especially as the network goes through a transformation, do you want to consume this as a service, or are you a do-it-yourself shop and you want to architect the network and consume this yourself. Depending on the level of proficiency of skills and people that you have, your options could vary as well. Now, again, those are all in the consolidated list of things that we have heard customers go through, and have seen the customers experience this as well, so we’ll bring all this together towards the very end after we talk about what options you have with respect to the solution as well.
Yeah. We are sharing the folders as well, so that you can see what that looks like. All right. Now, let’s go to the pictures here, and perhaps we’ll walk through some of the options here as well. First off, let’s take a picture. If you have access to Office 365, you have a secure SD-WAN fabric that provides access to that and you have branches, campus locations, data centers, whatnot. One of the options that you have, and the one that is the most simple to comprehend as well is direct internet access. Essentially, at the branch, if you have Internet access in addition to the, let’s say, an MPLS connection, then you do a split panel on the internet circuit and access Office 365 natively.
This is, again, Microsoft has enough of a presence, they make sure that once you exit out of the internet, that they can pick you up pretty quickly and then access the service. Now, there are a lot of elements around the last mile or the first mile here, the reliability that the ISP provides, how much bandwidth do you have, all of that comes into play, but this is kind of the easiest option for you to access Office 365. The second option, which gives you slightly better performance and reliability, and we’ll compare all of these as well in the next slide, is really around aggregating it regionally.
In this case, you would have a co-lo facility like an Equinix, where you can access all the traffic coming from branches belonging to a certain region, and there you can have an internet connection to Office 365. That internet connection can be like an IX connection, so it’s an internet exchange so that you’re an IX hop away from accessing the service. Or, it could just be regular internet and what you have done there is added the last mile availability. SD-WAN solutions from Viptela actually provides you the visibility so that you can get to the closest co‑lo, and the closest here could be, with respect to latency, with respect to loss and so forth, and you can get to the closest co‑lo and you can exit out to the internet right there.
Instead of dealing with availability and performance across each one of those sites, here you are able to optimally access a single location, and then only deal with the availability from that location going into Office 365. Most of the IX‑based connections optimize for that pretty well as well. The next one is actually taking it a little bit further and then actually using an express route as well. Here, at the carrier neutral facility, like a co‑lo, like an Equinix, you would have a peering arrangement with Microsoft through express route, whereby you will have a connection into Azure and also a connection into O365.
Now, the internet access required for that is also provided within the express route connection, and so you can access the servers that way. Once again, you can see that you’re going from a DIA model to an internet exchange model to a more reliable, robust, express outmodel as well. Each comes with its own set of challenges and trade-offs and we’ll expose that as well.
There are a couple of other options as well that are provided, some from the carriers who provide you with a cloud inter-connect solution, essentially from the MPLS PE, you can access O365 directly. That works, provided you are within the confines of a single carrier. Once you go hybrid WAN or SD-WAN, where you mix MPLS and internet together, those kind of models have different levels of complexity that you need to deal with. Finally, if you’re an uber-large customer with multiple 10 gigs of bandwidth going into Microsoft, then certainly you have a direct peering arrangement as well that you can explore.
Reliability here means, is it resilient to packet loss? Is it resilient to outages, brownouts, and so forth? At the same time, you should not overlook the last two columns either. First is the learning curve. We see a lot of customers embark on a SD-WAN journey and then bring in elements of Office 365 into the mix, but they completely overlook the fact that there is a bit of a learning curve here trying to make things work. I know simplicity is what SD-WAN provides, so by no means are we saying that this is going to be really complex, but you should just be aware of the nuances here to deal with, especially as he starts to talk about carrier neutral facilities, internet exchange points or express route connections, you want to be aware of how that works.
Is it a BGP connection into express route? Into Azure? If so, what device do I need to put connecting into that express route and so on and so forth. It’s just an element of complexity that you need to be aware of. Now, on an ongoing basis, you certainly want to make sure that you keep the staff of people who keep the lights on to a minimum so that the entire company or their entire IT staff is not just tasked with deploying and managing Office 365. That’s really where we see many of the customers make a very strategic decision as well. The DIA model, as you see, the level of complexity that is pretty simple, a lot of customers already do DIA for internet browsing traffic and so forth, and this naturally follows that path.
Certainly, it does come at the cost of security and reliability, and so the next model that you have is a regional hub model going to an internet exchange and then using an example of an IX connection to access Office 365. That seems to be a good middle ground where the amount of complexity in the learning curve is not as great. At the same time, it provides you very high reliability and security and gives you an optimal user experience as well.
There is no one-size-fits-all answer here. It really depends on the size, the footprint, the geographical spread of your customer, of your site base and so forth, but here are some of the ways you can think about it and some of the ways that you can go ahead deploying it as well. Now, I will click on security because through the whole deployment process with multiple customers, we have seen that this is an area of challenge for many customers. The choices here are really multiple.
So first off, you can have a cloud-based security type model whereby you have a branch that instead of putting a file in every single location, you can access a cloud-based security like a Zscaler and then access Office 365. That gives you a level of comfort that all your traffic is not just internet bound and you get all of the visibility and all of the other cool capabilities that Zscaler offers as well. If you do have and for structure already, so let’s say you do have a virtualized branch or you have firewalls as a policy before traffic exits out of the internet, again, that’s an option available to you as well.
Those are, again, to models that come right out of the gate for DIA type deployments. Now, you can also go to a co‑lo facility, as we spoke about, and then exit out to the internet. Then again, you have a choice of using cloud-based security or you can right-size your security firewall clients as well to access Office 365. The same thing is applicable to ExpressRoute, though we have seen if you’re going down the path of ExpressRoute and you do have an element of trust between the branch and the internet exchange, those are private connections and so you can actually eliminate the need for firewalls there, as well.
Once again, depending on the path that you take and depending on how you want to deploy this, you certainly want to be conscious of is it a cloud-based security model or an on-premise model? Certainly, within the SD-WAN infrastructure, the Viptela solution provides multiple capabilities so in that it’s really as simple as a single click. With a single click, you can access Zscaler and then exit out, or you can say, “I want to advertise firewall as a service into the network infrastructure and then service chain through that as well.”
The mechanics of how to get this to work is really simple, but you just need to be aware of the various things that go into the planning and deployment here. Now, let’s talk a little bit about the customer deployment as well here. This is a pretty large food distributor. Unfortunately, we are not at liberty to mention the name, but if I do I’m sure you will know. It’s a Fortune 500 food distributor. They started off their journey with a very simple network where they had multiple hundreds of branches, a couple of data centers, their exit point out to the internet was out of those datacenters. They had one primary MPLS vendor that provided them with roughly 4 to 6 megs of MPLS connectivity, and they also had a backup MPLS vendor that provided them with an RT1 line.
This is how they have been for over, I would say, about 5, 6 years, and they wanted to go down the O365 journey. Right off the bat, they started to deploy O365. They started a pilot and really quickly realized that skinny pipes really do not help. They had multiple types of branches, they had Class A, Class B, Class C. Class C actually had no more than a single T1 and a backup T1, actually. This is a location where they had roughly about 40 to 60 people in those branches.
The very quickly realized that O365 is not going to work. In fact, the CIO was hearing complaints about O365 deployment in the Class C site almost on a daily basis, to the point that they said, “You know what? I need to look at the alternative approaches here.” Just around that, also, they also had the Class B and the Class A. For the most part the Class A was good, but those were relatively fewer in number, just 20 to 25 different sites across a few hundred. Then, Class B and Class C were essentially the dominant ones. They said I need to now make my wired area network cloud ready. The first thing that they did was actually to bring internet into the mix.
At every single location, they said, “You know what? I’m going to longer-term transition from dual MPLS to a hybrid model where I’ll have a single MPLS provider and a really fat internet pipe and then augment that with 4G LTE for backup and diversity as well.” They brought in roughly a 50-meg internet connection into all their Class A and Class Bs and then roughly a 20-meg internet connection into their Class C locations as well.
Immediately, the security guys came in and said, “Hey, you know you cannot access the internet at every single one of these locations. Your network is heavily exposed and we need to put firewalls all over the place.” That’s when the customer started to look and said, “Okay, should I exit out locally using direct internet access at all the locations, or should I do a split tunnel, essentially, and do a DIA or should I do a split tunnel aggregate traffic at a co‑lo facility and then exit out from there as well?
The co-lo route was taking a little longer because of contracts involved and whatnot, so they initially said, “I will make sure that I can access Office 365 through a cloud-based security model,” and so inherently they had a pipe going into a cloud security provider and then exit out to O365 as well. They did a pilot across the seven sites, so all they did was actually deploy the Viptela infrastructure at the branches or at the sites, and then also add the head-in location and put in a very simple policy that said “For Office 365 IE identify the application using a DPI engine as Office 365. For that application, doing this order of priority.”
The first-order priority is due a split tunnel and exit out to Office 365. Do some level of [staple] inspection before traffic is sent out, so that it’s just Office 365 that exits out. All the other traffic actually still takes the default route into their head-ins because they didn’t want to change that too much. Now, in case there’s a problem with a split tunnel or the internet connection at the location, they had a backup policy that said aggregated or the other pipe that’s available, and then they had actually both MPLS providers.
Eventually they will phase one off, but today they have both of the MPLS providers and they put a policy in there that said across the MPLS providers, whoever gives me near-zero loss and gives me the less than 100 millisecond or less than 25 millisecond for some applications, then take that as the next preferred path. Essentially, they had an ordered list of priorities whereby they said the first priority is exit out of the internet. The next is aggregate to the datacenter provided my latency is bound, and once again this is where you have to be aware of the latency measurements.
It’s not just between the site and the datacenter, but it’s actually from the site all the way up to the cloud application. You start to think about your optimal user experience, you want to be aware of not just access to the internet exit point, but all the way up to the actual SAS services. Viptela can certainly provide you with all the tools and infrastructure and capability so that you can achieve that as well.
They did this pilot with a dozen sites. Very quickly, they realized the experience they measured in many cases up to 3 to 4X implement in performance right off the bat and then started to tune that as well so that they can get to much higher. Then, now, this customer is on a journey to actually deploy O365 across their entire infrastructure and also in the process deploy SD-WAN as well across the entire infrastructure. Those are, again, some of the things that we have heard as a consistent theme. I’m using the food distributor here as an anchor point, but it’s applicable to anybody that has a diverse footprint or just has skinny pipes that cannot make O365 work.
I just want to bring a few things together and then make sure that we have some time for questions as well. Then, we want to keep this really, really simple, right? First thing is you want to make sure that your network is cloud-ready. I cannot emphasize the importance of this, and if I were to create a list of all the customers that started O365 deployment without making the network cloud-ready, and have failed in the process, I think that would be at near 100%.
You want to make sure that your wired area is cloud-ready and certainly Viptela can provide the SD-WAN capabilities to make your network instantly cloud-ready. The second one is that you want to choose optimal exit points. You want to be aware of five things, actually. One is user experience, reliability, the amount of expertise required to learn about the technologies, especially if you do DIA versus internet exchange peering versus ExpressRoute and so forth, how should you be thinking about these things as well.
Then, certainly on an ongoing basis, you want to care about, if I do something for 10 size, is it going to scale for the next 500. Or, is it lenient, is it exponential, you want to really learn about the complexity involved that very simply the value that SD-WAN provides is you put a policy once, and that’s applicable if it’s one site or 1,000 site. That’s really the mechanism that you want to get to as well.
Then, finally, security. I cannot emphasize it enough. There have been many opportunities where O365 was meant to be delivered, deployed, all within a certain date, and invariably because of not thinking about security right at the start, the project invariably gets delayed as well. You want to be thinking about security. It should not be an afterthought. We leave that as takeaways and certainly open it up to questions as well before we move forward.
Lloyd: Wonderful. Thank you, Ramesh. We have a large set of questions. We’ll try to cover a few of them today and then the rest by email. The first question is a mixup of comment/question. It says, “We are using a proxy. It’s working okay, but you need to make certain that it is large enough to support your requirements. Also, Microsoft will always remind you of the proxy server and tell you it’s not recommended for use. Can you comment on the pros and cons of a proxy and to what extent will it fix the problem?”
Ramesh: Sure. That’s a great question. Typically, the way networks have been built is for anything that is bound to the internet, you have a proxy, you do some level of inspection there before traffic goes out. With the proxy, you have two things to take care of, right? One, is it a transparent proxy, or do you actually go change the end host themselves and point them in a certain way. What we have seen is that as long as you are using a transparent proxy, it is completely oblivious. You should be able to exit out of the internet, do some level of inspection and then go out.
Provided you need the extra level of security controls, if you can do without a proxy, certainly it would be beneficial because that’s when Microsoft can guarantee a certain level of SLA and end-performance as well, so you have those options. Now, if you are changing the destination IP of the actual application itself by putting client files and then forcing it to a certain proxy. Then, you do have to worry about some optimal routing there. It’s a much longer discussion, unfortunately, but we do have collateral that talks about it and then we’ll be happy to share more details there.
Lloyd: Thanks, Ramesh. The next question is about AWS and Azure. The question is as we are discussing the optimization for Office 365, how do you handle the fact that you also have AWS and Azure on your same network.
Ramesh: That’s a great question. Certainly, it comes only from somebody who was thinking about SD-WAN and wanting to make the network cloud-ready. This is actually one of the things that every single one of our customers goes through, right? O365 is the anchor application that causes them to think in this direction, but invariably they also have to think about IAAS, especially Azure and AWS as well. Interestingly, the solutions kind of diverge when you’re talking about SAS versus IAAS. Very simply, it’s this. In the SAS world, you cannot have an instance of your wired area inside the SAS infrastructure provider, while in the IAAS world, you can.
What I mean by that is in the Viptela technology, we have something called SOV Edge, which is a branch device. It actually provides all of the SD-WAN capabilities, and also the WAN router that talks to the external world. You can instantiate a VH inside Azure and inside of AWS and inherently extend your wired area into the cloud. Now, if you are within the confines of just IAAS and you’re thinking about just IAAS, that’s perfectly fine. Now, if you’re architecting the network so that you have intermediate points where you want to have security controls, you want to have reliability controls, and use that single location both for IAAS and for SAS, then you need to reasonably aggregate. That’s really where we see the dominant use case for regional peering.
Essentially, customers get a half-rack inside of Equinix, put some infrastructure gear in there, connect to one end of the gateway to IX. If they want to do ExpressRoute, then certainly have a cross-connect into ExpressRoute as well. Then that becomes the point where you decide whether you want to access IAAS through the front door or whether you want to use a direct connect or an express route as well. You have a few options. Interestingly, you make that decision for a cloud gateway or a cloud exit point once and that pays dividends multiple times over.
It’s not just for O365, not just for AWS or Azure. You use that for your Salesforce, you use that for multiple other CRM HR applications as well that are cloud-bound.
Lloyd: Thanks, Ramesh. The next question is more business-related. Do organizations normally include costs to network upgrades that are required for such cloud applications? How is this normally approached?
Ramesh: That’s a great question as well. Invariably, if all you’re thinking about is how do I roll out O365 and only think about it from a client and cloud standpoint, once again, you can roll it out but your experience is going to be pretty poor. To the extent that you’ll have to quickly come back and think about the wired area and cloud exit points and so forth. Our recommendation is if you’re going down this journey, at least be aware of the infrastructure network requirements that are involved.
Many of our customers have actually taken this as the opportunity to upgrade to SD-WAN capable infrastructure, and at the same time onboard Office 365 without breaking the bank. The interesting part about SD-WAN is the ROI offered pays within the calendar year and so you are able to make the economics of it work very easily.
Lloyd: Okay. So the next question is essentially on the slide that you displayed about latency, when you said latency concentration, did you mean latency requirements? Also, a rider to that question is, or the part about exchange, were you talking about cache mode or non-cached mode?
Ramesh: Yeah, so when I was talking about latency requirements from the standpoint of where can you see the most optimal experience. Now, certainly that is a recommendation that you have for the application itself, that the SAS provider will provide, in this case, Microsoft. Then, there is the realities of when you actually deploy, what should it be to get the most optimal experience. The slide was intended to cover what we have seen as working for our customers as well.
With respect to the cache versus the non-cache mode, certainly it’s a much more involved discussion around how much of real-time data do you have or what part of it comes from, let’s say, a CDN and so forth, if I understand the question correctly. We should certainly have an offline discussion around that as well.
Lloyd: Next question, Ramesh, is do the total number of users play a role in the selection?
Ramesh: Yeah. I’m inclined to say yes and no. Yes, because it has a dramatic impact on the bandwidth required as the number of users grow. It’s simple math, you multiply that with the average requirement per user, and so you need to right-size your network. From that standpoint, it is a yes. From a latency and user-experience standpoint, it’s a no, because once again, what you do for a 1‑meg file versus a 10-meg file does not really matter if you architect it right.
Lloyd: Wonderful. Next question is how many NAT entries can be supported by the Viptela Edge device towards Azure, knowing that 365 is a very chatty app.
Ramesh: Yeah, absolutely. This is where, again, when we say the underlying infrastructure needs to be application-aware, this is exactly what we’re talking about. As you start to talk about number of transactions, number of NAT entries and the timeouts required for each one of them, you want to make sure that you edge out your stale entries or look at a TCP reset and a TCP spin and then edge out those flows immediately. We have built a lot into the infrastructure so that this works across a multitude of site types. I mentioned the food distributor having Class A, Class B, Class C. In the Class C case, they had roughly about 40 to 60 users. In the Class B, they were averaging roughly about 200 or 250, and then in the Class A sites it was roughly about 800 to 1,000 people.
Naturally, there are flavors of devices that we provide so that you can right-size it for a certain application but needless to say, we provide a solution that works for all of these cases.
Lloyd: Last question is how does Viptela determine the performance to O365? On what basis are you selecting the best spot, since you don’t have an end point in the O365 setup, how are you doing that?
Ramesh: Yeah, certainly. I think that’s where innovation in the underlying network infrastructure comes into play, right? There are mechanisms that we can and we do use, so that our telemetry is not confined to just a pair of Viptela devices. Take the example of a site where I do a DIA so I can exit out of the internet directly, which means I’m on the internet, accessing Office 365 so there’s really no remote end that I can use to collect this information. That said, there is enough in the TCP and HTP stack that you can use to measure this telemetry, and then use that to make decisions. Now, that’s true if I’m doing a DIA, if I regionally aggregate, then I can use the telemetry information provided by the network in conjunction with the Telemetry 2, the remote end application, as well.
The short of it is we do measure end to end, so it is directly from the site all the way up to where the application is hosted. Our telemeter does not stop at the cloud exit point, if that’s the question.
Lloyd: Wonderful. That does it for the questions. With that, I want to say thank you so much to everyone for joining this webinar. We’ve had a strong attendance right to the very end and the questions were really good. The recording and slides will be available to everyone who’s registered, so if you don’t receive it in the next few days, please reach out to us and let us know. Thank you so much.
Ramesh: All right, thank you everyone. I know some of you this is early in the morning and late in the evenings and so forth, and you probably compromised on family time, so I hope this was well worth it and certainly look forward to chatting with a few of you again, as well. Thank you for attending the Viptela webinar and stay tuned for the next one coming soon as well.
Lloyd: Thank you.