# Transparent Redirections in Content Delivery Networks
## 5 Evaluation
### Redirection Delay  
The redirection procedure on client requests imposes some delay. It is crucial to keep this delay as low as possible. In the next set of measurements, we evaluated the imposed delay for both transparent and 302 application layer redirection. In the first phase, we examined the delay in various networks. We prepared a linear topology over the network, where we attached several forwarders in line, and we attached a client to one and a surrogate server to the other side of the topology. We attached the content origin and the DNS server halfway between the client and the surrogate server. We have to mention, that in this case, the origin server is closer to the client; however, we wanted to measure the delay over a various number of hops when dealing with the handoff procedure. The topology is shown in Figure 10.  
On each request 7 flow mods are installed, and 2 extra Packet OUTs are made to mitigate the sessions on the core and the access forwarder together. On each forwarder over path, there are 2 flow mods. S1 (access forwarder) gets 2 flow mods, S(n) (core forwarder) gets 5 flow mods and each forwarder on the path get 2 flow mods installed. This sums up to:  
\[\text{FM\_SUM}=7+2(n-2) \tag{5}\]  
This Formula (5) applies only for the transparent redirection as the 302 redirection method does not go through the SDN controller, thus no path calculation and installation are needed. Flow modsare only installed if the client has not communicated with the surrogate before. This represents 2n flow mods. We made several tests on various sizes of the linear network (3, 5, 10, 30, 50, 100), and we measured the time required for the first bytes of data to arrive from the surrogate server to the client. Figures 11 and 12 show how the transfer delay is affected by the number of forwarders in the path. Figure 11: Start transfer delay—transparent redirection. Figure 12: Start transfer delay—302 redirection. Figure 10: Linear testing topology. The difference in the start transfer delay is significant. The 302 redirection is relatively constant; only the network itself imposes some delay. The transparent redirection's start transfer delay is increasing linearly with the number of switches. Based on the graphs and the formula above we can see, that the delay is imposed by flow mods that have to be installed to the network. If we put a trendline over the graph, we can see the linearly increasing complexity, which linearly increases the start transfer delay too. Such delay using transparent redirection is unacceptable. We further modified the SDN controller, where we enabled caching of the shortest paths from the surrogate servers to the clients. Once we installed a path between the client and the surrogate, we do not install it again. In such case, the delay affects only the first request if the client did not make any communication with the surrogate before. This solution significantly decreases the delay. With this approach we have to listen to topology changes, which are handled by the framework itself (Ryu) and trigger installed path recalculations. The delay of the 302 redirection remains unchanged as the redirection does not require any flow modifications. This redirection only communicates with the SDN controller's Northbound API when the closest surrogate server is chosen based on the client's location. Figures 13 and 14 show how the delay is affected when path caching is enabled. The delay is still increasing by the number of hops over the network, but the complexity of the transparent redirection turns constant once the first request from the clients is received. The delay of the first request is visible as a flying dot in the upper outlier for both transparent and 302 redirections. The delay  
Figure 14: Cached start transfer delay—302 redirection. Figure 13: Cached start transfer delay—transparent redirection. is caused by the network and by the server, which has to fulfill the received request.