Re: [STDS-802-11-TGM] 11me/D1.0 CID 1859 (all-zero Classifier Mask field

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

>> 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

ROYAUME UNI WWW: http://www.samsung.com/uk

On Feb 17, 2022, at 9:26 AM, Mark Rison <m.rison@xxxxxxxxxxx> wrote:

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

ROYAUME UNI                             WWW: http://www.samsung.com/uk

From: Thomas Derham <thomas.derham@xxxxxxxxxxxx>
Sent: Thursday, 17 February 2022 17:10
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx; Jouni Malinen (jouni@xxxxxxxxxxxxxxxx) <jouni@xxxxxxxxxxxxxxxx>
Subject: Re: 11me/D1.0 CID 1859 (all-zero Classifier Mask fields)

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..

Thanks

Thomas

On Feb 17, 2022, at 2:53 AM, Mark Rison <m.rison@xxxxxxxxxxx> wrote:

I haven't seen any response to this post, so should I conclude that

there is no objection to resolving this comment as:

REVISED

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.

?

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: Mark Rison
Sent: Friday, 21 January 2022 21:00
To: 'STDS-802-11-TGM@xxxxxxxxxxxxxxxxx' <stds-802-11-tgm@xxxxxxxxxxxxxxxxx>
Cc: Thomas Derham (thomas.derham@xxxxxxxxxxxx) <thomas.derham@xxxxxxxxxxxx>; Jouni Malinen (jouni@xxxxxxxxxxxxxxxx) <jouni@xxxxxxxxxxxxxxxx>
Subject: 11me/D1.0 CID 1859 (all-zero Classifier Mask fields)

I was asked to start a thread on this comment:

CID 1859

9.4.2.30

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

masks:

0, 1, 2, 4, 5: bitmap indicating parameters that need to match

6, 7, 8, 9: bitmap with 2-bit subbitmaps

3: reserved

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

at the end of 9.4.2.30:

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.

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

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

Re: [STDS-802-11-TGM] 11me/D1.0 CID 1859 (all-zero Classifier Mask fields)