Of course, in thinking about moving the network functions from on premise to the cloud, there are important questions to be answered. The first question is, of course, how is the redirection implemented? The important consideration here is that we have to maintain the functional equivalence that we had in the network function chaining when we move to the cloud as well. And also, latency should not be inflated because of the fact that we are moving the network functions into the cloud. The second related question is how to choose the cloud provider to offload the functions to? And this of course, depends on the cloud providers geographical resource footprint in deciding, which may be the most opportune appropriate location to run the network functions for a given enterprise. Now, let's talk about the different options that we have for redirection of the network functions to a manage cloud provider. The first option is what is called bounce redirection and the simplest form of redirection. The basic idea is that, we will tunnel the ingress and egress traffic to the cloud service from the enterprise. And that way when the external traffic comes into the enterprise, it is bounced off to the cloud and it comes back to the enterprise, and we do the processing that needs to be done. And once again, once the processing is done, the enterprise gateway will send it to the cloud provider for the egress processing that may need to be done. And finally, we return the results back to the original external site that made the request in the first place. The benefit of this is of course, the fact that it does not require any modification to the enterprise or the client applications. The downside to this, of course, is the fact that there is an extra round trip to the cloud. As you can see that when the traffic comes in to the enterprise, I have to send it and then get it back, so there's a round trip involved in that. And similarly, when we're done with all the processing that needs to be done for the external request. Once again, the external request result has to be bounced off to the cloud, come back to the enterprise before it can be sent out to the client. It can be feasible, of course, if the cloud Point-of-Presence is located close to the enterprise. And here is just a snapshot of different cloud providers and the latencies from Georgia Tech campus. For example, the East US Cloud center for Azure is 24 milliseconds away from Georgia Tech, the intern terms of latency, and another one is 28 milliseconds. And on the other hand, North Central US in Illinois is 37 millisecond. So these are just to give you ballpark figures in terms of average latency that might be experienced because of the bounce redirection. The second approach to redirection is what is called IP redirection. In this what we are trying to do is we are trying to avoid the extra round trip by sending the client traffic directly to the cloud service before it hits the enterprise. So for this to happen, the cloud service that is serving the network functions for a particular enterprise will announce an IP prefix on behalf of the enterprise. And that way, when the client generates traffic intended for this particular enterprise, it'll automatically get routed to the particular cloud site, where the network functions will get evaluated. And then the processed result will be sent to the enterprise for further processing of the functional component of whatever the external query was. Now the drawback of this approach is the fact that a cloud provider have multiple points of presence. Now given that a cloud provider may have multiple points of presence, you cannot ensure that the same PoP. PoP is an acronym that is often used for Point of Presence, we cannot ensure that the same pop is gonna receive both the flows a through b and b to a. So that reverse traffic and the forward traffic, we cannot guarantee that it is gonna go through the same cloud provider. And the reason for this is simply because of the fact that the cloud provider is gonna advertise the same IP address range to a client. And therefore, the forward packets, just to make this illustration better, the forward packet may go through one PoP and return packet may go through a different pop for the given client. And this may not be something that is appropriate because we've talked about the fact that there may be flow affinity and connection affinity that may be there for certain network flows. And unfortunately, since traffic is directed using BGP protocol, there is no guarantee of selecting a PoP that minimizes the end-to-end latency also. So, these are the two main drawbacks. One is the fact that we cannot ensure that the egress traffic and the egress traffic will go through the same point of presence. The second is even the choice of the particular pop may not be something that the enterprise has control over. Because it's the Border Gateway Protocol that makes that selection of which PoP and therefore, we may not be able to minimize latency, even though that was the primary purpose of this IP redirection. So the third type of redirection is what is called DNS-based redirection, that is ultimately the preferred method for accomplishing what we wanna do. Here, what is happening is that the cloud provider runs a DNS resolution on behalf of the enterprise. By running the DNS resolution protocol, what the the cloud provider is doing is registering with a DNS server that it is the surrogate for a particular enterprise. Now any external site that wants to send traffic to the particular enterprise will do a DNS lookup of the enterprise. And it will automatically get redirected unbeknownst to the client to the cloud provider that is acting as a surrogate for the enterprise and the network functions will get run in this cloud provider. And the resulting packets will be sent over to the enterprise. And similarly, in order to come back in the egress traffic, we'll use the same IP address of the cloud provider that is provided by the DNS service. And that way, we can ensure that the egress traffic also goes through the same PoP and route to the final destination in this case, which is the external site that made the call. So to recap what this accomplishes, the cloud provider registers on behalf of the enterprise with a DNS. The external client looks up the DNS to get the address for the enterprise, which automatically goes through the cloud provider that is acting as a surrogate. So that the traffic will go through the cloud provider, and therefore, the network functions can be run in the cloud provider. And the enterprise will use the DNS service to determine the PoPs IP address, so that the egress traffic will also go through the same cloud provider back to the client. The drawback, of course, is the fact that there is loss of backward compatibility in that sense that there are legacy enterprise applications that may actually be exposing IP addresses to the external clients and not a DNS name. And that is a problem that can happen but given that the state of the art is DNS based redirection for internet traffic. That's the best way to do this redirection of the network functions as well. And just as a point of reference, what you do on your browser when you try to access cnn.com goes through the same kind of DNS base redirection. So that the traffic from a particular client will go to a mirrored site for a popular website like cnn.com, that may not be the origin website. So we are doing similar kind of technology adoption in DNS based redirection for network function hosting as well. Which solves the problem of making sure that the egress and ingress traffic to an enterprise can flow through the same cloud provider. So having talked about the different techniques that are available for redirection of traffic from the enterprise to the managed cloud infrastructure. We also have to worry about how to do the redirection, which is sensitive to the latency and that is what we mean by smart redirection. What we wanna do is, we wanna compute for each client c and enterprise e. What is the best PoP to use such that the latency going from the client to the PoP and from the PoP to the enterprise, the cumulative latency is minimized? In order to do this, the enterprise gateway has to maintain multiple tunnels to each participating PoP of the managed cloud infrastructure. And using the computed estimate latencies between PoPs and the clients and enterprises, using the IP address information that's available of the PoPs. One could come up with a way of optimizing this choice of the cloud PoP such that the latency end-to-end, from the client to the enterprise is minimized. And we put this together with a DNS based redirection that might be the best way to make sure that your network functions are hosted on the cloud infrastructure that best serves the enterprise's needs both in terms of latency. And in terms of keeping any flow and connection affinities. Needless to say, one has to worry when we do the redirection whether there's gonna be a latency inflation as the original latency is going from host one to host two. On the other hand, when we do this redirection, the inflated latency is gonna be going from the Host 1 to the cloud PoP, and then from the cloud PoP to the Host 2. Now, this graphic is a result that has been taken from a research paper that tried to see how much the inflated latency is compared to the original latency. And the way they did that was to run experiments on the PlanetLab which is a resource, it's available for networking switch. And in which they simulated different Amazon PoPs and found their own trip time inflation when redirecting their traffic between any two hosts using the PlanetLab. And what this is showing is the cumulative fraction of PlanetLab pairs and in terms of CDF and it is showing you for different redirection techniques what the observed latencies are. The blue line is for simple bounce redirection, and the green line is for DNS based redirection. And the red line is for DNS plus smart placement of the PoP in order to reduce latency. The interesting thing to note is that more than 30% of the host pairs have inflated latency less than the original latency. And the reason is because the triangle in that inequality is violated in inter domain routing. We think that you might be faster going from client to enterprise rather than going from client to the provider to the enterprise. But it turns out that the cloud providers are well connected to tier-1 and tier-2 ISP. And therefore, it might be that the redirected traffic through the cloud provider can get to the enterprise faster than directly going from the client to the enterprise. And that's the reason that in more than 30% of the cases, the inflated latency was less than the original latency. Which is sort of an interesting observation that as opposed to limiting inflation, the redirection may actually result in reducing the overall latency.
