| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello everyone, Just want to let everyone know that I uploaded revision 3 of contribution 993 with updated SP text which, better reflect our proposal. New text is:
Dmitry From: Akhmetov, Dmitry This is the thread to collect feedbacks on proposal 993 and to answer/address any possible question or comments. Here some questions I captured from the chat window : From Sai Cypress : There will be some bias on performance if the STA, that wins the right to transmission on link 1, needs to wait for the other link to get its BO to zero Yes, as Dibakar already mentioned, some may think that STA is going to be “penalized” for waiting. To some extend this can be true – if you wait on link 1 for link 2 and link 1 become busy you will lose your possible TXOP. This is why I
say link 1 can take it’s own decision to wait or not to wait depending on what is observe on its own link. There might be multiple interferers around - you will unlikely be synchronized ( environment really need to be clear for that). STA may have small packet
to send - there is no need for synchronization. STA may have some high priority packet – there is no need to synchronize, etc.
Another aspect is – if at least one link is “congested”, entire non-STR MLD performance converge to numbers close to Async (read: single-link) performance. From Sai Cypress: So if i look at link 1 alone, u will see little lower than conventional EDCA performance if it was 11be with just 1 link. Yes if you compare link 1 alone to single link alone than individual performance might be sliiiightly affected. Think about this artificial example: link 1 artificially always wait for 7 extra slots every contention and compare to case
when link just do regular contention. So it is 7*9=63us per TXOP. Or (ideally) 0.0126s of extra wait time per second or ~3 full 5ms “lost“ TXOPs per second. So this is from 1 link (or single link device) perspective, but we have MLD with 2 links and by waiting
for this extra time you get (ideally) 2x performance by utilizing 2 links, so sacrificing milliseconds you gain seconds of airtime on second link from [V] Subir Perspecta Labs to everyone: Can one link starve for waiting for another one?
If STA for some reasons decide to always (regardless of network state) for the other link it may end up not transmitting often. In some sense, situation with primary-secondary link concept might be an illustration of that. If you compete on primary/anchor link (which is assumed to include all devices and thus to be very congested) , the utilization of secondary
link going to be very low. So if you wait for congested link for a long time, utilization of you less congested link will be very low. But, why would link indefinitely wait for he other link?. Sync access is not the ultimate way to deliver traffic, it is just
a possible way to increase performance. And if not possible it would be much better to utilize existing opportunity and to transmit using single link. In low-load case starvation will not happen just because links will have opportunity to sync, in high-load
case sync will not happen and links will operate on their own as MLD can always decide to TX only on one link without waiting. from [V] Chunyu Hu FB to everyone: I also concur what Muhamed described and have a follow up question: How many times this hold is done so we don't lose chance at the 'clean' link / 6GHz? Yes, as Dibakar mentioned STA make a decision to wait or not. Normally if STA on link 1 wait for link 2 and link 2 became busy the condition for waiting disappear – link 2 is busy, not idle. There is no point of waiting for it at this moment
of time. It is highly unlikely that link 1 (if it can do so) wait for link 2 when it became busy and then in a short time it became idle so link 1 would to wait for it once again from [V] Chunyu Hu FB to everyone: But this wait slot can be also a implementation choice, so we end up as "should" and no "shall"? Not sure which shall you are talking about, but if this relates to the, say option 3, when link 1 (or 2) became busy than “shall” need to be used to clearly identify “recovery” behavior. If you talk about SP text “shall” is used to say
that if STA originates its own aggregated transmission it shall ensure that EDCA count down procedure is completed on all the links. Dmitry. P.S. Additional questions or comments are welcomed 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 |