Hi Payam,
Thanks again for the feedback. Based on the discussion, I think we all agree that we have used MLD association in 11.3 for the general state machine and association procedure for providing service to DS. I think we all agree
on that.
Using those two separate CIDs, my plan is to have separate document to clarify that 35.3.5 is for the link setup procedure embedded in the MLD association, which is new for MLD and use consistent wording across
the spec, where MLD association is a better context. Will certainly be happy to send the separate document to you and other comments for review to make the current spec better.
Best,
Po-Kai
From: Payam Torab <torab@xxxxxxxx>
Sent: Thursday, May 20, 2021 1:10 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/0390 | CIDs 3316, 2313
Thanks Po-Kai for separating these CIDs. I’m copying my offline response below to continue discussion.
The two commenters below, myself, Jarkko and Mike So far have suggested just to use the name ML Association for the procedure, seeing no confusion with this naming.
We are connecting two entities that will result in a DS interface through exchange of Association Request/Response frames, and we have a name for it.
I think a procedure that uses Association Request/Response does not need to be called anything but (some kind of) association.
Regards,
Payam
Thanks for the response. That approach sounds good to me.
Hi Mike,
Thanks for the feedback. Just to clarify that the intention is definitely not to replace MLD association with multi-link setup after all we have done in ARC group to clarify the situation.
Based on the discussion, I will take 3316 and 2313 out from the document for now and prepare a separate document to use consistent wording across the spec. I do agree that we can use MLD association directly in
many other places, and we can just clarify that 35.3.5 is for the link setup procedure embedded in the association request/response exchange.
Best,
Po-Kai
Hi Po-kai,
Thanks. I think that your proposed direction for wording is better. I'm ok with defining better terms to refer to the link between affiliated STAs that result from ML Association. I just think we should avoid using new terms like ML setup,
given the association service and related services are well defined in the base standard.
Hi Mike,
Thanks for the feedback. Just to explain more on the situation here.
I agree that we have spent a lot of times on making sure that we just extend association from STA level to MLD level so that the upper level DS knows the one entity that we are talking about. The term that we use to clarify
this is MLD association (or if you prefer association between two MLDs). The text in 11.3 does address that.
The link setup procedure is something on top of the association service provided to the DS, where request frame indicates the links requested to be setup and the response indicates the links accepted to be setup.
I respond to Payam in another email not on the reflector that if we really want to improve we can have editorial change to say links setup procedure under MLD association or something like that. The link setup procedure is
something new for MLD since we have multiple links for the first time in 802.11 spec.
Best,
Po-Kai
Hi Po-Kai,
I agree with Payam on this one. Given that we've been nailing down the ML Architecture, the connection and state transitions between MLDs still involves Discovery, Authentication, and Association, As a matter of fact, the text that I believe
you contributed to in 11.3 provides requirements on how this process works.
It's better and clearer to use ML Association. At this point, we should transition the draft away from ML Setup towards ML Authentication and ML Association. We already use ML Discovery (Note that I hate ML Probe :-) )
Po-Kai, I still can’t see “ML association” instead of “ML setup” causing any confusion,
-
ML association: Procedure of associating two MLDs; since it is “ML” association it is understood there is one DS interface
-
MLD association: invoking the association service (providing the non-AP MLD <-> AP MLD mapping to the DS)(e.g., existing references in the text don’t seem to need a change).
Re: “This works perfectly for higher layer because higher layer does not care exactly what is the entity. For them, it just one entity, and everything works exactly like before.”
That’s actually a good argument for having the name association (there is ana association happening) – “ML association” does not mean it is multiple; it means it is ML type.
Interested in hearing what other people think. Adding reflector for more feedback. Thanks.
Payam
Hi all,
Thanks for the discussion. Just want to also clarify that for association, what we end up with is that we generalize the concept of association between two STAs to association between two MLDs. This works perfectly for higher
layer because higher layer does not care exactly what is the entity. For them, it just one entity, and everything works exactly like before.
When we refer to the difference in the spec we use STA association vs MLD association. This is understood by a lot of people (ARC people specifically) to be the interaction with the DS.
Multi-link setup is something new for MLD and only relevant to our MAC layer of determining which links can be used. That term is used with the intention to make people understand that we are not designing something
that higher layer needs to be aware of.
Best,
Po-Kai
My understanding is that what we are discussing is a naming issue. I think ML association is easier for people to understand.
Regards,
Yunbo
Hi Po-Kai, no problem with that — it’s just called MLD association. The process/signaling can still be called ML association.
Hi all,
Perhaps I can elaborate more on this. What I mean is that the main meaning of (re)association in the current spec is to present one entry point to the DS.
What we have done in 11be is that under this abstraction of one entry point, we allow multiple links to be setup, which DS does not need to be aware, and there is indeed a setup procedure defined (links to be setup are indicated
in (re)association request and links that are accepted are indicated (re)association response.)
Agree that setup is a general term that we have been used to be the establishment of protocol. The prefix like TWT differentiate the difference, so I do not think there is a confusion for this.
Best,
Po-Kai
I agree with Payam. ML re/association is more accurate. Setup means lots of things, ML TWT setup, ML WNM setup…
Hi Po-Kai, I generally agree with these comments; ML re/association seems to be a good and accurate term. The “MLD association” you are pointing to below seems to have enough distinction (I assume you are referring to such sentences: “For
a non-AP MLD, the act of becoming associated with an AP MLD invokes the association service (MLD association), which provides the non-AP MLD to AP MLD mapping to the DS (see 35.3.5.1 (Multi-link (re)setup procedure)).”).
Would be good to get a sense of what this group thinks when you discuss.
Regards,
Payam
|
3316
|
Yunbo Li
|
130.46
|
35.3.5
|
Seems multi-link setup is the same concept as multi-link association. Do we need to keep both of them. Maybe only need to keep multi-link association in the spec.
|
as in comment.
|
Rejected –
We note that MLD association is focusing on the concept that one (non-AP MLD, AP MLD) mapping is presented to the DS.
For the additional concept of multiple links that are setup, clause 35.3.5 then describe the correspoinding procedure, where (re)association request/response are reused and links that are requested/accepted
for (re)setup is then further indicated in the frame.
|
|
2313
|
Ming Gan
|
130.46
|
35.3.5
|
Multi-link setup is not correct name, change it multi-link association in this subclause
|
As in comment
|
Rejected –
We note that MLD association is focusing on the concept that one (non-AP MLD, AP MLD) mapping is presented to the DS.
For the additional concept of multiple links that are setup, clause 35.3.5 then describe the correspoinding procedure, where (re)association request/response are reused and links that are requested/accepted
for (re)setup is then further indicated in the frame.
|
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
|