In the last blog (/blogs/2013/07/11/up-leveled-queuing-for-the-applications/) we discussed various queuing mechanism in NetScaler and how we got the core system queue up leveled for client connection handling. There are clear benefits of moving the queue to vserver/app layer from individual services but what beyond that?

That’s a tricky question and it was in all our minds once we decided to up level the queue. The thought process was around the end user experience and related issues at Application layer. Now as we have the queue control at Application layer, we can apply L4 to L7 intelligence ensuring we deliver best quality of experience for the Application. We deliver the QoE by applying traffic shaping policies which helps control allocation of resources based on prioritization. Here is a quick summary of the benefits:

–          Prioritization of requests

–          Prioritization at Page level

–          Controlled resource allocation

–          Admission control for all clients

–          Protecting backend resources

–          Alternate content to keep client busy

–          Request processing information visibility

–          Advance expressions for traffic classification

–          Maintaining priority order across multiple connections

–          HTTP/L7  DDoS protection at Application layer

–          Built-in responses to mitigate against DoS attacks

–          Ability to generate custom response against DoS attacks

Traffic classification and priority evaluation is critical for AppQoE module to work. Thus as soon as the client connection lands on the vserver, bound AppQoE policies are evaluated and prioritization is done. This step happens even before the load balancing decision is made for the client. Based on the policy match, there can be two types of action. Assign the priority to the connection and en-queue. Or based on the threshold match generate response from NetScaler.

The response generated is pretty important based on whether you treat the request as possible DoS request or you just want to hold the request for required resources to get free. Following type of responses may be generated:

–          Response from Alternate Content Server (ACS)

–          Built-in response from NetScaler to delay request processing

–          DOS challenge response with Javascript to validate client

–          Serve content from custom response file on NetScaler

–          Do not take any action and drop connections to lowest priority

Most of the time you would notice that even after prioritization, page loads partially and some of the objects take much longer cycle. This is where application of priority at Page level becomes pretty interesting as it applies to all the objects and embedded links within the page. Thus you would see that the whole page along with all the objects loads fast which results into much better end user experience. Similarly responding to clients with dynamic response is also something cool because based on the backend resource availability NetScaler can take the configured action and let client know of the status or alternate content etc…

Most interestingly the ability to generate DoS response which requires run time user input always ensures that the client is genuine and there is no DoS threat. There is no way the script kiddies can generate the captcha based response based on the content shown in the web page. This is all generate dynamically and randomly thus mimicking the behavior is really challenging.

In summary, this new module will change the way customers do Application deployment today. It will empower NetScaler admins to use resources efficiently and generate smart responses to end users.