23.3. Using Precedences

Home Prev	cOS Stream 4.00.03 Administration Guide	Next

The Default Precedence is Zero

All packets that pass through Pipe objects have a Precedence. In the examples so far, precedences have not been explicitly set and so all packets have had the same default precedence which is 0.

A Pipe can have 8 Precedence Levels

Traffic flowing through a pipe can be assigned one of eight Precedences which are numbered from 0 to 7. Precedence 0 is the lowest priority and precedence and 7 is highest priority. A precedence can be viewed as a separate traffic queue. Traffic with a precedence of 2 inside a pipe will be forwarded before traffic with a precedence of 0. Traffic with a precedence of 4 will be forwarded before traffic with a precedence of 2.

Figure 23.2. The Eight Pipe Precedences

Precedence Priority is Relative

The priority of a precedence comes from the fact that it is either higher or lower than another precedence and not from the number itself. For example, if two precedences are used in a traffic shaping scenario, choosing precedences 4 and 6 instead of 0 and 3 will makes no difference to the end result.

Allocating Precedence to Traffic

The way precedence is assigned to traffic before it enters a pipe is specified by the PrecedenceMethod property of the TrafficProfile object associated with the traffic. This property can have one of the following settings:

Override

The traffic will always get the precedence level which is set in the PrecedenceLevel property of the TrafficProfile associated with the traffic.
PipeDefault

Each Pipe object has a PrecedenceDefault property that has a default value of 0. If a packet does not already have a precedence assigned, it will take the precedence of the PrecedenceDefault property for the first Pipe it passes through.

This method is the default value for the PrecedenceMethod property.

SetDefault

If a packet enters the first pipe in the pipe chain without its precedence level set, it will always get the precedence which is set in the PrecedenceLevel property of the TrafficProfile associated with the traffic.

The PrecedenceLevel property can have a value of 0 to 7 but it can also take a value of MapDSCP. A setting of MapDSCP means that the packet's DSCP bits will determine the precedence value. DSCP is a subset of the DiffServ architecture where the Type of Service (ToS) bits are included in the IP packet header.

	Note: The DSCP bits can also be set by traffic shaping
	Conversely, it is possible to set the DSCP bits of the traffic emerging from traffic shaping to the precedence of the last pipe that the traffic passes through. This is done by enabling the updateDSCP property of the associated TrafficProfile object.

Pre-assigned Precedence

In the above explanations, packets are described as possibly already having a precedence assigned. This can happen when both an IPRule followed by a TrafficShapingRule trigger on the same traffic. The IPRule is always processed first in this situation, so the packets processed by the TrafficShapingRule will already have a precedence assigned to them.

Specifying Precedences Within Pipes

When a pipe is configured, the properties PrecedenceDefault, PrecedenceMin and PrecedenceMax can be specified. The default precedences are:

PrecedenceMin: 0
PrecedenceDefault: 0
PrecedenceMax: 7

The PrecedenceDefault property specifies the precedence taken by a packet when the PrecedenceMethod property of the pipe's associated TrafficProfile object is set to PipeDefault.

The minimum and maximum pipe precedences define the precedence range that the pipe will handle. If a packet arrives with an allocated precedence below the pipe minimum then its precedence is changed to be the minimum. Similarly, if a packet arrives with an already allocated precedence above the pipe maximum, its precedence is changed to be the maximum.

For each pipe, separate bandwidth limits may be optionally specified for each precedence level. These limits can be specified in units of bits per second and/or packets per second (if both are specified then the first limit reached will be the limit that is used).

Precedence Limits are also Guarantees

A precedence limit is both a limit and a guarantee. The bandwidth specified for precedence is also a guarantee that that bandwidth will be available at the expense of lower precedence traffic. If the specified bandwidth is exceeded, the excess traffic falls to the lowest precedence. The lowest precedence has a special meaning which is explained next.

The Lowest (Best-Effort) Precedence

The precedence which is the minimum (lowest priority) pipe precedence has a special meaning. It acts as the best-effort Precedence. All packets processed at this precedence will always be processed on a "first come, first forwarded" basis.

Packets with a higher precedence than best-effort and that exceed the limit of their precedence will automatically be transferred down into the lowest (best-effort) precedence and they are treated the same as other packets at the lowest precedence.

In the illustration below the minimum precedence is 2 and the maximum precedence is 6. Precedence 2 is taken as the best-effort precedence.

Figure 23.3. Minimum and Maximum Pipe Precedence

Lowest Precedence Limits

It is usually not required to have a limit specified for the lowest (best-effort) precedence since this precedence simply uses any spare bandwidth not used by higher precedences. However, a limit could be specified if there is a need to restrict the bandwidth used by the lowest precedence. This might be the case if a particular traffic type always gets the lowest precedence but needs to have restricted bandwidth usage.

Precedences Only Apply When a Pipe is Full

Precedences have no effect until the total limit specified for a pipe is reached. This is true because until the pipe limit is reached (it becomes "full") there is no competition between precedences.

When a pipe becomes full, traffic is prioritized according to precedence so that higher precedence packets that do not exceed the precedence limit are sent before lower precedence packets. Lower precedence packets are buffered until they can be sent. If the buffer space becomes exhausted then they are dropped.

If a total limit for a pipe is not specified, it is the same as saying that the pipe has unlimited bandwidth and consequently it can never become full so precedences have no meaning.

Applying Precedences

Continuing to use the previous traffic shaping example, let us add the requirement that SSH and FTP traffic is to have a higher priority than all other traffic. To do this we add a rule specifically for SSH and FTP and set the priority in the rule to be a higher priority, say 2. We specify the same pipes in this new rule as are used for other traffic.

The effect of doing this is that the SSH and FTP rule sets the higher priority on packets related to these services and these packets are sent through the same pipe as other traffic. The pipe then makes sure that these higher priority packets are sent first when the total bandwidth limit specified in the pipe's configuration is exceeded. Lower priority packets will be buffered and sent when higher priority traffic uses less than the maximum specified for the pipe. The buffering process is sometimes referred to as "throttling back" since it reduces the flow rate.

The Need for Guarantees

A problem can occur however if prioritized traffic is a continuous stream such as real-time audio, resulting in continuous use of all available bandwidth and resulting in unacceptably long queuing times for other traffic types such as HTTP. A means is required to ensure that lower priority traffic gets some portion of bandwidth and this is done with Bandwidth Guarantees.

Using Precedences as Guarantees

Specifying a limit for a precedence also guarantees that there is a minimum amount of bandwidth available for that precedence. Traffic flowing through a pipe will get the guarantee specified for the precedence it has, at the expense of traffic with lower precedences.

To change the prioritized SSH and FTP traffic from the previous example to a 96 Kbps guarantee, the precedence 2 limit for the std-in pipe is set to be 96 Kbps.

This does not mean that inbound SSH and FTP traffic is limited to 96 Kbps. Limits in precedences above the best-effort precedence will only limit how much of the traffic gets to pass in that specific precedence.

If more than 96 Kbps of precedence 2 traffic arrives, any excess traffic will be moved down to the best effort precedence. All traffic at the best-effort precedence is then forwarded on a first-come, first-forwarded basis.

Additional Notes on the Best-Effort Precedence

Below are some notes about using the lowest, best-effort precedence:

Setting a limit on the best-effort precedence usually serves no purpose except for special cases where there is a need to restrict best-effort from exceeding the total pipe limit.
The sum of all the limits for the individual precedences does not need to equal the limit for the pipe. When the best-effort precedence has no limit, it is only the total limit for the pipe that will restrict the precedence.

For example, if all precedences have a 5Mbps limit and the total pipe limit is 10 Mbps, precedences are no longer a guarantee since that would require a total limit of 40 Mbps. In this case, precedence 7 and 6 will be able to claim 5 Mbps each at the expense of precedence 5-0, even though precedence 5 is not best-effort. If precedence 7 only uses 2.5 Mbps but precedence 6 is using its full 5 Mbps, then precedence 5 will be able to use the last 2.5 Mbps at the expense of precedences 4,3,2,1 and 0.
When some precedence levels are unlimited, the lowest precedence does not need to be one of them. For example, all precedences can be set to 5 Mbps, except precedence 6 which is left unlimited. The total pipe limit is 10 Mbps. If precedence 7 is less than 5 Mbps (or zero), then precedence 6 will still be able to claim all of the whole total limit (that precedence 7 has not already claimed) at the expense of precedences 5, 4, 3, 2, 1 and 0.
Another case is where precedence 0 has a limit of 0, and the total pipe limit is 10M. This pipe will now only prioritize traffic. Precedences 7, 6, 5, 4, 3, 2 and 1 will be involved in a direct competition with each other for the total pipe limit. Precedence 7 can claim the whole 10 Mbps, in which case nothing else goes through. If, instead, each precedence is trying to to claim 2 Mpbs each, precedences 7, 6, 5, 4 and 3 will get 2 Mbps each and precedences 2, 1 and 0 get nothing (precedence 0 will never be able to claim anything).

Differentiated Guarantees

A problem arises if the aim is to give a specific 32 Kbps guarantee to FTP traffic, and a specific 64 Kbps guarantee to SSH traffic. A 32 Kbps limit could be set for precedence 2, a 64 Kbps limit set for precedence 4 and then pass the different types of traffic through each precedence. However, there are two obvious problems with this approach:

Which traffic is more important? This question does not pose much of a problem here, but it becomes more pronounced as the traffic shaping scenario becomes more complex.
The number of precedences is limited. This may not be sufficient in all cases, even without the "which traffic is more important?" problem.

The solution is to create two new pipes. One for FTP traffic, and one for SSH traffic. This is much like the "surf" pipe that was created earlier.

First, remove the 96 Kbps limit from the std-in pipe, then create two new pipes: ssh-in and ftp-in. Set the default precedence for both pipes to 2, and the precedence 2 limits to 32 and 64 Kbps, respectively.

Then, split the previously defined rule covering ports 22 through 23 into two rules, covering 22 and 23, respectively:

Keep the forward chain of both rules as std-out only. Again, to simplify this example, we concentrate only on inbound traffic, which is the direction that is the most likely to be the first one to fill up in client-oriented setups.

Set the return chain of the port 22 rule to ssh-in followed by std-in.
Set the return chain of the port 23 rule to ftp-in followed by std-in.
Set the priority assignment for both rules to Use defaults from first pipe and the default precedence of both the ssh-in and ftp-in pipes is 2.

Using this approach rather than hard-coding precedence 2 in the rule set, it is easy to change the precedence of all SSH and FTP traffic by changing the default precedence of the ssh-in and ftp-in pipes.

Notice that we did not set a total limit for the ssh-in and ftp-in pipes. We do not need to since the total limit will be enforced by the std-in pipe at the end of the respective chains.

The ssh-in and ftp-in pipes act as a "priority filter" and they make sure that no more than the reserved amount, 64 and 32 Kbps, of precedence 2 traffic will reach std-in. SSH and FTP traffic exceeding their guarantees will reach std-in as precedence 0, which is the best-effort precedence of the std-in and ssh-in pipes.

	Note: The return chain ordering is important
	Here, the ordering of the pipes in the return chain is important. Should std-in appear before ssh-in and ftp-in, then traffic will reach std-in at the lowest precedence only and hence compete for the 250 Kbps of available bandwidth with other traffic.

Example 23.4. Traffic Shaping with Precedences

This simple example shows how the three protocols SSH, FTP and HTTP can be prioritized with different precedences through a single traffic shaping pipe with a capacity of 1 Gigabit/second. HTTP traffic will be given the highest precedence of 2, FTP traffic will be given the next highest precedence of 1 and SSH traffic will be given the best-effort precedence of 0.

It is assumed that flows will originate from wan_net on the wan interface with a destination of the server at the IP address my_server_ip on the dmz interface.

Command-Line Interface

First, create the Pipe object with the required limit:

System:/> add Pipe my-pipe LimitBpsTotal=1G

Next, create a TrafficProfile with a precedence of 2:

System:/> add TrafficProfile prec2-tp
			ForwardChain=my-pipe
			PrecedenceMethod=Override
			PrecedenceLevel=2

Create another TrafficProfile with a precedence of 1:

System:/> add TrafficProfile prec1-tp
			ForwardChain=my-pipe
			PrecedenceMethod=Override
			PrecedenceLevel=1

Create a final TrafficProfile for the best-effort precedence of 0:

System:/> add TrafficProfile best-effort-tp
			ForwardChain=my-pipe
			PrecedenceMethod=Override
			PrecedenceLevel=0

There is no predefined service object for SSH so create one:

System:/> add Service ServiceTCPUDP ssh
			DestinationPorts=22
			Type=TCP
			PassICMPReturn=Yes

Now, add the TrafficShapingRule objects that will filter the traffic. Change the CLI context to be TrafficShapingRules:

System:/> cc TrafficShapingRules

Add a rule to give HTTP the highest precedence of 2:

System:/TrafficShapingRules> add TrafficShapingRule
			SourceInterface=wan
			SourceNetwork=wan_net
			DestinationInterface=dmz
			DestinationNetwork=my-server-ip
			Service=http
			TrafficProfile=prec2-tp

Continue with a rule that gives FTP the next highest precedence of 1:

System:/TrafficShapingRules> add TrafficShapingRule
			SourceInterface=wan
			SourceNetwork=wan_net
			DestinationInterface=dmz
			DestinationNetwork=my-server-ip
			Service=ftp
			TrafficProfile=prec1-tp

The final rule gives SSH the lowest (best-effort) precedence of 0:

System:/TrafficShapingRules> add TrafficShapingRule
			SourceInterface=wan
			SourceNetwork=wan_net
			DestinationInterface=dmz
			DestinationNetwork=my_server_ip
			Service=ssh
			TrafficProfile=prec0-tp

Return to the default CLI context:

System:/TrafficShapingRules> cc
System:/>

Example 23.5. Traffic Shaping with Precedence Limits - Solution 1

This example repeats the scenario from the previous example but this time HTTP is to be guaranteed 85% of the 1 Gbyte pipe capacity, FTP is to be guaranteed 10% and SSH is to be guaranteed 5%. These are minimums so that, for example, in the absence of other traffic, SSH could use 100% of the pipe's bandwidth.

Note that the best-effort precedence of 0 is not assigned to SSH. It gets precedence 1 instead.

Note that with this solution, HTTP traffic that is above the 85% guarantee will compete at the lowest best-effort precedence of 0 on equal terms with any FTP or HTTP traffic that is also above its guarantee.

Command-Line Interface

Create a single Pipe object with the required limit as in the previous example but this time specify the limits for the 3 precedences that will be assigned to the different protocols:

System:/> add Pipe my-pipe
			LimitBpsTotal=1G
			LimitBps3=85%
			LimitBps2=10%
			LimitBps1=5%

Next, create a TrafficProfile with a precedence of 3:

System:/> add TrafficProfile prec3-tp
			ForwardChain=my-pipe
			PrecedenceMethod=Override
			PrecedenceLevel=3

Create another TrafficProfile with a precedence of 2:

System:/> add TrafficProfile prec2-tp
			ForwardChain=my-pipe
			PrecedenceMethod=Override
			PrecedenceLevel=2

Create a final TrafficProfile with a precedence of 1:

System:/> add TrafficProfile prec1-tp
			ForwardChain=my-pipe
			PrecedenceMethod=Override
			PrecedenceLevel=1

There is no predefined service object for SSH so create one:

System:/> add Service ServiceTCPUDP ssh
			DestinationPorts=22
			Type=TCP
			PassICMPReturn=Yes

Now, add the TrafficShapingRule objects that will filter the traffic. Change the CLI context to be TrafficShapingRules:

System:/> cc TrafficShapingRules

Add a rule to give HTTP the highest precedence of 3 with an 85% of capacity guarantee:

System:/TrafficShapingRules> add TrafficShapingRule
			SourceInterface=wan
			SourceNetwork=wan_net
			DestinationInterface=dmz
			DestinationNetwork=my_server_ip
			Service=http
			TrafficProfile=prec3-tp

Continue with a rule that gives FTP the next highest precedence of 2 with a 10% of capacity guarantee:

System:/TrafficShapingRules> add TrafficShapingRule
			SourceInterface=wan
			SourceNetwork=wan_net
			DestinationInterface=dmz
			DestinationNetwork=my_server_ip
			Service=ftp
			TrafficProfile=prec2-tp

The final rule gives SSH a precedence of 1 with a 5% of capacity guarantee:

System:/TrafficShapingRules> add TrafficShapingRule
			SourceInterface=wan
			SourceNetwork=wan_net
			DestinationInterface=dmz
			DestinationNetwork=my_server_ip
			Service=ssh
			TrafficProfile=prec1-tp

Example 23.6. Traffic Shaping with Precedence Limits - Solution 2

This example repeats the previous example, where HTTP is guaranteed 85%, FTP is guaranteed 10% and SSH is guaranteed 5%. However this time, the precedences of HTTP, FTP, and SSH decide how any available capacity above their guarantee is to be allocated.

To achieve this, a separate pipe is created for HTTP and another for FTP which will also allocate their precedences. These pipes are then fed into the main pipe which they will share with SSH traffic.

The precedences of 5, 4 and 3 will be initially assigned to HTTP, FTP and SSH. The precedences of HTTP and FTP will be given a minimum precedence of 2 and 1 by their associated Pipe objects. This means that when they exceed their guarantee and compete for any available bandwidth, their precedences cannot drop below these minimums. However, SSH traffic will still drop to precedence 0 when it competes for bandwidth beyond its guarantee.

Command-Line Interface

Create a Pipe object for HTTP:

System:/> add Pipe my-http-pipe
			LimitBpsTotal=1G
			LimitBps5=85%
			PrecedenceDefault=5
			PrecedenceMin=2
			PrecedenceMax=5

Create another Pipe object for FTP:

System:/> add Pipe my-ftp-pipe
			LimitBpsTotal=1G
			LimitBps5=10%
			PrecedenceDefault=4
			PrecedenceMin=1
			PrecedenceMax=4

Create the Pipe that the previous pipes will feed into:

System:/> add Pipe my-main-pipe
			LimitBpsTotal=1G
			LimitBps3=5%

Next, create a TrafficProfile for HTTP:

System:/> add TrafficProfile http-tp
			ForwardChain=my-http-pipe,my-main-pipe
			PrecedenceMethod=PipeDefault

Create another TrafficProfile for FTP:

System:/> add TrafficProfile ftp-tp
			ForwardChain=my-ftp-pipe,my-main-pipe
			PrecedenceMethod=PipeDefault

Create a final TrafficProfile for SSH with a precedence of 3:

System:/> add TrafficProfile ssh-tp
			ForwardChain=my-main-pipe
			PrecedenceMethod=Override
			PrecedenceLevel=3

There is no predefined service object for SSH so create one:

System:/> add Service ServiceTCPUDP ssh
			DestinationPorts=22
			Type=TCP
			PassICMPReturn=Yes

Now, add the TrafficShapingRule objects that will filter the traffic. Change the CLI context to be TrafficShapingRules:

System:/> cc TrafficShapingRules

Add a rule to for HTTP:

System:/TrafficShapingRules> add TrafficShapingRule
			SourceInterface=wan
			SourceNetwork=wan_net
			DestinationInterface=dmz
			DestinationNetwork=my-server-ip
			Service=http
			TrafficProfile=http-tp

Add a rule for FTP:

System:/TrafficShapingRules> add TrafficShapingRule
			SourceInterface=wan
			SourceNetwork=wan_net
			DestinationInterface=dmz
			DestinationNetwork=my-server-ip
			Service=ftp
			TrafficProfile=ftp-tp

Add a final rule for SSH:

System:/TrafficShapingRules> add TrafficShapingRule
			SourceInterface=wan
			SourceNetwork=wan_net
			DestinationInterface=dmz
			DestinationNetwork=my-server-ip
			Service=ssh
			TrafficProfile=ssh-tp