Re: [STDS-802-11-TGAX] TGax CRC 2020-07-21

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

Thanks for your replies, Liwen.

An HE STA that transmits a multi-TID A-MPDU in an HE TB PPDU should aggregate MPDUs in the following order:

· first, any and all MPDUs that correspond to the Preferred AC subfield of the Trigger Dependent User Info field addressed to the STA in the Trigger frame

· then, any and all MPDUs that correspond to any AC that has a higher priority

· then, any MPDUs that correspond to any AC that has a lower priority

subject to:

· the limit indicated in the TID Aggregation Limit subfield in the Trigger Dependent User Info field addressed to the STA in the Trigger frame

· the duration indicated in the UL Length subfield in the Common Info field of the Trigger frame

NOTE—These rules permit a STA to not aggregate any MPDUs from the preferred AC or a higher priority AC.

[Liwen] This is not good since the single-TID A-MPDU in TB PPDU is missing.

OK, to me that was sufficiently implicit, but fine, then add the stuff

in red:

An HE STA that transmits a multi-TID A-MPDU in an HE TB PPDU should aggregate MPDUs in the following order:

· first, any and all MPDUs that correspond to the Preferred AC subfield of the Trigger Dependent User Info field addressed to the STA in the Trigger frame

· then, any and all MPDUs that correspond to any AC that has a higher priority

· then, any MPDUs that correspond to any AC that has a lower priority

subject to:

· the limit indicated in the TID Aggregation Limit subfield in the Trigger Dependent User Info field addressed to the STA in the Trigger frame, for a multi-TID A-MPDU

· inclusion of only one TID, for a single-TID A-MPDU

· the duration indicated in the UL Length subfield in the Common Info field of the Trigger frame

NOTE—These rules permit a STA to not aggregate any MPDUs from the preferred AC or a higher priority AC.

In 26.4.1 change:

An HE STA that transmits a Multi-TID BlockAckReq frame in a PPDU that is not an HE TB PPDU shall set the TID subfields in the AID TID Info fields in the Per TID Info subfields of the BAR Information field of the Multi-TID BlockAckReq frame to TIDs that correspond to ACs that have the same or higher priority as the primary AC. An HE STA that transmits a Multi-TID BlockAckReq frame in an HE TB PPDU may set the TID subfields in the AID TID Info fields in the Per TID Info subfields of the BAR Information field of the Multi-TID BlockAckReq frame to a TID that corresponds to any AC.

to:

An HE STA that transmits a Multi-TID BlockAckReq frame in a PPDU that is not an HE TB PPDU shall set the TID Value subfields in the Per TID Info subfields of the BAR Information field of the Multi-TID BlockAckReq frame to TIDs that correspond to ACs that have the same or higher priority as the primary AC. An HE STA that transmits a Multi-TID BlockAckReq frame in an HE TB PPDU should set the TID Value subfields in the Per TID Info subfields of the BAR Information field of the Multi-TID BlockAckReq frame to TIDs that correspond to ACs that have the same or higher priority as the preferred AC.

[Liwen]although I am fine with your change, your change is in different subclause from the subclause covered by the comments that I am addressing. The changes shouldn’t be in my document.

I'm not sure I follow you here. If your document does not cover the subclauses

referred to in the comments it is resolving, then your document and resolution

is incomplete. The comment is:

[Resubmission of comment withdrawn on D5.0] There has been extensive discussion in TGmd of the extent to which multiple ACs' traffic could be transmitted within a given TXOP. The conclusion (see 18/1368 and 18/1260) was that the correct balance of optimal spectrum utilisation and optimal QoS prioritisation was that:

* Allowing a lower AC to transmit into an AC with higher priority degrades the differentiated service offered to the higher AC

though:

* However, once a lower AC has gained access, allowing the same STA higher AC to leverage that same TXOP makes sense

i.e. you can aggregate higher-priority traffic only, after transmitting everything available on the primary AC.

This balance exists for non-TB transmission in 11ax/D5.0. However in 11ax/D5.0 for TB transmission any ACs are allowed, with just a recommendation to transmit from the preferred AC or higher. The rule should be closer to the above, with encouragement to use the preferred AC first, then any higher-priority ACs, then anything else.

There is also a lot of waffling and duplication in the current text. And references to non-existent fields in 26.4.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: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Liwen Chu
Sent: Tuesday, 21 July 2020 17:09
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] TGax CRC 2020-07-21

Hi Mark,

Thanks for the comments. Please find my replies below.

Best Regards,

Liwen

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Tuesday, July 21, 2020 6:36 AM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx; Liwen Chu <liwen.chu@xxxxxxx>
Subject: RE: TGax CRC 2020-07-21

I have the following comments on 20/1022r3, whose resolutions are I

think on the agenda for motion today (the agenda has not been formally

announced as far as I can tell).

- CID 24565: I think "Ack-enabled" should be "ack-enabled"

[Liwen]fixed

- CID 24403:

a) A free-for-all harms QoS and should be recommended against.

b) There are various editorial issues too, mentioned in the comment and

addressed in 19/1667r1, which should be fixed even if the group decides

that QoS is not worth worrying about, e.g.:

1) The para

An HE STA that intends to send QoS Data frames from a single TID should select a TID from the same or higher priority AC indicated in the Preferred AC subfield in the Trigger Dependent User Info field of a Basic Trigger frame. If the HE STA has no buffered MPDU for TIDs belonging to the same or higher priority AC indicated in the Preferred AC subfield in the Trigger Dependent User Info field of a Basic Trigger frame, then the HE STA may include MPDUs for a TID belonging to any other AC in that A-MPDU carried in the HE TB PPDU.

is confusing, because the first sentence is just a "should" (which is

fine) but the second sentence implies with its "may" that you can only

include lower-priority ACs if there are no buffered higher-priority

ACs, which I think is not the intent.

2) The Multi-TID BAR frame does not have "TID subfields in the AID TID Info fields in the Per TID Info subfields",

it has TID Value subfields in the Per TID Info subfields:

Here are the changes I propose (note it's all "should" so no-one is

going to jail):

In 26.6.3.1 change:

If the AP specifies a value defined in Table 9-154 (ACI-to-AC encoding)(#20006) in the Preferred AC subfield in the Trigger Dependent User Info field of a Basic Trigger frame, then an HE STA that transmits a multi-TID A-MPDU to the AP should aggregate QoS Data frames from any one of the TIDs from the same AC or higher priority AC as indicated in the Preferred AC subfield of the Trigger Dependent User Info field that is addressed to the STA in the Trigger frame, up to the limit indicated in the TID Aggregation Limit subfield in Trigger Dependent User Info field of the Trigger frame.

NOTE—While it is recommended that the STA transmit QoS Data from the AC that is same or higher than the preferred AC, the STA might still(#20227) to aggregate QoS Data from an AC that has lower priority than the preferred AC.

The STA may aggregate MPDUs from TIDs in other ACs within the remaining time to the HE TB PPDU duration value indicated in the UL Length subfield in the Common Info field of the received Trigger frame, up to the limit indicated in the TID Aggregation Limit subfield in Trigger Dependent User Info field of the Trigger frame.

NOTE—If the AP indicates AC_BK in the Preferred AC subfield in the Trigger Dependent User Info field of a Basic Trigger frame, then an HE STA that transmits a multi-TID A-MPDU to the AP might aggregate MPDUs from any AC/TID or combination of TIDs, up to the limit indicated in the TID Aggregation Limit subfield in Trigger Dependent User Info field of the Trigger frame.

to:

An HE STA that transmits a multi-TID A-MPDU in an HE TB PPDU should aggregate MPDUs in the following order:

· first, any and all MPDUs that correspond to the Preferred AC subfield of the Trigger Dependent User Info field addressed to the STA in the Trigger frame

· then, any and all MPDUs that correspond to any AC that has a higher priority

· then, any MPDUs that correspond to any AC that has a lower priority

subject to:

· the limit indicated in the TID Aggregation Limit subfield in the Trigger Dependent User Info field addressed to the STA in the Trigger frame

· the duration indicated in the UL Length subfield in the Common Info field of the Trigger frame

NOTE—These rules permit a STA to not aggregate any MPDUs from the preferred AC or a higher priority AC.

[Liwen] This is not good since the single-TID A-MPDU in TB PPDU is missing.

In 26.4.1 change:

to:

[Liwen]although I am fine with your change, your change is in different subclause from the subclause covered by the comments that I am addressing. The changes shouldn’t be in my document.

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: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Osama AboulMagd
Sent: Friday, 17 July 2020 15:15
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX] TGax CRC 2020-07-21

Hello All,

TGax CRC has a conference call scheduled for Tuesday July 21 @ 17:00 ET; for 2 hours.

Please let me know if you have a submission. I’ll send an agenda later.

Webex info https://ieeesa.webex.com/ieeesa/j.php?MTID=m6d9bf23fe89cca58d8d96f07f57cd8e9

Meeting number: 129 915 3467

Meeting password: wireless (94735377 from phones and video systems)

Join by phone: Tap to call in from a mobile device (attendees only) +1-408-418-9388 USA Toll
Global call-in numbers

Access code: 129 915 3467

Teleconferences are bound by the conditions stipulated by the documentation below. Please review them and bring up any questions/concerns you may have before proceeding with the teleconference

• IEEE Code of Ethics

– https://www.ieee.org/about/corporate/governance/p7-8.html

• IEEE Standards Association (IEEE-SA) Affiliation FAQ

– https://standards.ieee.org/faqs/affiliation.html

• Antitrust and Competition Policy

– https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/other/antitrust.pdf

• IEEE-SA Patent Policy

– http://standards.ieee.org/develop/policies/bylaws/sect6-7.html

– https://standards.ieee.org/about/sasb/patcom/

• IEEE 802 Working Group Policies &Procedures (29 Jul 2016)

– http://www.ieee802.org/PNP/approved/IEEE_802_WG_PandP_v19.pdf

• IEEE 802 LMSC Chair's Guidelines (Approved 13 Jul 2018)