| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Giovanni, Thanks for your feedback. Please find my response inline. I hope you can hold on your SP on this CR document. We can have more offline discussion.
Regards Guogang Huang 发件人: Giovanni Chisci <gchisci@xxxxxxxxxxxxxxxx>
Hi Guogang, Thanks for the engagement with this and the technical discussion. As I mentioned to you in hallway discussions, your proposed addition (text) doesn't glue together with the approach in the document. One issue is the underlaid assumption you made that for execution via current, client provides DL BA Info in ST execution request, which is not the case.
In fact the client provides DL BA Info in the UHR Link Reconfig Notify frame that terminates the DL drain time. This has been the working assumption to avoid any dependency of roaming execution from context transfer. Otherwise roaming performance will have
additional latency. [HGG] Your concern can be easily resolved. If the non-AP MLD decides to enable the simultaneous DL reception, it can first send DL BA Info in the UHR Reconfiguration
Notify frame to the target AP MLD and set the DL Draining Completed field equal to 0.
Another issue I see is the total receive buffer allocation from the client is not accounted, and you are assuming the buffer allocations for each AP
are independent, which are not. [HGG]I don’t understand what you say. The final DL buffer size is decided by the non-AP MLD, which can totally take into account its current condition. The separate
BA agreement is easier. Because the current AP MLD doesn’t need to struggle how much the next SN value should be. From the technical point of view, I don’t need to agree the common BA scheme. But to move forward, this is the bottom line I can accept, i.e.
the spec. supports both the separate BA scheme and the common BA scheme. Then leave it to the implementation.
On another note, I am not sure if these modifications are really needed for roaming BA handling, but on the other hand I do recognize that the proposal
has still some flaws and we need to make progress. I suggest to separate the discussion so that we can make some progress on roaming BA, and happy to discuss your future contribution on your proposed
enhancement whenever you finalize and solve the outstanding issues. Best, Giovanni From: huangguogang <huangguogang1@xxxxxxxxxx> WARNING:
This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. Hi Giovanni, I update the suggested text a little bit. Please find the details attached. Regards Guogang Huang 发件人: huangguogang
Hi Giovanni, Thanks for your effort! Generally, I think the current solution makes the roaming BA too complex. Just take a look at the existing FT protocol, the renegotiation of the BA agreement
in the FT protocol is much simpler. It’s a severe degradation to divided the DL BA into three cases.
To simplify the roaming BA operation and enable the simultaneous DL reception, the spec. should allow the non-AP MLD to maintain separate BA agreement respectively with the current
AP MLD and the target AP MLD. And we should limit the common BA is applied only when the DL buffer size is not changed. If the target AP MLD wants to change DL buffer size (regardless larger or smaller), the non-AP MLD shall set the Request DL SN Not Transfer
field to 1 and the separate BA agreements are used, rather than the common BA agreement. Please find the details attached. We can have more offline discussion. Regards Guogang Huang 发件人: Giovanni Chisci <00002b657bbbbed7-dmarc-request@xxxxxxxxxxxxxxxxx>
[Roaming TTT - Roaming Block Ack Handling] Dear all, I presented 26/0060r0 during PM2 solving 21 CIDs for roaming Block ack handling: 4313, 4327, 5005, 5040, 5041, 6375, 6878, 6966, 6976, 7472, 7478, 7499, 9007, 9008, 9009, 10410, 11344, 12010, 12393, 12395, 12467 Please let me know if you have feedback on the text itself and on the resolution table, and I will be happy to work with you towards completing this work this week. Best, Giovanni To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1 |