Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-08-20

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

Just kind remind, I send a request to the Chair.

If you have suggestion, please tell me.

Regarding 20/0980r3:

- I attach my comments again.

- I am probably OK with option 3 as long as Alfred (or anyone else) can

explain why ack+TRS needs to be forbidden unless MU cascading is supported.

- However, Tomo-san's point about whether

1. The AP triggers STA 1 and STA 2.

2. STA 1 and STA 2 transmit Data that solicits ack to the AP.

3. AP transmits ack + TF to STA 1 and STA 2 again. The ack is for the Data that STA 1 and STA 2 transmitted. The TF is to let STA 1 and STA 2 continue UL MU transmission.

4. STA 1 and STA 2 transmit Data that solicits ack to the AP.

is cascading or not needs to be agreed on

[Ming] I have no idea for this.

OK, well let's hope Alfred and Tomo-san do!

- The changes actually shown in 20/0980r3 are not correct:

* They don't effect option 3

in this figure the HE MU PPDUs contain a triggering frame and a Data or Management frame which solicits an immediate acknowledgement, and the HE TB PPDUs contain an Ack or BlockAck frame and a Data or Management frame which solicits an immediate acknowledgement. (#CID 20732, 20733 and 21450)

should be:

in this figure the second HE MU PPDU contains an Ack or BlockAck frame and a triggering [or Trigger, depending on the Tomo-san point outcome] frame.

[Ming] Does the second HE MU PPDU contain Data frame? This is just an example, I do not see any issue for the original sentence. Please point it out if any.

The A-MPDU may additionally contain one or more MPDUs and is constructed following the rules in 26.6 (A-MPDU operation in an HE PPDU).

should be:

The A-MPDU may contain other MPDUs, subject to the rules in 26.6 (A-MPDU operation in an HE PPDU).

[Ming] any difference between “additionally ” and “other”? if they are the same, I would like to keep it.

Yes.

"The A-MPDU may additionally contain one or more MPDUs and is constructed following the rules in 26.6 (A-MPDU operation in an HE PPDU)." means "In addition to the rules above, the A-MPDU may contain some MPDUs, per 26.6". But this is confusing, because the rules above already refer the inclusion of certain MPDUs in the A-MPDU (specifically the Ack/BA frames and the triggering frames -- these are all MPDUs).

Regarding CID 24557 in 20/0981r4:

- I attach my comments again.

- I'm not persuaded by

the PN assignment for the retransmitted fragment shall follow the rules defined in 12.5.3.3.2 (PN processing) except that the PN shall be incremented in steps of 1 for the retransmitted fragment if it has a different body length from the previously transmitted fragment

* I'm not sure we can guarantee that another frame hasn't been transmitted

(to the given receiver) with the PN specified here (incremented by 1), i.e.

that PN might already have been used. Can we guarantee this?

[Ming] It can be guaranteed because it has the following description in 12.5.3.3.2 (PN processing)

The PN shall never repeat for a series of encrypted MPDUs using the same temporal key.

The problem is the following sequence:

- Send dynfrag with PN 1234, but this dynfrag is not acked

- Send something else (maybe on a different AC) with PN 1235

- Can't retx the dynfrag with "PN shall be incremented in steps of 1", because that would cause a transmission with PN 1235, which is forbidden

* 12.5.3.3.2 is for CCMP, but we also need to support GCMP.

[Ming] Good catch. Actually there are two sub clause of PN processing. One is 12.5.3.3.2 (PN processing) in CCMP and the other is 12.5.5.3.2 PN processing in GCMP.

So I would like to change it to “the PN assignment for the retransmitted fragment shall follow the rules defined in 12.5.3 (CTR with CBC-MAC protocol (CCMP)) and 12.5.5 (GCM protocol (GCMP)) except that the PN shall be incremented in steps of 1 for the retransmitted fragment if it has a different body length from the previously transmitted fragment and is encrypted”

See above. I am not confident we can be sure PN+1 is available.

* the DU might not be encrypted

[Ming] What is the DU? Is this related

I meant this as a shorthand for MSDU, A-MSDU or MMPDU.

If there is no better proposal from e.g. Jouni then how about something

generic and safe like:

If the MSDU, A-MSDU or MMPDU is encrypted, and the retransmitted fragment has a different length from the previous fragment, the PN shall be greater than any PN previously used for transmissions to the receiver.

NOTE—This is to ensure that requirements on non-reuse of a PN with the same temporal key are met (see 12.5.3.3.2 and 12.5.5.3.2).

[Ming] “Greater” is not good since the baseline says “The PN is incremented by a positive number for each MPDU. The PN shall be incremented in steps of 1 for

constituent MPDUs of fragmented MSDUs and MMPDUs.”

See above. I am not convinced we can guarantee that incrementing the PN by 1 will be possible. And in any case the last sentence is not true for dynfrag when we start incrementing the PN on retx, since then the constituent MPDUs will not have PNs going up by 1 every time. Also that sentence does not cover A-MSDUs (since A-MSDUs cannot be statically fragmented). Maybe we need to change 12.5.x to say " The PN shall be incremented in steps of 1 for

constituent MPDUs of fragmented MSDUs and MMPDUs that do not use dynamic fragmentation."

NOT “the MSDU, A-MSDU or MMPDU is encrypted”, it is MPDU (or fragment) is encrypted

Ah, interesting point. I thought you could say that MSDUs/A-MSDUs/MMPDUs

are encrypted. But OK, then:

If the fragments of the MSDU, A-MSDU or MMPDU are encrypted, and the retransmitted fragment has a different length from the previous fragment, the PN shall be greater than any PN previously used for transmissions to the receiver.

NOTE—This is to ensure that requirements on non-reuse of a PN with the same temporal key are met (see 12.5.3.3.2 and 12.5.5.3.2).

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: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Sent: Thursday, 20 August 2020 12:02
To: Mark Rison <m.rison@xxxxxxxxxxx>; tomo.adachi@xxxxxxxxxxxxx; Alfred Asterjadhi <aasterja@xxxxxxxxxxxxxxxx>
Subject: 转发: TGax CRC Teleconference 2020-08-20

Just kind remind, I send a request to the Chair.

If you have suggestion, please tell me. We need to finalize it this week as Osama mentioned before that all the CIDs for D6.0 should be resolved . Once it is decided, hope no similar comment again.

Best wishes,

Ming Gan

发件人: Ganming (Ming)
发送时间: 2020年8月20日 18:58
收件人: Osama AboulMagd <Osama.AboulMagd@xxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: 答复: TGax CRC Teleconference 2020-08-20

Hello Osama

Could you add the 981/r4 (1 CID) and 980/r3 to the agenda? Thank you.

Best wishes,

Ming Gan

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Osama AboulMagd
发送时间: 2020年8月19日 21:23
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-08-20

Hello All,

TGax CRC has a conference call scheduled for Thursday August 20 @ 20:00 ET; for 3 hours.

I’ve uploaded a tentative agenda. It is available at: https://mentor.ieee.org/802.11/dcn/20/11-20-1169-09-00ax-tgax-crc-teleconference-agendas-august-september-2020.pptx

I believe submissions are available covering all (or most) the remaining 34 comments.

• Call the meeting to order

• IEEE-SA IPR policy and procedure

• Attendance. Please record your attendance on IMAT (imat.ieee.org).

• Please add [V} and [NV] beside your name on Webex

• Motions (Candidate CIDs are listed in the next page)

• https://mentor.ieee.org/802.11/dcn/20/11-20-0665-08-00ax-comment-resolution-on-mibs-and-pics.docx - Edward Au - CID 24209

• https://mentor.ieee.org/802.11/dcn/20/11-20-0981-03-00ax-mac-cr-on-fragmentation-for-draft-6-0.doc - Ming Gan - CID 24557

• https://mentor.ieee.org/802.11/dcn/20/11-20-1218-02-00ax-d6-0-misc-cr.docx - Robert Stacey

• Discussion on CID 24102 – Lili Hervieu

• https://mentor.ieee.org/802.11/dcn/20/11-20-0980-02-00ax-mac-cr-on-mu-cascading-for-draft-6-0.doc - Ming Gan

• https://mentor.ieee.org/802.11/dcn/20/11-20-1233-00-00ax-the-last-of-the-cids-plan-b.docx - Alfred Asterjadhi

• https://mentor.ieee.org/802.11/dcn/20/11-20-1235-00-00ax-11ax-d6-0-comment-resolution-of-cid-24043.docx - Liwen Chu

• AoB

• Adjourn

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

Meeting number: 129 383 1701

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

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