A Quick QoS Primer - Part 1

Discussion in 'Articles' started by eric_stewart, Jan 1, 2007.

  1. eric_stewart

    eric_stewart Super Moderator Staff Member Member

    A Quick QoS Primer - Part I

    A Quick QoS Primer - Part I of II - © Eric Stewart, all rights reserved
    With emphasis on classification and marking

    No part of this document may be used without the express written consent of Eric Stewart

    This is by no means an attempt to go into deep technical detail of QoS mechanisms, strategies, algorithms and terminology. If you are already a sophisticated QoS expert, some of the analogies and points will probably offend you with their simplicity. That said, the points that are made in this short primer are intended to give a good overview of some of the important terminology and technology involved in an end-to-end QoS solution to the beginner (but technical) reader. The perspective is deliberately skewed towards the SOHO user, though it dabbles in some service provider concepts as well. It finishes with a simple case study of a SOHO VoIP solution and deliberately leaves the reader hanging on the edge. The provider edge that is! The end of the story…which is really the middle of an end-to-end QoS solution….will wait for another day.

    The terminology is largely taken from the RFC which defines and describes DiffServ terminology. RFC 2475 defines “an architecture for differentiated servicesâ€. It can be found at http://rfc.net/rfc2475.html and is only a Google away for more information. The AF PHB (guess you’ll have to read on to know what that acronym soup means!) is defined in RFC 2597 and can be found at http://rfc.net/rfc2597.html among other places.

    The Need for QoS
    • From a customer’s perspective, QoS can be summarized as the ability of the service provider to maintain a level of service which will support their data networking needs in an acceptable manner.
    • “Acceptable†is defined in the service provider’s Service Level Agreement (SLA) with the customer.
    • Metrics are used to measure compliance with performance targets in the SLA.
    Adding to the debate and according to research conducted by Forrester Research’s Robert Whitely, December 16, 2005 entitled The Three Myths Of Network QoS
    “After a decade of avoiding complex quality of service (QoS) attributes in an IP network, Forrester's clients are showing renewed interest. Why? Because shifting to IP-based apps and converged multimedia networks can be easily foiled by IP's best effort nature. But QoS is not that simple. Forrester has found that firms shouldn't believe vendor hype and must avoid three pitfalls — that QoS is standard, easy to set up, and part of a static configuration. To combat the problem, limit QoS to only where it's needed — like in the wide-area network (WAN) — and use optimization appliances like those from[listed vendors] to avoid unnecessary QoS requirements.†​
    The conclusions are debatable since many vendors attest that QoS is never a PnP (Plug and Play) solution. Careful network planning and a detailed SLA with rigorous QoS will future-proof the customer’s traffic in a heterogeneous WAN.

    There is no doubt however that without QoS, there will be no differential treatment to user traffic. This will mean that the needs of different application traffic are not met. There would therefore be no need in an SLA to offer much beyond simple connectivity between customer sites. Traffic would be normally routed, normally on a FIFO (First In, First Out) basis.

    Natural Demarcation Points & Some Definitions
    There are natural demarcation points in a network where QoS can be applied, both at the edge and within the core of a provider’s network. An explanation of “edge†vs. “core†is needed before a QoS solution can be examined:

    The first step to a QoS solution is to examine and define the natural demarcations in a network. The terminology can be confusing because it is often vendor-specific or (worse) mixed and/or misused. Some equipment vendors simplify the terminology by defining Provide Edge (PE) and Customer Edge (CE) devices but even so, in order to achieve consistency some definitions are proposed.

    • The edge of the network (whether provider edge or customer edge) is an area of the network that carries traffic in a relatively high-bandwidth, congestion free and low latency, low BER (Bit Error Rate) part of the network where no specific control for QoS is required. A collapsed or hierarchical Ethernet LAN or Metropolitan Ethernet network would be a good example.
    • The core of the network will be defined as the high-speed, redundant transit area that carries aggregate traffic that has been distributed in from a number of devices at the edge.
    • Customer Edge (CE) devices define points of aggregation of a single customer’s traffic before it is distributed into the core of the network.
    • Provider Edge (PE) devices are more often than not in the core of the service provider’s network. A PE is a device that carries traffic, in the aggregate, often from several different customers CE devices. A PE device will peer on other devices in the core of the network.
    • An access interface is a natural demarcation on the router which defines an interface which “sees†customer traffic which may require classification and marking. On a CE, an access interface would typically see a single customer’s traffic. On a PE, the access interfaces would collectively see the traffic from several different customers. Some of this traffic may already have been marked for QoS at the CE. This fits well with the Cisco model of access->distribution->core.
    • A network interface is an interface that faces the core. Marked up customer traffic will have services applied to it in order to provide for QoS as needed.
    Summarizing these ideas:

    There are 3 steps in a QoS solution:
    1. Classifying customer traffic
    2. Marking customer traffic for differentiated services
    3. Applying differentiated services to the customer traffic
    …let’s look at a couple of these more closely:


    Classifying Traffic
    Traffic is classified; typically as it enters an access interface demarc, to separate it from other streams of traffic. On many Linksys routers this is done at layer 3, typically using DSCP (DiffServ Code Point) as the method to discriminate the traffic. One of the main advantages of DSCP, beyond its being a more modern protocol than ToS (or IP Precedence) is its granularity. 6 bits of the ToS byte are used for DSCP, yielding 26 = 64 possible differentiated streams or “Per-Hop Behaviours†(PHBs). It is important to note that classifying traffic does nothing more than separate the streams of traffic…it certainly does not apply differentiated services…it classifies the traffic for possible differentiated services later.

    For example, many VoIP phones and adapters express their requirement for differentiated services by setting the bits in the ToS byte of the IP packet header. If they did not do so, devices upstream of them might not be able to apply differentiated services.

    Table 1 -- 3 Methods of Classifying Traffic for QoS

    Another point worth noting is that there are other ways to classify user traffic beyond 802.1p, ToS, and DSCP. Traffic can be classified for QoS based on:

    Layer 2 (OSI Data Link Layer):
    • MAC address
    • IEEE 802.2 (LLC) SAPs (Service Access Points)
    • DIX Ethernet EtherType
    • VLAN Tags (IEEE 802.1Q)
    Layer 3 (OSI Network Layer):
    • Source/Destination IP address
    • Protocol Number (i.e.: 6 = TCP, 17 = UDP, 50 = ESP, etc.)
    Layer 4 (OSI Transport Layer)
    • Source/Destination Port Numbers
    There are probably others, but generally speaking, anything in a layer 2, 3, or 4 header can be used to discriminate traffic for classification.

    For example, Cisco PIX and ASA security appliances implement a simple QoS as part of the Modular Policy Framework.

    Here’s a link to a walk-through on Cisco’s website: http://www.cisco.com/E-Learning/bulk/public/celc/Cisco_QLM3_ASA_beta/course_skin.html

    Marking Traffic for Differentiated Service
    Once the traffic is classified, it is differentiated / separated by placing it in different queues.
    It is also possible that the traffic might be re-classified in a process called marking. In fact, a customer’s traffic might be remarked several times in its end-to-end journey through a service provider’s network…reflecting the unique requirements of what the traffic needs to “look like†to different QoS-aware devices within the network.
    The queues are internally organized into forwarding classes. I say “internally†since every manufacturer has their proprietary scheme for segregating traffic. For example, some manufacturers support 8 forwarding classes only. As you recall, the popular classifying mechanism, DSCP, can create up to 64 PHBs. These are sometimes called microflows reflecting their granular nature. 8 forwarding classes is 8x less granular.

    Forwarding Classes are therefore often called macroflows. Hypothetically this means that if we were to use all of the 64 PHBs in classifying the traffic at the access we might not be able to properly differentiate traffic in the provider’s network. In practical terms carriers are almost never asked to provide for that degree of granularity in making decisions as to how to prioritize traffic inside their network. They might be asked to give preferential treatment to VoIP traffic and then secondly a mission-critical, possibly delay-sensitive application. In this scenario, only 3 forwarding classes would be needed: one for VoIP, another for the mission-critical application, and a 3rd best efforts forwarding class for the remainder.


    Figure 1 -- Forwarding Classes with Differentiated Traffic between PEs

    As was previously noted, differentiating traffic is not the customer’s responsibility in any case. Forwarding classes are interesting, but only to the service provider who uses these forwarding classes to segregate traffic as it is dispatched through the device and between devices in the core. These forwarding classes are essentially big, virtual pipes that carry traffic in aggregate between customer’s devices.

    Applying Differentiated Services
    Once the traffic is in the provider’s network (and network devices), differentiated services can be applied to the customer’s traffic. Traffic is managed within the forwarding classes in order to both ensure QoS for complying traffic as well as to (in some cases) condition the traffic so that it will be more likely to be compliant. This is outside the discussion for now, but the short story is that a number of different algorithms, policies will effect this goal and ensure that the service provider can meet the requirements of their SLA with the customer. Some concepts and actions that fall within this (admittedly large for now) category include:
    • Policing
    • Priority Queuing
    • Bandwidth Reservation
    • Hardware & Virtual Scheduling
    • WRED (Weighted Random Early Detection)
    • WRR (Weighted Round Robin)
    • LLQ (Low Latency Queuing)
    • …and others including mechanisms for congestion detection and avoidance.
    Putting it Together: VoIP Case Study
    Consider a common scenario. A SOHO user has a VoIP adapter (or VoIP phone) on the inside of their network. The user has a QoS-Aware router, such as a Linksys WRV200 deployed behind a separate broadband router which doesn’t have a clue about QoS. Good thing the WRV200 is QoS-aware, because it will be able to distinguish the VoIP packets as they arrive at its access interface. This is because the VoIP adapter marks its packets with the EF PHB (per RFC 2598). Recall that 64 PHBs are defined with DSCP (see how it’s coming together?) The EF PHB is the VoIP adapter’s way of expressing its desire for the highest possible priority for its traffic in the IP network. Of course, if the WRV200 is not QoS-aware, all is lost before the IP packets’ journey even begins!


    Figure 2 -- QoS-Aware Router honours the EF PHB

    The DSCP EF PHB can be verified by using a protocol analyzer. Here is a snapshot of the packets as they leave the VoIP adapter:


    Figure 3-- Protocol Analysis indicating EF PHB

    As the packets leave the QoS-Aware router, something interesting happens. Re-marking has occurred. To verify this, where do we put the protocol analyzer?


    Figure 4 -- Remarking as the VoIP packets leave the QoS-Aware Router

    Still examining packets as they leave the QoS router it is clear that the packets that contain the actual VoIP call are using a different DiffServ Code Point than that used for the call setup (see previous). They use the AF PHB. It isn’t known whether the QoS router has re-marked the Code Point or whether the DSCP markings have been left as-is from when the VoIP packets left the VoIP adapter. This is more likely an artifact of how the vendor has architected the VoIP solution. All other traffic (www, DNS, etc.,) will not be marked with the DiffServ CP. It will probably be routed on a best efforts, normally-routed FIFO (first in first out) basis

    We can also assume that the QoS-aware router has some type of internal QoS mechanism such as WRR (Weighted Round Robin) queuing or some type of LLQ (Low Latency Queue) to dispatch the EF PHB traffic ahead of other, lower priority traffic. This is an efficient and simple local QoS mechanism.

    Note: In the protocol analyzer screenshot, the source address of the packets is NAT’d (Network Address Translated) to the IP address of the WAN interface of the QoS router, The SIP server is IP address This solution is Bell Canada’s “Digital Voice Liteâ€

    This behaviour can be observed with the following protocol analyzer output:


    Figure 5 -- VoIP packets leaving the QoS-Aware router

    This might all sound fairly abstract but it is actually straightforward. The packets will now enter the Internet with an AF PHB marking since it is unlikely that the “broadband router†(see diagram) will re-mark the bits in the IP packet header. All other traffic (www, DNS, etc.,) will not be marked with the DiffServ CP. It will probably be routed on a best efforts, normally-routed FIFO (first in first out) basis in the same way as the local QoS-aware router treated it.

    It is now up to the service provider in the Internet to either honour or disregard the DiffServ markings. In this particular solution, the DSL service is provided by Bell Canada, also the provider of the VoIP solution. It’s possible that they will honour the markings, at least within their small part of the Internet. The way that they will honour these markings is by applying differentiated services to the VoIP packets. How they do that is a moot point. This would normally be where the story ends, but let’s leave with a cliff hanger. Wouldn’t it be interesting to see what the markings for the reply VoIP packets from the VoIP provider are? If they are marked with DSCP anything other than 00, this would indicate that the VoIP provider is also expressing a desire for differentiated services in the reply VoIP packets.


    Figure 6 -- Reply VoIP packets indicating AF PHB
    This can be seen on the following protocol analyzer screenshot:


    Figure 7 -- Protocol Analyzer showing reply VoIP packets with AF PHB = 41

    QoS is a science and it’s not Plug-and-Play. Even vendor solutions that automate QoS are packed with algorithms that imitate a best-guess as to how customers would classify, mark and provide differentiated services if they had the wherewithal and knowledge to configure these things manually. There are a number of SOHO routers available on the market right now that employ very sophisticated logic to ensure that the customer’s traffic (that’s us!) is dispatched with sufficient priority as to ensure that delay-sensitive and variable-delay-sensitive (jitter) traffic is not adversely effected by other, lower priority traffic.

    The catch-word of today’s networks is convergence. The triple-play of voice, data, and video all sharing and therefore competing for bandwidth in this broadband world that we live in is putting abnormal pressure on the point of convergence….our broadband routers. While the D-Links, SMCs, Linksys’s and others of this world have done a creditable job of implementing QoS on their products, it is up to us, the sophisticated consumer and network planner to understand how it works and what the ripple effect of poor configuration on our parts will have on our Internet experience. Some of the mechanisms that these devices employ are deliberately cloaked behind simplistic configuration screens. This is probably OK, but hopefully after reading this short little “primer†you will look at that technical specification sheet and box panels a bit more carefully. They don’t all have “the right stuffâ€!

    That’s it for now. The next article will dig into some of the mechanisms that networks and network devices employ to apply differentiated services to customers’ packets.

    Appendix A – DiffServ Code Point PHBs



    The file can also be downloaded here: QoS Primer Document Part I

    NOTE: Eric has ask the administrators to add an example of the above using the Cisco ASA 5505



    © Eric Stewart, all rights reserved

    No part of this document may be used without the express written consent of Eric Stewart
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice