D-Link NetDefend DFL-210 User Manual page 230

10.1.5. Priorities and Guarantees
"which traffic is more important?" problem.
The solution here is to create two new pipes: one for telnet traffic, and one for SSH traffic, much
like the "surf" pipe that we created earlier on.
First, remove the 96 kbps limit from the std-in pipe, then create two new pipes: "ssh-in" and "telnet-
in". Set the default precedence for both pipes to 2, and the precedence 2 limits to 32 and 64 kbps, re-
spectively.
Then, split 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 concen-
trate 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 "telnet-in" followed by "std-in". Set the priority assignment for both rules to "Use de-
faults from first pipe"; the default precedence of both the ssh-in and telnet-in pipes is 2. Using this
approach rather than hard-coding precedence 2 in the rule-set, you can easily change the precedence
of all SSH and telnet traffic by merely changing the default precedence of the "ssh-in" and "telnet-
in" pipes.
Notice that we did not set a total limit for the ssh-in and telnet-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 telnet-in pipes act as a "priority filter": they make sure that no more than the reserved
amount, 64 and 32 kbps, respectively, of precedence 2 traffic will reach std-in. SSH and telnet
traffic exceeding their guarantees will reach std-in as precedence 0, the best-effort precedence of the
std-in and ssh-in pipes.
10.1.5.5. Problems in Priorities and Guarantees
Guarantees are not just "guarantees". Guarantees and prioritized traffic work by limiting everything
that is not prioritized. How are these limits calculated? In each pipe, the limit of lower priorities is
calculated from the total limit, minus the current throughput of higher precedences.
Set a total limit!
Bandwidth in lower precedences will not be throttled until a pipe thinks that it is full, i.e. passing as
much traffic as the total limit states. After all, why should it throttle any sooner? If you have a 512
kbps pipe, passing 400 kbps of low priority traffic and 100 kbps of high priority traffic, there is no
reason to throttle anything, since there is 12 kbps of bandwidth left.
So, in order to know how much to limit lower precedences, the pipe needs to know when it is full; it
needs to know its total limit.
Your total limits cannot be higher than your available connection bandwidth
If pipe limits are set higher than the available bandwidth, the pipe will never know the connection is
full. If you have a 512 kbps connection, but total pipe limits are set to 600 kbps, the pipe will think
that it is not full. Therefore, it will not throttle the lower precedences.
Note
Here, the ordering of the pipes in the return chain is important. Should std-in appear
before ssh-in and telnet-in, theN traffic will reach std-in as the lowest precedence only
and hence compete for the 256 kbps of available bandwidth like any other traffic.
217
Chapter 10. Traffic Management