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

Re: [STDS-802-11-TGBE] 11-21/1111 further discussion



Arik,

 

At the risk of opening up the PS queuing discussion here, I’ll respond to your text in red, that the reason we have group addressed MPDUs destined to non-AP MLDs in the MLD upper MAC sublayer of the affiliated APs, is exactly because we think/thought (are debating) whether these frames must be PS queued, assigned numbers, and encrypted, in the affiliated AP’s upper MAC.  If that is required (due to reasons such as are being discussed in the other thread), then we end up with the affiliated AP’s upper MAC handling some of the processing of these group addressed frames, and that is why the label in Figure 4-30c is that way.  So, we need to settle that discussion, and then we can go back and update the high-level descriptions in 4-30c to match.

 

Mark

 

From: Arik Klein <arik.klein@xxxxxxxxxx>
Sent: Thursday, May 12, 2022 11:58 AM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 11-21/1111 further discussion

 

Hi Mark,

 

Thanks for the response.

Please see my further inline response.

 

Regards,

Arik

 

From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: יום ה 12 מאי 2022 18:18
To: Arik Klein <arik.klein@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 11-21/1111 further discussion

 

Arik,

 

Please see separate email threads for the Block Ack description, and for the placement/ordering of the PS queuing.

 

I have responses on the rest of your comments, below.

 

Mark

 

From: Arik Klein <0000177967a59511-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Thursday, May 12, 2022 4:41 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion

 

Hi Mark,

 

Thanks for sharing the doc and for this further discussion.

 

Several comments for further discussion:

  • I agree with Duncan argument that “ML BACK Scoreboarding” term in the upper MAC layer is misleading. I would suggest to designate it as “Optional: Block ACK Scoreboarding (merging)”. Are you OK with that?
  • The “Merging” functional block in the “MSDU flow Receiving side” is vague/unclear. I would suggest to use “Link Merging” term that better explains what is merged here (as opposed to the TID-To-Link mapping functionality on the “MSDU flow Transmitting side”)

[[MAH]] I’ll note that this is not changed from the D1.5 text – just redrawn to separate the TX and RX directions.  However, I am fine with this change, if nobody has any objection.

  • I echo Stephen’s comment regarding the “PS Defer Queuing” functionality  - I think that this should be placed only in the lower MAC layer (i.e. per each link).
    Furthermore – I do not see any problem with assigning an SN to the individually addressed MPDU (in the upper MAC layer) and then queuing it in a specific buffer (per the link it is going to be sent) only if both conditions occur: (1)the non-AP STA affiliated with the associated non-AP MLD and operating on that link is in PS (2) and due to TID-To-Link mapping the MPDU can’t be transmitted on any other link. Otherwise – there is no PS queuing for that MPDU….
  • According to Figure 4-30c, the upper MAC layer of the affiliated AP handles the group addressed MLD traffic. I think this is incorrect, since upper MAC layer of the AP MLD receives all the MLD data frames (from the DS) to include both those that will be sent as individually addressed MPDUs and those that will be sent as group addressed MPDUs. Then, once the upper MAC layer processes the group addressed frames it delivers them to the lower MAC layer of each link (to be authenticated with GTK/IGTK/BIGTK per that link) and then these MPDUs are further processed and passed to the PHY (per link) to be sent following transmission of DTIM Beacon frames.
    (Note: this also applicable to MMPDUs sent as group addressed frames)
    Consequently, the upper MAC layer of the affiliated AP processes only the individually addressed frames sent to the non-MLD non-AP STAs associated with that affiliated APs (and these frames are delivered from the DS to the affiliated AP directly).
    Please revise the Figure 4-30c.

[[MAH]] This is a side-effect of the discussion (in the other email thread) about the placement of PS queuing, SN/PN assignment and encryption.  The discussion had been that these functions needed to be in the upper MAC sublayer, and hence for group addressed frames the MLD upper MAC sublayer can only process the frames (which it receives from the DS, as you correctly noted) to a certain point, and then it needs to “pass” those frames to the affiliated AP’s upper MAC sublayers for the PS/PN/SN/encryption steps.  Let’s let that discussion resolve, and then decide this point. 

[Arik Klein] I do not see it as a side effect of the PS Queuing discussion on other thread. The point is that upper MAC of the affiliated AP only deals with the MSDUs that are transmitted to the non-MLD non-AP STAs (as either individually addressed MPDUs or as group addressed MPDUs). Therefore, IMHO, the group addressed MPDUs that are destined to the non-AP MLDs shall be handled only through the upper MAC Layer of the AP MLD.

 

  • Does the NSTR mobile AP MLD architecture follow the Figure 4-30c or that of Figure 4-30d?
    Could you add a note to clarify that point in the corresponding figure?

[[MAH]] I have no idea!  I’d need someone with expertise in mobile AP to provide a proposal.  I believe this goes beyond the scope of the CIDs I am trying to resolve.

 

Thanks for your cooperation.

 

Regards,

Arik

 

From: Stephen McCann <mccann.stephen@xxxxxxxxx>
Sent: יום ה 12 מאי 2022 12:36
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion

 

Mark,

        Thanks for this discussion.  Regarding the "PS Defer buffering", what does this have to do with SN/PN assignment? If an MPDU is deferred for PS reasons, this implies that the MPDU is assigned to a link in the upper MAC and is then buffered until the PS state of that link is ok to transmit the MPDU. This seems to break the MLO concept?

 

Kind regards

 

Stephen 

 

On Thu, 12 May 2022 at 03:44, Tomo Adachi <tomo.adachi@xxxxxxxxxxxxx> wrote:

 

Hi Mark,

 

I echo Duncan and Po-Kais comment on the scoreboarding terminology.

Full state is to keep all the statuses within the reception window from an initiator, while the record can be temporal in partial state.

 

Best regards,

tomo

 

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Thursday, May 12, 2022 7:51 AM
To:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion

 

Hi, Alfred,

 

If we can have just a few minutes (5-10) to discuss these topics on the morning call, I can get the document updated with any agreement, for consideration at a future call.

 

Thanks.  Mark

 

From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Wednesday, May 11, 2022 4:36 PM
To: Mark Hamilton <
mark.hamilton2152@xxxxxxxxx>
Cc: TGBE <
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion

 

[re-sending from gmail account]

 

Thanks Mark, and all for working on these resolutions.


I scheduled the doc for SP/discussion tomorrow evening (MAC call) however if the preference is to have the discussion on the morning call we can try to find some time on that call.

 

Let me know.

 

Regards,


Alfred

 

On Wed, May 11, 2022 at 3:31 PM Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:

All,

 

As there does not appear to be consensus on how to describe the Block Ack blocks (based on the comments on the call this morning, and now these comments on my proposed update), can I suggest that we have a quick discussion on this on the call tomorrow morning (U.S. time).

 

Also, I am having a hard time figuring out how to sequence the SN and PN assignment versus PS queueing, for group addressed frames.  In particular, we have existing text in D1.5 that says the AP MLDs upper MAC sublayer will do the SN assignment, and then pass the frame to the affiliated AP(s) to be buffered and then do further processing/transmission.  I think that causes issues with SN and PN ordering.  Has this been covered in some other power save presentations/agreements (that perhaps I missed)?  Does anyone have a clear view of how this is planned to work and/or is there agreement in the group?  (I dont think this is a significant change to my document, but there are details discussing this that need to be aligned to the correct operation).  Perhaps this can be discussed quickly tomorrow morning, also?

 

@Alfred Asterjadhi, Ill look to your direction on how to proceed most efficiently for the groups time.

 

Thanks.  Mark

 

From: Huang, Po-kai <po-kai.huang@xxxxxxxxx>
Sent: Wednesday, May 11, 2022 2:28 PM
To:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion

 

Hi all,

 

                I agree with Duncan that we do not need to create term like ML BA Scoreboarding and we also do not need say lower MAC is always partial state.

 

              Partial and full is just about whether your record is temporary or not, which is an implementation choice.

 

                The following text also seems to be enough, so do we really need to add more?

 

·  The MLD Upper MAC sublayer functions: Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Lower MAC sublayer). Optionally, the MLD Upper MAC sublayer delivers the Block Ack record on one link to the MLD Lower MAC sublayer of other links

·  The MLD Lower MAC sublayer functions: Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Upper MAC sublayer). Optionally, the MLD Lower MAC sublayer receives from the Block Ack record on the other links from the MLD Upper MAC sublayer

 

Best,

Po-Kai

 

From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Sent: Wednesday, May 11, 2022 12:13 PM
To:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-21/1111 further discussion

 

Hi Mark,

 

Thanks for the updates. I do not think the BA scoreboarding changes are needed because D1.5 section 4.9.5 already describes the following:

 

·  The MLD Upper MAC sublayer functions: Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Lower MAC sublayer). Optionally, the MLD Upper MAC sublayer delivers the Block Ack record on one link to the MLD Lower MAC sublayer of other links

·  The MLD Lower MAC sublayer functions: Block Ack scoreboarding for individually addressed frames (in collaboration with the MLD Upper MAC sublayer). Optionally, the MLD Lower MAC sublayer receives from the Block Ack record on the other links from the MLD Upper MAC sublayer

 

The spec also has a NOTE saying NOTE 2The Block Ack scoreboarding maintenance collaborated between the MLD Upper MAC sublayer and MLD Lower MAC sublayer is implementation dependent. So its clear how the MLD upper and lower layer collaborate is implementation dependent.

 

Besides, the new term ML BA Scoreboarding could be misleading because a reader may try to find a section in the spec that describes how scoreboarding is done in the MLD while the Scoreboard Context procedures are well defined in REVme sections 10.25.6.3 (Full state) and 10.25.6.3 (Partial state) at the link level (not MLD level).

 

Also whether to do Full or Partial state is a choice of the receiver (per REVme) so we should not mandate Partial BA Scoreboarding in the lower MAC.

 

I believe the scoareboarding functionalities are mandatory for the lower MAC due to immediate BA but the BA scoreboarding-related functionalities in the Upper MAC should be optional.

 

Thanks,

Duncan

 

 

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Wednesday, May 11, 2022 10:46 AM
To:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 11-21/1111 further discussion

 

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

All,

 

Here is some status update, and request for ongoing discussion on the architecture presentation from this morning (document 11-21/1111):

·  I removed the word physical from physical links in the text

·  I corrected the typo the use of

·  In Figure 4-30c, I am renaming MLD lower MAC sublayer (MLD and legacy) to just MLD lower MAC sublayer.  This removes the legacy as correctly pointed on the call.  However, this leaves the MLD lower MAC sublayer as the term for the shared component which is doing both MLD support and affiliated AP support.  I note that this term is already in many locations in the draft, in clauses 4 and 5, so I proposed to keep it in the new figures to remain aligned.  If there is concern with this use of the term, that can be a comment (on all the occurrences), on the next LB.  Any disagreement?

·  I am taking the suggestions in the chat, and proposing to change the Block Ack Scoreboarding boxes in the figures, as follows:

o For the upper MAC, in the MLD, it will say ML BA Scoreboarding

o For the lower MAC, it will say Partial BA Scoreboarding

o For the upper MAC, in the affiliated AP, it seems this is an implementation choice (is that right?), so how about BA Scoreboarding (optional)?

o There was a request to add some clarification about these Scoreboarding blocks to the text.  I suggest that would go just below Figure 5-2b, and Ill work on that and remit shortlySuggestions/contributions would be helpful!

·  For PS Defer buffering:

o I think the conclusion/agreement on the call was that this is correct to be in the upper MAC (and above the SN assignment).  Any disagreement?

o Clearly, the label in the affiliated AP that says AP MLD only is just wrong.  However, my latest understanding of how frame generation and routing needs to happen resulted in frames (such as Management frames, and group addressed Data frames) will need to be routed from the MLD upper MAC over to the affiliated upper MAC for SN/PN assignment and encryption, so the buffering for these frames needs to be merged with the buffering for legacy data frames, and it all needs to happen high in the affiliated AP stack.  If this is agreed, then we need this block (in that location) in the affiliated AP upper MAC.  I think that means just removing the (AP MLD only) text in all copies of this block, in the affiliated AP and the AP MLD.  Agreed?

o There was a request to add some more text to better clarify this PS Defer buffering.  I think that goes just below Figure 5-2b, and Ill work on that and remit shortly.

·  Figure 5-2b should be clarified with labels for the AP MLD and affiliated APs.  The figure is already too complicated, so I do not want to add the outlines shapes, like Figure 4-30c.  I suggest maybe just braces across the top of the figure, saying Affiliated AP and AP MLD?  That is slightly misleading in that it is really only correct for the upper MAC sublayers, but would imply it carries into the lower MAC, also.  But, I think its the best alternative.  Comments or other thoughts?

 

Thanks.  Mark


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


 

--

Alfred Asterjadhi, PhD

IEEE802.11 TGbe Chair,

Qualcomm Technologies Inc.

Cell #:    +1 858 263 9445

Office #: +1 858 658 5302


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