Specifications

MBG Engineering Guidelines, Release 8.0
9 Traffic Shaping
9.1 Overview
For small businesses with a simple setup to the Internet, sharing that upstream link between voice and data can
be problematic. Users in the middle of calls to the PSTN via SIP trunks, for example, will find the voice quality of
their calls greatly reduced if a member of the office were to suddenly start a large download from the Internet. To
mitigate these issues, MBG has the capability to prioritize the IP traffic that it is handling. This technique is
commonly known as traffic shaping.
To shape traffic, MBG must be in a position to handle all traffic to the organization’s upstream link; specifically, it
must be in gateway mode with a minimum of two network interfaces. In this mode, it can act as the
organization’s firewall. More commonly, however, the organization already has a firewall product of some kind,
and would like to deploy MBG and use traffic shaping with a minimum of disruption. This “transparent”
deployment is possible on servers with three network interfaces.
Using MSL 9.2+ the third interface can be put into bridged mode. The bridged interface can then be connected to
the WAN interface on the existing firewall. This configuration transparently places MBG between the existing
firewall and the WAN, and allows MBG to prioritize the organization’s traffic, without requiring changes to the
existing firewall.
9.2 Technical Details
Figure 13 below illustrates the queuing discipline that MBG uses for traffic shaping. The hierarchical nature of
the algorithm allows lower priority queues to use tokens available in higher priority queues, which means that
when little VoIP traffic is available, lower priority data will not be unnecessarily constrained. Thus, the customer
can make full use of their available bandwidth to the Internet.
The categorization of high priority vs. low priority traffic is performed based on two criteria:
1. Source IP Address If the source IP address of the traffic belongs to any of the network interfaces on the
MBG server, then it matches the first criteria. In other words, MBG must originate the traffic.
2. DSCP value The second criteria of high priority traffic is a DSCP value of 46 decimal, 0x2E hex
(Expedited Forwarding). This value must be set on packets that are considered high priority. MBG will
set the value for its own VoIP-related traffic.
If both of these criteria are satisfied, then the traffic ends up in the high priority queue. Otherwise, it is considered
low priority and will only be permitted through the HTB queue if the high priority queue has unused tokens.
This does mean that excessive high priority traffic can starve low priority data traffic. However, 10% of available
bandwidth is reserved for low priority traffic (if it is present), so it should not starve completely. This reservation
does not waste bandwidth: it can be “borrowed” by the high priority queue if no low priority traffic is present.
31