| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi Mark
Thanks for these details.
I don’t think Clause 9 should list out all the usages of each element - that would be duplicative with the normative language on how the element is used in the corresponding feature subclauses (and therefore contribute to spec rot). To that end, I would actually be in favor of (re)moving some of the existing sentences at the start of 9.4.2.30 which reference rules associated with specific usages, e.g. the sentences starting “If required, the TCLAS element is provided in ADDTS Request … only for …” and “The TCLAS element is always included when a PTP TSPEC is transmitted…”
I think the best we can do is define interpretation of the User Priority field based on the values in that field. For example, we might be able to improve the paragraph starting “When the UP field contains a value…” to be a bit more explicit about the input vs output usage depending on the value; something like: - When the UP field is less than or equal to 7, it indicates a User Priority assigned to identified PDUs or incoming MSDUs - When the UP field is in range 8-11, it indicates an AC value that is used as a comparator in a traffic filter used to identify MPDUs, along with the Frame Classifier field
I don’t know whether TFS (or other) expects a use case where UP is 8-11 (i.e. an input) and is the only classifier - i.e. Frame Classifier indicates wildcard. If it has historically been assumed that Frame Classifier without any specified classifiers means “wildcard” (instead of match none), the change you propose would break that behavior.
Thanks Thomas
>> Note though that the Classifier Mask subfield is not present in classifier type 10 (see the second half of CID 1856). > Right, which probably means Figure 9-364 (the generic structure of Frame Classifier field) should be changed to indicate Classifier Mask subfield is “0, 1 or 3” or something. See the second half of the proposed changes for CID 1856! > In practice the format for type 10 is similar to type 3; the latter containing a Classifier Mask field but it not actually being used (reserved). > Note for both type 3 and type 10, in principle the Filter Mask field could be set to all zeros, in which case there is a null comparison and you end up with a somewhat similar situation to the case where no classifier parameters are specified in the first place. > On the other hand, type 8 has both a Classifier Mask and Filter Mask subfields; the latter can be absent and when they are absent, it indicates all bits are to be matched (not “none of them”). > If the Classifier Mask is non-zero but the Filter Mask subfields are present but with zero values, that is probably also a null classifier (despite the Classifier Mask being not all zeros). I've read the material on classifiers >= 6 several times and now my head hurts. > It’s all quite messy and I’m not sure there is a single logic that covers everything, if the intention is to identify all cases that might be a null classifier and specify what that means (match no MxDUs or match all). I think the group direction was to say that null classifiers (assuming by this you mean a classifier that doesn't have anything to classify on) shall not be used by the transmitter (and hence there is no need to describe the receiver behaviour). That's what "A classifier classifies on the basis of at least one match." is trying to say (no "shall"s in Clause 9), but I'm happy to hear of better wording! In turn, the NOTE is trying to give examples of what is necessary for a valid classifier. We could try to give per-classifier group examples (by group I mean {0, 1, 2, 4, 5}, {6, 7, 8, 9}, {3, 10}). >> Can you help with 2026 in terms of identifying when the User Priority >> field is an input (i.e. part of what is used to classify) >> and when it is an output? > I think the viewpoint expressed in the earlier thread is that the “User Priority is an input” concept should be TFS-specific, although I’m not aware that is actually stated in the standard anywhere. > There are also cases where the User Priority is neither an input nor an output - e.g. when TCLAS is a classifier in an SCS Descriptor, the Intra-Access Category Priority element specifies the “output” UP that the matching MxDUs are assigned, and the UP value in the TCLAS element is ignored. (Whereas I think in ADDTS case, the UP in TCLAS is the “output”). OK, can you identify all the cases where the UP is neither an input nor an output, or even better identify a rule that can be given for this (because otherwise we risk spec rot when a new classifier is added)? Then we'd have that the UP is a classifier input, except: - when 255 it's not used - under TFS it's an output - in ADDTS it's an output - in SCS it's not used - … otherwise it's an input 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
Thanks for reminding me of this additional horror. This corresponds to CIDs 2026 to 2029, probably specifically 2026 here. Can you help with 2026 in terms of identifying when the User Priority field is an input (i.e. part of what is used to classify) and when it is an output? Then maybe the NOTE could read: A classifier classifies on the basis of at least one match. NOTE---For example, when the Classifier Mask field is present and not reserved, at least one bit of this field that is not reserved is set to 1, unless the User Priority field is used to classify and is not set to 255. > given the Frame Classifier field must be present Note though that the Classifier Mask subfield is not present in classifier type 10 (see the second half of CID 1856). 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 In general this looks OK to me, but I recall a previous discussion about whether the User Priority field in TCLAS element is an “input” or “output”, which could be relevant here. In cases where the UP is an “output” (i.e. that UP is assigned to MSDUs that match the filter), it probably makes sense that the Frame Classifier field is not completely wildcard (although I’m not sure it hurts to allow that possibility). OTOH, in the specific case of TFS which was identified in the previous thread, it seems the UP field (when it takes values 8 thru 11) is an *input* for MPDU classification, i.e. it’s effectively part of the classifier itself. Then, might there be a use case where the only required filter is the AC of the MPDU, and no other filters (e.g. MAC addresses, IP tuples) is necessary? If so, given the Frame Classifier field must be present, it might need to specify a wildcard classifier.. I haven't seen any response to this post, so should I conclude that there is no objection to resolving this comment as: At the end of 9.4.2.30 add: A classifier classifies on the basis of at least one match. NOTE---For example, when the Classifier Mask field is present and not reserved, at least one bit of this field that is not reserved is set to 1. 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 I was asked to start a thread on this comment: | | It is not clear whether it is OK to have a Classifier Mask field (where it is not reserved) that is all-0, and if so whether that is an "always matches" or a "never matches" | At the end of the subclause add "If a Classifier Mask field is present and all bits that are not reserved are 0, then this classifier never matches." |
As far as I can tell, the classifiers have the following classifier 0, 1, 2, 4, 5: bitmap indicating parameters that need to match 6, 7, 8, 9: bitmap with 2-bit subbitmaps 10: not present (despite what Figure 9-364—Frame Classifier field format says -- see CID 1856) The direction of the group was to specify that classifiers that don't classify anything shall not be transmitted, rather than trying to specify that they never or always match. Because there are so many classifiers, and they classify in quite significantly different ways, I propose adding this general statement A classifier classifies on the basis of at least one match. NOTE---For example, when the Classifier Mask field is present and not reserved, at least one bit of this field that is not reserved is set to 1. 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
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
|