Quality of Service Best Practices

QOS Best Practices - What is best practice ? Below is a Wikipedia definition of best practice. This apply to education as well. A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things, e.g., a standard way of complying with legal or ethical requirements.

Always classify and mark applications as close to their sources as possible.   Although in real life designs we may not be able to follow best practice network design due to many constraints such as technical , budgetary or political constrains, knowing the best practices is very critical for network design in real life as well as in the exams.  

Thus below are the general accepted Quality of Service Best Practices. I covered Quality of Service Best Practices and the many other technology best practices in the CCDE In-Depth which is my latest network design book.  

• Classification and marking usually done on both ingress and egress direction but queuing and shaping usually are done on Egress.
• Ingress Queening can be done to prevent Head Of Line blocking. Other wise, queuing is done almost in any case at the egress interface.
• Less granular fields such as CoS and MPLS EXP (Due to number of bits) should be mapped to DSCP as close to the traffic source as possible. COS and EXP bits are 3 bits. Thus you can have maximum 8 classes with them. DSCP is 6 bits and 64 different classes can be used. Thus DSCP is considered as more granular. This knowledge is important because when MPLS Layer 3 and Layer 2 VPN is compared, MPLS Layer 3 VPN provides more granular QoS as it uses DSCP instead of COS (Class of Service bits which is carried in Layer 2)
• Follow standards based Diffserv PHB markings if possible to ensure interoperability with SP networks, enterprise networks or merging networks together. RFC 4594 provides configuration guidelines for Diffserv Service Classes.
• If there is real time, delay sensitive traffic, LLQ should be enabled. Because LLQ is always served before than any other queuing mechanism. When the traffic in LLQ is finished, the other queues are handled.
• LLQ is the combination of CBWFQ (Class based weighted fair queuing) and Priority Queuing.
• Enable queuing at every node, which has potential for congestion. For example in Wide Area Network edge node, generally the bandwidth towards wide area network is less than local area network or datacenter, thus WAN edge is common place of QoS queuing mechanism.
• Limit LLQ to 33% of link bandwidth capacity. Otherwise real time traffic such as voice can eat up all the bandwidth and other applications suffer in case of congestion.
• Enable Admission Control on LLQ. This is very important since if you allocated a bandwidth which can accommodate 10 voice call only, 11th voice call disrupts all 11 calls. Not only the 11th call. Admission control for real time traffic is important.
• Policing should be done as close to the source as possible.Because you don’t want to carry the traffic which would be dropped any way. (This is a common network design suggestion which I give my clients for security filters). This is one of the most important Quality of Service Best Practices.
• Do not enable WRED on LLQ. (WRED is only effective on TCP based applications. Most if not all real time applications use UDP, not TCP)
• Allocate 25% of the capacity for the Best Effort class if there is large number of application in the default class.
• For a link carrying a mix of voice, video and data traffic, limit the priority queue to 33% of the link bandwidth.
• Use WRED for congestion avoidance on TCP traffic. WRED is effective only for TCP traffic.
• Use DSCP based WRED wherever possible. This provides more granular implementation.
• Always enable QoS in hardware as opposed to software if possible. In the campus environment, you should enable classification and marking on the switches as opposed to routers. Switches provide hardware based Quality of Service.
• Because 802.1p bit (COS bits) is lost when the packet enters the IP or MPLS domain, mapping is needed. Always implement QoS at the hardware, if possible, to avoid performance impact.
• Switches support QoS in the hardware, so, for example, in the campus, classify and mark the traffic at the switches.
• QoS design should support a minimum of three classes: EF (Expedited Forwarding)DF (Default Forwarding/Best Effort) AF (Assured Forwarding)
• If company policy allows YouTube, gaming, and other non-business applications, scavenger class is created and CS1 PHB is implemented. CS1 is defined as less than best effort service in the standard RFC.
• On AF queues, DSCP-based WRED should be enabled. Otherwise, TCP synchronization occurs. WRED allows the packet to be dropped randomly and DSCP functionality allows packet to be dropped based on priority.
• Whenever it is possible, don’t place TCP and UDP traffic in the same queue, place them in a separate queues.
• If the requirement is to carry end to end customer marking over MPLS Service Provider network, ask Pipe Mode Diffserv tunnelling service from the service provider. Uniform mode changes the customer marking thus customer needs to remark the QoS policy at the remote site. This creates configuration complexity for the customer.