RFC 8325
Mapping Diffserv to IEEE 802.11
Mapping Diffserv to IEEE 802.11 🎀
okay bestie, here's the title block tea ☕💅
- RFC number: 8325
- Title: Mapping Diffserv to IEEE 802.11
- Authors: T. Szigeti, J. Henry (Cisco Systems), and F. Baker
- Stream: Internet Engineering Task Force (IETF)
- Category: Standards Track
- ISSN: 2070-1721
- Date: February 2018
- Obsoletes / Updates: the title block doesn't list any RFCs this one obsoletes or updates 🙈
Abstract ✨
okay so this is the big picture 🦋 Internet traffic is increasingly coming from and going to wireless devices, so Quality of Service (QoS) has to match between wired and wireless networks. by default, it doesn't always 😭 this document sets out a mapping from Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP). the point is to combine the marking advice from the IETF and the IEEE so that wired and IEEE 802.11 wireless networks treat traffic consistently 💖
Status of This Memo 🌸
this is an Internet Standards Track document, bestie 🧚
it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 7841 ✨
for the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8325 💜
Copyright Notice 🔥
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please read these carefully, because they explain your rights and restrictions for this document 🫶 any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🌈
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Interaction with RFC 7561 . . . . . . . . . . . . . . . . 4
1.3. Applicability Statement . . . . . . . . . . . . . . . . . 4
1.4. Document Organization . . . . . . . . . . . . . . . . . . 5
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.6. Terminology Used in This Document . . . . . . . . . . . . 6
2. Service Comparison and Default Interoperation of Diffserv and
IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 9
2.2. EDCF Queuing . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Default DSCP-to-UP Mappings and Conflicts . . . . . . . . 10
2.4. Default UP-to-DSCP Mappings and Conflicts . . . . . . . . 11
3. Recommendations for Capabilities of Wireless Device Marking
and Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Recommendations for DSCP-to-UP Mapping . . . . . . . . . . . 13
4.1. Network Control Traffic . . . . . . . . . . . . . . . . . 14
4.1.1. Network Control Protocols . . . . . . . . . . . . . . 14
4.1.2. Operations, Administration, and Maintenance (OAM) . 15
4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 17
4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 17
4.2.5. Multimedia Streaming . . . . . . . . . . . . . . . . 17
4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 18
4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 18
4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 18
4.2.9. Standard . . . . . . . . . . . . . . . . . . . . . . 19
4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 20
4.3. Summary of Recommendations for DSCP-to-UP Mapping . . . . 20
5. Recommendations for Upstream Mapping and Marking . . . . . . 21
5.1. Upstream DSCP-to-UP Mapping within the Wireless Client
Operating System . . . . . . . . . . . . . . . . . . . . 22
5.2. Upstream UP-to-DSCP Mapping at the Wireless AP . . . . . 22
5.3. Upstream DSCP-Passthrough at the Wireless AP . . . . . . 23
5.4. Upstream DSCP Marking at the Wireless AP . . . . . . . . 24
6. Overview of IEEE 802.11 QoS . . . . . . . . . . . . . . . . . 24
6.1. Distributed Coordination Function (DCF) . . . . . . . . . 25
6.1.1. Slot Time . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Interframe Space (IFS) . . . . . . . . . . . . . . . 26
6.1.3. Contention Window (CW) . . . . . . . . . . . . . . . 26
6.2. Hybrid Coordination Function (HCF) . . . . . . . . . . . 27
6.2.1. User Priority (UP) . . . . . . . . . . . . . . . . . 27
6.2.2. Access Category (AC) . . . . . . . . . . . . . . . . 28
6.2.3. Arbitration Interframe Space (AIFS) . . . . . . . . . 29
6.2.4. Access Category CWs . . . . . . . . . . . . . . . . . 29
6.3. IEEE 802.11u QoS Map Set . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8.1. Security Recommendations for General QoS . . . . . . . . 31
8.2. Security Recommendations for WLAN QoS . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Normative References . . . . . . . . . . . . . . . . . . 34
9.2. Informative References . . . . . . . . . . . . . . . . . 35
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 371. Introduction ✨
okay so the wireless medium defined by IEEE 802.11 [IEEE.802.11-2016] has become the go-to for endpoints connecting to business and private networks 💅 but it makes end-to-end QoS kinda hard 😭 some of that comes from the RF medium itself, which is half-duplex and shared. the rest comes from the fact that IEEE 802.11 isn't run by the same standards body that handles IP networking. the IEEE has built tools for QoS over wireless, but there's barely any guidance on keeping QoS consistent between wired IP networks and wireless IEEE 802.11 networks. that's the gap this document fills 🫶
1.1. Related Work 🦋
a bunch of RFCs spell out Diffserv QoS recommendations over IP networks, including:
RFC 2474: specifies the Diffserv Codepoint Field. it also details Class Selectors and the Default Forwarding (DF) PHB for best effort traffic. the Default Forwarding PHB is called the Default PHB in RFC 2474 🍓RFC 2475: defines a Diffserv architecture 🌈RFC 3246: specifies the Expedited Forwarding (EF) Per-Hop Behavior (PHB) ⚡RFC 2597: specifies the Assured Forwarding (AF) PHB 💜RFC 3662: specifies a Lower-Effort Per-Domain Behavior (PDB) 🌸RFC 4594: presents configuration guidelines for Diffserv service classes 🎀RFC 5127: presents the aggregation of Diffserv service classes 🧚RFC 5865: specifies a DSCP for capacity-admitted traffic 👑
Note: [RFC4594] is meant to be read as a framework for supporting Diffserv in any network, wireless ones included 🫶 so it describes the different traffic types you'd expect on IP networks and gives guidance on which DSCP marking(s) go with each type. this document leans heavily on [RFC4594], [RFC5127], and [RFC8100] 💖
on the wireless side, the relevant standard is IEEE 802.11. it keeps getting updated, and at the time of writing the current version is [IEEE.802.11-2016] ✨
1.2. Interaction with RFC 7561 💅
there's also a recommendation from the Global System for Mobile Communications Association (GSMA) on DSCP-to-UP Mapping for IP Packet eXchange (IPX). it lives in their Guidelines for IPX Provider networks [GSMA-IPX_Guidelines] 🙈 the GSMA Guidelines were written without looking at the existing IETF specs for various services, which are covered in Section 1.1. then [RFC7561] was written based on those GSMA Guidelines, which [RFC7561], Section 4.2 says outright. so [RFC7561] clashes with the overall Diffserv traffic-conditioning service plan, both in the services it specifies and in the codepoints it assigns to them 😭 that means the two plans can't be normalised into one. instead, as [RFC2474], Section 2 explains, the two domains (IEEE 802.11 and GSMA) are separate Differentiated Services Domains with a Differentiated Services Boundary between them. at that boundary, codepoints from one domain get translated into codepoints for the other, and maybe to Default (zero) if there's no matching service to translate to 🦋
1.3. Applicability Statement 🌷
this document applies to Differentiated Services that interconnect with IEEE 802.11 wireless LANs (called Wi-Fi throughout this document, for simplicity) 📶 these guidelines work whether the wireless access points (APs) are deployed autonomously, managed by WLAN controllers (centralized or distributed), or some hybrid setup. that's because in every one of those cases, the wireless AP is the bridge between wired and wireless media 🌈
this document applies to IP networks that use Wi-Fi infrastructure at the link layer. those networks usually have wired LANs with wireless APs at their edges. but they can also include Wi-Fi backhaul, wireless mesh solutions, or any other AP-to-AP wireless network that extends the wired network infrastructure 🧚✨
1.4. Document Organization 🗺️
okay so here's the tour of the doc, bestie 💖
- Section 1 introduces the wired-to-wireless QoS challenge, references related work, outlines the organization of the document, and specifies both the requirements language and the terminology used in this document. ✨
- Section 2 begins the discussion with a comparison of IETF Diffserv QoS and Wi-Fi QoS standards and highlights discrepancies between these that require reconciliation. 💅
- Section 3 presents the marking and mapping capabilities that wireless APs and wireless endpoint devices are recommended to support. 🎀
- Section 4 presents DSCP-to-UP mapping recommendations for each of the [RFC4594] service classes, which are primarily applicable in the downstream (wired-to-wireless) direction. 🦋
- Section 5, in turn, considers upstream (wireless-to-wired) QoS options, their respective merits and recommendations. 🌈
- Section 6 (in the form of an Appendix) presents a brief overview of how QoS is achieved over IEEE 802.11 wireless networks, given the shared, half-duplex nature of the wireless medium. 🧚
- Section 7 contains IANA considerations. 📋
- Section 8 presents security considerations relative to DSCP-to-UP mapping, UP-to-DSCP mapping, and re-marking. 😭 this one is the serious one, so pay attention!
1.5. Requirements Language 📜
okay this part is the rulebook 🔥 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
1.6. Terminology Used in This Document 📖
these are the key terms we need to know, so let's get into them 🫶
- AC: Access Category. A label for the common set of enhanced distributed channel access (EDCA) parameters that are used by a QoS station (STA) to contend for the channel in order to transmit medium access control (MAC) service data units (MSDUs) with certain priorities; see [IEEE.802.11-2016], Section 3.2.
- AIFS: Arbitration Interframe Space. Interframe space used by QoS stations before transmission of data and other frame types defined by [IEEE.802.11-2016], Section 10.3.2.3.6.
- AP: Access Point. An entity that contains one station (STA) and provides access to the distribution services, via the wireless medium (WM) for associated STAs. An AP comprises a STA and a distribution system access function (DSAF); see [IEEE.802.11-2016], Section 3.1.
- BSS: Basic Service Set. Informally, a wireless cell; formally, a set of stations that have successfully synchronized using the JOIN service primitives and one STA that has used the START primitive. Alternatively, a set of STAs that have used the START primitive specifying matching mesh profiles where the match of the mesh profiles has been verified via the scanning procedure. Membership in a BSS does not imply that wireless communication with all other members of the BSS is possible. See the definition in [IEEE.802.11-2016], Section 3.1. 🏠
- Contention Window: See CW.
- CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. A MAC method in which carrier sensing is used, but nodes attempt to avoid collisions by transmitting only when the channel is sensed to be "idle". When these do transmit, nodes transmit their packet data in its entirety.
- CSMA/CD: Carrier Sense Multiple Access with Collision Detection. A MAC method (used most notably in early Ethernet technology) for local area networking. It uses a carrier-sensing scheme in which a transmitting station detects collisions by sensing transmissions from other stations while transmitting a frame. When this collision condition is detected, the station stops transmitting that frame, transmits a jam signal, and then waits for a random time interval before trying to resend the frame. 🫠
- CW: Contention Window. Limits a CWMin and CWMax, from which a random backoff is computed.
- CWMax: Contention Window Maximum. The maximum value (in units of Slot Time) that a CW can take.
- CWMin: Contention Window Minimum. The minimum value that a CW can take.
- DCF: Distributed Coordinated Function. A class of coordination function where the same coordination function logic is active in every station (STA) in the BSS whenever the network is in operation.
- DIFS: Distributed (Coordination Function) Interframe Space. A unit of time during which the medium has to be detected as idle before a station should attempt to send frames, as per [IEEE.802.11-2016], Section 10.3.2.3.5.
- DSCP: Differentiated Service Code Point [RFC2474] and [RFC2475]. The DSCP is carried in the first 6 bits of the IPv4 Type of Service (TOS) field and the IPv6 Traffic Class field (the remaining 2 bits are used for IP Explicit Congestion Notification (ECN) [RFC3168]). 🏷️
- EIFS: Extended Interframe Space. A unit of time that a station has to defer before transmitting a frame if the previous frame contained an error, as per [IEEE.802.11-2016], Section 10.3.2.3.7.
- HCF: Hybrid Coordination Function. A coordination function that combines and enhances aspects of the contention-based and contention-free access methods to provide QoS stations (STAs) with prioritized and parameterized QoS access to the WM, while continuing to support non-QoS STAs for best-effort transfer; see [IEEE.802.11-2016], Section 3.1.
- IFS: Interframe Space. Period of silence between transmissions over IEEE 802.11 networks. [IEEE.802.11-2016] describes several types of Interframe Spaces.
- Random Backoff Timer: A pseudorandom integer period of time (in units of Slot Time) over the interval (0,CW), where CWmin is less than or equal to CW, which in turn is less than or equal to CWMax. Stations desiring to initiate transfer of data frames and/or management frames using the DCF shall invoke the carrier sense mechanism to determine the busy-or-idle state of the medium. If the medium is busy, the STA shall defer until the medium is determined to be idle without interruption for a period of time equal to DIFS when the last frame detected on the medium was received correctly or after the medium is determined to be idle without interruption for a period of time equal to EIFS when the last frame detected on the medium was not received correctly. After this DIFS or EIFS medium idle time, the STA shall then generate a random backoff period for an additional deferral time before transmitting. See [IEEE.802.11-2016], Section 10.3.3. 🎲
- RF: Radio Frequency.
- SIFS: Short Interframe Space. An IFS used before transmission of specific frames as defined in [IEEE.802.11-2016], Section 10.3.2.3.3.
- Slot Time: A unit of time used to count time intervals in IEEE 802.11 networks; it is defined in [IEEE.802.11-2016], Section 10.3.2.13. ⏱️
- Trust: From a QoS-perspective, "trust" refers to the accepting of the QoS markings of a packet by a network device. Trust is typically extended at Layer 3 (by accepting the DSCP), but may also be extended at lower layers, such as at Layer 2 by accepting UP markings. For example, if an AP is configured to trust DSCP markings and it receives a packet marked EF, then it would treat the packet with the Expedite Forwarding PHB and propagate the EF marking value (DSCP 46) as it transmits the packet. Alternatively, if a network device is configured to operate in an untrusted manner, then it would re-mark packets as these entered the device, typically to DF (or to a different marking value at the network administrator's preference). Note: The terms "trusted" and "untrusted" are used extensively in [RFC4594]. 🤝
- UP: User Priority. A value associated with an MSDU that indicates how the MSDU is to be handled. The UP is assigned to an MSDU in the layers above the MAC; see [IEEE.802.11-2016], Section 3.1. The UP defines a level of priority for the associated frame, on a scale of 0 to 7. priority queue energy 💜
- Wi-Fi: An interoperability certification defined by the Wi-Fi Alliance. However, this term is commonly used, including in the present document, to be the equivalent of IEEE 802.11. 📶
- Wireless: In the context of this document, "wireless" refers to the media defined in IEEE 802.11 [IEEE.802.11-2016], and not 3G/4G LTE or any other radio telecommunications specification. 📡
2. Service Comparison and Default Interoperation of Diffserv and IEEE 802.11 🎀
(Section 6 provides a brief overview of IEEE 802.11 QoS.)
okay so the comparison starts here, and honestly some of these are a little bit of a letdown 🙈 The following comparisons between IEEE 802.11 and Diffserv services should be noted:
- [IEEE.802.11-2016] does not support an EF PHB service [RFC3246], as it is not possible to assure that a given access category will be serviced with strict priority over another (due to the random element within the contention process) 💀
- [IEEE.802.11-2016] does not support an AF PHB service [RFC2597], again because it is not possible to assure that a given access category will be serviced with a minimum amount of assured bandwidth (due to the non-deterministic nature of the contention process) 😭
- [IEEE.802.11-2016] loosely supports a Default PHB ([RFC2474]) via the Best Effort Access Category (AC_BE) 🫤
- [IEEE.802.11-2016] loosely supports a Lower Effort PDB service ([RFC3662]) via the Background Access Category (AC_BK) 🫤
As such, these high-level considerations should be kept in mind when mapping from Diffserv to [IEEE.802.11-2016] (and vice versa); however, APs may or may not always be positioned at Diffserv domain boundaries, as will be discussed next. 🧠
2.1. Diffserv Domain Boundaries 🌐
It is important to recognize that the wired-to-wireless edge may or may not function as an edge of a Diffserv domain or a domain boundary. this is where it gets interesting 👀
In most commonly deployed WLAN models, the wireless AP represents not only the edge of the Diffserv domain, but also the edge of the network infrastructure itself. As such, only client endpoint devices (and no network infrastructure devices) are downstream from the access points in these deployment models. Note: security considerations and recommendations for hardening such Wi-Fi-at-the-edge deployment models are detailed in Section 8; these recommendations include mapping network control protocols (which are not used downstream from the AP in this deployment model) to UP 0. 🔒
Alternatively, in other deployment models, such as Wi-Fi backhaul, wireless mesh infrastructures, wireless AP-to-AP deployments, or in cases where a Wi-Fi link connects to a device providing service via another technology (e.g., Wi-Fi to Bluetooth or Zigbee router), the wireless AP extends the network infrastructure and thus, typically, the Diffserv domain. In such deployments, both client devices and infrastructure devices may be expected downstream from the APs, and, as such, network control protocols are RECOMMENDED to be mapped to UP 7 in this deployment model, as is discussed in Section 4.1.1. 🦋
Thus, as can be seen from these two examples, the QoS treatment of packets at the AP will depend on the position of the AP in the network infrastructure and on the WLAN deployment model. so the answer is always "it depends" lol 🙃
However, regardless of whether or not the AP is at the Diffserv boundary, marking-specific incompatibilities exist from Diffserv to 802.11 (and vice versa) that must be reconciled, as will be discussed next. ✨
2.2. EDCF Queuing ✨
okay so [IEEE.802.11-2016] shows a reference queuing model in Figure 10-24 🎀, and it has four transmit queues, one for each access category 💖
but ngl, real WLAN vendors don't usually do it that neat 💅 it's super common for them to make dedicated transmit queues per UP (not per AC) 🫶 and then those get dequeued into their matching AC in a preferred order, or even a strict priority order 😭 for example, vendors often dequeue UP 5 ahead of UP 4 to the hardware doing the EDCA function (EDCAF) for the Video Access Category (AC_VI) 🦋
Some of the recommendations in Section 4 actually refer to this per-UP queuing model 🌸
2.3. Default DSCP-to-UP Mappings and Conflicts ✨
so there's no explicit guidance on mapping (6-Bit) Layer 3 DSCP values to (3-Bit) Layer 2 markings (like IEEE 802.1D, 802.1p or 802.11e) 🙈 but the networking industry has a common habit called "default DSCP-to-UP mapping" (lowkey not the most creative name, but it's what we've got 💀) where the three Most Significant Bits (MSBs) of the DSCP get used as the L2 markings 🍓
Note: [IEEE.802.11-2016], Annex V Tables V-1 and V2 have mappings too, but those are just examples, not explicit recommendations 💅 and some of them don't line up with [RFC4594], which we'll get into in this section and the next one (Section 2.4) 🌈
but here's the tea ☕: when this default DSCP-to-UP mapping is applied to packets marked per [RFC4594] and sent to 802.11 WLAN clients, it gives a bunch of inconsistent QoS mappings, specifically:
- Voice (EF-101110) gets mapped to UP 5 (101) and treated in the Video Access Category (AC_VI) instead of the Voice Access Category (AC_VO), which is where it's meant to go 😭
- Multimedia Streaming (AF3-011xx0) gets mapped to UP 3 (011) and treated in the Best Effort Access Category (AC_BE) instead of the Video Access Category (AC_VI), which is where it's meant to go 💔
- Broadcast Video (CS3-011000) gets mapped to UP 3 (011) and treated in the Best Effort Access Category (AC_BE) instead of the Video Access Category (AC_VI), which is where it's meant to go 🥺
- OAM traffic (CS2-010000) gets mapped to UP 2 (010) and treated in the Background Access Category (AC_BK), which is not what [RFC4594] intends for this service class 🙃
it's also worth noting that [IEEE.802.11-2016] gives each access category an intended use through the AC name (like UP 6 and UP 7 belonging to AC_VO, the Voice Access Category) 🎀 but [IEEE.802.11-2016] does not:
- define how upper-layer markings (such as DSCP) should map to UPs (and, from there, to ACs) 🤷♀️
- define how UPs should translate to other mediums' Layer 2 QoS markings 🛸
- strictly restrict each access category to the applications reflected in the AC name 🌷
2.4. Default UP-to-DSCP Mappings and Conflicts ✨
going the other way (the upstream direction, from wireless-to-wired) 🦋 a lot of APs use what we'll call "default UP-to-DSCP mapping" (again, no better name for it 🙃), where DSCP values come from UP values by multiplying the UP by 8 (aka shifting the three UP bits left and adding three extra zeros to make a DSCP value) 🧚 this derived DSCP value is then used for QoS treatment between the wireless AP and the nearest classification and marking policy enforcement point (which might be the centralized wireless LAN controller, pretty deep in the network) 🏢 but if there's no other classification and marking policy enforcement point, the derived DSCP value gets used across the rest of the Internet path 🌍
it goes without saying that when six bits of marking granularity get derived from three, information gets lost in translation 💀 you can't differentiate 12 classes of traffic (like [RFC4594] recommends), only eight 😭, and one of those is reserved for future use (UP 7, which maps to DSCP CS7) 🫠
this default upstream mapping can also cause several inconsistencies with [RFC4594], including:
- Mapping UP 6 (which would include Voice or Telephony traffic, see [RFC4594]) to CS6, which [RFC4594] recommends for Network Control 🙈
- Mapping UP 4 (which would include Multimedia Conferencing and/or Real-Time Interactive traffic, see [RFC4594]) to CS4, so you lose the ability to tell these two distinct service classes apart, as [RFC4594] recommends in Sections 4.3 and 4.4 💔
- Mapping UP 3 (which would include Multimedia Streaming and/or Broadcast Video traffic, see [RFC4594]) to CS3, so you lose the ability to tell these two distinct service classes apart, as [RFC4594] recommends in Sections 4.5 and 4.6 🥺
- Mapping UP 2 (which would include Low-Latency Data and/or OAM traffic, see [RFC4594]) to CS2, so you lose the ability to tell these two distinct service classes apart, as [RFC4594] recommends in Sections 4.7 and 3.3 😩 and it could overwhelm the queues provisioned for OAM (which are usually smaller, since it's Network Control Traffic, compared to Low-Latency Data queues, which carry user traffic) 🫨
- Mapping UP 1 (which would include High-Throughput Data and/or Low-Priority Data traffic, see [RFC4594]) to CS1, so you lose the ability to tell these two distinct service classes apart, as [RFC4594] recommends in Sections 4.8 and 4.10, and legitimate business-relevant High-Throughput Data ends up getting a [RFC3662] Lower-Effort PDB, which it was never meant to have 😤
the next sections fix these limitations and concerns so [RFC4594] and [IEEE.802.11-2016] can get along 🫶 first we line up the downstream (wired-to-wireless) DSCP-to-UP mappings, and then we tackle the upstream (wireless-to-wired) models 💖
3. Recommendations for Capabilities of Wireless Device Marking and Mapping 🎀
this document assumes and RECOMMENDS that all wireless APs (as the interconnects between wired and wireless networks) can:
- mark DSCP, per Diffserv standards
- mark UP, per the [IEEE.802.11-2016] standard
- support fully configurable mappings between DSCP and UP
- process DSCP markings set by wireless endpoint devices
this document also assumes and RECOMMENDS that all wireless endpoint devices can:
- mark DSCP, per Diffserv standards
- mark UP, per the [IEEE.802.11-2016] standard
- support fully configurable mappings between DSCP (set by applications in software) and UP (set by the operating system and/or wireless network interface hardware drivers) 🧚
okay, so after all those assumptions and recommendations, it's worth saying that the mappings in this document are RECOMMENDED to replace the current common default practices (as discussed in Sections 2.3 and 2.4) 💅 but these mapping recommendations are not expected to fit every single deployment model 😭 so they MAY be overridden by network administrators, as needed 🌸
4. Recommendations for DSCP-to-UP Mapping ✨
this section specifies the downstream (wired-to-wireless) mappings between [RFC4594], "Configuration Guidelines for Diffserv Service Classes" and [IEEE.802.11-2016] 🦋 so it draws heavily from [RFC4594], including its service class definitions and recommendations 🎀
this section assumes [IEEE.802.11-2016] wireless APs and/or WLAN controllers that support customizable, non-default DSCP-to-UP mapping schemes 🫶
this section also assumes that [IEEE.802.11-2016] APs and endpoint devices differentiate UP markings with corresponding queuing and dequeuing treatments, as described in Section 2.2 🧚
4.1. Network Control Traffic 💖
Network Control Traffic is defined as packet flows that are essential for stable operation of the administered network [RFC4594], Section 3 🌷 it's different from user application control (signaling) that some applications or services might generate 🙈 Network Control Traffic MAY be split into two service classes:
- Network Control, and
- Operations, Administration, and Maintenance (OAM)
4.1.1. Network Control Protocols ✨
the Network Control service class is used for sending packets between network devices (e.g., routers) that need to exchange control (routing) information between nodes within the administrative domain 🛸 and also across a peering point between different administrative domains 🌍
[RFC4594], Section 3.2, recommends that Network Control Traffic be marked CS6 DSCP 🎀 and as [RFC4594], Section 3.1 says: "CS7 DSCP value SHOULD be reserved for future use, potentially for future routing or control protocols." 🫠
by default (as described in Section 2.4), packets marked DSCP CS7 get mapped to UP 7 and serviced within the Voice Access Category (AC_VO) 💅 this is the RECOMMENDED mapping for CS7, so packets marked CS7 DSCP are RECOMMENDED to be mapped to UP 7 ✨
but by default (as described in Section 2.4), packets marked DSCP CS6 get mapped to UP 6 and serviced within the Voice Access Category (AC_VO) 😩 that mapping and servicing contradicts the intent in [RFC4594], Section 3.2 💔 so it is RECOMMENDED to map Network Control Traffic marked CS6 to UP 7 (per [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1), which admits it to the Voice Access Category (AC_VO), though with a marking that sets it apart from (data-plane) voice traffic 🫶
it should be noted that encapsulated routing protocols for encapsulated or overlay networks (e.g., VPN, Network Virtualization Overlays, etc.) are not Network Control Traffic for any physical network at the AP 🧚 so they SHOULD NOT be marked with CS6 in the first place 🙅♀️
also, as mentioned earlier, the Security Considerations section (Section 8) has extra recommendations for hardening Wi-Fi-at-the-edge deployment models 🔥 where, for example, network control protocols are not expected to be sent or received between APs and downstream client endpoint devices 🛡️
4.1.2. Operations, Administration, and Maintenance (OAM) 🌈
the OAM (Operations, Administration, and Maintenance) service class is recommended for OAM&P (Operations, Administration, and Maintenance and Provisioning) 🎀 the OAM service class can include network management protocols like SNMP, Secure Shell (SSH), TFTP, Syslog, etc., as well as network services like NTP, DNS, DHCP, etc. 💖 [RFC4594], Section 3.3, recommends that OAM traffic be marked CS2 DSCP 🦋
by default (as described in Section 2.3), packets marked DSCP CS2 get mapped to UP 2 and serviced with the Background Access Category (AC_BK) 😭 that servicing contradicts the intent in [RFC4594], Section 3.3 💀 so it is RECOMMENDED that a non-default mapping be applied to OAM traffic, so that CS2 DSCP maps to UP 0, which admits it to the Best Effort Access Category (AC_BE) 🫶✨
4.2. User Traffic 💖
okay so user traffic is basically any packet flow between different users or subscribers 🌸. it's the stuff going to and from end-terminals, and it powers a super wide variety of apps and services [RFC4594], Section 4.
network admins can sort their apps by the behavior they need, and they MAY choose to support all or just a subset of the defined service classes ✨
4.2.1. Telephony 📞
bestie, the Telephony service class is recommended for apps that need real-time, very low delay, very low jitter, and very low packet loss for relatively constant-rate traffic sources (inelastic traffic sources) 😭. this class SHOULD be used for IP telephony service. the core promise of Telephony is minimum jitter, delay, and packet loss up to a specified upper bound 💅. [RFC4594], Section 4.1, recommends that Telephony traffic be marked EF DSCP.
here's the tea: traffic marked to DSCP EF maps by default (see Section 2.3) to UP 5, which lands it in the Video Access Category (AC_VI) instead of the Voice Access Category (AC_VO) it was actually meant for 💀. so a non-default DSCP-to-UP mapping is RECOMMENDED, with EF DSCP going to UP 6, which admits it into AC_VO 🎀.
same energy for the VOICE-ADMIT DSCP (44 decimal / 101100 binary) from [RFC5865]. it is RECOMMENDED to be mapped to UP 6 too, so it gets admitted into AC_VO as well 🦋.
4.2.2. Signaling 📡
the Signaling service class is recommended for delay-sensitive client-server (e.g., traditional telephony) and peer-to-peer application signaling 🧚. telephony signaling covers 1) IP phone to soft-switch, 2) soft-client to soft-switch, and 3) media gateway to soft-switch, plus peer-to-peer signaling using various protocols. this class is meant for controlling sessions and applications. [RFC4594], Section 4.2, recommends that Signaling traffic be marked CS5 DSCP.
Signaling gets better service than the default class (AC_BE), but it doesn't need the top tier (AC_VO) 🫶. that leaves the Video Access Category (AC_VI), which is where it lands by default (see Section 2.3). so it is RECOMMENDED to map CS5 Signaling traffic to UP 5, which admits it into AC_VI.
Note: Signaling traffic isn't control-plane traffic from the network's point of view (it's data-plane traffic), so it doesn't deserve the Network Control class (CS6, mapped toUP 6) 🙈. but from the voice/video telephony overlay's point of view, it IS control-plane traffic, so it should get preferential servicing over other data-plane flows. in common WLAN deployments, this may be achieved by mappingCS5Signaling traffic toUP 5. on APs that support per-UP EDCAF queuing logic (see Section 2.2), this gives Signaling preferential treatment over other video flows in the same access category (AC_VI), which are marked toUP 4, plus better treatment than the Best Effort (AC_BE) and Background (AC_BK) access categories 👑.
4.2.3. Multimedia Conferencing 🎥
the Multimedia Conferencing service class is recommended for apps that need real-time service for rate-adaptive traffic. [RFC4594], Section 4.3, recommends Multimedia Conferencing traffic be marked AF4x (that is, AF41, AF42, and AF43, according to the rules defined in [RFC2475]).
video is the main media type here, so it is RECOMMENDED to map this class into the Video Access Category (AC_VI), which it does by default (see Section 2.3). specifically, it is RECOMMENDED to map AF41, AF42, and AF43 to UP 4, thereby admitting Multimedia Conferencing into AC_VI ✨.
4.2.4. Real-Time Interactive 🎮
the Real-Time Interactive service class is recommended for apps that need low loss and jitter and very low delay for variable-rate inelastic traffic sources 🏃. these apps may include inelastic video-conferencing, but also gaming (as pointed out in [RFC4594], Sections 2.1 through 2.3 and Section 4.4). [RFC4594], Section 4.4, recommends Real-Time Interactive traffic be marked CS4 DSCP.
video is the main media type again, so it is RECOMMENDED to map this class into the Video Access Category (AC_VI), which it does by default (see Section 2.3). specifically, it is RECOMMENDED to map CS4 to UP 4, thereby admitting Real-Time Interactive traffic into AC_VI 🌈.
4.2.5. Multimedia Streaming 🍿
the Multimedia Streaming service class is recommended for apps that need near-real-time packet forwarding of variable-rate elastic traffic sources. these flows are typically unidirectional. [RFC4594], Section 4.5, recommends Multimedia Streaming traffic be marked AF3x (that is, AF31, AF32, and AF33, according to the rules defined in [RFC2475]).
video is the main media type here too, so it is RECOMMENDED to map this class into the Video Access Category (AC_VI), which it will do by default (see Section 2.3). specifically, it is RECOMMENDED to map AF31, AF32, and AF33 to UP 4, thereby admitting Multimedia Streaming into AC_VI.
4.2.6. Broadcast Video 📺
the Broadcast Video service class is recommended for apps that need near-real-time packet forwarding with very low packet loss for constant-rate and variable-rate inelastic traffic sources. typically these flows are unidirectional. [RFC4594] Section 4.6 recommends Broadcast Video traffic be marked CS3 DSCP.
as the name directly implies, the main media type is video, so it is RECOMMENDED to map this class into the Video Access Category (AC_VI). however, by default (see Section 2.3), this class maps to UP 3, which puts it in the Best Effort Access Category (AC_BE) 😬. so a non-default mapping is RECOMMENDED, with CS4 mapping to UP 4, thereby admitting Broadcast Video into AC_VI.
4.2.7. Low-Latency Data ⚡
the Low-Latency Data service class is recommended for elastic, time-sensitive data apps, often transactional, where a user is waiting on the network so they can keep going with a task at hand 🧠. so these flows count as foreground traffic, and delays or drops hit user productivity directly. [RFC4594], Section 4.7, recommends Low-Latency Data be marked AF2x (that is, AF21, AF22, and AF23, according to the rules defined in [RFC2475]).
by default (see Section 2.3), Low-Latency Data maps to UP 2, which lands it in the Background Access Category (AC_BK). that's contrary to the intent in [RFC4594] 💀.
mapping Low-Latency Data to UP 3 may let targeted traffic get a superior level of service through per-UP transmit queues servicing the EDCAF hardware for the Best Effort Access Category (AC_BE), as described in Section 2.2. therefore it is RECOMMENDED to map Low-Latency Data traffic marked AF2x DSCP to UP 3, admitting it into AC_BE 🚀.
4.2.8. High-Throughput Data 🚚
the High-Throughput Data service class is recommended for elastic apps that need timely packet forwarding of variable-rate traffic sources and, more specifically, is configured to provide efficient, yet constrained (when necessary) throughput for TCP longer-lived flows. these flows are typically not user interactive. according to [RFC4594], Section 4.8, it can be assumed that this class will consume any available bandwidth, and that packets traversing congested links may experience higher queuing delays or packet loss. it is also assumed that this traffic is elastic and responds dynamically to packet loss. [RFC4594], Section 4.8, recommends High-Throughput Data be marked AF1x (that is, AF11, AF12, and AF13, according to the rules defined in [RFC2475]).
by default (see Section 2.3), High-Throughput Data maps to UP 1, which lands it in the Background Access Category (AC_BK). that's contrary to the intent in [RFC4594] 😤.
unfortunately, there really is no corresponding fit for the High-Throughput Data service class within the constrained 4 Access Category [IEEE.802.11-2016] model 😩. if High-Throughput Data goes to the Best Effort Access Category (AC_BE), it would contend with Low-Latency Data (even though [RFC4594] recommends a distinction in servicing between these service classes) as well as with the default service class. alternatively, if it goes to the Background Access Category (AC_BK), it would receive a less-than-best-effort service and contend with Low-Priority Data (as discussed in Section 4.2.10).
so, since there is no directly corresponding fit for the High-Throughput Data service class within the [IEEE.802.11-2016] model, it is generally RECOMMENDED to map High-Throughput Data to UP 0, thereby admitting it to the Best Effort Access Category (AC_BE) 🫶.
4.2.9. Standard 🌟
the Standard service class is recommended for traffic that hasn't been classified into any of the other supported forwarding service classes in the Diffserv network domain. this class provides the Internet's "best-effort" forwarding behavior 💜. [RFC4594], Section 4.9, states that the "Standard service class MUST use the Default Forwarding (DF) PHB".
the Standard service class loosely corresponds to the [IEEE.802.11-2016] Best Effort Access Category (AC_BE). therefore, it is RECOMMENDED to map Standard service class traffic marked DF DSCP to UP 0, thereby admitting it to the Best Effort Access Category (AC_BE). this happens to match the default mapping (see Section 2.3) 🍓.
4.2.10. Low-Priority Data 🐢
the Low-Priority Data service class serves apps that the user is willing to accept without service assurances. this class is specified in [RFC3662] and [LE-PHB].
[RFC3662] and [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP.
Note: This marking recommendation may change in the future, as [LE-PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic and recommends an additional DSCP for this traffic.
the Low-Priority Data service class loosely corresponds to the [IEEE.802.11-2016] Background Access Category (AC_BK). therefore, it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1, thereby admitting it to the Background Access Category (AC_BK). this happens to correspond to the default mapping (see Section 2.3) 💅.
4.3. Summary of Recommendations for DSCP-to-UP Mapping ✨
okay bestie, this is the big cheat sheet 💖 it summarizes the [RFC4594] DSCP marking recommendations mapped onto the [IEEE.802.11-2016] UPs and Access Categories, applied in the downstream direction (aka wired-to-wireless) 🎀
+-------------------------------------------------------------------+
| IETF Diffserv | PHB |Reference | IEEE 802.11 |
| Service Class | | RFC |User Priority| Access Category |
|===============+======+==========+=============+====================|
| | | | 7 | AC_VO (Voice) |
|Network Control| CS7 | RFC 2474 | OR |
|(reserved for | | | 0 | AC_BE (Best Effort)|
| future use) | | |See Security Considerations-Sec.8 |
+---------------+------+----------+-------------+--------------------+
| | | | 7 | AC_VO (Voice) |
|Network Control| CS6 | RFC 2474 | OR |
| | | | 0 | AC_BE (Best Effort)|
| | | | See Security Considerations |
+---------------+------+----------+-------------+--------------------+
| Telephony | EF | RFC 3246 | 6 | AC_VO (Voice) |
+---------------+------+----------+-------------+--------------------+
| VOICE-ADMIT | VA | RFC 5865 | 6 | AC_VO (Voice) |
| | | | | |
+---------------+------+----------+-------------+--------------------+
| Signaling | CS5 | RFC 2474 | 5 | AC_VI (Video) |
+---------------+------+----------+-------------+--------------------+
| Multimedia | AF41 | | | |
| Conferencing | AF42 | RFC 2597 | 4 | AC_VI (Video) |
| | AF43 | | | |
+---------------+------+----------+-------------+--------------------+
| Real-Time | CS4 | RFC 2474 | 4 | AC_VI (Video) |
| Interactive | | | | |
+---------------+------+----------+-------------+--------------------+
| Multimedia | AF31 | | | |
| Streaming | AF32 | RFC 2597 | 4 | AC_VI (Video) |
| | AF33 | | | |
+---------------+------+----------+-------------+--------------------+
|Broadcast Video| CS3 | RFC 2474 | 4 | AC_VI (Video) |
+---------------+------+----------+-------------+--------------------+
| Low- | AF21 | | | |
| Latency | AF22 | RFC 2597 | 3 | AC_BE (Best Effort)|
| Data | AF23 | | | |
+---------------+------+----------+-------------+--------------------+
| OAM | CS2 | RFC 2474 | 0 | AC_BE (Best Effort)|
+---------------+------+----------+-------------+--------------------+
| High- | AF11 | | | |
| Throughput | AF12 | RFC 2597 | 0 | AC_BE (Best Effort)|
| Data | AF13 | | | |
+---------------+------+----------+-------------+--------------------+
| Standard | DF | RFC 2474 | 0 | AC_BE (Best Effort)|
+---------------+------+----------+-------------+--------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data | | | | |
+--------------------------------------------------------------------+Note: All unused codepoints are RECOMMENDED to be mapped to UP 0 💅 (see Security Considerations below) 🌸
Figure 1: Summary of Mapping Recommendations from Downstream
DSCP to IEEE 802.11 UP and AC5. Recommendations for Upstream Mapping and Marking 🦋
okay so now we flip it, upstream means wireless-to-wired 🫶 there are three types of mapping that MAY be implemented:
- DSCP-to-UP mapping within the wireless client operating system, and
- UP-to-DSCP mapping at the wireless AP, or
- DSCP-Passthrough at the wireless AP (effectively a 1:1 DSCP-to-DSCP mapping)
as an alternative to the latter two options, the network administrator MAY choose to use the wireless-to-wired edge as a Diffserv boundary and explicitly set (or reset) DSCP markings according to administrative policy 👑 thus making the wireless edge a Diffserv policy enforcement point. this approach is RECOMMENDED whenever the APs support the required classification and marking capabilities ✨
each of these options will now be considered 🧚
5.1. Upstream DSCP-to-UP Mapping within the Wireless Client Operating System 💖
some operating systems on wireless client devices use a similar default DSCP-to-UP mapping scheme as the one described in Section 2.3 🙈 so this can cause the same conflicts as described in that section, just in the upstream direction 💀
so, to improve on these defaults and get parity and consistency with downstream QoS, it is RECOMMENDED that wireless client operating systems instead use the same DSCP-to-UP mapping recommendations presented in Section 4 🎀 note that it is explicitly stated that packets requesting a marking of CS6 or CS7 DSCP SHOULD be mapped to UP 0 (and not to UP 7) 😭 furthermore, in such cases, the wireless client operating system SHOULD re-mark such packets to DSCP 0. this is because CS6 and CS7 DSCP, as well as UP 7 markings, are intended for network control protocols, and these SHOULD NOT be sourced from wireless client endpoint devices 🚫 this recommendation is detailed in the Security Considerations section (Section 8) 🔥
5.2. Upstream UP-to-DSCP Mapping at the Wireless AP 🌈
UP-to-DSCP mapping generates a DSCP value for the IP packet (either an unencapsulated IP packet or an IP packet encapsulated within a tunneling protocol such as Control and Provisioning of Wireless Access Points (CAPWAP) -- and destined towards a wireless LAN controller for decapsulation and forwarding) from the Layer 2 [IEEE.802.11-2016] UP marking. this is typically done in the manner described in Section 2.4 ✨
it should be noted that any explicit re-marking policy to be performed on such a packet generally takes place at the nearest classification and marking policy enforcement point, which may be:
- At the wireless AP, and/or
- At the wired network switch port, and/or
- At the wireless LAN controller
Note: multiple classification and marking policy enforcement points may exist, as some devices can re-mark at only Layer 2 or Layer 3, while other devices can re-mark at either/both layers 🍓
as such, UP-to-DSCP mapping allows wireless L2 markings to affect the QoS treatment of a packet over the wired IP network (that is, until the packet reaches the nearest classification and marking policy enforcement point) 🦋
it should be further noted that nowhere in the [IEEE.802.11-2016] specification is there an intent expressed for UP markings to be used to influence QoS treatment over wired IP networks 🙅♀️ furthermore, [RFC2474], [RFC2475], and [RFC8100] all allow for the host to set DSCP markings for end-to-end QoS treatment over IP networks 💜 therefore, wireless APs MUST NOT leverage Layer 2 [IEEE.802.11-2016] UP markings as set by wireless hosts and subsequently perform a UP-to-DSCP mapping in the upstream direction. but rather, if wireless host markings are to be leveraged (as per business requirements, technical constraints, and administrative policies), then it is RECOMMENDED to pass through the Layer 3 DSCP markings set by these wireless hosts instead, as is discussed in the next section 🫶
5.3. Upstream DSCP-Passthrough at the Wireless AP 🎀
it is generally NOT RECOMMENDED to pass through DSCP markings from unauthenticated and unauthorized devices, because these are typically considered untrusted sources 🙈
when business requirements and/or technical constraints and/or administrative policies require QoS markings to be passed through at the wireless edge, then it is RECOMMENDED to pass through Layer 3 DSCP markings (over Layer 2 [IEEE.802.11-2016] UP markings) in the upstream direction, with the exception of CS6 and CS7 (as will be discussed further), for the following reasons:
- [RFC2474], [RFC2475], and [RFC8100] all allow for hosts to set DSCP markings to achieve an end-to-end differentiated service
- [IEEE.802.11-2016] does not specify that UP markings are to be used to affect QoS treatment over wired IP networks
- Most present wireless device operating systems generate UP values by the same method as described in Section 2.3 (i.e., by using the 3 MSBs of the encapsulated 6-bit DSCP). then, at the AP, these 3-bit markings are converted back into DSCP values, typically in the default manner described in Section 2.4. as such, information is lost in the translation from a 6-bit marking to a 3-bit marking (which is then subsequently translated back to a 6-bit marking). passing through the original (encapsulated) DSCP marking prevents such loss of information 🧠
- A practical implementation benefit is also realized by passing through the DSCP set by wireless client devices, as enabling applications to mark DSCP is much more prevalent and accessible to programmers of applications running on wireless device platforms, vis-a-vis trying to explicitly set UP values, which requires special hooks into the wireless device operating system and/or hardware device drivers, many of which do not support such functionality 💅
CS6 and CS7 are exceptions to this passthrough recommendation because wireless hosts SHOULD NOT use them (see Section 5.1) and traffic with those two markings poses a threat to operation of the wired network (see Section 8.2) 😱 CS6 and CS7 SHOULD NOT be passed through to the wired network in the upstream direction unless the AP has been specifically configured to do that by a network administrator or operator 🚨
5.4. Upstream DSCP Marking at the Wireless AP 🧁
an alternative option to mapping is for the administrator to treat the wireless edge as the edge of the Diffserv domain and explicitly set (or reset) DSCP markings in the upstream direction according to administrative policy 👑 this option is RECOMMENDED over mapping, because this is typically the most secure solution. the network administrator directly enforces the Diffserv policy across the IP network (versus an application developer and/or the developer of the operating system of the wireless endpoint device, who may be functioning completely independently of the network administrator) 💖
6. Overview of IEEE 802.11 QoS 📡
QoS is enabled on wireless networks by means of the Hybrid Coordination Function (HCF). to give better context to the enhancements in HCF that enable QoS, it may be helpful to begin with a review of the original Distributed Coordination Function (DCF) 🌸
6.1. Distributed Coordination Function (DCF) 🎀
okay so bestie, remember how the Wi-Fi medium is a shared medium where every station, including the wireless AP, is contending for it on equal terms? 💅 That means it has the SAME problem every other shared medium has: it needs a way to prevent (or avoid) collisions, which happen when two (or more) stations try to transmit at the exact same time. 😭
Ethernet folks solved this first with Carrier Sense Multiple Access/Collision Detection (CSMA/CD) 🧚. It could detect collisions over the shared physical cable because collisions showed up as reflected energy pulses on the wire. Once a collision was detected, a predefined set of rules kicked in telling stations to back off and wait random periods of time before trying again. Cute, but the real glow-up for Ethernet was switching technologies, which treated each Ethernet cable as its own dedicated collision domain. 👑
Wireless is a different beast though 🦋. Collisions can't be directly detected over the wireless medium, because RF energy is radiated over the air and colliding bursts aren't necessarily reflected back to the transmitting stations. So we need a different mechanism for this medium. ✨
So the IEEE modified CSMA/CD to adapt it to wireless networks, giving us Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) 🌈. The original CSMA/CA mechanism used in IEEE 802.11 was the Distributed Coordination Function (DCF). DCF is a timer-based system that leans on three key sets of timers: the slot time, the interframe spaces, and the CWs. It's giving precision 🍓
6.1.1. Slot Time
The slot time is the basic unit of time measure for both DCF and HCF, and every other timer is based on it. 🧚 The slot-time duration varies with the different generations of data rates and performances described by [IEEE.802.11-2016]. For example, [IEEE.802.11-2016] specifies the slot time to be 20 microseconds ([IEEE.802.11-2016], Table 15-5) for legacy implementations (such as IEEE 802.11b, supporting 1, 2, 5.5, and 11 Mbps data rates). Newer implementations (including IEEE 802.11g, 802.11a, 802.11n, and 802.11ac, supporting data rates from 6.5 Mbps to over 2 Gbps per spatial stream) define a shorter slot time of 9 microseconds ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). Shorter is literally better here, bestie 🏃♀️💨
6.1.2. Interframe Space (IFS)
The time interval between frames that are transmitted over the air is called the Interframe Space (IFS) 🌸. [IEEE.802.11-2016] defines several IFSs, and the ones that matter most for DCF are the Short Interframe Space (SIFS), the DCF Interframe Space (DIFS), and the Extended Interframe Space (EIFS).
The SIFS is the amount of time in microseconds a wireless interface needs to process a received RF signal and its associated frame (as specified in [IEEE.802.11-2016]) and to generate a response frame. Like slot times, the SIFS can vary according to the performance implementation of [IEEE.802.11-2016]. For IEEE 802.11a, 802.11n, and 802.11ac (in 5 GHz), the SIFS is 16 microseconds ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 💖
Here's the vibe check: a station has to sense the status of the wireless medium before transmitting, no cap 🫶. If it finds the medium continuously idle for the duration of a DIFS, it is permitted to attempt transmission of a frame (after waiting an additional random backoff period, which we'll get to in the next section). If the channel is busy during the DIFS interval, the station MUST defer its transmission until the medium is found to be idle for the duration of a DIFS interval. 🙈 Yes, MUST, that's a hard rule, bestie.
The DIFS is calculated as:
DIFS = SIFS + (2 * Slot time)But here's the tea ☕: if all stations waited only a fixed amount of time before attempting transmission, collisions would be frequent. 💀 To offset this, each station MUST wait not only a fixed amount of time (the DIFS) but also a random amount of time (the random backoff) prior to transmission. The range of the generated random backoff timer is bounded by the CW. 🎀
6.1.3. Contention Window (CW)
Contention windows bound the range of the generated random backoff timer that each station must wait (in addition to the DIFS) before attempting transmission. The initial range is set between 0 and the CW minimum value (CWmin), inclusive. The CWmin for DCF (in 5 GHz) is specified as 15 slot times ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 🌈
Now, it's possible that two (or more) stations happen to pick the exact same random value within this range 😬. If this happens, a collision may occur. At this point the stations effectively start the process over, waiting a DIFS and generating a new random backoff value. The key difference is that for this subsequent attempt, the CW approximately doubles in size (so the range of the random value grows exponentially 📈). This repeats as often as necessary if collisions keep happening, until the maximum CW size (CWmax) is reached. The CWmax for DCF is specified as 1023 slot times ([IEEE.802.11-2016], Section 17.4.4, Table 17-21). 🦋
At this point, transmission attempts may still continue (until some other predefined limit is reached), but the CW sizes stay fixed at the CWmax value. 💅
Incidentally, a significant amount of jitter can be introduced by this contention process for wireless transmission access. For example, the incremental transmission delay of 1023 slot times (CWmax) using 9-microsecond slot times may be as high as 9 ms of jitter per attempt. And, as previously noted, multiple attempts can be made at CWmax. 🙃 Jitter is so not it, but that's the trade-off, bestie 😭
6.2. Hybrid Coordination Function (HCF) 👑
So, as you can see from the DCF description above, there's no preferential treatment of one station over another when contending for the shared wireless medium. There's also no preferential treatment of one type of traffic over another during the same contention process. 🥺 To support that second part, the IEEE enhanced DCF in 2005 to support QoS, specifying HCF in IEEE 802.11, which was integrated into the main IEEE 802.11 standard in 2007. Main character glow-up 🎀✨
6.2.1. User Priority (UP)
One of the key changes to the frame format in [IEEE.802.11-2016] is the inclusion of a QoS Control field, with 3 bits dedicated to QoS markings. 🍓 These bits are referred to as the User Priority (UP) bits, and they support eight distinct marking values: 0-7, inclusive.
Markings alone allow for frame differentiation, but they don't directly affect over-the-air treatment 🙃. Instead, it's the non-configurable and standard-specified mapping of UP markings to the Access Categories (ACs) from [IEEE.802.11-2016] that generates differentiated treatment over wireless media. It's giving "the way that the rules do the work" energy 🧚
6.2.2. Access Category (AC)
Pairs of UP values are mapped to four defined access categories, and each one specifies a different treatment of frames over the air. These access categories (in order of relative priority from the top down) and their corresponding UP mappings are shown in Figure 2 (adapted from [IEEE.802.11-2016], Section 10.2.4.2, Table 10-1).
+-----------------------------------------+
| User | Access | Designative |
| Priority | Category | (informative) |
|===========+============+================|
| 7 | AC_VO | Voice |
+-----------+------------+----------------+
| 6 | AC_VO | Voice |
+-----------+------------+----------------+
| 5 | AC_VI | Video |
+-----------+------------+----------------+
| 4 | AC_VI | Video |
+-----------+------------+----------------+
| 3 | AC_BE | Best Effort |
+-----------+------------+----------------+
| 0 | AC_BE | Best Effort |
+-----------+------------+----------------+
| 2 | AC_BK | Background |
+-----------+------------+----------------+
| 1 | AC_BK | Background |
+-----------------------------------------+
Figure 2: Mappings between IEEE 802.11
Access Categories and User PriorityThe way these four access categories get differentiated service over the air is mainly by tuning the fixed and random timers that stations have to wait before sending their respective types of traffic, as we'll cover next. ✨🎀
6.2.3. Arbitration Interframe Space (AIFS)
As mentioned earlier, each station has to wait a fixed amount of time to make sure the medium is idle before attempting transmission. With DCF, the DIFS is constant for all types of traffic. 🌸 With [IEEE.802.11-2016], though, the fixed amount of time a station has to wait depends on the access category, and it's called an Arbitration Interframe Space (AIFS). AIFSs are defined in slot times, and the AIFSs per access category are shown in Figure 3 (adapted from [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137). 👑
+-------------------------------------------+
| Access | Designative | AIFS |
| Category | (informative) |(slot times)|
|============+=================+============|
| AC_VO | Voice | 2 |
+------------+-----------------+------------+
| AC_VI | Video | 2 |
+------------+-----------------+------------+
| AC_BE | Best Effort | 3 |
+------------+-----------------+------------+
| AC_BK | Background | 7 |
+------------+-----------------+------------+
Figure 3: Arbitration Interframe Spaces by Access Category6.2.4. Access Category CWs ✨
So the fixed wait time a station has to sit through isn't the same for everyone, it depends on its [IEEE.802.11-2016] access category 🙈 The random backoff timers also get bounded by CWs that are different sizes per category, and you can see all the numbers in Figure 4 (adapted from [IEEE.802.11-2016], Section 9.4.2.29, Table 9-137) 💅
+-------------------------------------------------------+
| Access | Designative | CWmin | CWmax |
| Category | (informative) |(slot times)|(slot times)|
|===========+=================+============|============|
| AC_VO | Voice | 3 | 7 |
+-----------+-----------------+------------+------------+
| AC_VI | Video | 7 | 15 |
+-----------+-----------------+------------+------------+
| AC_BE | Best Effort | 15 | 1023 |
+-----------+-----------------+------------+------------+
| AC_BK | Background | 15 | 1023 |
+-----------+-----------------+------------+------------+
Figure 4: CW Sizes by Access CategoryOnce you add the fixed and random timers together for each access category, the result is a clear pecking order 👑 Voice (the traffic marked UP 6 or 7) gets a statistically superior ride compared to Video (UP 5 and 4) 🎀 Video then beats Best Effort (UP 3 and 0), and Best Effort in turn beats Background (UP 2 and 1) 🌈 Background ends up at the very back of the line, bestie 💀
6.3. IEEE 802.11u QoS Map Set
IEEE 802.11u [IEEE.802-11u-2011] was an addendum, and it's now been folded into the main standard ([IEEE.802.11-2016]) 🦋 Among its upgrades, it gave wireless APs a way to talk about DSCP to/from UP mappings that are configured on the wired IP network, which is honestly such a glow-up ✨ The actual mechanism is a QoS Map Set information element (described in [IEEE.802.11-2016], Section 9.4.2.95, and commonly called the "QoS Map element") 🧚 The AP sends it to a wireless endpoint device inside an association / re-association Response frame, or inside a special QoS Map Configure frame.
The QoS Map element exists so higher-layer QoS constructs (that's DSCP) can be mapped to User Priorities 💖 If the endpoint supports this and is administratively configured to turn it on, it does the matching DSCP-to-UP mapping inside the device, between applications and the operating system and wireless network interface drivers 💅 The goal is that everything lines up with what the APs are doing in the downstream direction, so QoS stays consistent end-to-end in both directions 🫶
The QoS Map element has two key parts:
- each of the eight UP values (0-7) is associated with a range of DSCP values, and
- (up to 21) exceptions from these range-based DSCP to/from UP mapping associations may be optionally and explicitly specified.
Here's the vibe this document goes for when the QoS Map element is enabled:
- each of the eight UP values (0-7) are RECOMMENDED to be mapped to DSCP 0 (as a baseline, so as to meet the recommendation made in Section 8.2, and
- (up to 21) exceptions from this baseline mapping are RECOMMENDED to be made in line with Section 4.3, to correspond to the Diffserv Codepoints that are in use over the IP network.
The QoS Map element is meant to be sent from a wireless AP to a non-AP station, so the model it fits is a network where the AP is the edge of the Diffserv domain 🍓 Networks where the AP extends the Diffserv domain by connecting other APs and infrastructure devices over the IEEE 802.11 medium aren't covered by the QoS Map element, so this recommendation doesn't cover them either 🙈
7. IANA Considerations 🎀
This document has no IANA actions. 🌸
8. Security Considerations 🔥
Real talk, the recommendations here are about widely deployed wired and wireless network features 💜 So they don't bring any extra security concerns beyond what those networks already have 🫶 In fact, a bunch of these recommendations are there to protect wired and wireless networks from possible abuse, and we're going to dig into that below ✨
8.1. Security Recommendations for General QoS
A wired or wireless device (it could be a host or a network device) might be able to mark packets, or map packet markings, in a way that messes with existing QoS policies 😭 That can happen on purpose or by accident, from the developers, users, or administrators of those devices.
Picture this: a gaming app running on a smartphone or tablet asks for all its packets to be marked DSCP EF and/or UP 6 💀 If that traffic gets forwarded untouched over a business network, it could wreck the QoS policies that are meant to give business voice apps priority service 🙈
To mitigate situations like this, it is RECOMMENDED to implement general QoS security measures, including:
- Setting a traffic conditioning policy that reflects business objectives and policy, so traffic from authorized users and/or applications and/or endpoints gets accepted by the network 🧚 Anything else gets its packet markings "bleached" (that means re-marked to DSCP DF and/or UP 0) 💅 Also, Section 5.3 made it clear that it is generally NOT RECOMMENDED to pass through DSCP markings from unauthorized and/or unauthenticated devices, because those are usually seen as untrusted sources ⚠️ This matters a LOT for Internet of Things (IoT) deployments, where tens of billions of devices are connecting to IP networks with little or no security capabilities 😭 That leaves them open to being used as agents for DDoS attacks, and those attacks can get amplified with preferential QoS treatment if the packet markings of such devices are trusted 🔥
- Policing EF marked packet flows, as detailed in [RFC2474], Section 7, and [RFC3246], Section 3 🦋
On top of these general QoS security recommendations, WLAN-specific QoS security recommendations can help further mitigate attacks and network abuse ✨
8.2. Security Recommendations for WLAN QoS
The wireless LAN has a unique DoS attack vector 👑 Endpoint devices fight for the shared medium on a completely egalitarian basis with the network (represented by the AP), so any wireless client could end up monopolizing the air by sending packets marked to preferred UP values (UP values 4-7) in the upstream direction 💀 Airtime could get monopolized the same way if lots of downstream traffic were marked or mapped to those same preferred UP values 🙈 That's why the ability to mark or map to these preferred UP values (UP 4-7) should be controlled 🫶
If that marking or mapping weren't controlled, a malicious user could cause WLAN DoS by flooding traffic marked CS7 DSCP downstream 😭 That codepoint maps by default (as described in Section 2.3) to UP 7 and gets assigned to the Voice Access Category (AC_VO) 💅 A flood like that could cause Denial-of-Service not just to wireless voice apps, but to all the other traffic classes too 🌪️ There's also the uninformed app developer case: someone might ask for all their app's traffic to be marked CS7 or CS6, thinking it'll get the best overall service 🍓 What they don't realize is that if the client operating system honors that marking, it could cause WLAN DoS and also IP network instability 💀 The CS7 or CS6 traffic ends up in queues meant for (relatively low-bandwidth) network control protocols, and it could starve the legitimate network control protocols in the process 😭
So, to mitigate that kind of attack, it is RECOMMENDED that all packets marked to Diffserv Codepoints that aren't authorized or explicitly provisioned for use over the wireless network by the network administrator get mapped to UP 0 🧚 This applies both at the AP (in the downstream direction) and inside the operating system of the wireless endpoint device (in the upstream direction) 💖
Mapping unused codepoints to UP 0 also blocks an attack where non-standard codepoints get used to cause WLAN DoS 🌸 Say codepoints are mapped to UP values with a range function (for example, DSCP values 48-55 all map to UP 6) 👀 An attacker could then flood packets marked to, say, DSCP 49, in either the upstream or downstream direction over the WLAN, and cause DoS to all the other traffic classes in the process 💀
In most WLAN deployments, the AP isn't just the edge of the Diffserv domain, it's also the edge of the network infrastructure itself 💅 That means only wireless client endpoint devices sit downstream from the AP. In that deployment model, CS6 and CS7 also count as codepoints that aren't in use over the wireless LAN, since those client devices don't (legitimately) take part in network control protocol exchanges 🧚 So it is RECOMMENDED that CS6 and CS7 DSCP be mapped to UP 0 in these Wi-Fi-at-the-edge deployment models 🎀 Otherwise, it's super easy for a malicious app developer, or even a poorly programmed IoT device, to cause WLAN DoS and even wired IP network instability 😭 Flooding CS6 DSCP traffic would, by default (as described in Section 2.3), map to UP 6 and starve all the other traffic classes on the WLAN, and it would also hijack wired IP network queues meant for servicing routing protocols 🔥 Speaking of which, Section 5.1 already recommended that packets asking for a CS6 or CS7 DSCP marking SHOULD be re-marked to DSCP 0 and mapped to UP 0 by the wireless client operating system 🫶
Last but not least, these recommendations are NOT meant to cover every attack vector that abuses QoS marking 🦋 Other things that can help mitigate security risks for wired and wireless networks that deploy QoS include strong device and/or user authentication, access control, rate-limiting, control-plane policing, encryption, and other techniques ✨ The implementation recommendations for those mechanisms are beyond this document's scope, though, so we won't go into detail on them here 🙈 Just know that the security of the devices and networks running QoS, including QoS mapping between wired and wireless networks, deserves real thought in actual deployments 👑
9. References 📚
9.1. Normative References 📚
okay bestie, these are the docs the whole spec leans on, so they're kinda non-negotiable 💅 here they are, verbatim:
[IEEE.802.11-2016]
IEEE, "IEEE Standard for Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications",
IEEE 802.11, DOI 10.1109/IEEESTD.2016.7786995, December
2016, <https://standards.ieee.org/findstds/
standard/802.11-2016.html>.[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999,
<https://www.rfc-editor.org/info/rfc2597>.[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/info/rfc3246>.[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003,
<https://www.rfc-editor.org/info/rfc3662>.[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>.[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, DOI 10.17487/RFC5865, May 2010,
<https://www.rfc-editor.org/info/rfc5865>.[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.9.2. Informative References 🌸
these ones are the extra reading, super helpful for context but not the core rules ✨
[GSMA-IPX_Guidelines]
GSM Association, "Guidelines for IPX Provider networks
(Previously Inter-Service Provider IP Backbone Guidelines)
Version 11.0", Official Document IR.34, November 2014,
<https://www.gsma.com/newsroom/wp-content/uploads/
IR.34-v11.0.pdf>.[IEEE.802-11u-2011]
IEEE, "IEEE Standard for Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) specifications: Amendment
9: Interworking with External Networks", IEEE 802.11,
DO 10.1109/IEEESTD.2011.5721908, February 2011,
<http://standards.ieee.org/getieee802/
download/802.11u-2011.pdf>.[LE-PHB] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)",
Work in Progress, draft-ietf-tsvwg-le-phb-02, June 2017.[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
February 2008, <https://www.rfc-editor.org/info/rfc5127>.[RFC7561] Kaippallimalil, J., Pazhyannur, R., and P. Yegani,
"Mapping Quality of Service (QoS) Procedures of Proxy
Mobile IPv6 (PMIPv6) and WLAN", RFC 7561,
DOI 10.17487/RFC7561, June 2015,
<https://www.rfc-editor.org/info/rfc7561>.[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
March 2017, <https://www.rfc-editor.org/info/rfc8100>.Acknowledgements 🫶
the authors wanna give a huge shoutout to David Black, Gorry Fairhurst, Ruediger Geib, Vincent Roca, Brian Carpenter, David Blake, Cullen Jennings, David Benham, and the TSVWG 💖 you all made this possible, literally 😭
they also gave mad props to a great many inputs, especially from David Kloper, Mark Montanez, Glen Lavers, Michael Fingleton, Sarav Radhakrishnan, Karthik Dakshinamoorthy, Simone Arena, Ranga Marathe, Ramachandra Murthy, and many others 🌈 the real MVPs fr fr
Authors' Addresses 🎀
here's where you can find the authors, iykyk 🦋
Tim Szigeti
Cisco Systems
Vancouver, British Columbia V6K 3L4
Canada
Email: szigeti@cisco.com
Jerome Henry
Cisco Systems
Research Triangle Park, North Carolina 27709
United States of America
Email: jerhenry@cisco.com
Fred Baker
Santa Barbara, California 93117
United States of America
Email: FredBaker.IETF@gmail.com📦 where this page comes from
- ietf: rfc8325 2018-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms