Solutions

Selecting a Resource Overload Action for my CacheFlow 5000 appliance

Solutions ID:    KB4362
Version:    2.0
Status:    Published
Published date:    04/04/2011
Updated:    06/20/2011
 

Problem Description

The CacheFlow 5000 appliance is considered "overloaded" when it cannot keep up with the incoming request load. Rather than fault or block transactions, it applies a "resource overload action" to handle the over-capacity load. This action is either "bypass" or "drop", and is configurable to suit the deployment in question.

What Resource Overload Action should be selected for my deployment: Bypass or Drop?

Resolution

The two overload actions are implemented as follows.

Bypass

When the system is critically overloaded, new incoming traffic is ‘bypassed’, that is, simply forwarded at layer 2. No caching or policy enforcement will occur, but user traffic is not affected. For most ISP deployments, this is a desirable failsafe for appliance overload. This approach maintains transparency of the deployment.

When the appliance recovers, new connections will again be handled normally, but bypassed connections will remain bypassed until those TCP flows complete.

Bypass mode ensures minimal consequences for end-user traffic. Generally there should be no increase in perceived latency for bypassed connections.

 

Drop

When the system is critically overloaded, the appliance drops connection initialization packets (TCP SYNs) for incoming new connections. Clients may eventually retry their connection request, at which point the appliance may have recovered. If the system has not recovered, the client requests will eventually timeout. In this scenario, overload will generally result in increased latency or outright interruption for end-users, but avoids the possibility that URL filtering or other regulatory policy might be bypassed. That is to say, the “drop” action is the only one that guarantees URL filtering. By selecting “drop”, the appliance will either filter all proxied traffic (when healthy) or drop all incoming traffic (when unhealthy).

In both cases, HTTP connections that were already in an established state when overload was entered will continue to be handled normally, though there may be increased latency if the appliance is severely resource constrained. That is, no established connections are subject to the ‘drop’, only new connections.

 

Recommendations

If the deployment is subject to URL filtering or other mandatory regulatory filtering, then “drop” should be used. In these cases, “bypass” would allow traffic through without the required filtering.

In all other cases, “bypass” is strongly recommended. Bypass mode is designed as ‘graceful’ mechanism for overload, with minimal subscriber interruption. For this reason, it is the recommended setting for all applicable deployments.

In CacheFlow OS version 2.x, to enable the Overload Bypass recommended configuration use the following commands:

#(config)general
#(config general)resource-overflow-action bypass

To enable drop on overload (for URL filtering)

#(config)general
#(config general)resource-overflow-action drop 


Rate this Page

Please take a moment to complete this form to help us better serve you.

Did this document help answer your question?
 
 
If you are finished providing feedback, please click the RATE CONTENT button. Otherwise, please add more detail in the following text box and then click RATE CONTENT.
 
 

Your response will be used to improve our document content.

Ask a Question