---
title: "QoS"
canonical: "https://docs.aryaka.com/space/KNOW/1283784714/QoS"
format: markdown
---
Quality of Service (QoS) is a suite of technologies used to manage bandwidth usage as data crosses multiple networks. Its most common use is for protection of real-time and high-priority data applications. The following QoS tools are most commonly used to handle traffic: Classification—Identifies and marks traffic to ensure network devices know how to identify and prioritize data as it traverses a network. Queues are buffers in devices that hold data to be processed. Queues—Provide bandwidth reservation and prioritization of traffic as it enters or leaves a network device. If the queues are not emptied, they overflow and drop traffic. Policing and shaping are also commonly used QoS technologies that limit the bandwidth utilized by administratively defined traffic types: Policing—Enforces bandwidth to a specific limit. If applications try to use more bandwidth than they are allocated, their traffic is remarked or dropped. Shaping—Defines a software-set limit on the bandwidth transmission rate for a class of data. If more traffic needs to be sent than the shaped limit allows, the excess will be buffered. This buffer can then utilize queuing to priorities data as it leaves the buffer. While network level QoS is designed for UDP traffic such as real-time voice and video, it does not work well for TCP traffic. Typically, packet loss is the biggest performance problem for users of TCP applications (that is, transactional apps). Lost packets cause delays in things like mouse movements, onscreen data entry (typing), and issues with voice and image quality with collaborative programs (for example, MS-Lync). The impact of traffic loss on a TCP connection is a function of the Round Trip Time (RTT) of the link. At high RTTs, TCP performance is degraded significantly, and the problem gets worse when there are a large number of users on the network. This results in multiple TCP connections competing for the same bandwidth. TCP performs retransmissions to ensure reliable messaging, which cause unnecessary loss, degraded performance, and ultimately results in an “avalanche breakdown” that significantly affects the user's quality of experience (QoE). QoS does not help much in this case—in fact, QoS can actually induce packet loss by techniques like RED (also known as Random Early Discard or Random Early Drop), which is a mechanism to drop packets from the buffers before the buffers are full. Since Aryaka owns the edge router (last mile) and the core network (middle mile), Aryaka can remove the primary causes of packet loss. Aryaka never oversubscribes its bandwidth so there is never core congestion. In fact, Aryaka maintains a significantly higher amount of bandwidth than what is guaranteed to our customers. This allows for quick provisioning of additional bandwidth for customers when needed, and allows for customer  bursting  above their provisioned rates. Also, Aryaka uses advanced QoS features combined with TCP optimization to ensure high user QoE. The TCP optimization and compression tools ensure that critical applications do not suffer from high jitter, delay, or congestion due to peak usage. Aryaka QoS Details This section included detailed information about the following QoS traffic processing technologies: Scheduling and Queuing Marking and Classification Scheduling and Queuing Aryaka uses the Hierarchical Token Bucket (HTB) algorithm as part of its QoS implementation. HTB is used to create a hierarchical queue structure and determine relations between queues (priority, burst possibility, and so on). The HTB algorithm also shares the bandwidth between different classes of traffic using a scheme that allows certain classes to borrow bandwidth from other classes that are not using it. Marking and Classification Aryaka honors the marked packets that are coming to the ANAP device. Aryaka can also mark or remark packets on the ANAP. Marking and queuing takes place at the ingress of ANAP based on 5-tuple flow classification. The following five QoS queues/classes are supported on the ANAP—they are listed in decreasing order of priority: Real Time Mission Critical Transactional Productivity Best Effort You can map the TOS/DSCP values to any of these five classes. Unmapped TOS/DSCP fields go the Best Effort class by default. It is highly recommended that you separate the accelerated traffic from the pass-through traffic when defining class mapping. The different traffic types are processed as follows: TCP accelerated traffic is traffic optimized by the Aryaka TCP optimization engine. Accelerated traffic is organized into two classes Transactional class (high priority class) Productivity class (low priority class) Pass-through traffic is non-TCP traffic (for example, UDP, GRE, and ICMP traffic). Pass-through traffic is organized into two classes: Real Time class (high priority class) Mission Critical class (low priority class) All other traffic uses the Best Effort class The following table lists the recommended classification and traffic profiles: Class Name Priority Description Example Real Time (RT) Highest Requires low latency and has low bandwidth Critical voice UDP-based traffic that is latency sensitive is a candidate for high priority pass-through traffic. Mission Critical (MC) Medium Variable rate, variable size Video, voice signaling, and Routing protocols are candidates for low priority pass-through traffic. Transactional (TR) Medium Variable rate, short lived elastic flows Interactive database transactions, TCP applications that burst, Citrix VDI, and other applications that require quicker response times (user interaction) are candidates for high priority accelerated traffic. Productivity (PR) Medium High throughput data, bursty traffic Email applications, bulk data and file transfer over TCP/UDP, and sync apps are candidates for low priority accelerated traffic. Best Effort (BE) Lowest All other traffic types, and recreational traffic All other non-critical and recreational applications (for example, YouTube and Facebook). Aryaka offers reserve (guaranteed bandwidth) and limit (maximum bandwidth) per class. For any bandwidth not reserved, the highest class gets priority, followed by the next highest class, and so on (using the following priority order: RT, MC, TR, PR, then BE). Aryaka supports absolute priority between queues/classes. Consider the following three reserve and limit bandwidth allocation examples: QoS Example 1 The following five classes are each configured with a 10% reserve and a 100% limit. Class Reserve (Guaranteed Bandwidth) Limit (Max Bandwidth) Real Time 10% 100% Mission Critical 10% 100% Transactional 10% 100% Productivity 10% 100% Best Effort 10% 100% This means that the five classes are reserving 50% of the link capacity. If there is sufficient traffic in one of the classes such that it uses all of its reserves, then any excess from the other classes can be shared with the classes in need. The priority goes to the Real Time class first, after it has reached its peak, if there is any remaining capacity, the priority then goes to the Mission Critical class, which can use use the bandwidth or pass it to the Transactional class, and so on. QoS Example 2 This example uses the same five classes, but assigns a 20% limit to the Real Time class instead of 100%. Class Reserve (Guaranteed Bandwidth) Limit (Max Bandwidth) Real Time 10% 20% Mission Critical 10% 100% Transactional 10% 100% Productivity 10% 100% Best Effort 10% 100% This means that the five classes are still reserving 50% of the link capacity. The Real Time class gets any excess capacity until it reaches 20% of the link bandwidth (that is, until it reaches its limit). In this case, the remaining 40% is now available for the Mission Critical class to use. If after the Mission Critical class has reached its peak, and there is capacity remaining, it is made available to the Transactional class, and so on. We recommend having at least 10% reserve for each class, and setting the reserve value as multiples of 10 (10, 20, 30, and so on). Lastly, do not limit bandwidth for optimized traffic classes (PR, TR, and BE) when possible. Remember that the sum of all reserves need not be 100%. Rest is called  bandwidth remaining . Bandwidth remaining (after guarantees are met) is distributed in strict priority order based on class traffic (RT > MC > TR > PR > BE). QoS Example 3 This example only uses two of the five classes, and only assigns the Real Time class for VOIP, and the Best Effort class for everything else. Class Reserve (Guaranteed Bandwidth) Limit (Max Bandwidth) Real Time 20% 100% Best Effort 10% 100% As long as there is enough Best Effort traffic, VOIP traffic cannot go over 90% of the link bandwidth (because 10% of the bandwidth is guaranteed to Best Effort). Aryaka Class-based WAN Rate Control (WRC) Aryaka implements class-based WRC, which guarantees fair connection bandwidth control by monitoring end-to-end aggregate utilization for TCP traffic, and scaling back bandwidth usage without dropping packets. This helps when multiple TCP connections are competing for the same bandwidth. Aryaka also enhances the TCP performance by implementing two TCP priorities: high and low. The high and low priority queues are used only for accelerated TCP traffic. Aryaka observes all TCP sessions coming from all users that belong to the same customer and prioritizes the TCP sessions into high priority sessions and low priority sessions. High priority sessions get processed first based on the priority weight assigned to it. This significantly improves the user QoE. By default, Aryaka captures the TCP accelerated traffic from the Real Time, Mission Critical, and Transactional classes and classifies them as high priority sessions. These high priority TCP sessions get treated as one class (that is, they are placed in one queue). TCP accelerated traffic from the Productivity and Best Effort classes are classified as low priority sessions and they are placed in one low priority queue. Aryaka assigns 60% weight for the high priority queue and 40% weight for low priority queue for traffic that is processed by the Aryaka TCP optimization engine. These weights can be customized if needed, and these weights are based on the total number of sessions supported for a customer. Adaptive Quality of Service Aryaka supports Adaptive QoS for sites that deploy an Aryaka Network Access Point (ANAP) as an edge router. This feature can dynamically allocate more bandwidth to the internet when it is not used by Aryaka Network. For example, if Aryaka is using less than the guaranteed bandwidth and there is no network congestion, then Aryaka dynamically increases the internet bandwidth up to the configured link size. However, if traffic is going to Aryaka network, and there is congestion, then Aryaka uses its guaranteed bandwidth, and internet uses the remaining configured ISP link size bandwidth. When this feature is enabled, Adaptive QoS is configured to know each ISP’s size. It then determines what is available to the internet by calculating what is currently used by Aryaka Network, and then adding a buffer (known as  guardband ) to it. The remaining bandwidth is available for internet. The guardband is added to the Aryaka Network utilization to allow Aryaka Network’s utilization to grow quickly to the link bandwidth without having to compete with internet. Summary Aryaka uses advanced algorithms on TCP and UDP traffic to ensure high user QoE. The following is a summary of Aryaka QoS features: Aryaka leverages HTB. Aryaka honors the marked packets that are coming to the ANAP. Aryaka can also mark or remark packets on the ANAP. Marking and queuing takes place at the ingress of the ANAP based on 5-tuple flow classification. Aryaka can also use DNS-based classification to classify cloud service applications such as Salesforce or Office 365. DNS proxy must be enabled on the ANAP for DNS-based SaaS classification. Aryaka supports five queues. It is recommended to use two queues for pass-through traffic (high and low) and two queues for accelerated traffic (high and low). The five queues have absolute priority between them. Each queue gets reserve (guaranteed bandwidth) and limit (max bandwidth) parameters. For any bandwidth that is not reserved, the highest class gets priority, followed by the next highest, and so on through the following priority order: RT, MC, TR, PR, and BE. In this topic Related topics Manage QoS markings Manage QoS shaping Assign a QoS policy to a site Monitor VPN Path Aryaka QoS