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, Thanks for your comments. Please see my comments inline. I think the question we ought to ask ourselves is how TC is contributing to EDCA or HCCA? Knowing that MSDUs with a given UP belong to a TC, how this knowledge is useful in any way? Are there any clauses in the draft highlighting the role of TC in QoS? Regards; Osama. From: Payam Torab <torab@xxxxxxxx> --- This message came from the IEEE 802.11 Working Group Reflector --- Hi Osama, >> 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? Sorry, I meant 0814 (your document) You are misreading the word TC. Not a technical issue – a word issue. TC is not UP. TC is a “group of MSDUs with a given UP”, as exactly defined (and as UP is also defined). There are very few places that can be written better, but they are not about changing UP To TC. Changes such as following are not correct, [Osama] You seem to imply that the issue is linguistic where it is really a technical one. Yes sure TC is not UP and it is a problem because, as I argue, TC is a useless parameter that can be replaced by UP without losing anything. Now using the definition of TC then: MSDUs with UP0 belong to TC. MSDU with UP1 belong to another TC....etc. Having known that how does TC with UPi (i=0-7) figure in any way, shape, or form in using either HCF contention based access (EDCA) or the HCF controlled channel access (HCCA)? This is the question I am asking and so far I haven’t received any good answer. In my mind It doesn’t. EDCA is managed using UP (Table 10-1) and HCCA is managed using TSID. What role does TC play? P797L60 | The TID subfield identifies the MSDU doesn’t belong to a UP, MSDU has a UP. MSDU can belong to a TC (or TS). That’s the correct usage by existing definitions, which are consistent. But I can also see over time some sentences have mixed them up. For example, the change you’ve proposed here P918L5 | The TID subfield contains the Should really be “The TID subfield [Osama] Actually the TID definition is very confusing. In some places it says it defines a TC. For example the TID definition includes the note: “NOTE—There are 16 possible TID values; eight identify traffic categories (TCs), and the other eight identify parameterized traffic streams (TSs). The TID is assigned to an MSDU in the layers above the MAC.” If that is true then how come Table 10-1 title is “UP to AC Mapping”. Why don’t we change the title to “TC to AC mapping”? While on P299L38 (D3.3) it says: In QoS STAs either associated in a BSS or having membership in an IBSS, the MAC uses a set of rules that tends to cause higher UP MSDUs in a BSS to be sent before lower UP MSDUs in the BSS. The MAC sublayer entities determine the UPs for MSDUs based on the TID values provided with those MSDUs. No mention of TC. Overall, there is no technical issue regarding TC and UP. Some sentences can be improved, but based on existing definitions, not removing TC. [Osama] You make an assertion without any proof. There is an issue because the TC is redundant and can be replaced by the UP. My submission 11-20/0814 includes a number of reasons why TC is redundant. From: Osama AboulMagd <Osama.AboulMagd@xxxxxxxxxx> 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 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 |