Date: Wednesday, October 7, 2026 at 02:41
To: Kerstin Johnsson (Nokia) <kerstin.johnsson@xxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: 答复: [STDS-802-11-TGBN] Request to defer SP on 26/1704
Hi Kerstin，
Thanks for your discussion. Please find my response inline.
Regards
发件人: Kerstin Johnsson (Nokia) [mailto:kerstin.johnsson@xxxxxxxxx]
发送时间: 2026年10月7日 3:23
收件人: huangguogang <huangguogang1@xxxxxxxxxx>; STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] Request to defer SP on 26/1704
Hi Guogang,
Thanks. I agree that “received from the DS” is not the right way to distinguish the two sets of MSDUs, since the forwarded MSDUs also originally came from the DS.
I think your old #5025 addresses the part I’m concerned about. Could we keep a forwarding-complete indication, while still leaving the actual forwarding policy implementation-dependent? For example:
When Request DL SN Not Transferred is equal to 1, the current AP MLD shall indicate to the target AP MLD when data forwarding for each TID is complete. Until receiving this indication for a TID, the target AP MLD shall not assign sequence numbers to MSDUs for that TID other than MSDUs forwarded from the current AP MLD.
[HGG] I have a clarification question. Do we need to limit it only for Request DL SN Not Transferred equal to 1? In my opinion, it is also needed for Request DL SN Not Transferred equal to 0.
I also think the second sentence of your old #5025 is useful. If the target AP MLD wants to stop waiting and start transmitting other MSDUs, it could request the current AP MLD to stop forwarding for that TID. But I think it should then wait for the forwarding-complete indication before assigning SNs to the other MSDUs, since some forwarded MSDUs may already be in flight.
[HGG]Maybe the target AP MLD doesn’t need to wait for the forwarding-complete indication even some forwarded MSDUs are in flight. In this case, what we need to define is, the target AP MLD shall discard any forwarded MSDUs if the target AP MLD has assigned SNs to the other MSDUs.
On leaving this to implementation, I think there is an important distinction:
- Forwarding policy can be implementation-dependent: which MSDUs to forward, when to start forwarding, and how much to forward.
- The synchronization needed to preserve ordering should be defined by the standard: the target AP MLD needs to know when no older forwarded MSDUs can still arrive before it starts assigning SNs to other MSDUs.
Otherwise, the target AP MLD has no way to know whether an older MSDU is still coming from the current AP MLD. If it assigns SNs to newer MSDUs too early, we can get the packet 1/2/3 ordering problem we discussed. “Prioritize transmission” does not fix that if the SNs have already been assigned.
Similarly, a request to stop forwarding is not enough by itself, because forwarded MSDUs may already be in flight. The target AP MLD needs confirmation that forwarding for that TID has actually completed.
So I think your old #5025, or something similar, is still needed. It preserves implementation flexibility for the forwarding algorithm while defining the minimum coordination needed to guarantee in-order delivery.
[HGG] I agree with you. I will add the text to describe this part in the next version. We can keep discussion. Thanks!
Best regards,
Kerstin
From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Date: Tuesday, October 6, 2026 at 06:43
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
<STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-11-TGBN] 答复: [STDS-802-11-TGBN] Request to defer SP on 26/1704
|
|
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. |
Hi Kerstin,
Thanks for your discussion. Please find my response inline.
Regards
Guogang Huang
发件人: Kerstin Johnsson (Nokia) [mailto:kerstin.johnsson@xxxxxxxxx]
发送时间: 2026年10月1日 9:20
收件人: huangguogang <huangguogang1@xxxxxxxxxx>;
STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBN] Request to defer SP on 26/1704
Hi Guogang,
Regarding CIDs 19895/19902:
For Request DL SN Not Transferred = 1, I’m not clear how the original MSDU order is preserved when an older MSDU is forwarded later from the current AP MLD.
For example, suppose packet 1 is still buffered at the current AP MLD, while the target AP MLD receives newer packets 2 and 3, assigns:
packet 2 → target AP MLD SN 0
packet 3 → target AP MLD SN 1
and transmits them. Later, packet 1 is forwarded to the target AP MLD and assigned:
packet 1 → target AP MLD SN 2
The non-AP MLD therefore sees:
SN 0 = packet 2
SN 1 = packet 3
SN 2 = packet 1
At that point, it has no way to determine from the SNs that packet 1 originally came first.
So I think “prioritize the transmission of MSDUs forwarded from the current AP MLD” needs to be made more explicit. Would something like the following work?
When Request DL SN Not Transferred is equal to 1, for each TID, the target AP MLD shall not assign sequence numbers to new MSDUs received from the Distribution System until all MSDUs forwarded from the current AP MLD for that TID have been assigned sequence numbers.
[HGG]I’m not sure this description is more clearer than the original one. And I received comments from other members, the forwarded MSDUs are also received from the DS. Hence, it’s not accurate to use from the DS or not to distinguish these two categories of MSDUs. We can have more discussion.
But would we also need some way for the target AP MLD to know that the current AP MLD has finished forwarding the older MSDUs for that TID? Do we need a forwarding-complete indication, or is that already provided somewhere else?
[HGG] I agree with you. In my original version (11-25/1993r9, as shown in below), the current AP MLD can inform the target AP MLD the data forwarding is finished. And the target AP MLD also can inform the current AP MLD to stop the data forwarding if the target AP MLD wants to transmit non-forwarded MSDUs. Based on the offline discussion, some members want to leave the data forwarding to the implementation and don’t want to add ‘shall’ requirements. That’s why I remove the above text from this version. But we can have more discussion if you have any suggested text.
BR,
Kerstin