Traffic Shaping Overview

The traffic management mechanisms provided by the EdgeMarc are designed to ensure that high-priority, real-time voice traffic is processed before lower-priority data traffic. At the same time, bandwidth not in use by voice traffic is made available so that data traffic can burst up to a full line rate, making efficient use of WAN bandwidth.

Classifying

High-priority voice traffic generated by endpoint devices such as IP phones and client adaptors is identified by their IP address. The user configures these addresses into a priority list using the traffic-shaping features of the EdgeMarc VOS. As the EdgeMarc processes packets, they are marked as either high or low priority based on this configuration.

Upstream Traffic Management

The EdgeMarc uses a combination of class-based queuing and simple classless queuing to send data in the upstream direction. The class-based queue (CBQ) consists of two priority classes (high and low), a scheduler to decide when packets need to be sent earlier than others, and a traffic shaper to rate limit by delaying packets before they are sent. Voice traffic is placed in the high-priority class, and data traffic is placed in the low-priority class. High-priority data is sent at up to the configured priority data rate. This class is polled before lower-priority data to reduce overall latency for voice traffic. Although preferential treatment is given to priority data, it is bounded so that low-priority data is not starved. To smooth bursts from high-speed data links (typically from the LAN Ethernet segment to the WAN) the EdgeMarc uses a buffer that clocks data out at a rate not exceeding the maximum amount for the slowest link. Any lasting burst condition causes packets to be delayed and then dropped.

Downstream Traffic Management

In the upstream direction (LAN to WAN), QoS mechanisms are applied to voice traffic sent by the EdgeMarc to guarantee sufficient bandwidth. The EdgeMarc has control over how packets are handed to the WAN interface. In the downstream direction (WAN to LAN), the EdgeMarc is installed at the CPE end of a service provider link and has no control over the amount of voice or data traffic sent to the WAN interface.

Voice traffic quality is guaranteed by shaping the egress LAN and egress WAN ports of the EdgeMarc and leveraging the congestion avoidance mechanisms built into TCP to reduce the amount of data traffic on the link. Essentially, data packets received at a rate that exceeds the configured maximum are delayed (then dropped if necessary) when sent to the LAN interface by the EdgeMarc. Similarly, data traffic sent back to the EdgeMarc for transmission to the WAN is also delayed. This results in the end stations slowing down their transmit rate. This technique is effective because end stations usually reduce their transmit rate before VoIP signaling has completed for the new call setup.

Excessive UDP traffic must be shaped in the service provider network because UDP does not provide congestion avoidance mechanisms. The exception is RTP messages for voice traffic. Although RTP is based on UDP, the EdgeMarc provides its own congestion avoidance mechanism for voice traffic using CAC.

Basic Traffic Shaping

Traffic shaping in the system ensures that high-priority real-time data is processed before lower-priority non-real-time data. The VoIP ALG function identifies high-priority endpoint devices such as VoIP phones and automatically marks them as high priority. No user configuration is required.

To ensure that some bandwidth is available to non-priority traffic, the system enforces an upper limit on the 90-95% priority data rate of the slowest link rate. Priority data is bounded so that low-priority data is not starved. If low-priority clients are starved, they generate retries that may exacerbate congestion during peak usage periods.

Advanced Traffic Shaping

Advanced traffic shaping is available for use with MPLS-based virtual private networks. Advanced traffic shaping allows you to distinguish between up to eight different traffic classes. You can configure these classes to further prioritize traffic, using bandwidth specifications and rules that are applied to traffic flows.

Advanced traffic shaping uses the Differentiated Services Coding Point (DSCP) to distinguish between the priority classes. All priority classes can exceed their specified bandwidth if bandwidth is available. Otherwise, they are restricted to the bandwidth values assigned to them. When multiple classes exceed the bandwidth values assigned to them but the WAN link is not yet saturated, each class is equally allocated the remaining unused bandwidth. This continues until the WAN link becomes congested or saturated, at which point the throughput for any class falls back to its configured bandwidth.

If a class is not created for a DSCP value in use, all packets with that value are sent to the class that has a DSCP Best Effort value. CAC values for Primary and Secondary links specified on the Traffic Shaper page must not exceed the specified bandwidth of the class that is associated with the voice and video traffic.

ToS Byte Setting

Because the Internet itself has no direct knowledge of how to optimize the path for a particular application or user, the IP protocol provides a limited facility for upper layer protocols to convey hints to the Internet Layer about how the trade-offs should be made for the particular packet. This facility is the “Type of Service” or ToS facility.

ToS settings allow the service provider to prioritize time sensitive traffic, such as voice plus video to ensure minimized packet loss and delay through their network. When providing end-to-end QOS, it is important that the voice plus video traffic be placed in the correct queues to deliver a higher QOS than regular traffic. Regular traffic, that is not time sensitive, can be delayed with little or no indication to the user, while the slightest delay in voice plus video can cause audible differences. The ToS byte setting helps prioritize traffic going to the WAN so a provider can prioritize the traffic correctly in its network.

Although the ToS facility has been a part of the IP specification since the beginning, it has been little used in the past. However, the Internet host specification now mandates that hosts use the ToS facility. Additionally, routing protocols (including OSPF and Integrated IS-IS) have been developed which can compute routes separately for each type of service. These new routing protocols make it practical for routers to consider the requested type of service when making routing decisions.

For all RTP traffic (voice and video), the EdgeMarc marks the ToS byte in the IP header as “High Priority,” and strips (set to 0) the ToS byte for all other traffic. Un-checking the “Enable ToS Byte Stripping” option means that the ToS byte will not be stripped from non-RTP traffic but will remain unchanged.

For most situations, you should leave this setting as it is. Only change it if your provider indicates that you should do so.

Traffic Marking

While the Internet maintains no direct knowledge of how to optimize the path for a particular application or user, the IP protocol does provide a limited facility for upper layer protocols to convey hints to the Internet layer about how the trade-offs should be made for the particular packet. This facility is called Type of Service (ToS).

ToS settings allow the service provider to prioritize time sensitive traffic, such as voice plus video, to ensure minimized packet loss and delay through the network. When providing end-to-end quality of service (QoS), it is important that the voice plus video traffic be placed in the correct queues to deliver a higher QoS than regular traffic. Normal traffic that is not time sensitive can be delayed with little or no impact on the user, whereas the slightest delay in voice plus video can cause noticeable differences.

Although ToS has been a part of the IP specification since its inception, it has not been used extensively. However, the Internet host specification now mandates that hosts use ToS. Additionally, routing protocols (including OSPF and Integrated IS-IS) can now compute routes separately for each type of service. These new routing protocols make it practical for routers to consider the requested type of service when making routing decisions.

The Differentiated Services Code Point (DSCP) is the priority value that is encoded in the IP packet header. The DSCP value determines the level of preferred treatment that the packet receives as in travels through the network.

For all real-time transport protocol (RTP) traffic (voice and video), the EdgeMarc marks the ToS byte in the IP header as High Priority, and strips (set to 0) the ToS byte for all other traffic. un-checking the Enable ToS Byte Stripping option means that the ToS byte will not be stripped from non-RTP traffic, but instead will remain unchanged.

Call Admission Control (CAC)

CAC uses a deterministic algorithm to decide when there are insufficient network resources available to adequately support new calls and then return the equivalent of a “fast busy” to new call requests.

The EdgeMarc uses CAC to limit the number of active voice calls over the WAN link. This is necessary because a typical installation uses a ratio of 1:2 or 1:4 active voice calls to voice devices on the assumption that 50% or 25% of all users are on the phone at the same time.

These ratios are guidelines only, and at times the number of concurrent calls may exceed the amount of WAN bandwidth available to process the calls. In this instance existing phone calls will experience poor quality or be dropped altogether. To prevent this from occurring, a typical voice installation will set a threshold for the maximum number of concurrent voice calls supported by the WAN access link. New call requests in excess of this threshold will receive the equivalent of a “fast busy” and the WAN link will not become oversubscribed.

For IP Centrex installations the maximum number of concurrent voice calls is usually configured in the EdgeMarc by enabling CAC. When the EdgeMarc is deployed in IP PBX applications, the maximum number of concurrent calls could be configured in the IP PBX. If the PBX is responsible for this setting, you do not need to configure CAC in the EdgeMarc. Check with your IT administrator to determine if this is the case.

Determining the Maximum Number of Concurrent Calls

The maximum number of concurrent calls that can be supported by the WAN access link is calculated using the following formula: Max calls equals the Maximum WAN upstream bandwidth * .85/VoIP codec rate, where the maximum WAN upstream bandwidth equals the value entered in the WAN Upstream Bandwidth field (in Kbps).

VoIP codec rate equals 85.6 Kbps for G.711 voice devices or 29.6Kbps for G.729 voice devices.

The maximum WAN upstream bandwidth is multiplied by .85 in this formula to reduce the total bandwidth available for voice calls by 15%. This reduction is necessary because the EdgeMarc automatically reserves 15% of the total WAN bandwidth for low priority data traffic so that data traffic is not starved completely. Starving data traffic completely would increase the number of retry attempts and exacerbate congestion on the link during periods of peak usage. The following table describes WAN bandwidth calculation examples.

Maximum Calls Allowed with Call Admission Control

CAC uses a combination of values to determine the maximum number of calls to allow through the system:

• The maximum number of calls set in the license key.
• The maximum number of calls configured on the Primary and Secondary WAN.
• The maximum number of calls support by the hardware platform.

The number of calls allowed is the smallest and most restrictive of these values. For example, the system hardware supports 10 calls, the license key allows 5 calls, and the CAC value is set to 8. In this example, the system allows up to simultaneous 5 calls.

To enable Call Admission Control (CAC), first determine the number of calls that can be achieved through the WAN connection. If the codec is G.711, the required bandwidth per call is 85.6 Kbits/sec. If the codec is G.729, the required bandwidth per call is 29.6 Kbits/sec. The data rates apply in both the upstream and downstream directions. The smaller of the upstream and downstream rates should be used to determine how many calls can be supported.

For example, you have a DSL line with physical data rates of 768/128 Kbits. Enter 768 in the WAN Downstream Bandwidth field and 128 in the WAN Upstream Bandwidth field. If CAC is enabled and the codec used is G.711, the maximum number of calls supported is one call. In this case, the upstream bandwidth is the limiting value.

Another example is a T1 line with physical data rates of 1544/1544 Kbits. Enter 1544 in the WAN Downstream Bandwidth field and 1544 in the WAN Upstream Bandwidth field. If CAC is enabled and the codec used is G.711, the maximum number of calls supported is 15 calls.

CAC value when using H.323

H.323 calls use multiple RTP streams for each video call, typically around 6-12 streams. If CAC is enabled and H.323 is used, you must account for the total number of RTP streams that will be created. For example, if your endpoints typically use 8 streams/call, then to allow 3 H.323 calls the CAC must be set to at least 24.

Priority IP Addressing

VoIP traffic from devices that use the VoIP ALG function (for example, telephones, video stations, or softphones on PCs) are already marked as high priority and do not need to be manually configured in this list. This list is used to prioritize voice traffic from trunk interfaces of IP PBXs or other high-priority devices that do not use the VoIP ALG function of the EdgeMarc.

SIP Inactivity Monitoring

Dangling RTP occurs when a VoIP call completes but is not properly deallocated and torn down. Not properly tearing a call down can occur due to endpoint power failures, loss of Internet connection, or other abnormal behaviors. To the system, the call is still active (although it is inactive since there is no RTP activity) and the resources needed to maintain the call persist indefinitely. If CAC is enabled or the number of calls is limited by the license and the max number of allowed calls is reached, the system will prevent additional calls from being placed or received.

The SIP Inactivity Monitor periodically scans all calls and monitors RTP activity. The timeout setting is a timeout period of inactivity (no RTP traffic in either direction) for a SIP call before it is torn down and deallocated by the system. Be cautious of configuring a short timeout value since a call with both parties not speaking (on mute) and silence suppression disabled has the same characteristics of an inactive call: the call was not properly torn down by either endpoint and there is no RTP activity). Should both parties not speak for longer than the timeout value, the system will erroneously tear the call down. The default and recommended timeout value is 90 minutes.

Generalized Random Early Detection (GRED)/ Low Latency Queuing (LLQ)

To improve congestion management, the EdgeMarc supports Low Latency Queuing (LLQ) using Strict Priority Queuing (SPQ). LLQ allows high priority traffic to jump to the front of the queue to improve latency.

The assignment of a strict priority queue is dynamically assigned by the client registration process or by the client configuration process (configuration of a SIP trunking endpoint). Any traffic type may be configured to use the SPQ queue.

When LLQ is enabled, the strict priority queue (SPQ or Q1) is always emptied before all other queues. If multiple traffic policies/classifications are assigned to the strict priority queue, the EdgeMarc treats the packets within those traffic classes as first-in, first-out (FIFO). When LLQ is disabled, all configured queues use the standard priority queuing policies (up to 8) previously supported on the EdgeMarc.

GRED monitors the average queue size and drops packets based on statistical probabilities when a minimum threshold is reached. If the EdgeMarc sends more traffic than the uplink can handle, the second “maximum” threshold is reached and all traffic in that class is dropped.

The EdgeMarc can be configured to support up to eight classes of service. Depending on the number of traffic classes created, multiple classes can be assigned to the LLQ. This allows, for example, a media class and signaling to be assigned to the same high-priority queue. Any traffic classification created can be directed to any of the queues selected on the on the Network > Traffic Shaper > Advanced page. Refer to Configuring Advanced Traffic Shaping.

Traffic Shaper QoS CLI Statistics

You can now use line command to display QoS status output (statistics) about how the EdgeMarc is managing and processing QoS functionality.

The command line utility, trafficstats, prints information about how the traffic is shaped in your system.

When traffic shaping is enabled, multiple queues of a certain priority with an allocated bandwidth can be created to define the traffic flow. Advanced classification rules allow you to route traffic through a particular queue.

View traffic shaping stats in the following combinations:

• Traffic Policy Name
• Bandwidth
• Algorithm
• Sent packets
• Dropped packets
• Classification Rules