1 2 Previous Next 15 Replies Latest reply: Jan 23, 2018 1:45 PM by arteq RSS

    QoS Design Recommendations

    Juan


      There are different QoS tools that help us to achieve the same result in a given QoS design. This discussion brings together the principles of QoS design that help to match the right QoS tool to the right QoS design challenge.


      The next sections analyze the best QoS design practices for each QoS tool.


      General QoS Best Practice: Hardware vs Software

      Whenever possible, you should implement QoS policies in hardware rather than in software. This is a fundamental QoS design principle that every designer should apply.


      Devices that have dedicated hardware to perform QoS policies can execute more complex QoS policies on maximum traffic loads much faster than devices that process QoS in software. Therefore, implementing the QoS policies in hardware at much faster speeds results in a more efficient use of network resources and improves overall QoS performance.


      Classification and Marking

      Classification and Marking tools QoS best practices recommendations can be summarized as:


      • Classify and mark traffic as close to their source as possible.
        • Move the Classification and Marking to places in the network where that QoS is implemented in hardware.
        • As a general design recommendation, do not trust the marking performed by the application and do not trust marking at the network edge (unless the edge were administratively managed).


      • Use DSCP marking whenever possible.
        • Compared with Layer 2 marking protocols, DSCP provides 6 bits instead 3 bits, so it supports a greater marking granularity with up to 64 levels.
        • DSCP is standards-based. When the traffic is treated based in standards (standards-based DSCP PHB) there is a greater interoperability increasing the effectiveness of the policies even beyond the borders of the administrative domain.


      Policing and Markdown

      Regards to Policing and Markdown tools, the QoS best practices recommendations can be summarized as:

      • It is recommended to police traffic flows as close to their sources as possible, doing it by hardware (Hardware-based switches at the edge of the network is usually the best place to do policing whenever possible).


      • Whenever supported, markdown should be done according to standards-based rules (RFC 2597). For example: 
        • AF21 traffic:
          • Conforming -> remains AF21
          • Exceeding -> marked down AF22
          • Violating -> marked down AF23


      • Following such standards-based markdown has other advantages:
        • Other SP are going to follow these standards so we are going to achieve that end-to-end per hop behaviour.
        • Congestion management policies, such as DSCP-based weighted random early detection (WRED), can use these marks to drop priority traffic less aggressively than lower priority traffic when a congestion situation occurs.


      • Limit the transmit rate at the source to use the network resources more efficient and be sure that the traffic are not going to be dropped after entering the core of the network.


      Congestion Management

      As a general recommendation always enable queuing policies at every node that has the potential of congestion, even if the node is rarely congested.
      Other QoS design recommendations regards to queuing are:

      • Whenever possible, assign each application class to its own dedicated queue. This recommendation is the only way to provide an assured service level for a set of applications that have similar QoS requirements.


      • It is recommend using at a minimum four different queues so it can implement four-standard PHB at a minimum.


      • Use only platforms and/or service providers that offer a minimum of four standard-based queuing behaviours:
        • Real-time queue to support an RFC 3246 Expedited Forwarding Per-Hop Behaviour Service
        • Guaranteed-bandwidth queue to support an RFC 2597 Assured Forwarding Per-Hop Behaviour Services
        • Default queue to support an RFC 2474 Default Forwarding Per-Hop Behaviour  service
        • Bandwidth-constrained queue to support an RFC 3662 Scavenger service.


      Congestion Avoidance Tools

      To get into Congestion Avoidance Recommendations the next scenario is going to be assumed:

      • WRED will be assume as a standard-based congestion avoidance mechanism.
      • 4-Class Model Per-Hop-Behaviour with EF, AF, DF and the Less than best effort service as Scavenger class with 4 dedicated queues is assumed as a congestion management design strategy.


      With this scenario the best design practices regards to congestion avoidance tools are:

      • Enable DSCP-based WRED on Assured Forwarding (AF) queue.- So non priority traffic will be dropped more often than priority packets.


      • Enable WRED on the DF queue .- Enabling WRED with only a single marking to a class, all packets are marked to the same weight so there is actually no weight involved in drop decision but it helps to avoid or minimize the TCP synchronization and that increases the overall throughput of the DF queue.


      • Do not enable DSCP-based WRED on the EF queue. It is recommended do not enable it on a strict priority queue. That’s contradictory to the overall purpose of an EF service.


      • Do not enable WRED on the Scavenger queue. Any traffic is assigned to the less than best effort service so it is better to assure an efficient throughput on the scavenger queue rather than unnecessarily assigning additional resources to the scavenger queue taking into account that there is actually no service guarantee on traffic that is assigned to this scavenger queue.


      • Do not enable WRED on control traffic application class queues. If this traffic is under provision it is necessary to increase the bandwidth allocation for it and not try to optimize with WRED because this traffic is a traffic that is keeping the network alive.


      • Finally, an optimal recommendation is to tune WRED thresholds consistently. This best design practice is not necessary but it does provide additional consistency because assuring the same thresholds across different platforms is a way to get a very consistent implementation of the DSCP-based WRED. A good example that is illustrated in the next diagram would be:
        • Set the minimum WRED thresholds for AFx3 to 60% of the queue depth
        • Set the minimum WRED thresholds for AFx2 to 70% of the queue depth
        • Set the minimum WRED thresholds for AFx1 to 80% of the queue depth
        • Set the maximum WRED thresholds to 100% (tail of the queue)

       


       

      PHB QoS Model: Minimum QoS Queuing Capabilities and Recommendations


      As it was said, to guarantee an end-to-end QoS solution it is recommended to use only platforms and service providers that offer at a minimum of four PHB-standard-based queuing behaviours.


      The next table summarizes the additional minimum design recommendations for each of these four queues services with an EF, AF, DF and Less than best effort service as Scavenger class:



      Minimum QoS Queuing Capabilities and PHB Design Principles

      Real-Time queue.- RFC 3246 EF PHB

      Limit the amount of real-time queuing to 33% of link bandwidth

      Apply an admission control mechanism on this strict-priority queue

      Do not enable WRED

      Guaranteed-bandwidth queue.- RFC 2597 AF PHB

      Assign AF allocations according to traffic and application requirements

      Enable DSCP-based WRED

      Default queue.- RFC 2474 DF PHB

      Assign at least 25% of link bandwidth for the default class

      Enable WRED

      Bandwidth-constrained queue.-RFC 3662 Lower Effort per-domain behavior

      Assign minimum bandwidth to the Scavenger class queue

      WRED is not required



      The following diagram illustrates these previous minimum QoS PHB best design practices to preserve a end-to-end QoS solution:





      Summary

      The next table lists the QoS design principles that have been described in this discussion.



      QoS Recommendation Design Practices

      Principal

      Enable QoS policies in hardware rather than in software.

      Classification and Marking

      Classify and mark applications as close to their sources as possible.

      Use DSCP marking whenever possible to ensure interoperability.

      Policing and Markdown

      Police traffic as close to their source as possible.

      Mark down according to standards-based rules.

      Queuing

      Enable queuing policies at every node that has the potential for congestion.

      Assign each application class to its own dedicated queue.

      Use platforms and service providers that offer a minimum of four standards-based queuing behaviors: Expedited Forwarding; Assured Forwarding; Default Forwarding; Lower Effort per-domain behavior

      WRED

      Enable DSCP-based WRED on AF queue

      Enable WRED on the DF queue.

      Do not enable DSCP-based WRED on the EF queue

      Do not enable WRED on the scavenger queue

      Do not enable WRED on control traffic application class queues

      Configure WRED thresholds consistently

      WRED Thresholds

      Set the minimum WRED thresholds for AFx3 to 60 percent of the queue depth.

      Set the minimum WRED thresholds for AFx2 to 70 percent of the queue depth

      Set the minimum WRED thresholds for AFx1 to 80 percent of the queue depth

      Set all WRED maximum thresholds to 100 percent



      I hope you find it useful

        1 2 Previous Next