Thanks Dibakar for your e.mail.
In fact there are many confusion clauses and definitions related to QoS in the spec. I agree there is no enough time to take the whole QoS clauses and try to remove the sources of confusion. It is something perhaps
for REVme with enough time to take the QoS issues as a whole.
My comments were really limited in scope related to the use of the term TC and relationship to UP. It may be possible to deal with this now since the discussion has been going on in REVmd for some time now. I
understand it is up to the TG to decide. My concern is the issue may get forgotten with the time.
Regards;
Osama.
From: Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
Sent: Sunday, August 2, 2020 4:41 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] TGm Submission 11-20-0814 -- TC (traffic category/categories)
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Osama, all,
I generally agree with your view about “TC”: the term does not seem to add any technical value, but rather just adds to the confusion. To improve readability I am supportive of replacing its usage with direct reference to “UP” everywhere
as you suggest.
Having said that, my only concern is whether we have enough time to review the suggested changes in next couple of days while ensuring we don’t break anything inadvertently.
Regards,
Dibakar
From: Osama Aboul-Magd <oamagd@xxxxxxxxx>
Sent: Saturday, August 1, 2020 4:31 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] TGm Submission 11-20-0814 -- TC (traffic category/categories)
--- 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>
Reply-To: Payam Torab <torab@xxxxxxxx>
Date: Friday, July 31, 2020 at 2:04 PM
To: <STDS-802-11@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11] TGm Submission 11-20-0814 -- TC (traffic category/categories)
--- 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
TCUP or TS to which the corresponding MSDU …
belongs.
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
TCUP or TS for which the
BlockAck frame is being requested.
Should really be “The TID subfield contains
identifies the TC or TS for which the BlockAck is being requested.”
[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>
Date: Monday, July 27, 2020 at 5:47 AM
To: Payam Torab <torab@xxxxxxxx>, "STDS-802-11@xxxxxxxxxxxxxxxxx" <STDS-802-11@xxxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11] TGm Submission 11-20-0814 -- TC (traffic category/categories)
Hello Payam and All,
I have some comments inline.
Regards;
Osama.
From: Payam Torab [mailto:torab@xxxxxxxx]
Sent: Friday, July 24, 2020 3:59 PM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] TGm Submission 11-20-0814 -- TC (traffic category/categories)
--- 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>
Reply-To: Thomas Derham <thomas.derham@xxxxxxxxxxxx>
Date: Wednesday, July 22, 2020 at 3:30 PM
To: "STDS-802-11@xxxxxxxxxxxxxxxxx" <STDS-802-11@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11] TGm Submission 11-20-0814 -- TC (traffic category/categories)
--- 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:
Disclaimer: as I said, I'm very confused by all this stuff, so some/all of
the following may be bogus.
With respect to the excerpt of the discussion below, at least as far as EDCA is concerned, I think the behavior in terms of the TID field value and BA/SN should be the same for a TS, irrespective of whether or not it has an associated TCLAS.
To my understanding, the only differences between TS “with” and “without” TCLAS are as follows:
- When TCLAS is present, it explicitly defines rules used by higher layers for classifying MSDUs in the TS. If TCLAS is not present, the rule is not defined and is presumably determined based on local policies or some other mechanism.
- When TCLAS is present, the UP associated with the TS is as defined in that element. If TCLAS is not present, the UP associated with the TS is as defined in the TSPEC element instead.
Do we agree that the UP in the TCLAS element is not the UP to be used
for DUs matching that TCLAS, but the optional UP to be used when looking
for a TCLAS match? 9.4.2.30 TCLAS element says:
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.
[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...
[I am not sure whether the fact that the first sentence talks of MSDUs and
the second of MPDUs is significant/deliberate or an error.]
[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.
Either way, the higher layers set the Priority parameter of MA-UNITDATA.request for the MSDUs in the TS to the TSID (8 thru 15), and the MAC is responsible for mapping the TSID to a UP (using either TCLAS or TSPEC element, per above). And since we are talking EDCA, the TID subfield is set to the UP from 0 to 7 (not the TSID).
(There is language in 5.1.1.3 which refers to the receiver inferring the UP by mapping the TSID in TID subfield based on TSPEC/TCLAS, but I think that only applies to non-EDCA cases since, as defined in Table 9-12, the TID subfield always contains the UP for EDCA).
Regarding this:
>> BA is set up and identified on a per-UP (not per-TSID) basis
It seems this is quite a fundamental concept, but I am unable to find any clear statements in the standard (although I’m sure there are some experts who know better than I). It is obvious that BAs are negotiated for a given “TID”, however a TS used with EDCA is in the odd situation where a TSID (8-15) is defined yet the TID subfield is set to the UP (0-7). If the MAC receives an MPDU with TID subfield in the range 0-7, the only way it could know it is actually related to a TS is to try matching its content against the classifier (e.g. TCLAS), which does not sound reasonable for BA window handling. This suggests to me that MPDUs in an EDCA TS would be treated in the same BA agreement as other MPDUs with the same UP (?)
Well, for the ADDBA Request frame, 9.4.1.13 Block Ack Parameter Set field says:
The TID subfield contains the TC or TS for which the BlockAck frame is being requested.
and 6.3.27.2 MLME-ADDBA.request says that the TID parameter is in the range 0-15,
so at least at that level it could be a TSID (8-15) or it could be a (UP/)TC (0-7).
Are you saying that a TSID (8-15) can only be used for ADDBA requests when the
TSPEC element Access Policy field indicates HCCA or HEMM, not when it indicates
EDCA? And that when it's EDCA then the same BA agreement is used for both
stuff sent under the TSID that maps to a certain UP, and stuff sent directly
on that UP
[Thomas] That is my interpretation, yes.
(which, going back to 20/0814 and Osama's CIDs, might also/instead
be a TC here?)?
[Thomas] Maybe, although in principle I would support removal of TC concept if it is redundant.
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 <00000ad2eabc2931-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, 20 July 2020 21:57
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] TGm Submission 11-20-0814 -- TC (traffic category/categories)
--- This message came from the IEEE 802.11 Working Group Reflector ---
Thanks Mark and Osama for working on this.
With respect to the excerpt of the discussion below, at least as far as EDCA is concerned, I think the behavior in terms of the TID field value and BA/SN should be the same for a TS, irrespective of whether or not it has an associated TCLAS.
To my understanding, the only differences between TS “with” and “without” TCLAS are as follows:
- When TCLAS is present, it explicitly defines rules used by higher layers for classifying MSDUs in the TS. If TCLAS is not present, the rule is not defined and is presumably determined based on local policies or some other mechanism.
- When TCLAS is present, the UP associated with the TS is as defined in that element. If TCLAS is not present, the UP associated with the TS is as defined in the TSPEC element instead.
Either way, the higher layers set the Priority parameter of MA-UNITDATA.request for the MSDUs in the TS to the TSID (8 thru 15), and the MAC is responsible for mapping the TSID to a UP (using either TCLAS or TSPEC element, per above). And since we are talking EDCA, the TID subfield is set to the UP from 0 to 7 (not the TSID).
(There is language in 5.1.1.3 which refers to the receiver inferring the UP by mapping the TSID in TID subfield based on TSPEC/TCLAS, but I think that only applies to non-EDCA cases since, as defined in Table 9-12, the TID subfield always contains the UP for EDCA).
Regarding this:
>> BA is set up and identified on a per-UP (not per-TSID) basis
It seems this is quite a fundamental concept, but I am unable to find any clear statements in the standard (although I’m sure there are some experts who know better than I). It is obvious that BAs are negotiated for a given “TID”, however a TS used with EDCA is in the odd situation where a TSID (8-15) is defined yet the TID subfield is set to the UP (0-7). If the MAC receives an MPDU with TID subfield in the range 0-7, the only way it could know it is actually related to a TS is to try matching its content against the classifier (e.g. TCLAS), which does not sound reasonable for BA window handling. This suggests to me that MPDUs in an EDCA TS would be treated in the same BA agreement as other MPDUs with the same UP (?)
Best
Thomas
======
As you can see from my CID 7796 I too find the terms and their intent confusing.
· As for your statement; “The TSID is a number in the range 8-15 identifying a defined traffic stream or a frame that is part of this stream (but the frames in this stream are, in EDCA, identified over the air by the UP for that stream)”
This is a very confusing statement. How EDCA can be applied to TS? The UP in the TSPEC element is the UP of the MSDUs or A-MSDUs belonging to the TS as defined in “UP subfield(#2494) indicates the actual value of the UP to be used for the transport of MSDUs or A-MSDUs belonging to this TS when relative prioritization is required. When the TCLAS element is present in the request, the UP subfield in TS Info field of the TSPEC element is reserved.” This UP value cannot be included in the TID field because the TID field will include the TSID in this case. Perhaps this one of the areas where the spec is not clear and need to be clarified, but it is beyond the scope of the CIDs I am resolving.
I'm not sure I can answer this question. I'm hoping maybe the Chair of the ARC SC
(copied) might be able to help. My guess at this point is that there are three paths:
1) Data not subject to a TCLAS or TSPEC just uses UPs throughout. At the MAC SAP
it's called the priority, in QoS Data frames it's in the TID field (so the msb is 0).
TSID and TC are N/A.
2) Data sent under a TSPEC without a TCLAS is associated with a TSID that has b3 set
and a UP. The TSID is used at the MAC SAP, but apparently (per that statement above)
over the air they go out with the UP, not the TSID, in the TID field in the QoS Control
field. TC is N/A.
3) Data sent under a TSPEC with an associated TCLAS has a TSID and no UP per se.
It has a TC, which is then used in the TID field in the QoS Control field.
It's possible that for the latter two cases the ADDBA uses the TSID not the
UP as the TID. At this point I'm floundering, and again hoping some ARC guru
can rescue me.
[osama] I think the spec is not clear here and needs to be fixed.
· BA is set up and identified on a per-UP (not per-TSID) basis [think group response was "No, can be TSID (see e.g. 669.65). In case of TS can have TCLAS. Use TC if no TSPEC in ADDBA Req, use TS(ID) otherwise"] even for defined traffic streams (hm, so why 16 replay counters? Or maybe you can have BAs under HCCA/HEMM/SPCA/SEMM?)
So at least then the direction was that you couldn't just delete TC
because it was involved in TCLASes. I thought you were going to go
off and examine this point.
[osama] I don’t know you reference. P669.65 in draft 3.0 doesn’t have any text. I am not sure what you are referring to. My recollection is the TCLAS never been mentioned during the discussion. Theminutes doesn’t include any reference to TCLAS. I looked at clause 9.4.2.30 of draft 3.0 and there is no mention of traffic category in the context of TCLAS element even though there is a UP field.
On July 20, 2020 at 1:02:01 PM, Osama AboulMagd (osama.aboulmagd@xxxxxxxxxx) wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Mark,
Thanks for your comments. I have few short answers below. Let’s discuss during the teleconference.
Regards;
Osama.
From: Mark Rison [mailto:m.rison@xxxxxxxxxxx]
Sent: Monday, July 20, 2020 8:59 AM
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11] TGm Submission 11-20-0814 -- TC (traffic category/categories)
--- This message came from the IEEE 802.11 Working Group Reflector ---
Thanks for your further thoughts, Osama.
> > 2.6.2.17 The discussion was leading to removing TC and update the description on how UP is defined when it is not passed in through the MAC SAP
> the description is already available P299, “The UP is provided with each MSDU at the medium access control service access point (MAC SAP) either directly, in the UP parameter, or indirectly, in a TSPEC or SCS Descriptor element designated by the UP parameter”. Is there a need for something else? If yes, what is needed?
> Please let me know if other things I need to consider.
When we discussed this in the teleconf, I referred to CID 7796 in 16/0276, where we had got to:
[osama] I wasn’t part of the discussion of CID 7796 and I don’t know how it was resolved. However CID 7796 scope is different from the CIDs I submitted. If you think more work on this area is needed then perhaps you can resubmit the comment again.
CID 7796 was:
Identifiers
Comment
Proposed change
CID 7796
Mark RISON
The distinctions made in the specification w.r.t. TS/TC/TSID/TID are incomprehensible
Make the definitions comprehensible. E.g. what does "UP for either TC or TS" mean?
This seems to me pretty similar to the comments you are resolving in
20/0814, which are essentially about when exactly TS, TC, TSID and TID
are the right terms to use:
CID
Page
Line
Clause
Comment
Proposed Change
Resolution
4145
797.00
59
9.2.4.5.2
In many places in the draft it is mentioned; "The TID subfield identifies the TC or TS to which the corresponding MSDU (or fragment thereof) or
A-MSDU in the Frame Body field belongs". It is probably more straightforward to mention that "TID subfield indicates the UP or the TSID..." as per table 9-12.As in comment
Revised
TGm Editor: Please make the following changes (#4145, #4147)
4147
917.00
5
9.4.1.13
"TID subfield contains the TC or TS for which the BlockAck frame is being requested". In fact the TID doesn't contain the TC or the TS. It contain the UP or the TSID. The same sentence is repeated in other places of the draft.
Change "TID subfield contains the TC or TS for which the BlockAck frame is being requested." to "TID subfield contains the UP or TSID for which the BlockAck frame is being requested.".
Revised
TGm Editor: Please make the following changes (#4145, #4147)
4146
798.00
30
9.2.4.5.2
Table 9-12 - the second row includes; "UP for either TC or TS, regardless of whether admission
control is required". Now the issue is how TID can indicate the priority of a TS when TID is used for indicating UP or TSID? It seems not possible to indicate UP of a TSChange; "UP for either TC or TS, regardless of whether admission
control is required" to "UP regardless of whether admission
control is required"Revised
TGm Editor: Please make changes in <this document> related to CID 4146
[0sama] I still think my comments have a narrow scope compared to your comment.
·
· A TS is a traffic stream
· A TSPEC is a definition of a traffic stream
· The UP is a number in the range 0-7 specifying a user priority
· The TC is a number also in the range 0-7 but identifying a user priority or a frame that is not part of a defined traffic stream (not 100% sure how this differs from a UP, really -- think group response (maybe from Mark?) was "UP notionally carried across MAC-MAC transport; UP can be mapped to TC either directly or via classifier; ditto on receive. UP carried across SAP, TC is internal mechanism used to achieve this")
· The TSID is a number in the range 8-15 identifying a defined traffic stream or a frame that is part of this stream (but the frames in this stream are, in EDCA, identified over the air by the UP for that stream)
· The TID is a number in the range 0-15 that is a UP if it is <8 and is a TSID otherwise
[osama] All this is good and I don’t disagree. However I fail to see how it is related to the CIDs or their resolutions. I submitted these comments with the hope to remove the confusion arising from adding a parameter (Traffic Category) that doesn’t figure in anything in the spec. It is a redundant parameter and can easily be replaced with UP.
The point of the discussion that occurred and was captured under CID 7796 in 16/0276
is that it was claimed then that TC is not a "redundant parameter" that "can easily
be replaced with UP".
I’d be happy to withdraw my comments if I am the only one confused with the term Traffic Category. As I mentioned in my presentation before, this term doesn’t have any equivalent in 802.1Q or 802.1D where I believe 802.11e borrowed the concept of UP.
As you can see from my CID 7796 I too find the terms and their intent confusing.
· As for your statement; “The TSID is a number in the range 8-15 identifying a defined traffic stream or a frame that is part of this stream (but the frames in this stream are, in EDCA, identified over the air by the UP for that stream)”
This is a very confusing statement. How EDCA can be applied to TS? The UP in the TSPEC element is the UP of the MSDUs or A-MSDUs belonging to the TS as defined in “UP subfield(#2494) indicates the actual value of the UP to be used for the transport of MSDUs or A-MSDUs belonging to this TS when relative prioritization is required. When the TCLAS element is present in the request, the UP subfield in TS Info field of the TSPEC element is reserved.” This UP value cannot be included in the TID field because the TID field will include the TSID in this case. Perhaps this one of the areas where the spec is not clear and need to be clarified, but it is beyond the scope of the CIDs I am resolving.
I'm not sure I can answer this question. I'm hoping maybe the Chair of the ARC SC
(copied) might be able to help. My guess at this point is that there are three paths:
1) Data not subject to a TCLAS or TSPEC just uses UPs throughout. At the MAC SAP
it's called the priority, in QoS Data frames it's in the TID field (so the msb is 0).
TSID and TC are N/A.
2) Data sent under a TSPEC without a TCLAS is associated with a TSID that has b3 set
and a UP. The TSID is used at the MAC SAP, but apparently (per that statement above)
over the air they go out with the UP, not the TSID, in the TID field in the QoS Control
field. TC is N/A.
3) Data sent under a TSPEC with an associated TCLAS has a TSID and no UP per se.
It has a TC, which is then used in the TID field in the QoS Control field.
It's possible that for the latter two cases the ADDBA uses the TSID not the
UP as the TID. At this point I'm floundering, and again hoping some ARC guru
can rescue me.
[osama] I think the spec is not clear here and needs to be fixed.
· BA is set up and identified on a per-UP (not per-TSID) basis [think group response was "No, can be TSID (see e.g. 669.65). In case of TS can have TCLAS. Use TC if no TSPEC in ADDBA Req, use TS(ID) otherwise"] even for defined traffic streams (hm, so why 16 replay counters? Or maybe you can have BAs under HCCA/HEMM/SPCA/SEMM?)
So at least then the direction was that you couldn't just delete TC
because it was involved in TCLASes. I thought you were going to go
off and examine this point.
[osama] I don’t know you reference. P669.65 in draft 3.0 doesn’t have any text. I am not sure what you are referring to. My recollection is the TCLAS never been mentioned during the discussion. Theminutes doesn’t include any reference to TCLAS. I looked at clause 9.4.2.30 of draft 3.0 and there is no mention of traffic category in the context of TCLAS element even though there is a UP field.
16/0276 is "Resolutions for some comments on 11mc/D5.0 (SBmc1)" so I
think that's where you'd need to look at 669.65.
[Also, I don't understand the concept of a "frame UP" (CID 4145/4147) or
"MSDU or A-MPDU UP" (CID 4146) you are apparently trying to introduce.]
[osama] I think we can come up with a better name if frame UP is confusing. I’ll think of something and present to the group.
OK. (Are you suggesting we're going to have multiple flavours of UP?
A frame/MPDU UP, and an MSDU or A-MPDU UP?)
[osama] No, I don’t intend to introduce multiple flavors of UP. I’ll see what language is used in the draft and use it.
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: Osama Aboul-Magd <oamagd@xxxxxxxxx>
Sent: Wednesday, 1 July 2020 15:15
To: STDS-802-11@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11] TGm Submission 11-20-0814
--- This message came from the IEEE 802.11 Working Group Reflector ---
Hello All,
I’d like to start an e.mail discussion on doc 11-20/0814 which I presented on June 5.
From the teleconference minutes:
2.6.2.16 Two instances of Traffic Categories are not included in the proposed changes that will need to be added.
2.6.2.16.1 ""Other "traffic category" locations; P275.13 and P299.24
[osama] I have looked in drafts 3.0, 3.1, and 3.2 and couldn’t find these occurrences. Can someone point them to me, Note that my reference is draft 3.0
2.6.2.17 The discussion was leading to removing TC and update the description on how UP is defined when it is not passed in through the MAC SAP
[osama] the description is already available P299, “The UP is provided with each MSDU at the medium access control service access point (MAC SAP) either directly, in the UP parameter, or indirectly, in a TSPEC or SCS Descriptor element designated by the UP parameter”. Is there a need for something else? If yes, what is needed?
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 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
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
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