What is Direct Server Return & Why Does it Matter?

Direct Server Return (DSR) was introduced into the feature set of load balancers or Application Delivery Controllers (ADCs) to deal with a particular potential problem. The core design concept of load balancers is to distribute traffic load across clustered CPUs, RAM, network infrastructure and discs in order to increase network reliability and performance while introducing the benefits of redundancy. Incoming requests are assigned a Virtual IP address or VIP on the load balancer itself, and then the load balancer passes the request to the appropriate server with negligible modification to the packets. The server responds to the load balancer with the required data and then this is relayed onto the client by the load balancer.

Although this is a secure solution, there is a major drawback, which is that incoming requests can be small - for example 20Mbits - but replies are typically up to ten times bigger (200Mbits). As traffic needs to travel the load balancer on high traffic networks, the risk of the load balancer acting as a bottleneck rises considerably and network performance consequently suffers. Hence the requirement for DSR, which modifies the traffic flow by permitting the server to respond directly to the client, relieving the network load balancer of the need to handle the heavy traffic load.

The Drawbacks of DSR

• Backend servers have to crank up the amount of work that they must do, responding to health check requests with their own IP address and to content requests with the VIP assigned  by the load balancer.
• Cookie insertion and port translation are not able to be implemented.
• ARP (Address Resolution Protocol) requests must be ignored by the backend servers. If not, the VIP traffic routing will be bypassed as the backend server establishes a direct two way connection with the client.
• Application acceleration is not an option, as the load balancer plays no part in the handling of outbound traffic.
• Protocol vulnerabilities are not protected. Slack enforcement of Request for Comments (RFC) and incorrectly specified protocols are unable to be addressed and resolved.
• Caching needs to take place on the routers using Web Cache Communication Protocol (WCCP). This means a more complex network, an additional potential point of failure and greater latency due to an additional network hop.
• There is no way to handle SOAP/Error/Exception issues. The user receives classic error messages such as 404 and 500 without the load balancer having the chance to retry the request or even notify the administrator.

While you may be left scratching your head and thinking you would have to be nuts to use DSR at any time, there are applications where it is very suitable. From the introduction of network load balancers, DSR was identified as being an ideal way to handle UDP applications that deliver streaming of audio or video content through Real Time Streaming Protocol (RTSP).

In conclusion, as these are extremely sensitive real time applications, it is not sufficient to implement your load balancers, set up DSR algorithms and just sit back thinking that the job has been done.  You will need to carefully check the application performance on each server and assure you have tuned each component in your network to be performing as optimally as possible.