| 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 ---
Hmm… (see below). Mark From: Stephens, Adrian P [mailto:Adrian.P.Stephens@xxxxxxxxx]
Hello Mark, Regarding the figure on page 16: Duplicate detection is, IMHO, in the wrong place. MSDU integrity operates on complete MSDUs. Duplicate detection operates on MPDUs, so it needs to be below defragmentation. [MAH] I can’t find text to support this point-of-view. It seems to be ambiguous. What you are saying is logical, but not necessary, I’ll claim (since this an abstract model, you can view
it either way and get the same result, is part of my claim). My first response is to acknowledge that I put it in that spot in the stack up, only so it would align nicely with the Sequence Number Assignment block – just makes for a nice, neat architecture.
But, that said, here are some thoughts that could be argued support my point of view: - Sequence numbers are assigned to MSDUs on TX. Therefore, it’s logical to assume they are logically connected to MSDUs on the RX side, to be checked (and duplicates removed) at the same level
in the stack as where they are assigned. - The duplicate detection logic described in clause 9 has all the various caches of frames already seen. These caches are all described using only the sequence number (not the fragment number),
and thus would seem to apply to the entire MSDU, after defragmentation. - It could be argued that defragmentation will, by its very nature, remove duplicate fragments within an MSDU. In fact, the defragmentation clause says this explicitly. Of course, I have
to admit, it says that duplicate fragments are discarded as described in the Duplicate detection sub-clause, even though I don’t believe the Duplicate detection sub-clause does actually describe discarding duplicate fragments. (It does say that the fragment
number in the frame is part of facilitating duplicate filtering, even though it never mentions it again to say how that is so.) I think the spec is broken in this regard. - So, if defragmentation will remove duplicate fragments, it seems okay (and equivalent in the end) to remove duplicate MSDUs higher up the stack, after the defragmentation is done. Also note that duplicate detection and block ack reassembly are logical “OR”s, as the block ack reassembly performs also the role of duplicate detection. But if this view of the world is not supported by the text, then duplicate detection needs to occur below block ack reordering, because window sizes etc… operate on unique MPDUs, i.e., not including duplicates. [MAH] The text says, “Additional duplicate filtering is performed during Receive Buffer Operation for frames that are part of a (#2353)block ack agreement as described in 9.23.4 (Receive buffer operation) and 9.23.7 (HT-immediate block ack(#2069) extensions).” So, no, the text does not support
these being “OR”s, but rather are additive. Further, I think it is reasonable to say that Block Ack buffering takes care of some duplicates (those that it can detect due to being within a buffer window) and that is just fine and can operate in parallel (and
addition) to doing the cached sequence number duplicate detection higher up the stack to catch duplicates that are further apart in time. If non-APs need DA address filtering, then so do mesh STAs. Not every MSDU received by a mesh STA is necessarily forwarded. I’m unclear about the details, but if it knows no route to the destination, does it forward it to the root, or discard the MSDU? [MAH] Just FYI, “If the source mesh STA is not able to forward the frame because its destination is unknown, the mesh STA shall assume that the destination is outside the MBSS and shall forward the frame to known mesh gates in the MBSS …” But, my shorter answer is that I didn’t specify what happens inside the magic circle within the mesh switching function. All the behaviour of 9.34 could (and probably should)
be assumed to be inside that little magic circle. To your list of questions at the end, I would ask how the figure on page 18 relates to the existing figures expounding the evolution of architectural concepts. Is it the intention to replace these figures with similar ones to p18? [MAH] For now, I’m not proposing to do anything with the figure on page 18. I agree that this needs quite a bit more work and study of the concepts and figures in clause 4, to decide if, or
how, to integrate this. Best Regards, Adrian P STEPHENS Tel: +44 (1793) 404825 (office) Tel: +1 (408) 2397485 (mobile, USA) ---------------------------------------------- From: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx]
On Behalf Of Hamilton, Mark --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
All, I have updated my discussion document, and proposed diagram(s) to replace Figure 5-1 (and Figure 5-2), to resolve CID 2434. Find the updated document here:
https://mentor.ieee.org/802.11/dcn/13/11-13-0115-09-0arc-considerations-on-ap-architectural-models.doc. See pages 14 and 15 of this document for the proposed diagram replacements. No text changes are being proposed. Thanks. Mark _______________________________________________________________________________
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 _______________________________________________________________________________ |