Amer Networks E5Web GUI - Manual (Page 668)

Lowest Precedence Limits
It is usually is not needed 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 the pipe is full, traffic is prioritized by cOS Core according to precedence with higher
precedence packets that do not exceed the precedence limit being sent before lower
precedence packets. Lower precedence packets are buffered until they can be sent. If 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
Telnet traffic is to have a higher priority than all other traffic. To do this we add a Pipe Rule
specifically for SSH and Telnet 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 Telnet 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 services such as surfing, DNS or FTP. 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 Telnet 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 Telnet 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.
Chapter 10: Traffic Management
668