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

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

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
发送时间: 2020年10月20日 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
发送时间: 2020年10月19日 21:03
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-10-20

Thanks for these resolutions. Some comments: