| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Thanks, John. Comments in line below. And, a summary (of my position):
Mark From: Wullert, John R II (PERATON LABS) <jwullert@xxxxxxxxxxxxxxx> Mark, I do agree with your stated intention that definitions should stand by themselves. Much of the exchange we had so far was the dealing with the tradeoffs between conciseness, completeness and accuracy and in some places the proposed definitions rely on the references for conciseness and accuracy at the expense of completeness. See some additional comments in line. John From: Huang, Po-kai <po-kai.huang@xxxxxxxxx> Hi Mark, Thanks for the discussion. I provide response below. Best, Po-Kai From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx> Thanks, Po-Kai, Reponses, also in-line. Mark From: Huang, Po-kai <po-kai.huang@xxxxxxxxx> Hi Mark, I provide the comments below for the suggestion. Best, Po-Kai From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx> John/all, 1) While I’m okay with a reference to body (sub)clauses from within clause 3, I think having a definition which cannot be understood without reading the body subclause is not appropriate. Thus, I’m not happy with the new definition for BSS transition: basic service set (BSS) transition: Change of association by a station (STA) [10512] or non-AP MLD while remaining within the same extended service set (ESS) as defined in 4.5.3.2 (Mobility types). as it seems the only way to know what sort of “change” to the association constitutes a BSS transition, is to read 4.5.3.2. (There are lots of ways to “change” an association; we’re trying to narrow this to be the movement from one BSS/MLD to another, as the change that is relevant here.) May I suggest instead: basic service set (BSS) transition: [Po-Kai]: I have some discussions with John on this. The reason for seeing 4.5.3.2 is that we have 4 bullets now for STA to STA case, STA to MLD case, MLD to STA case, and MLD to MLD case. The tricky part is that when STA move to AP MLD, it will use non-AP MLD entity. 4.5.3.2 have detailed description to have everything captured. The above simplified version does not capture this, and may look like STA may directly connect to MLD. This is the reason why I suggest to have reference and keeps the description more general as proposed in John’s doc. [[MAH]] 1) I believe the definition is that this is a transition from BSS or AP MLD to another BSS or AP MLD. The details of how that happens are interesting/important, and need to be detailed, as they are in 4.5.3.2, but are not important to the definition of this concept. The concept is simply that this is one of those transitions. That said, I think the proposed definition, which doesn’t even say that it is one of those four types of transitions (but instead tells the reader to go read 4.5.3.2 to figure that out) is imappropriate. [Po-Kai]: I will be ok if you have a better way to capture the fact that the entity needs to change. The current proposal as I have pointed out creates confusions on STA connects to MLD, which is not allowed. [JRW] Perhaps we can augment the definition with text that describes the possible transformations by appending “that may involve transformation from STA to MLD or vice versa”. [[MAH]] John’s proposal works for me. I think this wording is consistent with the ways BSS-transition is described in 4.5.3.2, and is self-sufficient. 2) I’m also uncomfortable with the changes to the definition of fast BSS transition, as now it says the security association (etc.) must be transitioned _before_ the reassociation, while I think it is somewhat before, and somewhat during, the reassociation. We actually debated the current definition a fair bit in REVm<x> trying to prevent this. (But I applaud your use of “BSS transition” so that we don’t have to repeat all that stuff, like the current definition does.) [Po-Kai]: The following sentence is from the baseline directly. Hence, I think there is no issue for the correctness. A fast BSS transition is a BSS transition that establishes the state necessary for [[MAH]] I’m not sure what baseline you’re referencing. In both IEEE 802.11-202 and REVme D1.4, the definition of “fast basic service set transition” is currently, “Change of association by a station (STA) that is from one BSS in one extended service set (ESS) to another BSS in the same ESS and that minimizes the amount of time that the data connectivity is lost between the STA and the distribution system (DS)”. I gather you’re talking about some other sentence somewhere, which does not seem relevant to this CID. Such a sentence might make sense in context. But, with no other context (which is how definitions are supposed to be written), we should be clear and complete. To say the state is established before the reassociation is not clear, and is in fact confusing. [Po-Kai]: You can search that exact sentence, and you will find that directly in the baseline 4.5.3.2. May I suggest instead: fast basic service set (BSS) transition: A BSS transition that minimizes the amount of time that the data connectivity is lost between the STA and the distribution system (DS). [JRW] The text that Po-Kai refers to is in fact basically a definition in 4.5.3.2, with no additional context, so using this text is consistent but it does have the issue with accuracy that Mark highlights. Mark’s proposed definition includes STA, and therefore does not address the comment which is to update defintions to include MLDs. So I would propose: fast basic service set (BSS) transition: A BSS transition that minimizes the amount of time that data connectivity to the distribution system (DS) is lost.” Mark’s concerns with alternate definition, which remains in 4.5.3.2, can be addressed with a subsequent comment. [[MAH]] John’s proposal works for me. Or, we could be more explicit and say “between the STA or MLD, and the distribution system (DS)”. I’m good either way. (And, I acknowledge that I failed to address the comment – sorry about that, it was an inadvertent omission.) To Po-Kai’s comment: I had not noticed that text in the 4.5.3.2, baseline, so thanks for pointing that out (I’m actually not sure why that sentence is even needed/useful in that location – seems out of place, frankly, to me – it presumably is just to clarify that “fast BSS transition” is a type of “BSS-transition” for purposes of this subclause). Seems like a REVme comment to me (which I’ll do). But, I still stand by that the definition should be clear, complete, and correct, whereas a particular sentence in clause 4 may be more “explanatory” and not as crisp and accurate. 3) I hesitate to go here, but reviewing these made me see what I had missed in earlier reviews of 11be draft: that the definition of MLD says the entity has to provide the MAC SAP to the LLC sublayer. Note that on an AP, there is no LLC sublayer (in the controlled port side, anyway, so for all non-EAPOL data frames) – see 5.1.5.3 of 802.11-2020. The same is true for an AP MLD. May I suggest we just remove “to the logical link control (LLC) sublayer” from the end of this definition? [Po-Kai]: John will transfer the CID related to MLD definition to me. My understanding for having LLC sublayer is that in the baseline, we say data service provides peer LLC sublayer to exchange MSDUs. Hence, we say we have one MAC SAP for the LLC sublayer. 5.1.1 Data service This service provides peer LLC sublayer entities or IEEE 802.1Q bridge ports with the ability to exchange [[MAH]] The data service you’re talking about here is for the overall 802.11 “system”, which does transfer data (MSDUs) from one LLC sublayer entity (or 802.1Q bridge port in the case of GLK) to another. However, a given MLD, and in particular an AP MLD, does _not_ transfer data to an LLC entity, it transfers the data to the DS. To say/imply that an AP MLD transfers data to the LLC sublayer is just plain incorrect. And, further, to have the definition of an MLD appear so different (in this respect) to the definition of a STA makes no logical sense – they serve basically the same function, just with different underlying methods. Part of the point of 11be is that in the end, the non-AP MLD and AP MLD appear the same to the rest of the network structure to be performing the same function as the non-AP STA and AP used to perform. [Po-Kai]: I will think the MAC SAP is the data service that we are talking about. The definition just says we will have one MAC SAP to the LLC as required based on the sentence that I point out above. [[MAH]] The first sentence of that 5.1.1.1 subclause makes it clear what “data service” is talking about – it provides “LLC sublayer entities … the ability to exchange MSDUs”. An AP (and now, an AP MLD) does not do that. It is not an LLC sublayer entity (again, ignoring the 802.1X entities for the moment), and does not deliver MSDUs (literally) to any entity – rather it is part of a larger system, and it bridges MSDU payloads between the WM and the DS as part of that system, but only the actual endpoints (wired or wireless) deliver the MSDUs to an LLC entity. But, how about just a simplicity argument. We never mentioned the LLC sublayer before in the definitions of things like AP or STA. Why do we need it as part of the definition of an MLD? We all agree that it has a single MAC SAP and affiliated stations, and that is the definition. Thanks. Mark From: Wullert, John R II (PERATON LABS) <jwullert@xxxxxxxxxxxxxxx> Alfred, Would you please add document 802.11-22-1255r1 to the queue. This addresses 19 CIDs dealing with the definitions in Clauses 3.1 and 3.2. This document has been reviewed by several of the commenters. If others have comments/suggestions, please provide via the reflector. Thanks, John From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx> Hi Alfred, Could you kindly help move the following document from the TGBe MAC technical submission queue to the TGbe MAC CR queue? The r1 version is now a PDT instead of a PPT.
It resolves 1 CID. Regards, Vishnu From: Abhishek Patil <appatil@xxxxxxxxxxxxxxxx>
Hi Alfred, Liwen, Jeongki, Could you please help add the following doc to the TGbe MAC agenda? 11-22/1354: LB266: Resolution for CID 10611 It resolves 2 CIDs. Regards, From: Morteza Mehrnoush <000012bde833b015-dmarc-request@xxxxxxxxxxxxxxxxx> Hi Alfred, Can you please add the following CR doc to the MAC queue?
Thanks, Morteza From: Eunsung Park <esung.park@xxxxxxx> Hi Alfred, Sigurd and Tianyu, Please add the following CR document to the PHY queue. - 11-22/1358r0 LB266 CR for CID 11343 and 12145, Eunsung Park, LG Electronics (2C) ZjQcmQRYFpfptBannerStart This Message Is From an External Sender ZjQcmQRYFpfptBannerEnd Hi Alfred, Sigurd and Tianyu, Please add the following CR document to the PHY queue. 11-22/1358r0 LB266 CR for CID 11343 and 12145, Eunsung Park, LG Electronics (2C) Best regards, Eunsung From: Eunsung Park [mailto:esung.park@xxxxxxx] Hi Alfred, Sigurd and Tianyu, Please add the following CR documents to the PHY queue. 11-22/1288r0 LB266 CR for CID 11341, Eunsung Park, LG Electronics (1C) 11-22/1289r0 LB266 CR for 36.3.2.6 RU and MRU restrictions for 20 MHz operation, Eunsung Park, LG Electronics (2C) Best regards, Eunsung From: Eunsung Park [mailto:esung.park@xxxxxxx] Hi Alfred, Sigurd and Tianyu, Please add the following CR documents to the PHY queue. 11-22/1226r0 LB266 CR for Equations in 36.3.12.9 EHT-STF, Eunsung Park, LG Electronics (2C) 11-22/1227r0 LB266 CR for 36.3.2.3 Null Subcarriers, Eunsung Park, LG Electronics (1C) Best regards, Eunsung From: Alice Jialing Li Chen [mailto:jialing.li.phd2@xxxxxxxxx] Hi Alfred, Could you please add the following CR document to the PHY queue?
Thanks, Alice On Thu, Jul 28, 2022 at 6:53 PM 李雅璞(Yapu) <00001b0ec2563bd4-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |