| Home Prev |  cOS Stream 4.00.03 Administration Guide
|
Next |
|---|
Traffic Shaping in cOS Stream
QoS architectures like DiffServ fall short if applications themselves supply the network with QoS information. In most networks, it is usually unwise to let the users of the network decide the priority of their own traffic. The network equipment must make the decisions concerning priorities and bandwidth allocation.The Clavister NetShield Firewall provides QoS control by allowing the administrator to apply limits and guarantees to the network traffic passing through the system. This approach is often referred to as traffic shaping and is well suited to managing bandwidth for local area networks as well as managing the bottlenecks that might be found in larger wide area networks. It can be applied to any traffic, including that passing through VPN tunnels.
Traffic shaping operates by measuring and queuing IP packets with respect to a number of configurable parameters. The principal objectives are the following:Applying bandwidth limits and queuing packets that exceed configured limits, then sending them later when bandwidth demands are lower.
Dropping packets if packet buffers are full. The packets to be dropped should be chosen from those that are responsible for the congestion.
Prioritizing traffic according to administrator decisions. If traffic with a high priority increases while a communication line is full, traffic with a low priority can be temporarily limited to make room for the higher priority traffic.
Providing bandwidth guarantees. This is typically accomplished by treating a certain amount of traffic (the guaranteed amount) as high priority. The traffic that is in excess of the guarantee then has the same priority as other traffic, competing with all the other non-prioritized traffic.
Traffic shaping does not typically work by queuing large amounts of data and then sorting out the prioritized traffic to send before sending non-prioritized traffic. Instead, the amount of prioritized traffic is measured and the non-prioritized traffic is limited dynamically so that it will not interfere with the throughput of prioritized traffic.
The Clavister NetShield Firewall offers extensive traffic shaping capabilities for the packets passing through a Clavister NetShield Firewall. Different rate limits and traffic guarantees can be assigned based on the traffic's source, destination and protocol.
The configuration objects used for for traffic shaping are as follows:
Traffic Shaping Profiles
A TrafficProfile object specifies which Pipe object or objects are to be used to shape traffic and in what direction. A TrafficProfile object can be used in one of the following ways:
One way to enable traffic shaping, is associating a TrafficProfile object with a TrafficShapingRule object. When the TrafficShapingRule triggers on the targeted traffic, its associated TrafficProfile is applied to that traffic.
Alternatively, a TrafficProfile object can be associated with an IP Rule object to enable traffic shaping. In this case, the profile is applied when the IP rule triggers.
It should be noted that an IPRule triggers and applies its traffic shaping before a TrafficShapingRule triggers for the same traffic and both can apply different types of traffic shaping to that traffic. In other words a TrafficShapingRule could add further shaping to that applied by an IPRule.
It should also be noted that it is also possible to use the same TrafficProfile with multiple rules so that the profile can be applied to different traffic flows.
It is also possible for a traffic shaping rule and an IP rule to trigger on the same traffic and for both to apply a different TrafficProfile and a different set of Pipe objects to the same traffic (the IP rule traffic shaping will always be applied first if this happens).
Pipes
Each TrafficProfile object has properties called the ForwardChain (outgoing traffic) and the ReturnChain (incoming traffic). Each of these chain properties is assigned one or more Pipe objects. Up to 8 pipes are allowed in one chain of a TrafficProfile object.
A Pipe object is the fundamental building block for traffic shaping and is a conceptual channel through which traffic can flow. Various properties can be set to define how traffic passing through it is handled.
Pipes do not care about the types of traffic that pass through them nor the direction of that traffic. They simply measure the aggregate data flow and then apply the configured limits for the pipe as a whole or the limits for Precedences and/or Groups (these concepts are explained later in Section 23.3, Using Precedences and Section 23.4, Grouping Users).
Hundreds of pipes can be handled simultaneously, but in reality most scenarios require only a handful of pipes. It is possible that dozens of pipes might be needed in scenarios where individual pipes are used for individual protocols. Large numbers of pipes might also be needed in an ISP scenario where individual pipes are allocated to each client.
Traffic Shaping Rules and the Traffic Shaping Rule Set
A TrafficShapingRule object has filtering criteria, similar to an IPRule, so it can trigger on a given combination of source/destination interface/network and a given Service.
TrafficShapingRule objects are added to the TrafficShapingRules object. There can only be one TrafficShapingRules object and this exists by default and does not need to be created.
As mentioned previously, an IPRule object can perform the same triggering function as a TrafficShapingRule object, providing an additional way of enabling traffic shaping. The IPRule traffic shaping will always be applied first if both trigger on the same traffic.
Explicitly Excluding Data from Traffic Shaping
Suppose that no pipes are assigned to a TrafficProfile object. Traffic that triggers an associated TrafficShapingRule or IPRule object will not flow through any pipes. It also means that the triggering traffic will not be subject to any other matching rules found later in the rule sets.This provides a means to explicitly exclude particular traffic from traffic shaping. Such rules are not absolutely necessary but if placed at the beginning of the pipe rule set, they can guard against accidental traffic shaping by rules that are lower down in rule sets.
