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

Re: [STDS-802-11-TGM] CID 3392 (concurrent reception of fragments of at least three MSDUs or MMPDUs)



--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

Last and final call for CID 3392, gate D4.0 closing now!

 

Here is some further research on the topic of the statement

 

A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs.

 

in the spec.  It appears this pre-dates 11e, so this is not about

inter-AC interleaving.  It has been put to me that this is not about

reception from different peers either.

 

So, what is it about?

 

Similarly, regarding the statement:

 

Except when using block ack, a DMG STA shall complete the transmission of a fragmented MSDU before

starting transmission of another MSDU with the same TID of the fragmented MSDU.

 

the following appears in the ad-hoc notes:

 

we are quite sure there is text somewhere else that does require this for all STAs.

Need to recall that discussion (from the F2F in San Antonio) and find the cite.

 

It would be very desirable for those who participated in "that discussion"

to recall it!

 

Backup

 

Here are extracts from the spec and some comments on them:

 

9.5 Fragmentation

 

Except when using block ack, a DMG STA shall complete the transmission of a fragmented MSDU before

starting transmission of another MSDU with the same TID of the fragmented MSDU.

 

[“we are quite sure there is text somewhere else that does require this for all STAs.  Need to recall that discussion (from the F2F in San Antonio) and find the cite. Will reconsider on the next telecon, and confirm that we've covered all the cases, and determined whether there are any special cases or not (after refreshing the memory of the F2F discussion, as well).”  OK, where?]

 

9.6 Defragmentation

 

A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs. Note that a

STA receiving more than three fragmented MSDUs or MMPDUs concurrently may experience a significant

increase in the number of frames discarded.

 

The destination STA shall maintain a Receive Timer for each MSDU or MMPDU being received, for a

minimum of three MSDUs or MMPDUs.

 

[Note: both these fragments appear in 802.11-1999.  So this is nothing to do with EDCA reordering.]

 

9.8 MSDU transmission restrictions

 

To avoid reordering MSDUs between pairs of LLC entities and/or unnecessarily discarding MSDUs, the

following restrictions shall be observed by any STA that is able to concurrently process multiple outstanding

MSDUs for transmission. The term outstanding refers to an MPDU containing all or part of an MSDU or

MMPDU for which transmission has been started, and for which delivery of the MSDU or MMPDU has not

yet been completed (i.e., an acknowledgment of the final fragment has not been received and the MSDU or

MMPDU has not been discarded due to retries, lifetime, or for some other reason). A STA may have any

number (greater than or equal to one) of eligible MSDUs outstanding concurrently, subject to the restrictions

below.

 

A non-QoS STA shall not have more than one MSDU or MMPDU from a particular SA to a particular

individual RA outstanding at a time.

 

NOTE 1—A simpler, more restrictive alternative to the rule in the above paragraph that may be used is that no more than

one MSDU with a particular individual RA be outstanding at a time.

 

[The “simpler, more restrictive alternative” seems to ensure that a STA will never have to support concurrent reception of fragments of more than one MSDU/MMPDU.  So is all the fuss for non-QoS about the case where you have MSDUs from multiple SAs being sent to/via the same AP?!]

 

For frames that are not sent within the context of a block ack agreement, a QoS STA shall not have more than

one MSDU or A-MSDU for each TID or MMPDU from a particular SA to a particular individual RA

outstanding at any time.

NOTE 2—A simpler, more restrictive alternative to the rule in the above paragraph that may be used is that no more than

one MSDU or A-MSDU with any particular TID with a particular individual RA be outstanding at any time.

 

[Ditto, though on a per-TID basis.  But as noted above the “three concurrent” thing pre-dates TIDs.]

 

9.22.2 HCF contention based channel access (EDCA)

9.22.2.1 Reference model

 

A DMG STA may implement a single AC. If the STA implements a single AC, all UP and frame types shall

be mapped to AC_BE.

 

NOTE—A DMG STA that implements a single AC has only one queue in Figure 9-23 (Reference implementation

model when dot11AlternateEDCAActivated is false or not present).

 

[Where is the stuff which explains how stuff is taken off queues?  Is it just that each queue is a pseudo-STA fed MSDUs one at a time?  That would still require a statement that a new MSDU is not fetched if a previous one is outstanding.]

 

11.4.3.4 CCMP decapsulation

11.4.3.4.4 PN and replay detection

 

h) The receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not

sequential.

 

[What exactly does “sequential” mean?]

[Not in GCMP.]

 

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: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx] On Behalf Of Mark Rison
Sent: 11 December 2014 08:52
To: STDS-802-11-TGM@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGM] CID 3392 (concurrent reception of fragments of at least three MSDUs or MMPDUs)

 

--- This message came from the IEEE 802.11 Task Group M Technical Reflector ---

> 1. Minutes for 802.11 TG REVmc on Friday November 21, 2014 –

> 1.6.2.   CID 3392 (MAC)

 

Namely:

 

"A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs. [...]
The destination STA shall maintain a Receive Timer for each MSDU or MMPDU being received,

for a minimum of three MSDUs or MMPDUs." -- does this always apply (e.g. DMG STAs -- see end

of 9.5 and 9.22.2.1; also what about the risk of MSDU/MMPDU reordering caused by concurrent

reception causing replay detection to discard MSDUs/MMPDUs)?

 

> 1.6.2.1. Cited text duplicates text in 9.5.

> 1.6.2.2. Consider deleting text in 9.5

> 1.6.2.3. Review on Dec 12th teleconference.

 

I think the "text in 9.5" in question is the following:

 

Except when using block ack, a DMG STA shall complete the transmission of a fragmented MSDU before

starting transmission of another MSDU with the same TID of the fragmented MSDU.

 

0) Is this being deleted because it is believed to be duplicated by

material elsewhere in the standard?  If so, where, exactly?

 

Furthermore, the commenter specifically mentioned the following

text in 9.6:

 

A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs.

 

What does this mean, exactly?

 

1) Is there an implied "from different peer STAs"?

 

2) If there isn't, is there an implied "with different TIDs,

if sent in QoS Data MPDUs"?  Or is there an implied "as long

as replay counter constraints are met, if sent in an RSNA"?

 

3) Is there some difference between EDCA and HCCA (and HEMM)

behaviour?

 

4) Note also the sentence in 11.4.3.4.4 PN and replay detection

at 1895.40:

 

The receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not

sequential.

 

which appears for CCMP but not for GCMP.

 

Asking this in a different way, which of the following would be correct:

 

a) A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs,

where these are received from different STAs.

NOTE—Fragmented MSDUs/MMPDUs sent by a STA to another STA are not interleaved.

 

b) A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs,

where these are received from different STAs, and where these are received from the same STA.

NOTE— Fragmented MSDUs with different TIDs, and MMPDUs, sent by a STA to another STA might be interleaved,

subject to the maximum number of replay counters advertised by the receiving STA.

Fragmented MSDUs with a given TID/MMPDUs sent by a STA to another STA are not interleaved.

 

c) A STA shall support the concurrent reception of fragments of at least three MSDUs or MMPDUs,

where these are received from different STAs, and where these are received from the same STA.

NOTE— Fragmented MSDUs with a given TID/MMPDUs sent by a STA to another STA might be interleaved.

 

d) Something else (whether to account of HCCA/HEMM differences

or unencrypted/WEP/TKIP/CCMP/GCMP differences or otherwise)?

 

I also note the following:

 

9.8 MSDU transmission restrictions

 

A STA may have any

number (greater than or equal to one) of eligible MSDUs outstanding concurrently, subject to the restrictions

below.

 

A non-QoS STA shall not have more than one MSDU or MMPDU from a particular SA to a particular

individual RA outstanding at a time.

NOTE 1—A simpler, more restrictive alternative to the rule in the above paragraph that may be used is that no more than

one MSDU with a particular individual RA be outstanding at a time.

 

For frames that are not sent within the context of a block ack agreement, a QoS STA shall not have more than

one MSDU or A-MSDU for each TID or MMPDU from a particular SA to a particular individual RA

outstanding at any time.

NOTE 2—A simpler, more restrictive alternative to the rule in the above paragraph that may be used is that no more than

one MSDU or A-MSDU with any particular TID with a particular individual RA be outstanding at any time.

 

[Tsk, tsk, a "may" in a NOTE!]

 

My interpretation of the NOTEs is that you can end up with interleaved

fragments, as long as the SA (not the TA, obviously) differs, or,

for HCF, the TID differs.  [I'm not entirely sure how to parse

the "or MMPDU" in the latter case, though.]  But I'm not sure how

that's compatible with the rule on sequential PNs for CCMP.

 

Mark

 

P.S.: There's probably at least one egregious error on my part above.

After some time, fragments, TIDs, PNs, replay counters, etc. just

start becoming one big blur.

 

--

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

 

_______________________________________________________________________________

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________

_______________________________________________________________________________

IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.

SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.

Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________