# Transparent Redirections in Content Delivery Networks
## 5 Evaluation
### TCP Option Prerequisites  
The transparent redirection was not working in the beginning. Later we found out that some of the TCP options caused the packets to be dropped by the Linux kernel. Some of these headers had to be stripped off when they were sent through the SDN controller during the initial 3-way handshake:  
* TCP Timestamps: Timestamp Value (TSval) timestamps are carried in both data and \(<\)ACK\(>\) segments and are echoed in Timestamp Echo Reply (TSecr) fields carried in returning \(<\)ACK\(>\) or data segments, originally used primarily for timestamping individual segments, as the properties of the timestamps option allow for taking time measurements. The Timestamps option is important when large receive windows are used to allow the use of PAWS (Protection Against Wrapped Sequence numbers) mechanism. This option further enhances security by eliminating TCP session hijacking [38]. In the moment of the handoff, the TSecr field does not match the TSval of its peer, as this packet was generated by a different node. Stripping off this TCP Option made the \begin{table}
\begin{tabular}{c c c c} \hline
**Domain Name** & **Record** & **IP/Domain** & **Node** \\ \hline dns.dzip.bt & A & 10.11.0.99 & DNS server \\ rr.dzip.bt & A & 10.11.0.100 & Request Router \\ se1.cdn.dzip.bt & A & 10.11.0.11 & Surrogate 1 \\ se2.cdn.dzip.bt & A & 10.11.0.12 & Surrogate 2 \\ origin.dzip.bt & A & 10.11.0.99 & Origin \\ www.dzip.bt & CNAME & origin.dzip.bt & Origin \\ cdn.dzip.bt & CNAME & rr.dzip.bt & Request Router \\ \hline \end{tabular}
\end{table} 
Table 2: Configured domain names. handoff work. This option could be synchronized via the control plane too, as during the handoff procedure the packets are traversing through the SDN controller. * TCP Selective Acknowledgement Option (SACK): TCP may experience poor performance when multiple segments are lost from one window of data. With the limited information available from cumulative acknowledgments, a TCP sender can only learn about a single lost packet per round trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been successfully received. A Selective Acknowledgment (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations. The receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments [39]. After the handoff, endpoints would see ranges in incorrect values. This could be solved by implementing the incrementing feature of this TCP option too. However, such a feature is challenging, as the order and the position of the TCP options are not fixed in the TCP header. Currently TCP SACK Option is stripped off during the 3-way handshake by the SDN controller. * Window Scale Option: The three-byte Window Scale option MAY be sent in an SYN segment by a TCP. It indicates that the TCP is prepared to send and receive window scaling and communicate the exponent of a scale factor. The value of the Window Scale option cannot be changed on an established connection [38]. Window scaling option might be problematic when synchronizing different TCP sessions. When a handover is done via the TCP_REPAIR, initial TCP options are synchronized too, which will not happen when two sessions are synchronized with each other. We run several tests and found out when the actual WSCALE is different from the negotiated value the connection control might have issues correctly setting the window sizes, which can end up in a stalled connection. This might happen if the WSCALE TCP option is different on the client and the request router. This issue could be fixed by pre-establishing a pool of TCP sessions towards the surrogate servers using various WSCALE options and choosing the TCP session when doing the handoff, which matches the WSCALE option of the client. This will ensure, that the negotiated WSCALE value is going to be the same even after the handoff.