# Transparent Redirections in Content Delivery Networks
## 2 State of the Art
### Existing Transparent Redirection Mechanisms  
The vast majority of communication over CDN happens using HTTP protocol, which is carried in TCP. To achieve a transparent redirection, TCP session handoff must be performed from the request router (or another node) to the surrogate server. This is challenging, as the TCP is meant to be a connection-oriented point-to-point protocol. [PERSON], [PERSON] and [PERSON] in IBM T.J. Watson Research Center already came up with an idea of handing off an existing TCP session from a load balancer to a content server in 1997 [11]. Authors in this report introduce the handoff mechanism of TCP sessions from the load balancer, where the initial TCP session from the client is established. After establishment, the clients send the HTTP request, which is examined and inspected by the load balancer, and based on the requested content, the TCP session is handed off to a content server, which has the requested content cached. The initial TCP session parameters between the client and the load balancer are passed to the cache server (windows sizes, various TCP options, sequence numbers) re-using the same TCP session parameters between the load balancer and the cache server. Once the session is handed off, the communication flows directly between the client and the cache server, while the IP address of the cache server is rewritten, to mimic the load balancer. It is not clear from the report, whether a working prototype was implemented or not. Authors also mention a different approach using T/TCP (Transactional TCP) where the initial HTTP request can be sent already in the 3-way handshake phase [12; 13]. This protocol is faster than TCP and delivery reliability is comparable to that of TCP. T/TCP suffers from several major security problems as described by [PERSON] [14; 15]. It has not gained widespread popularity and the protocol was moved to historic status in May 2011 by RFC 6247. Authors also mention in the report a commercial product by Resonate Inc., which adopts the same mechanism, which they call 'connection hop'; however, the product does not seem to exist anymore [16]. [PERSON] introduces an implementation of TCP handoff based on the FreeBSD kernel, which adopts the same concept of triangular routing depicted in Figure 3 mentioned earlier. In this implementation, the load balancer communicates with the content servers in the same way as in the previous prototype. The implementation is limited to FreeBSD and requires modifications to the content servers to make it work [17]. [PERSON] and [PERSON] in their report [18] exploit the mobility support of IPv6. IPv6 mobility allows binding the TCP session to a different host during the TCP session establishment procedure. In the initial phase, the client sends a TCP SYN packet to the request router, which chooses an optimal surrogate server for the given session. The TCP SYN packet is sent over an IP-in-IP to the surrogate server including an IPv6 binding update information indicating that the request router is the home address for this session. This mobility header tells the IP layer to update the source IP address with the home address field of the binding update (IP address of request router) in the SYN, ACK response, which is sent directly to the client. The client's TCP layer sees a packet with the source IP of the request router, thus allowing it to complete the connection [19]. This approach works only in the TCP session establishment phase, which means, the surrogate server cannot be chosen based on application layer information; however, it eliminates the need to use DNS based redirection. Furthermore, such a feature is allowed only in IPv6, while the vast majority of clients still use IPv4 [20]. [PERSON], [PERSON] and [PERSON] in their paper [21] did extensive measurements on live TCP socket migrations.