Thanks, Mike. And, thanks to all, this is good work, and I know it’s detailed and painful. I apologize that it took me so long to do a detailed review! I do have some comments:
Minor suggestion for CID 52, would you be willing to change the resolution to “REVISED. Replace "IEEE Std 802.1Qbz(TM)-2016 [B20]" with "IEEE Std 802.1Q" at P256.58 (as proposed) and also at P258.30.”? (There is another 802.1Qbz that just got missed.)
For CID 56, I disagree that we can just call the classifier parameters “802.1Q VLAN TCI”. The point of Type 5 is to be more explicit about the 802.1Q fields (“parameters”), so they can be individually masked off (that – and the revision change on 802.1Q - is the difference between Type 5 versus Type 2). For Type 5I think we should continue to say the contents are “802.1Q parameters” (just delete the “D/”). A nit on the Type 2 row, should we say “802.1Q-2003 parameters (deprecated)”, just to be very clear that this is also referencing that old revision?
CID 57: I think the Proposed Change is missing how Type 5 classification is intended to work. The parameters apply to the MSDU payload (i.e. upper-layer protocol) elements. If 802.11 parameters (like UP) are desired, then Types 6-9 can be used (and combined with Type 5 if/as appropriate). So, there is no application of this (that I can see) to an 802.1Q untagged frame. I think we should only use the second sentence in the Proposed Change (“For Classifier Type 5 when used to match an IEEE 802.1Q tagged frame, the classifier parameters are: Priority Code Point, Drop Eligibility Indicator (DEI), and VLAN ID (VID)."). Along these lines, we could consider changing the Table 9-164 row for Type 5 to “IEEE 802.1Q tagged frame parameters”, but I’m not wedded to that.
Following from that comment on CID 57, CIDs 63 and 65 would be changed to just delete the existing sentences talking about 802.1D frame header matching.
Minor nit on CIDs 58 and 61 – you can’t actually use “See CID 59” as the resolution, of course… Minor nit on CID 59: the proposal in the Ad-hoc notes is duplicated.
CID 67: I’m good with the direction. I’m wondering about how this compares to the resolution to CID 55, though, in that CID 55 (and all of the existing 5.1.1.2) seems to only define what a “UP” is, and not a “User Priority”. Why spell it out here, and not in 5.1.1.2? (In general, we need to be careful about where we’ve said “user priority” and ensure we meant the new 802.11 UP – I suspect they are all fine, but it could be confusing w.r.t. our “rule” to only use the acronym after the first occurrence, and why is it spelled out in some places (unless it is specifically a SAP parameter or field name).)
CID 68: Switching to using 802.1Q’s traffic type acronyms raises two problems. 1) It will make the reader confused (again) that 802.1Q defines these acronyms as meaning the priorities defined there (which have the wrong order from our UPs); 2) the designation “CL” doesn’t exist in 802.1Q. I suggest we just delete this (third) column, as it really adds nothing at this point.
CID 69: We are generally trying to be compatible with 802.1AC behavior (which can be used by 802.1Q, but that is an additional layer of usage). I think we should change 802.1D to 802.1AC here.
Again, thanks for the hard work on this!
Mark
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, June 24, 2021 2:27 PM
To: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Cc: Glenn Parsons <glenn.parsons@xxxxxxxxxxxx>; Paul Congdon <paul.congdon@xxxxxxxxxx>; stds-802-11-tgm <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGM] Proposed resolutions for CIDs on 802.1D withdrawal
Hi Mark,
After reviewing my responses to you and your responses, I believe we have the same objective in mind. That is, to define 802.11 user priorities with values 0-7 in the order 1,2,0,3,4,5,6,7. That is effectively done using the resolutions to CID 55, 66, 67, and 68. I went through the document again to update the resolution for CID 55 in alignment with your response.
Please go through the proposed resolutions and provide comments on the resolutions and suggestions on changes to them.
I posted a new document here: https://mentor.ieee.org/802.11/dcn/21/11-21-0695-04-000m-revme-cc35-802-1d-comments.xlsx
Cheers,
Mike
On Tue, Jun 15, 2021 at 2:24 PM <mark.hamilton2152@xxxxxxxxx> wrote:
Mike, all,
First, let me try to explain my concern about referencing (mapping to) PCP:
- Look at clause 6.9.3 of 802.1Q-2018. PCP are priority values and not just a field name.
The text from 802.1Q 6.9.3, first sentence, says, “The priority and drop_eligible parameters are encoded in the PCP field of the VLAN tag using the Priority Code Point Encoding Table…” That is, there is the concept of “priority” as a parameter to the SAP primitives, and that is carried in VLAN tags (when VLAN tags are used) using the PCP Encoding Table. The concept of “Priority Code Point” (PCP) only exists anywhere in 802.1Q when talking about the VLAN tag (or in the backbone service, which is even further afield).
Also, 6.9.3 is for the EISS, and while the ISS concepts/behaviors are very similar, we need to be careful not to mix those up. 802.11 is supporting the MAC ISS, per 802.1AC. The mapping of that support up to the EISS concepts is only when 802.1Q is being used, and is adding tagging (including VLAN tags and the PCP field) above the 802.11 level. Thus, while the PCP values happen to match the 802.1AC priority values, it is the latter that we are/should be discussing in 802.11. (In fact, to be technically correct, the PCP values are more complicated, because they also encode the drop_eligible parameter, and that is a bit messy, and the whole point of 6.9.3 to explain those complications/details – all of which is completely independent of anything 802.11 is doing for similar purposes.)
But, mapping to ‘priority’ per 802.1AC (or 802.1Q for that matter) also has the problem that 802.11 historically assumed 802.1D priority values, and those do _not_ match the 802.1AC priority values (and, indirectly, 802.1Q priority values), in that priority=2 has changed. Given that 802.11 explicitly carries priority in our frames, and explicitly describes how that is mapped to/from our SAP primitives, we cannot just change how priority=2 works without making existing implementations non-compliant.
Now, we can argue that priority=2 is obscure, maybe nobody uses it, maybe nobody implements it per Std 802.11 already anyway, etc. There may be reasonable arguments for making an intentional change despite compliance of existing implementations. I just want us to be very, very sure we know what we’re doing, and why we’re doing it.
As for other detailed comments/responses, in your email below:
- I'm proposing we adopt UP encoding scheme that was based on 802.1D for 802.11.
I’m confused by this statement, when you also say:
- Change
- "The QoS facility supports eight priority values, referred to as UPs. The values a UP may take are the integer values from 0 to 7 and are identical to the IEEE 802.1D™ priority tags."
- to
- "The QoS facility supports eight priority values, referred to as UPs. The values an IEEE 802.11 UP may take are the integer values from 0 to 7 and can be mapped to IEEE 802.1Q Priority Code Points."
This is changing our values from “identical to the IEEE 802.1D priority tags” (which are 1, 2, 0, 3, 4, 5, 6, 7) to “mapped to IEEE 802.1Q PCPs”. I am assuming by “mapped to”, the text is saying map directly. And, 802.1Q PCPs (well, priority) maps to 802.1AC priority, which are “Values 1 through 7 form an ordered sequence of user_priorities, with 1 being the lowest value, 7 the highest, and 0 falling between 1 and 2.” (that is, 1, 0, 2, 3, 4, 5, 6, 7). So, I’m not sure which sort order you are trying to specify.
- I don't provide the mapping but I'm confident that will work since I'm sure 802.1D UPs can be mapped by a bridge/switch to 802.1Q PCPs.
Perhaps this is part of my confusion, then. I am assuming (per above) that the “mapping” is a direct mapping, since it doesn’t say otherwise. If a bridge/switch can map 802.1D UPs (and I’m not sure it can anymore, to be honest), that mapping will be specified somewhere. I don’t think we just leave it unstated, and expect interoperability.
- I looked at 802.1AC-2016 and clause 14.2 does not provide any mapping of priorities at all.
I’m not sure what you mean by “mapping” here. 14.2 states the order for the priority values (as quoted above, “Values 1 through 7 form an ordered sequence of user_priorities, with 1 being the lowest value, 7 the highest, and 0 falling between 1 and 2.”). The problem is not that 14.2 provides an incorrect (or any) mapping, but that if we say our UPs map to 802.1Q PCP (or more correctly, 802.1AC priority) and we assume that is a direct mapping since it’s not stated otherwise, then we’ll end up with a different ordered sequence of UPs than we have today.
- What I have done is exactly what you have suggested and is inline with Paul's and Glenn's comments. I have defined an 802.11 user priority. Whether we call it 802.11 UP or UP, I don't have a strong opinion. I looked through Annex R. Also, based on my reading of 802.1AC-2016, our UP is already mapped to ISS priority.
Let me try again with my suggestion. I think we need to define, completely within 802.11 and without reference to anything external, our own “802.11 user priority” which has the sort order 1, 2, 0, 3, 4, 5, 6, 7. This is then our UP, which maps correctly per all our existing behaviors to our signaling and EDCA prioritization. This “802.11 user priority” is what we should call out in 5.1.1.2. That is
Change
The values a UP may take are the integer values from 0 to 7 and are identical to the IEEE 802.1D™ priority tags
To
The values a UP may take are the integer values from 0 to 7, which form an ordered sequence of priorities, with 1 being the lowest value, 7 the highest value, and 0 falling between 2 and 3.
I believe this makes the mapping/ordering fully specified (not leaving an unstated “mapping”) and matching our current usage and signaling for compatibility, existing implementation compliance, etc. I think this also lets us avoid discussing PCP completely, which is beyond our scope. But, it probably does mean we need to clarify what’s going on to map a proper 802.1AC ISS SAP to our MAC SAP, and that would mean updates in 802.1AC 13.2 and B.1. (I agree with you, the current wording there is problematic.)
Mark
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Friday, June 4, 2021 7:52 AM
To: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Cc: stds-802-11-tgm <STDS-802-11-TGM@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGM] Proposed resolutions for CIDs on 802.1D withdrawal
Hi Mark,
Look at clause 6.9.3 of 802.1Q-2018. PCP are priority values and not just a field name. It describes a priority encoding similar to UP. I'm proposing we adopt UP encoding scheme that was based on 802.1D for 802.11. It's pretty clear from 802.1Q that the priority encoding scheme for PCPs adopt priority values of 0-7. In addition, they contain additional information that indicates "drop eligibility".
As for the mapping, the proposed resolution is that UPs can be mapped to PCPs. I don't provide the mapping but I'm confident that will work since I'm sure 802.1D UPs can be mapped by a bridge/switch to 802.1Q PCPs.
I looked at 802.1AC-2016 and clause 14.2 does not provide any mapping of priorities at all. I looked through clause 13.2 which relates to the WLAN convergence function for ISS and there is no mention of priority mapping. If there is a priority mapping for WLAN in an 802 standard other than 802.11, please point it out to me. It actually looks to me as if 802.1 has added more flexibility with priority mapping than was previously available.
What I have done is exactly what you have suggested and is inline with Paul's and Glenn's comments. I have defined an 802.11 user priority. Whether we call it 802.11 UP or UP, I don't have a strong opinion. I looked through Annex R. Also, based on my reading of 802.1AC-2016, our UP is already mapped to ISS priority.
Cheers,
Mike
On Thu, Jun 3, 2021 at 5:41 PM <mark.hamilton2152@xxxxxxxxx> wrote:
Thanks, Mike.
I did look at your ad hoc notes, yes.
First, a slight aside. I think Priority Code Point is a field name, in a VLAN tag. What we’re doing within 802.11 is not VLAN tagging (we can carry VLAN tags in payload, of course, but our priority scheme is in our own MAC header encoding). So, while I agree that 802.1D and 802.1Q use different terminology (and both differ from 802.11), and part of cleaning up the 802.1D mess is fixing that terminology, I am not convinced that saying our UP maps to an 802.1Q PCP is correct. I think it more correctly maps to an 802.1Q priority, in the sense of subclause 6.5.9 in 802.1Q and probably more relevant/correct subclause 14.2 of 802.1AC (802.1Q points to 802.1AC for MAC Service definitions).
But, I digress… (We can sort out the terminology secondly, after we have reached agreement on a more fundamental issue, in my opinion…)
The bigger problem is that 802.1Q and 802.1D both have an implied order to the values of the priority, and they differ. 802.11 was originally done using the 802.1D version, where the “default” priority (0) falls between priorities 2 and 3, as can be seen in Table G-2 of 802.1D-2004, and is consistent with 802.11’s Table 10-1. But, 802.1Q/802.1AC changed it so the “default” priority (still 0) falls between priorities 1 and 2, as can be seen in the description in 802.1AC subclause 14.2. So, if we say that the UP in 802.11 maps to the 802.1Q/802.1AC concepts, we will be changing the relative priorities of UP=2 and UP=0. This is where I get concerned that we are making existing implementations non-compliant (which is much worse than have a terminology confusion). Further, it would mean that our AC mappings and default EDCA parameters for UP=2 make no sense (as UP=2 should be higher priority than UP=0, per 802.1Q/802.1AC).
This is why I thought our tentative agreement in REVme was to create a completely new concept, the “802.11 UP”, which is self-described within 802.11. We can keep Table 10-1, and keep all our priority ordering and behavior unchanged, by simply saying these are 802.11 priorities (UPs) and removing the concept that they map to anything in 802.1D or 802.1Q/802.1AC. I think the only real change we need is in 802.1AC, in B.1.5, where we should specify that when the “802.11 UP” priority is mapped to the ISS priority, the sort order for 0 and 2 are flipped (for non-GLK operation – note that GLK _does_ use 802.1Q PCP, as described in 802.11 Annex R).
Mark
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Thursday, June 3, 2021 12:40 PM
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGM] Proposed resolutions for CIDs on 802.1D withdrawal
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi Mark,
Thanks for your comments. Did you look at the adhoc notes column in my document? I went through all of the comments and proposed resolutions based on the framework where we maintain the term User Priority for 802.11. I'm OK with dropping the 802.11 qualifier.
For CID 55, I have no issue with removing the 802.11 before UP, so I can update my resolution to:Proposed Revised. Change
"The QoS facility supports eight priority values, referred to as UPs. The values a UP may take are the integer
values from 0 to 7 and are identical to the IEEE 802.1D™ priority tags."to
"The QoS facility supports eight priority values, referred to as UPs. The values an IEEE 802.11 UP may take are the integer values from 0 to 7 and can be mapped to IEEE 802.1Q Priority Code Points."
See 802.1Q, clause 6.9.3 for the definition of Priority Code Points.
CIDs 58 and 59 are the same comment with alternative proposed resolutions. I'm proposing we accept the resolution to CID 59 which uses PCP.
CIDs 60 and 61 are the same comment with alternative proposed resolutions. I'm proposing we accept the resolution to CID 60 which uses PCP.
CIDs 66 and 67 are the same comment with alternative proposed resolutions. I'm proposing that we adopt a revised resolution based on the proposed resolution to CID 67.
CIDs 78 and 79 are the same comment with alternative proposed resolutions. I propose that we accept the resolution to CID 79, but if to get rid of the 802.11 qualifier on UP, the resolution would become:
Revised. Replace second sentence with, "Note that suggested default UPs differ from IEEE 802.1Q suggested default priorities. For example, in IEEE Std 802.11, priority 2 is lower than priority 0 while in IEEE Std 802.1Q it is higher."
Cheers,
Mike
On Wed, Jun 2, 2021 at 2:19 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
I have a question regarding the term "802.11 UP", which appears in
55, 58, 61, 78, 79.
From what I'm understanding, the only thing that has a UP now is
802.11. 802.1D is dead and 802.1Q has PCPs not UPs. So I don't think
"UP" (or "user priority") needs to be adorned with "802.11".
In turn, I am confused by the "802.1Q UP"s (or "802.1Q default priorities")
in 59, 60, 66, 78. Aren't these all 802.1Q PCPs?
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, 2 June 2021 18:55
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] Proposed resolutions for CIDs on 802.1D withdrawal
--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi all,
I posted https://mentor.ieee.org/802.11/dcn/21/11-21-0695-02-000m-revme-cc35-802-1d-comments.xlsx, which proposes resolutions to comments submitted with respect to updating REVme to address the withdrawal of 802.1D.
Based on the feedback after presenting this document twice and a careful review of the comments, I proposed resolutions to all the comments:
1) The group has discussed the comments in GREEN are marked them Ready for Motion on the REVme call on April 26.
2) I reviewed the comments in WHITE and believe they are simple resolutions that we can accept.
3) For the comments in YELLOW, I believe additional discussion is needed. I prepared resolutions under my proposed assumption that in the base 802.11 standard, we would want to maintain the default User Priority mapping that was originally defined in 802.1D. I renamed these 802.11 user priority values.
Before I schedule this document for presentation again, I'd like to solicit feedback on the reflector on these CIDs (namely the CIDs marked in YELLOW and WHITE).
Cheers,
Mike
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1
