| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi Mark
>> 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.
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).
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).
>> Can you help with 2026 in terms of identifying when the User Priorityfield 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”).
Best Thomas
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). 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 Hi Mark 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.. Thomas
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
|