Guarantees; Differentiated Guarantees - D-Link NetDefend DFL-210 User Manual

10.1.7. Guarantees

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 the prioritized traffic is a continuous stream such as real-time
audio, resulting in continuous use all available bandwidth and resulting in unacceptably long
queuing times for other services such as surfing, DNS or FTP. A means is therefore required to
ensure that lower priority traffic gets some portion of bandwidth and this is done with Bandwidth
Guarantees.
10.1.7. Guarantees
Bandwidth guarantees ensure that there is a minimum amount of bandwidth available for a given
precedence. This is done by specifying a maximum limit for the precedence in a pipe. This will be
the maximum amount of bandwidth that the precedence will accept and will send ahead of lower
precedences. Excess traffic above this limit will be sent at the Best Effort precedence, behind traffic
at precedences higher than Best Effort.
To change the prioritized SSH and Telnet traffic from the previous example to a 96 kbps guarantee,
you set the precedence 2 limit for the std-inpipe 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.
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.

10.1.8. Differentiated Guarantees

A problem arises if you want to give a specific 32 kbps guarantee to Telnet traffic, and a specific 64
kbps guarantee to SSH traffic. You could set a 32 kbps limit for precedence 2, a 64 kbps limit for
precedence 4, and pass the different types of traffic through each respective 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 your traffic shaping scenario becomes more complex.
• The number of precedences is limited. This may not be sufficient in all cases, even barring the
"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, respectively.
Then, split the previously defined rule covering ports 22 through 23 into two rules, covering 22 and
23, respectively:
Note: A limit on the lowest precedence has no meaning
Setting a maximum limit for the lowest (best effort) precedence or any lower
precedences has no meaning and will be ignored by NetDefendOS.
410
Chapter 10. Traffic Management