# Transparent Redirections in Content Delivery Networks
## 3 SDN Based Transparent Redirection
### SDN Based TCP Session Handoff  
A TCP session is defined and uniquely identified by a 4 tuple, which is the source IP address, destination IP address, source port, and destination port. These values cannot be changed once a TCP session is established. The main idea of the proposed SDN-based transparent redirection is not to handoff the client's TCP session from the request router to the surrogate server but to synchronize two separate TCP sessions with each other (depicted in Figure 5). The two separate TCP sessions must be established before the synchronization--one from the client towards the request router and the other from the request router towards the surrogate server (steps 1 and 2). Once the TCP sessions are established, an HTTP request is expected from the client towards the request router (step 3). This request is modified and sent over the other TCP session from the request router to the surrogate server (step 4). At this point, the surrogate server starts sending a byte stream as a response to the request. This byte stream is however directed from the surrogate server directly to the client bypassing the request router, while the IP addresses and port numbers are rewritten to match the 4-tuple value of the initial TCP session (step 5). To make this solution work we must synchronize the sequence and acknowledgement numbers in the TCP headers too. Such modification could be implemented on a data plane as an experimenter action. The action must be able to increment these numbers to map the other TCP session's values. Once the sequence/acknowledge number reaches the maximum value of a 32 bit number, it overflows and starts from 0. Upon successful installation of actions to the data plane, the client consumes the response message from the surrogate server, which was originally generated for the request router (1 st TCP session), while the client \"thinks\" the response is coming directly from the request router (2 nd TCP session). In the end, to finish the handover procedure, the SDN controller must create reset (RST) or FIN messages to mitigate both sessions which were established with the request router. To be able to perform the handoff, we have to keep track of the existing TCP sessions in the network. This can be achieved by intercepting the initial TCP handshakes with the request router and the surrogate servers. The request router prepares a pool of established TCP sessions towards the surrogate servers, which are reused for the handoff. Once the client establishes a TCP session with the request router a valid HTTP request message is expected. From this point, the handoff procedure begins. The whole handoff procedure is depicted in divided into 4 parts. The solution is designed to work with the standardized HTTP 1.1 in unencrypted form [28]. In the 1 st part, the clients send an HTTP GET request including the URL and additional request headers. This request is sent to the controller (CNT) and then forwarded to the request router  
Figure 5: Transparent redirection. Once the full request is sent to the request router the controller blocks the communication from the request router towards the client (Flow Mod:1). The request router parses the request and reports the request size to the controller over the management WebSocket channel in a _setrequestsize_ message. This confirms the controller, that a full request was received (request might be fragmented into multiple packets). Once confirmed, the controller chooses a surrogate server, where the TCP session will be handed off (synchronized with). The request router queries this information in a _getmatchingsess_ message, which returns the TCP session parameters. Based on the returned information the request router modifies the request by updating the _Host_ header in the HTTP request. The size of the new request is reported again to the controller via the _setrequestsize_ message.