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

[STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答���: [STDS-802-11-TGBE] CR doc 22/1709 - Requesting feedback on add/delete link procedure



Hi Binita,

 

Based on the SP results, it seems that most members don’t want to consider the seamless link addition in TGbe. As some members often mention in the call,  considering the 11be timeline, it should be discussed in UHR.

 

Furthermore, according to my observation, there are many candidate technique proposals people want to discuss in TGbe. It’s not good to make an exception for the seamless link addition.

 

 

Regards

Guogang Huang

发件人: Binita Gupta [mailto:00001d96db2c011d-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 20221216 13:54
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] CR doc 22/1709 - Requesting feedback on add/delete link procedure

 

Hi Ming,

 

The first SP you mentioned from Payam was run about 2 years ago (Jan 28, 2021) and many things have changed since then. As Po-Kai mentioned in his response, there have been several updates to link management procedures for the AP MLD side and we need to enhance link management for non-AP MLD to enable seamless addition and deletion of links for non-AP MLDs. May I know the technical reasons why you are opposed to this proposal? As I have mentioned multiple times offline and over the reflector, I am willing to work with members to address their concerns.

 

Thanks,

Binita

 

 

From: Ganming(Ming Gan) <000017d5b1a95115-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, December 15, 2022 7:35 PM
To:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] CR doc 22/1709 - Requesting feedback on add/delete link procedure

 

Hello Mike For your info, this SP was run two times. It is far away to reach consensus. We need to respect the groups opinion to move forward. 20/1554r4 (ML Reconfiguration, Payam Torab, Facebook) Straw Poll Result: 43 Y/30 N/18 A 22/1709r4

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

Hello Mike

 

For your info, this SP was run two times. It is far away to reach consensus. We need to respect the group’s opinion to move forward.

 

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

 

Best wishes

Ming Gan

 

发件人: M Montemurro [mailto:montemurro.michael@xxxxxxxxx]
发送时间: 20221216 8:08
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] CR doc 22/1709 - Requesting feedback on add/delete link procedure

 

Hi Yongho, 

 

From a process point of view the draft has not passed a letter a ballot and is far from even getting to SA Ballot. At this point I dont see how this proposal or any other for that matter, will result in the ballot passing or failing.

 

If there is a technical issue that the group needs to resolve and there is a solution proposed to address the issue, the group needs to consider whether the issue needs to be addressed in this amendment, and if it does, the technical merits of the proposal.

 

Id like to see a reflector discussion to understand:

a) is this an issue that needs to be resolved in TGbe?

 

b) with respect to this proposal, what are the technical issues with it and are there changes that could be made address the issues?

 

c) are the there alternative proposals?

 

 

Cheers,

 

Mike

 

On Thu, Dec 15, 2022 at 3:34 AM Yongho Seok <yongho.seok@xxxxxxxxx> wrote:

Hi Binita, 

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.

 

Thanks, 

Yongho Seok 

 

2022 12 11 () 오후 6:20, Binita Gupta <00001d96db2c011d-dmarc-request@xxxxxxxxxxxxxxxxx>님이 작성:

Hi all,

 

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 didnt express any technical concerns on the add link part, so are you fine with the proposed add link procedure?

  • 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.
  • 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 cant 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 groups direction was that this feature could be brought back in D2.0, and thats what we are doing here. So, shouldnt 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.

 

Thanks,

Binita


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