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

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



Thanks Mark. Please find inline.

Regards,

Alfred

On Wed, Oct 21, 2020 at 6:42 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

> I would like to keep capability for the AP

 

Well, why -- what is the purpose of signalling the AP's capability here?

[AA] Useful for the non-AP STA to know if the AP implements this feature or not is my guess.

 

If the AP supports MU cascading, it sends the kinds of MU PPDUs that

are only used if MU cascading is supported (of course it first has to

check whether the non-AP STA supports MU cascading too).  The non-AP

STA doesn't have to check anything before sending the TB PPDU, since

the AP will not send those kinds of MU PPDUs if the AP doesn't support

MU cascading.

[AA] That is correct. And i dont think there is something as of now which asks the STA to check something. I believe Ming was adding something to that extent if i recall correctly but i dont think we need to. 

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 Ganming (Ming)
Sent: Tuesday, 20 October 2020 17:05
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX]
答复: TGax CRC Teleconference 2020-10-20

 

Alfred and Mark

 

Could you help check the following comment? I would like to keep capability for the AP. Any comments

 

25075

195.06

9.4.2.248.2

There is no normative behaviour associated with the MU Cascading Support subfield at the AP, i.e. a non-AP STA does not have to look at it to do or not do anything in particular

In Table 9-323a—Subfields of the HE MAC Capabilities Information field change "For an HE AP:
Set to 1 to indicate that the AP is capable of trans-
mitting an A-MPDU that is constructed following
the MU cascade sequence rules (see 26.5.3 (MU
cascading sequence)) under MU cascade operation.
Set to 0 otherwise." to "Reserved for an AP."

 

Best wishes,

Ming Gan

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Mark Rison
发送时间: 20201020 21:34
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-10-20

 

Mu Cascading: https://mentor.ieee.org/802.11/dcn/20/11-20-1646-00-00ax-mac-cr-on-mu-cascading-for-draft-7-0.doc

 

25058: I'm not sure about the change w.r.t. the proposed change.

The receivers of an MU PPDU are the same as the transmitters of

the immediately following TB PPDUs, except for the corner cases

of no-ack MPDUs, corruption and CS Required denial, etc., but

this is not a special feature of cascading, it's always the case.

[Ming]but the original text cover the exception you mentioned. So this rephrasing is better

 

I assert the original text is poor too.

 

Also, you don't need "within the same TXOP" since the whole para is

about "In an MU cascading sequence", though if you wanted to say

"Within an MU cascading sequence" I'd be OK.

[Ming] I am not sure MU cascading sequence could cross one TXOP, but we do not disallow it. So “within the same TXOP” is reasonable

 

I think an MU cascading sequence has to be a single TXOP, because

the point of cascading is to have an MU PPDU that both acks some stuff just

received, and triggers some stuff immediately next.  Figure 26-5—An example

of an MU cascading sequence supports this.

 

25075: I'm not sure about the proposed additional requirement for

a non-AP STA to check the AP's MU Cascading Support subfield

before responding to an MU PPDU from the AP.  If the AP can't

cope with MU cascading, it should not trigger a STA for a

cascading transmission.

[Ming] but you know this is optional for AP, so I use similar language for the nonAp STA.

 

No, the point is that a STA should not be required to do additional

checks when it receives a Trigger frame from the AP.

 

[Also I don't know what "a response frame to a received triggering frame" is in the

new proposed text.]

 

Fragment: https://mentor.ieee.org/802.11/dcn/20/11-20-1647-00-00ax-mac-cr-on-fragmentation-for-draft-7-0.doc

 

25112: the problem with saying "shall also support level 1 dynamic

fragmentation" is that it's not clear: do you support level 1

dynamic fragments at the same time as level 2/3 dynamic fragments,

or is it just that you have L1 support if the peer doesn't support

L2/L3?  I think the proposed change is better.

[Ming] I am not sure I get your question. The proposed change is “An HE STA that is operating in level 2 or level 3 shall also support level 1 dynamic fragments”, my resolution is “An HE STA that is operating in level 2 or level 3 can still transmit and receive the dynamic fragments under Level 1 shall support level 1 dynamic fragmentation”. Why do you say the proposed change is better?

 

Your r0 resolution was:

 

An HE STA that is operating in level 2 or level 3   shall support level 1 dynamic fragmentation

 

which as I said was not clear: do you support level 1

dynamic fragments at the same time as level 2/3 dynamic fragments,

or is it just that you have L1 support if the peer doesn't support

L2/L3?

 

In r1 you now have:

 

An HE STA that is operating in level 2 or level 3   shall support to transmit and receive the dynamic fragments under level 1

 

but that basically has the same problem: is "under level 1" saying that

if the peer doesn't support L2/L3 you have to support L1, or is it

saying that in addition to supporting the types of dynamic fragments

described for L2/L3 you also support the L1 dynamic fragments

(when operating with an L2/L3 peer)?

 

I think

 

An HE STA that is operating in level 2 or level 3 shall also support level 1 dynamic fragments

 

is better because it clearly distinguishes the operating level from

the types of dynamic fragments that need to be supported.

 

Or reject this comment because we have the corresponding descriptions in 26.3.2 and 26.3.3. or we could change it to “An HE STA that is operating in level 2 or level 3 shall also support to transmit and receive the dynamic fragments under level 1

 

No, I think we need it in 26.3.1 for the description to be complete.

 

25115: I am not 100% sure "so that the PN never repeats for the same temporal key"

is correct.  I agree that's what md/D5.0/12.5.3.3.1/a)1) suggests,

but on the other hand 12.5.3.1 indicates only reuse of a TK

with the same nonce is an issue, and as 12.5.3.3.4 shows the

nonce includes the UP, so maybe the PN can repeat for the same

TK as long as it's for a different UP?  +Jouni here; the proposed

wording is:

[Ming]PV0 MPDU, PN is not related to UP, but if that is PV1 MPDU, it is related to UP, please refer to 12.5.3.3.1/b)1)

 

We don't need to worry about PV1 MPDUs because HE does not use them.

 

12.5.3.1 says:

 

CCM also requires a unique nonce value for each frame

protected by a given temporal key(#4086). Reuse of a nonce value(#4086) with the same temporal key voids

all security guarantees.

 

12.5.3.3.4 shows that the nonce includes the priority (UP):

 

 

So I have two concerns with:

 

The frame body length and contents of the retransmitted fragment shall be the same as the initially transmitted fragment and shall remain fixed for the lifetime of the MSDU, A-MSDU or MMPDU at that STA except when all the fragments preceding the initial transmitted fragment were received and all the fragments following the initial transmitted fragment have either explicitly failed or have not been transmitted, in which case the frame body length and contents of the retransmitted fragment may be different from the initially transmitted fragment and the PN assignment for the retransmitted fragment shall follow the rules defined in 12.5.3.3.2 (PN processing) and 12.5.5.3.2 (PN processing) except that the PN shall be incremented for the retransmitted fragment so that the PN never repeats for the same temporal key (#CID 25115) if it has a different body length from the previously transmitted fragment and is encrypted.

 

1) I am not sure it's a problem if the PN repeats, as long as it's

for different UPs

 

2) But even if we play it safe an say the PN must never repeat full

stop, the specification shall be incremented so that the PN never repeats is not clear.

We need to be more explicit on how this is to be achieved, e.g.

does the sender have to remember all the PNs it has ever used and

pick one it hasn't used before, even if it's less than one it has

used before?  Or can/shall it just remember the biggest it has ever used

and use one more than that?

 

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 Ganming (Ming)
Sent: Tuesday, 20 October 2020 10:04
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX]
答复: TGax CRC Teleconference 2020-10-20

 

Thanks Mark for your comments. Please see my response inline. Thanks

 

Please refer to the new version in the server.

 

Best wishes

Ming Gan

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Mark Rison
发送时间: 20201019 21:03
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-10-20

 

Thanks for these resolutions.  Some comments:

 

Mu Cascading: https://mentor.ieee.org/802.11/dcn/20/11-20-1646-00-00ax-mac-cr-on-mu-cascading-for-draft-7-0.doc

 

25058: I'm not sure about the change w.r.t. the proposed change.

The receivers of an MU PPDU are the same as the transmitters of

the immediately following TB PPDUs, except for the corner cases

of no-ack MPDUs, corruption and CS Required denial, etc., but

this is not a special feature of cascading, it's always the case.

[Ming]but the original text cover the exception you mentioned. So this rephrasing is better

 

Also, you don't need "within the same TXOP" since the whole para is

about "In an MU cascading sequence", though if you wanted to say

"Within an MU cascading sequence" I'd be OK.

[Ming] I am not sure MU cascading sequence could cross one TXOP, but we do not disallow it. So “within the same TXOP” is reasonable

 

25075: I'm not sure about the proposed additional requirement for

a non-AP STA to check the AP's MU Cascading Support subfield

before responding to an MU PPDU from the AP.  If the AP can't

cope with MU cascading, it should not trigger a STA for a

cascading transmission.

[Ming] but you know this is optional for AP, so I use similar language for the nonAp STA.

 

(Also editorially "it transmit" -> "it transmits" (2x))

[Ming] I forgot to change it. Before it was “they transmit”. Thanks

 

 

In the first para below Discussion… Word is showing a change bar,

but I can't work out what is being changed.  What is being changed here?

[Ming] No change there. Maybe I used previous CR document as template and removed the corresponding discussion

 

Fragment: https://mentor.ieee.org/802.11/dcn/20/11-20-1647-00-00ax-mac-cr-on-fragmentation-for-draft-7-0.doc

 

25109: the proposed change is better; you cannot have "shall"

in a NOTE.

[Ming]I strike out “shall” and do not inlcude “will”

 

25110/25111: these are the same comment with different proposed

changes, one for each of the possible interpretations.  In the

resolution it would be better to say which is the correct

interpretation.  (Seems it's "1) for a dynamic fragment containing a Management

frame, you can only have one in the A-MPDU"?)

[Ming] the first interpretation is correct, I added it to the resolution and have one more explaination

 

 

25112: the problem with saying "shall also support level 1 dynamic

fragmentation" is that it's not clear: do you support level 1

dynamic fragments at the same time as level 2/3 dynamic fragments,

or is it just that you have L1 support if the peer doesn't support

L2/L3?  I think the proposed change is better.

[Ming] I am not sure I get your question. The proposed change is “An HE STA that is operating in level 2 or level 3 shall also support level 1 dynamic fragments”, my resolution is “An HE STA that is operating in level 2 or level 3 can still transmit and receive the dynamic fragments under Level 1 shall support level 1 dynamic fragmentation”. Why do you say the proposed change is better?

 

Or reject this comment because we have the corresponding descriptions in 26.3.2 and 26.3.3. or we could change it to “An HE STA that is operating in level 2 or level 3 shall also support to transmit and receive the dynamic fragments under level 1

 

25115: I am not 100% sure "so that the PN never repeats for the same temporal key"

is correct.  I agree that's what md/D5.0/12.5.3.3.1/a)1) suggests,

but on the other hand 12.5.3.1 indicates only reuse of a TK

with the same nonce is an issue, and as 12.5.3.3.4 shows the

nonce includes the UP, so maybe the PN can repeat for the same

TK as long as it's for a different UP?  +Jouni here; the proposed

wording is:

[Ming]PV0 MPDU, PN is not related to UP, but if that is PV1 MPDU, it is related to UP, please refer to 12.5.3.3.1/b)1)

 

The frame body length and contents of the retransmitted fragment shall be the same as the initially transmitted fragment and shall remain fixed for the lifetime of the MSDU, A-MSDU or MMPDU at that STA except when all the fragments preceding the initial transmitted fragment were received and all the fragments following the initial transmitted fragment have either explicitly failed or have not been transmitted, in which case the frame body length and contents of the retransmitted fragment may be different from the initially transmitted fragment and the PN assignment for the retransmitted fragment shall follow the rules defined in 12.5.3.3.2 (PN processing) and 12.5.5.3.2 (PN processing) except that the PN shall be incremented for the retransmitted fragment so that the PN never repeats for the same temporal key (#CID 25115) if it has a different body length from the previously transmitted fragment and is encrypted.

 

Thanks,

 

Mark

 

P.S.: As regards "could you add the tile for 26.6, like 26.6 (A-MPDU operation in an HE PPDU)?"

I think it appears automatically in drafts and disappears automatically

in the final published document.

[Ming] thanks for your info

 

--

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 Ganming (Ming)
Sent: Monday, 19 October 2020 03:05
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX]
答复: TGax CRC Teleconference 2020-10-20

 

Hello all,

 

I uploaded two CR documents to the server, please refer to the following link, comments are welcome

 

Fragment: https://mentor.ieee.org/802.11/dcn/20/11-20-1647-00-00ax-mac-cr-on-fragmentation-for-draft-7-0.doc

Mu Cascading: https://mentor.ieee.org/802.11/dcn/20/11-20-1646-00-00ax-mac-cr-on-mu-cascading-for-draft-7-0.doc

 

Best wishes

Ming Gan

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Ganming (Ming)
发送时间: 20201019 9:22
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGAX] 答复: TGax CRC Teleconference 2020-10-20

 

Hello Osama,

 

Is the meeting time Tuesday October 20 @ 10:00 ET based on the calendar of 802.11?

 

Best wishes

Ming Gan

 

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Osama AboulMagd
发送时间: 20201018 3:17
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-10-20

 

Hello All,

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

Please let me know if you plan a submission. A draft agenda is available at: https://mentor.ieee.org/802.11/dcn/20/11-20-1552-10-00ax-tgax-crc-teleconference-agendas-october-november-december-2020.pptx

 

Webex Info: https://ieeesa.webex.com/ieeesa/j.php?MTID=mfb526d03f3e9ec7b8b28fe7a78faf086  

Meeting number: 173 002 9529

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: 173 002 9529

 

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

 https://mentor.ieee.org/802-ec/dcn/17/ec-17-0120-27-0PNP-ieee-802-lmsc-chairs-guidelines.pdf

•       Participation in IEEE 802 Meetings

https://mentor.ieee.org/802-ec/dcn/16/ec-16-0180-05-00EC-ieee-802-participation-slide.pptx

•       IEEE 802.11 WG OM: (Approved 10 Nov 2017)                                                                                                                                                                      

https://mentor.ieee.org/802.11/dcn/14/11-14-0629-22-0000-802-11-operations-manual.docx

Regards;

Osama.

 


To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1


To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1


To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1


To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1


To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1


To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1


To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1


To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1



--
Alfred Asterjadhi, PhD
IEEE802.11 TGbe Chair,
Qualcomm Technologies Inc.
Cell #:    +1 858 263 9445
Office #: +1 858 658 5302

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1