| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear all, I realize that my use of the term “Scoreboard Size” may not have been very clear in 20/55r2. In baseline, the buffer size negotiated during ADDBA Request/Response exchange determines two sizes at the Recipient STA: 1) WinSizeB: Size of the reception window (Receive reordering buffer) 2) WinSizeR: maximum transmission window size (Scoreboard Context) “Scoreboard Size” in 20/55r2 refers to WinSizeR. Let me also clarify the statement on slide#5: “if all links are required to have the same Scoreboard size,
the scoreboard size of a slower link may constrain a faster link’s throughput.
” Regardless of Full-state or partial-state operation, different STAs (Links) of an MLD may have different memory resources availabe at the time of BA negotiation. If the WinSizeR of all the STAs of an MLD is required to be the same, an MLD
with a memory resource constraint on one of the STAs will set the “Buffer Size subfield” in the ADDBA Response frame to the smallest memory available across all the STAs of the multi-link operation. For example, STA1 (link1) may not have any issue supporting
a 1024 bits scoreboard but STA2 (link2) may only be able to support 256bits scoreboard and subsequently negotiate a buffer size of 256. This would mean that Link1 is also restricted to 256 MPDUs per BA. This was what we meant by “the scoreboard size of
a slower link may constrain a faster link’s throughput”. De-couping the scoreboard sizes of different links would resolve this issue. Best regards, Rojan Chitrakar 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 |