| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
My understanding is that this is about receiving from different STAs, and does predate 802.11. An IBSS STA and an AP might have received incomplete fragmented MSDU/MMPDUs from different STAs. Three was a number plucked out of the air, which strictly should be multipled by the number of AC in the QoS case. But because the rationale for the original value 3 was non-existent, there is no compelling argument to change it in the QoS case. The requirement is moot when BA is used, because BA provides a negotiated buffer space from which the defragmentation can be performed. And because DMG always uses BA (needs to be verified), the requirement is moot in the DMG case. Best Regards, Adrian P STEPHENS Tel: +44 (1793) 404825 (office) ---------------------------------------------- From: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx]
On Behalf Of Mark Rison --- 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 --- 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. [...] 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 _______________________________________________________________________________
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 _______________________________________________________________________________ |