Cheers --
ganesh
“It is amazing what you can accomplish if you don’t care who gets the credit.” – Harry Truman
From: Dick Roy <dickroy@xxxxxxxxxxxx>
Sent: Thursday, July 15, 2021 12:46 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
From: Ganming(Ming Gan) [mailto:ming.gan@xxxxxxxxxx]
Sent: Thursday, July 15, 2021 5:10 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Hello Mark
The below response from you is aligned with my question.
now my concern is that we are mixing the transmitting end and receiving end (I think). We have one side of the link that is trying to transmit a block of MPDUs, split (somehow, probably unknown to the receiver) across the links. The other
side is trying to manage the block ack scoreboard, as those MPDUs are received. If the transmitter detects a failure, and needs to retry the transmission on a different link, the receiver won’t be able to track that with any kind of dynamic reassignment (of
‘expected reception block’, apparently) so that a different link on that end is now expecting the MPDU on its link.
[RR] How does a “link” come to “expect an MPDU” and what does that even mean?? Perhaps what is meant is a receiver at one end of a link? Even then, the question
still stands. And how does a receiver know that a transmission attempt meant for it has failed? Are we now mandating all receivers be prescient? :^))))
[[gv]] The receiver can be ‘expecting’ in some cases – e.g. received a MPDU with an SN value higher than the expected value (leaving a hole in the received SN values) in which case it is in a state ‘expecting’ those MPDUs with the
SN value lower than the one received but higher than those received earlier. In more simpler cases, if the receiver had sent a 802.11 management frame and is awaiting a response, it can be in an ‘expecting’ state as well.
Moreover, this is not only related to retransmission, but also related to initial transmission
Best wishes
Ming Gan
发件人:
Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
发送时间:
2021年7月15日
4:30
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题:
Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Mike,
Ah, okay. So, this is even more dynamic than I thought. So, now my concern is that we are mixing the transmitting end and receiving end (I think). We have one side of the link that is trying to transmit a block of MPDUs, split (somehow,
probably unknown to the receiver) across the links. The other side is trying to manage the block ack scoreboard, as those MPDUs are received. If the transmitter detects a failure, and needs to retry the transmission on a different link, the receiver won’t
be able to track that with any kind of dynamic reassignment (of ‘expected reception block’, apparently) so that a different link on that end is now expecting the MPDU on its link.
Mark
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, July 14, 2021 1:58 PM
To: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Hi Mark,
I don't really see entire blocks being re-assigned. I see it more like the MLD assigns a block to an affiliated STA; the STA attempts to transmit the frames and then gives back control to the MLD. If frames were not transmitted, the MLD
then groups and assigns them to another affiliated STA (or even back to the same STA).
It's kind of like control is passed back and forth between the MLD and the affiliated STA.
Cheers,
MIke
On Wed, Jul 14, 2021 at 3:52 PM <mark.hamilton2152@xxxxxxxxx> wrote:
Mike,
- If a set of MSDUs need to be retried, the affiliated STA would have to pass the block back to the MLD and the MLD would have to assign the block to another link.
(Minor nit, but it is the MPDUs that need to be retried, and that might span and/or consist of only partial MSDUs.)
This approach of reassigning the whole block seem untenable to me. The real-time dynamics of retries versus the (initial) transmissions of other frames that were already targeted to use the same block are just too complex to be able to suddenly move the entire block to a different affiliated AP. IMHO.
Mark
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, July 14, 2021 9:31 AM
To: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Hi Mark,
The MSDUs associated with sequence number 'blocks" would need to be assigned to a single link. The MLD would have to re-order the MSDUs on receipt. If a set of MSDUs need to be retried, the affiliated STA would have to pass the block back to the MLD and the MLD would have to assign the block to another link.
Cheers,
Mike
On Wed, Jul 14, 2021 at 11:02 AM <mark.hamilton2152@xxxxxxxxx> wrote:
Do we agree/know that the MSDUs handled by a given link are consecutive (a range)? I was thinking it would be a ‘sparse’ array of IDs within the master window, with the different links having non-overlapping (but not consecutive) subsets. It seems difficult/impossible to do retries on a different link than the original transmission, if the IDs have to be consecutive, right? I admit that I haven’t thought this through, though.
Mark
From: M Montemurro <montemurro.michael@xxxxxxxxx>
Sent: Wednesday, July 14, 2021 8:51 AM
To: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Hi Mark,
Perhaps another way to explain this is that when a BA agreement is established, the MLD hands off a window (a range of sequence Ids corresponding to MSDUs). The affiliated STA is responsible to manage the delivery of those MSDUs. When completed, the affiliated STA hands back the state of those sequence Ids back to the MLD (at least the way I think of it conceptually).
Cheers,
Mike
On Wed, Jul 14, 2021 at 10:21 AM Mark Hamilton <mark.hamilton2152@xxxxxxxxx> wrote:
Ming,
My disagreement (or at least clarification), is that, in my understanding:
- The MLD layer (upper MAC sublayer) maintains the entire “master” block ack status, including the ack state for all the links. That is, when any frame is received and/or BA’d at an individual link, the MLD level block ack status must be updated to know this. (There might be some delay, etc., here, as the implementation may not need that information at the MLD level immediately – but in the standard we generally don’t get into such discussions.)
- Each link can be implemented to either also have a copy of this completely/master state, or it could have only a subset of that state which includes at least all the frame received/ack’d over that link, and optionally some/all of the state from other links. The latter part is not important, generally. If the links only have a subset of the master state, and a frame is retried over a different link, the receiving links need to (quickly?) coordinate to make sure the BA state is consistent. I think in practice this ‘just works’, but I’d have to think about it.
So, where I got hung up was that I read your email to imply that the MLD is _only_ handling the delivery of BA state between/among the links. But, I think it is important that the MLD also has the master BA state. That latter part seemed to be missing in your description.
Mark
From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Sent: Wednesday, July 14, 2021 7:57 AM
To: mark.hamilton2152@xxxxxxxxx; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Hello Mark
I am not sure I get your point. Which part do you disagree?
From this, it can be seen that the MLD Upper MAC sublayer manages the scoreboarding for all MPDUs in this BA session, on all the links. The scoreboarding in the MLD Lower MAC sublayer is only the scoreboard for MPDUs that happen to be received over that link
[Ming] agree
This is just a local link optimization. HT-immediate block ack can be implemented by responding based on the Lower MAC sublayer’s (partial) scoreboard, or optionally with additional information about other links if the implementation desires to do so.
[Ming] I am not sure what do you mean by “This is just a local link optimization”. My question which scoreboard does an affiliated STA use when it responds with BA. I assume it is local scoreboard, is this correct? My follow up question is how does each affiliated STA maintain its own scoreboard by following HT-immediate block ack architecture.
Best wishes
Ming Gan
发件人: Mark Hamilton [mailto:mark.hamilton2152@xxxxxxxxx]
发送时间: 2021年7月14日 20:57
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Ming,
I disagree with how you describe scoreboarding based on 21/577r5. I reference this text:
When MLO is being used, the “Block Ack Scoreboarding” block in the MLD Upper MAC sublayer manages the BA status of the MPDUs (of this BA session) that are received on any setup link. The “Block Ack Scoreboarding” block in the MLD Lower MAC sublayer manages the BA status of the MPDUs (of this BA session) that are received on this link. It may convey BA status of the MPDUs received on another link if it obtained such info from the other link via the MLD Upper MAC sublayer.
From this, it can be seen that the MLD Upper MAC sublayer manages the scoreboarding for all MPDUs in this BA session, on all the links. The scoreboarding in the MLD Lower MAC sublayer is only the scoreboard for MPDUs that happen to be received over that link, and optionally for some/all other MPDUs on other links. This is just a local link optimization. HT-immediate block ack can be implemented by responding based on the Lower MAC sublayer’s (partial) scoreboard, or optionally with additional information about other links if the implementation desires to do so.
Mark
From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Sent: Wednesday, July 14, 2021 2:21 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Hello Mark
Sorry for missing your email. Based on 21/577r5, each link maintains its own scoreboard and the MLD Upper MAC sublayer optionally delivers the BA record on one link to the MLD Lower MAC sublayer of other links. Now it seems the size of the scoreboard of each link is quite important since each STA will use this to provide reception status. However, it is still confusing how to implement the HT-immediate block ack architecture, including WinSizeO, WinSizeR. What do you think about it?
Best wishes
Ming Gan
发件人: Duncan Ho [mailto:dho@xxxxxxxxxxxxxxxx]
发送时间: 2021年7月14日 6:54
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Hi Mark,
Yes, adding it to your 21/1111 sounds good to me. I think that would be a good clarification.
Thanks,
Duncan
From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: Monday, July 12, 2021 4:57 PM
To: Duncan Ho <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
CAUTION: This email originated from outside of the organization.
By the way, we could add this to document 11-21/1111, if you are worried about touching 11-21/0577 since it has already passed straw poll.
Mark
From: mark.hamilton2152@xxxxxxxxx <mark.hamilton2152@xxxxxxxxx>
Sent: Monday, July 12, 2021 5:49 PM
To: 'Duncan Ho' <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Ming/Duncan,
Should we add a statement that the Block Ack agreement is between the peer MLDs, the scoreboarding function that is in the Lower MAC sublayer is just a “link local” optimization that may provide partial information about block ack status? That is, it is not where the overall block ack agreement is negotiated or maintained.
Mark
From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Sent: Monday, June 28, 2021 12:07 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Hi Ming,
The diagram and associated text made no such requirement/assumption since they are meant for describing the functions and not how the detailed parameters are set or negotiated, etc.
Thanks,
Duncan
From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Sent: Monday, June 28, 2021 7:33 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
CAUTION: This email originated from outside of the organization.
Hello Duncan
I have a general question about the figure. Does it imply the size of each scoreboard for each link needs negotiation during ADDBA request/response?
Best wishes
Ming Gan
发件人: 顾祥新 (Xiangxin Gu) [mailto:Xiangxin.Gu@xxxxxxxxxx]
发送时间: 2021年5月10日 17:04
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Hi Duncan,
Thank you for the contribution!
I think we can have a more general example in Figure 35-xxx – Example MLD and the affiliated STA communication system, such as 2 STAs in non-AP MLD setting up link1 and link3 with AP MLD which has 3 STAs.
BR,
Xiangxin
Unisoc Technologies Co., Ltd.
+86 21 20360600 3324
From: Arik Klein <arik.klein@xxxxxxxxxx>
Sent: Thursday, May 6, 2021 5:15 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Now with the doc…
Sorry.
Regards,
Arik
From: Arik Klein
Sent: יום ה 06 מאי 2021 12:12
To: 'Duncan Ho' <dho@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Hi Duncan,
Thanks for sharing this document.
I’ve attach my comments with my colleague (Stephen McCann) comments.
I’ll appreciate your review for these comments.
Regards,
Arik
From: Duncan Ho <dho@xxxxxxxxxxxxxxxx>
Sent: יום ד 28 אפריל 2021 21:00
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] Feedback Requested for CRs related to MLD architecture - 11-21-0577
Hi all,
Please see https://mentor.ieee.org/802.11/dcn/21/11-21-0577-00-00be-cr-mld-architecture.docx and let me know if you have any comments or questions.
Thanks,
Duncan
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
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