Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hello Payam and All, I have some comments inline. Regards; Osama. From: Payam Torab [mailto:torab@xxxxxxxx] --- This message came from the IEEE 802.11 Working Group Reflector ---
Hello all, Regarding CID4145, 4147 (replacing TC with UP), I find the current text consistent and hope we don’t make the change. TC is a cleverly short definition for -all- MSDUs with a given UP of 0-7 and without a TSPEC. UP is an attribute of an
(a single) MSDU; TC is a group (category) of MSDUs with the same UP, and is defined as follows, 5.1.1.2 (Determination of UP) An MSDU with a particular UP is said to belong to a traffic category (TC) with that UP. [Osama] My first impression here is so what? How this info is useful for anything? I am more confused now since we have 8 priority levels and one TC definition. I am assuming MSDUs with priority 0 belong to a
TC, MSDU with priority 1 belong to a TC,…. . Do we need to define 8 TCs to cover all the possible Ups? TC was not invented as an alias for UP. TC is an 802.11 concept (not 802) to help define a common behavior for all MSDUs with a given UP. You can appreciate usage when you read sentences such as this one (random example), [osama] Indeed TC is an 802.11 concept. It is not available in the 802.1 and any other QoS architecture that I am aware of. I am guessing its absence in other QoS models because it is really not needed. If priority
is the main attribute then let’s call it priority and not use an intermediate meaningless parameter. As for the use of the word “behavior” I think we need to be careful here and clarify what do you mean by it. Other QoS models like IP Diffserv has introduced the Per Hop Behavior (PHB) where indeed a behavior
was defined and it is a building block for defining services. I don’t think 802.11 defines any behavior and if it does it is useful to explicitly include a description of this behavior. (P1034L63) The Average bit(M101)
is set to 1 to request that a Transmit Stream/Category Measurement report be generated when the number of MSDUs for the TC or TS given by the TID that are discarded out of the number of preceding MSDUs specified in … [Osama] I believe you can replace TC with UP in the above sentence with no change in the meaning. Additionally the TID doesn’t indicate TC. It indicate UP when its value is 0-7. UP and TS don’t go together in one sentence (as suggested by some changes in DCN 1814) – UP and TSID do (both attributes of an MSDU), and also TC and TS (both groups of MSDUs). [Osama] I tried to find any relevant DCN 1814 but failed. Can you be more specific? I don’t understand the above statement. --- There are a few other topics discussed below. I appreciate if someone clarifies if they are going to result in (or have already resulted in) text changes. Again I find the text and concepts consistent and support clarifications, but not
any technical changes. Exception is this text under TCLAS (9.4.2.30) and also Table 9-165
When the UP field contains a value that is less than or equal to 7, the value specifies the UP of the associated MSDUs. When the UP field contains a value that is greater than or
equal to 8 and less than or equal to 11, the value specifies the access category of the associated MPDUs. The UP field value 255 is reserved and indicates that the UP of the MSDU and the access category of the MPDU are not compared as part of the traffic filter. Reference to Access Category for MPDUs is obviously only meaningful for EDCA channel access. Same comment for entries 8-11 (UP values of 8-11) in Table 9-165. If someone knows the context I appreciate if they can share. At TCLAS level,
references to MPDUs should not exist, or if they have been used for a special purpose they should be clarified with additional assumptions. [Osama] I agree the above text needs to be made clear. IMHO the source of confusion is the use of “UP” as the name of the field. It is very confusing to say UP value is greater than or equal 8 and less than or
equal 11 when we know there are only 8 UP values (0-7). The name of the field may need to change. Payam From: Thomas Derham <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx> --- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Mark Thanks, please see inline: On July 21, 2020 at 12:41:51 AM, Mark Rison (m.rison@xxxxxxxxxxx) wrote:
[Thomas] (Responding to the question just above this quotation): Well, TCLAS element is used in various contexts but, assuming we’re referring to classification of MSDUs based on ADDTS negotiation with TSPEC+TCLAS present, my understanding is that the UP
in the TCLAS element is used equivalently to how the UP field in TSPEC element is used if TCLAS is absent i.e. it specifies the UP to be used for that TS. In other words, I don’t think the UP in TCLAS is used as a “matching criterion” in that case. So short
answer, “no”. That said, please see next comment below...
[Thomas] The sentence you highlight above is a bit curious, it was added in REVmc when when support for added for classification of (M)MPDUs. (In 802.11-2012, it simply said “The UP field contains the value of the UP of the associated MSDUs”). Note that
the entity that classifies MSDUs based on a TCLAS classifier associated with a TS is *above* the MAC, as specified in 11.4.8 - and that entity sets the Priority parameter accordingly (which, in EDCA case, is set to the UP [specified in the TCLAS element]).
I think that, in (all??) cases where TCLAS is used to classify MPDUs, the intention is not to assign them a UP but rather to discard them or trigger some other action (e.g. TFS); so it appears in those cases the UP field is used to specify a matching criterion
instead. So with regard to the sentence above, when MSDUs are being classified, UP field in TCLAS is not set to 255 so the rest of the sentence is irrelevant (albeit, arguably, confusing). That said, it’s not entirely obvious to me how it is determined whether
MSDUs or MPDUs are being classified - I think the intention is for it to be implied from the Frame Classifier type of the TCLAS element although I am not aware of an explicit statement to that effect.
[Thomas] That is my interpretation, yes.
[Thomas] Maybe, although in principle I would support removal of TC concept if it is redundant.
To unsubscribe from the STDS-802-11 list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1 |