Hello Binita
Please check my response inline.
Best wishes
Ming Gan
发件人: Binita Gupta [mailto:binitagupta@xxxxxxxx]
发送时间: 2022年12月17日
0:35
收件人: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGBE] CR doc 22/1709 - Requesting feedback on add/delete link procedure
Hi Ming,
Thanks for your comments. I have already provided my responses to the points you raised during the call in my very first email in this thread. As I have clarified several times, I am asking for
technical concerns to address those and make progress on this proposal.
Now you are questioning the entire ML Reconfiguration, which is already voted in the draft by members. ML Reconfiguration procedures for adding and removing affiliated APs are defined to add a
new AP to the AP MLD and completely remove an affiliated AP from the AP MLD. That functionality can’t be achieved by the Advertised T2LM, which is designed to first disable an AP/link and then at some later point enable that link. Advertised T2LM can’t provide
the functionality of adding a completely new AP to the AP MLD and also can’t provide the functionality of completely removing an AP from the AP MLD. There are management scenarios in real deployments which require those functionalities. So, I strongly disagree
with your point that ML Reconfiguration is redundant.
[Ming] not now, I questioned it before. Just minor difference between T2LM and ML reconfiguration. Where does new completely new AP come from? The device has fixed hardware, although
sometime it could be used by other non-WiFi system.
For link removal at the non-AP MLD, using power save still requires AP and non-AP MLD to keep maintaining that link and keep using resources for that link. I clarified this point in the first
email. Allowing a non-AP MLD to delete a link is a cleaner solution and simplifies link management for both sides.
[Ming] is there any essential difference? I don’t see it. If you really think it is needed, we could add one more bit for current power save to further differentiate one from the
other.
For link addition at the non-AP MLD, the main scenario which needs to be addressed is when the AP MLD adds a new affiliated AP. There can’t be any disabled link at the AP MLD for an AP which is
not yet added. So, the first option you are mentioning below can’t work for the scenario when a new affiliated AP is added. The second option you mentioned about non-AP MLD doing reassociation is disruptive for non-AP MLD as it tears down association, security,
block ack, TWT, SCS etc. context (as has been clarified by several members). Now you are saying that non-AP MLD should wait for a time when it is not doing any transmissions and then do reassociation to add a link. This is very restrictive for non-AP MLD and
will impact performance because non-AP MLD can’t add links when it needs those. Also, as Jarkko pointed out, if a non-AP MLD does a reassociation it may get less number of links from the AP or the entire reassociation could fail. So, doing a reassociation
for adding a link is not a viable option for many reasons.
[Ming] The question is where the new affiliated AP comes from. If the AP MLD has this hardware, could it advertise a disable one for it? For the association, I just mentioned in
some cases, it doesn’t impact the traffic delivery.
Overall, as Jarkko said it is vey hard to come up with reasons why add link signaling should not be included in TGbe spec. If group prefers, one approach we can take is to include the add link
signaling in the 11be spec now and bring in the delete link signaling at a later point. I am open to that path since including the add link signaling is more important functionality wise.
On the SP being run two times – as I said the first SP was run about two years ago and draft spec has changed a lot after that so we need to consider that and move forward in terms of what issues
need to be addressed in the current draft, not just keep citing an old SP.
[Ming] I reviewed old version and new version, I don’t find any essential difference. What spec changes help this proposal?
Thanks,
Binita
Hello all I second Yongho’s opinion. I am fully against this proposal. I raised my concern in the call, I repeated here. Hope some guys do not just
ask for technical concern for the sake of asking. ML configuration is totally redundant, even
|
This Message Is From an External Sender
|
|
|
|
Hello all
I second Yongho’s opinion. I am fully against this proposal. I raised my concern in the call, I repeated here. Hope some guys do not just ask for technical concern for the sake
of asking.
ML configuration is totally redundant, even for AP MLD side. We have TID to link mapping mechanism which can achieve the same/similar function. Advertised T2LM can achieve both AP
addition and AP removal. Please make the spec precise. Now we almost reach D3.0, proposing redundant mechanism will bring risk to the draft development.
For link removal at the non-AP MLD side, Abhi already mentioned below it can be achieved by power save, why do we need to develop another redundant mechanism again?
For link addition at the non-AP MLD side, first one way is that we could let non-AP MLD to have multi-link setup with disable link at the beginning, then once this disable link is
enabled，this link is automatically added at the non-AP MLD side. The other way, non-AP MLD can do reassociation at some time.
The non-AP MLD doesn’t have frame exchange at each time slot. It can choose some idle time slots to do this. This impact is minor.
By the way, this was run two times, lots of people were against it.
Best wishes
Ming Gan
Thank you all for your reflector discussion on add/delete link proposal in 22/1709. I fully agree with the technical reasons given by Abhi, Po-Kai, Thomas and Jarkko in support of this proposal.
As others have voiced, there is a gap in the TGbe spec today as no mechanism is defined to seamlessly add or delete links for a non-AP MLD forcing it to do reassociation if it needs to make changes to ML setup which is
disruptive and will impact performance. The need for addressing this issue in 11be draft is clearly called out by 20+ CIDs submitted by members on this same topic. Hence, we need to address this gap identified. I would like to hear specific technical concerns
on the proposal so we can work towards addressing those and make progress.
On the process aspect – agree with Mike that there is no reason to assert that this proposal or for that matter any other proposal will impact ballot passing or failing.
Again, the need to address this gap is clearly identified by members. There is a proposal providing resolution for the issue, so the group members opposing this proposal should provide their technical concerns so that
we can work together to resolve those and reach consensus to fix this gap in TGbe spec.
@Yongho, @Ming – request you to please provide your technical concerns on the proposal if you see any.
Thanks,
Binita
Hi, I would like to speak in favor this submission too. I agreee with the reasons given by Abhi, Po-Kai and Thomas. AP may not accept all links that
STA is requesting and currently there is no easy way to add the missing links to the association.
|
This Message Is From an External Sender
|
|
|
|
Hi, I would like to speak in favor this submission too.I agreee with the reasons given by Abhi, Po-Kai and Thomas.
AP may not accept all links that STA is requesting and currently there is no easy way to add the missing links to the association.
Currently the STA needs to re-associate, i.e. destroy its current keys and association, redo all setups of Block Acs, SCS, etc. that requires ~ 40 UL and DL messages transmissions.
Even if the STA re-associates, the STA does not know which links the AP is going to accept.
It may happen that STA gets less links than it used to have, or AP just rejects the reassociation request.
With Add Link signaling, the STA may continue to transmit low delay traffic while it adds the missing links to its association.
This improves networking reliability and avoids additional delay caused by totally unnecessary re-association.
It is very hard to come up any reasons why add link signaling should not be included.
As one of the cosigners of the document, I also speak in favor of the proposal.
The proposal has obvious benefits for non-AP MLD to have better link management without going through complicated reassociation procedure.
I understand that there are discussions in the past. However, I will also point out that we have added many link management schemes on the AP MLD side after those discussion in the past as pointed
out by another member. As a result, having better link management for non-AP MLD is now required to balance the current asymmetry of link management capability and is definitely in the scope of 11be.
It will be shocking to me that we decide not to have the proposed link management capability for non-AP MLD due to non-technical reasons.
I also support this proposal, and fully agree with Abhi’s comments.
We should keep in mind that many non-AP STA (MLD) devices will need to dynamically adjust usage of their radio resources for many reasons - e.g. concurrent infra + P2P, in-device coex with other
technologies, neighbor discovery, ranging/sensing, deeper power save, etc.
If a client device needs to disassociate (and later re-associate) each time its available radio resources become insufficient to operate (in an 802.11-compliant manner) the affiliated non-AP STAs
it previously negotiated, it is very disruptive to performance/UX (e.g. due to teardown and recreation of many states including Block acks, QoS, etc). It can also cause unnecessary overhead on the network side (e.g. disassociation might trigger network accounting
events etc).
I agree if there are technical concerns they should be discussed on this thread (there is no way to respond to hearsay about concerns expressed offline). The proposal is not particularly complex,
so I find it hard to believe we could not find a reasonable consensus on the design that avoids unnecessary performance degradation.
I speak in favor of this proposal and here’s my reasoning:
Today, when an AP MLD adds a link (which the non-AP MLD is capable of operating on), there is no mechanism specified in the standard for the non-AP MLD to add that link to its existing ML setup.
This is a gap in the spec that needs to be fixed. It is not a new feature. Due to lack of guidance from the spec, the only option available to a non-AP MLD is to disassociate and reassociate with the same AP MLD. Disassociation is very disruptive. It tears-down
association, security and block ack context. As a result any on-going session is terminated. This will impact performance.
The proposal in 1709 will address the gap and provide a mechanism for a non-AP MLD to seamlessly add a link to an existing ML setup while maintaining association, security and BA context. Furthermore,
any on-going sessions will not be interrupted.
The 1:1 remove feature has benefits too. In the current spec, an AP MLD is allowed to remove a link (on a global basis). However, the spec fails to provide a mechanism for a non-AP MLD to do the
same. There were some arguments made about ‘disabling a link’. Here too, there is asymmetry in the protocol. An AP MLD is allowed to disable a link (on a global basis) if it can’t operate on that link. However from a non-AP MLD point of view, it has to ‘negotiate’
disablement if it cannot use that link. Signaling PM=1 can be a way to address the issue. However, it still keeps the resources (such as memory etc) allocated and blocked on both sides. Deleting a link is a clean solution for scenarios where the non-AP MLD
knows it won’t be using the link going forward.
We can’t decide to not address an issue because we failed to reach consensus in the past. Instead, I would like to hear technical concerns so that we can work together to solve them and fix the
gaps in the TGbe spec.
WARNING: This
email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
As I commented in an offline discussion, this feature has been discussed for 2 years.
Based on the SP result from the November meeting, it seems that the result is going worse compared with last year's result.
20/1554r4 (ML Reconfiguration, Payam Torab, Facebook)
Straw Poll Result: 43 Y/30 N/18 A
22/1709r4 (LB266 CR for ML Reconfiguration Add Delete Link procedure, Binita Gupta, Meta)
Straw Poll Result: 50 Y/47 N/18 A
I think that it is late to address in TGbe, like other quarantine documents,
Rather than a technical advantage, passing the Letter Ballot is more important to me. Actually, that is the goal of the comment resolution.
In that context, I checked the comment spreadsheet, I know that this CR document may address 8 NO voters' concerns. But, I heard concerns from tens of other NO voters about this feature in the
offline discussion. So, I believe that adding this feature is not helpful to make the approved TG draft in the next LB because they will not change their vote to Approve and will submit more technical comments.
So, as I said in an offline discussion, I like to reject those CIDs for the same reason as other quarantine documents. And, please refer to the rejection document (11-22/2042)
for the motion in the next joint meeting.
I presented CR doc 22/1709r4 during
the TGbe Nov plenary session which proposes add/delete link procedures for dynamically adding a link to the ML setup or deleting a link from the ML setup of a non-AP MLD.
There were some concerns raised by Ming and Yongho on the proposal. I tried to initiate small group discussions to understand and address their concerns, however due to holidays time, it is hard
to find a suitable time slot which works for most.
Hence, I am initiating this discussion on the reflector to hear their concerns and make progress on this CR doc.
I would like to briefly summarize below the reasons/benefits for this proposal, to help the group better understand.
·
Add Link - Currently the spec does not define any action for the non-AP MLD to take when a new affiliated
AP is added to the AP MLD. If the non-AP MLD wants to add a link to the new AP it is forced to do a re-association, which is very disruptive as it clears all the context on BA, security etc. and interrupts ongoing transmissions on existing links. The add link
procedure in 22/1709 proposal a mechanism for seamlessly adding a link to the ML setup of the non-AP MLD without requiring a re-association - it maintains current BA and security context and does not cause any interruption to ongoing transmission on existing
links. This is a highly desirable behavior for adding a link to an ML setup.
·
Delete Link – In current spec if a non-AP MLD intends to delete a link from its ML setup, there is no procedure
defined for it to do that. It still has to keep using resources for maintaining the link as part of ML setup even if it moves that link to Power save or negotiate a TID-to-link mapping excluding that link. The delete link procedure in 22/1709 allows explicit
deletion of a link from the ML setup and frees up resources for both the non-AP MLD and AP MLD and simplifies link management.
@Ming – please provide your specific concerns on the add link and delete link procedure. You
expressed some concerns on delete link procedure during the call and below are my responses on those. You didn’t express any technical concerns on the add link part, so are you fine with the proposed add link procedure?
1.
You mentioned that non-AP MLD can use the power save or negotiate a new T2L mapping for disabling a link from its ML setup. That is possible but that still requires both sides to keep using resources to maintain
the disabled link as I mention above. It is desirable to provide an explicit mechanism to remove the link to simplify the link management for both sides.
2.
You also mentioned that Advertised T2LM can be used for deleting a link. That feature is defined for disabling a link for the entire AP MLD level and not for deleting a link from the ML setup of a specific non-AP
MLD. So, the Advertised T2LM can’t be used for deleting a link from the ML setup of a non-AP MLD.
@Yongho – please provide your specific concerns on the add/delete link procedure. The main
concern I heard from you is that this is a new feature, and it could impact other parts of the spec and hence should be addressed in UHR timeframe. I think this feature is pretty self-contained and if there is any impact on some other part of the spec, it
would be minor clarification, not any big technical change. Please let me know what specific spec impact you are concerned about (if any). BTW, this feature has been discussed in the group previously in 11-21/0534 CR doc, so this is not a new feature being
discussed first time. I also understand that at that time the group’s direction was that this feature could be brought back in D2.0, and that’s what we are doing here. So, shouldn’t reject this feature saying that this is a new feature.
Again, I would like to understand your specific concerns and find ways to address those to make progress on this proposal in D2.0 timeframe.
Others – please let me know if you have any feedback/comments on the proposal.
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