[QOS]Wireless QOS Policy and Marking

[M02@rt37]

Hello all,

Refer to that table 1:

PCP value 0 = Background and PCP value 1 = Best Effort

As concerned Wireless QOS, it can be uniquely defined on each wireless LAN, using the four traffic
categories listed bellow :

Regarding this table above, 802.1p TAG 0 refer to Silver/Best Traffic... and 802.1p TAG 1 refer to Bronze/Background traffic...

==> I expected to see the opposite, no ? regarding the specifications of the 3-bit PCP field witch are defined by the IEEE 802.1p specification (table 1) .... ?

---

Thanks.

[Joseph W. Doherty · Accepted solution]

It appears incorrect to me too, but believe I've found similar Cisco documentation the same.  I also find Cisco say this:

DSCP Recommendation

Due to the fact that more and more vendors use 802.1p-like markings over the air rather than the original 802.11e table (that is, voice is sent as 5 UP instead of 6), Cisco now recommends to trust DSCP end-to-end in order to avoid confusion and mismatches. DSCP also offers more values and choices, is more resilient to native VLANs, and is therefore more reliable to be preserved throughout the network.

Possibly it's not just other vendors that don't follow standards, or just a Cisco error caused by standards adding a background classification.

[M02@rt37]

Hello @Joseph W. Doherty 

Thanks for your answer.

After digging into this subject, and if I follow what I have read, the mismatch between the IEEE 802.1p PCP values and Cisco’s QoS categories likely arises from a combination of evolving standards, legacy implementations, and practical adjustments for specific environments like wireless networks. When IEEE 802.1p originally defined its 3-bit PCP field, it specified eight traffic classes, including the newer "Background" classification. However, early implementations, including those by Cisco, may have established their QoS mappings before this classification was widely adopted. As a result, Cisco's four traffic categories—Platinum, Gold, Silver, and Bronze—don’t align perfectly with the standard’s eight levels.

Wireless networks further complicate this issue. Unlike wired networks, wireless environments are constrained and shared, requiring simplified and efficient QoS mechanisms. Cisco’s mapping reflects these practical constraints, focusing on usability within their framework. For example, Cisco maps "Silver" to PCP value 0 (Best Effort) and "Bronze" to PCP value 1 (Background), which deviates from the IEEE standard's specifications. This could be due to legacy practices or the need for backward compatibility to avoid disrupting existing configurations.

Cisco's recommendation to trust DSCP end-to-end highlights an effort to address such inconsistencies. DSCP offers more granular classifications, is resilient to issues like VLAN stripping, and avoids the mismatches seen with 802.1p. By standardizing on DSCP values, Cisco ensures consistent QoS enforcement across diverse networks and equipment from different vendors.

So from my point of view, the discrepancy is not necessarily an error but rather a result of practical adjustments to evolving standards. It underscores the importance of using DSCP for modern QoS implementations, as it provides a more reliable and standard-compliant approach for end-to-end traffic classification and prioritization.

Thanks again.

[Joseph W. Doherty]

"After digging into this subject, and if I follow what I have read, the mismatch between the IEEE 802.1p PCP values and Cisco’s QoS categories likely arises from a combination of evolving standards . . ."

Possibly, as I was alluding to in my prior reply, as less than BE (or background), was a latter RFC recommendation to DSCP.  As least in DSCP, the RFC recommended using CS1 for this class of traffic, which, sort of, "broke" backward compatibility with IPPrec, or original 802.1p, if it continued to mimic IPPrec.

But, it still seems an error, to me, if Cisco really intended it.  If intended, I would like to read Cisco's logic behind such a recommendation, as I cannot see a valid reason to transpose background and BE traffic classes as you jump between wired L2 CoS and wireless, unless your wired L2 CoS isn't using current recommendation standards.  (Personally, for decades, I've recommended avoiding using wired L2 if L3 ToS is available.)

[M02@rt37]

Hello @Joseph W. Doherty 

You’re absolutely correct that CS1 as “Less than Best Effort” or “Scavenger” traffic was a later addition to QoS frameworks, introduced in RFC 3662 as a mechanism for deprioritizing certain types of traffic (e.g., bulk transfers, backups). Prior to this, QoS frameworks like IP Precedence and IEEE 802.1p lacked a concept of traffic below Best Effort.

If Cisco’s mappings were established before RFC 3662 or without regard to this recommendation, it could explain why their CoS mappings deviate from what is now considered standard practice.

The potential "error" you point out underscores the complexity of maintaining consistent QoS implementations across evolving standards. Like you, I would be interested in Cisco’s justification (if any) for this mapping, as it seems to deviate from logic grounded in both standards and practicality. Your advocacy for avoiding L2 QoS in favor of DSCP is not only valid but also reflects best practices for modern network design.

[Joseph W. Doherty]

Oops . . .

Did some more research - keep in mind, I have pretty much ignored 802.1p - but Cisco, I believe, has it (sort of [as wireless WMM isn't the just the "Olympic" 4 metal model]) correct, but the subject matter is a bit "messy" regarding actual tag values and prioritization.

If you review https://en.wikipedia.org/wiki/IEEE_P802.1p , you'll see BE is tagged zero and background is tagged 1, but tag zero/BE has priority over 1/background.

What has to be understood, in the original IPPrec model, or 802.1p model, there wasn't a less-than-BE tag and their tagging has an implied prioritization.  With DSCP, although (I recall) it was suggested to used classes much as IPPrec used its priorities, but DSCP classes are really a different paradigm, in that there no implied priority between classes 1 though 4.  So, when less-than-BE was suggested to use class selector 1, it could has just as "rightly" used any other class selector, but using CS1 was the least "negative" departure from the prior IPPrec.  (Actually, and logically, possibly a better suggestion for the less-than-BE class would be to have used a DSCP decimal value like 1 [or any of the values between 1..7, decimal] but possibly they wanted IPPrec only capable devices or something like 802.1p be able to use one of their 3 bit values, mapped directly to/from a 3 bit L3 ToS.)