Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBE] CID 22343 in 24/296



Thanks Brian, I agree with your comments.

In addition, to add to that, note that per 11.22.9, the QoS Map table is made available to higher layers so that they can set the correct priority in an MA-UNITDATA.request primitive.
The MA-UNITDATA.request primitive is at the MAC SAP (see 5.2.4), and there is only one MAC SAP in an MLD.
Therefore, the concept of applying different DSCP-to-UP mapping per link of an MLD does not exist in the standard.

(If someone wishes to propose that - presumably defined at some lower layer of the affiliated STA/AP - then that would be a completely new feature in some future amendment).

Note also that the EDCA/WMM parameters of each link can be different, so even though a packet is assigned the same TID/AC irrespective of which link it is sent on, the channel access parameters used to win a TXOP to send the packet might be link-specific (e.g. based on different load/contention on each channel, etc).

Finally, I would note that QoS Map is implemented and deployed in implementations today, including Wi-Fi 7 devices, and this comment is really just to align the standard with that since it seems the frame/feature was forgotten about in earlier drafts of 11be.

Thanks
Thomas


On Apr 17, 2024 at 8:27:14â?¯AM, Brian Hart (brianh) <00000c7561051aea-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

Hi all

 

Documenting my reasoning for my support for Po-Kaiâ??s comment resolution for CID 22343 in 24/296, and why I think it is the only permitted, viable way forward:

 

22343

Alfred Asterjadhi

35.3.14.1

559.55

[Thomas Derham] QoS Map Configure frame is a QoS Action frame used to send updated QoS Map to a STA containing DSCP-to-UP mapping table. The DSCP-to-UP mapping is implemented above the MAC SAP, therefore the frame should be handled at the MLD layer.

Add QoS Map Configure frame to the list of frames that are "intended for an MLD"

Revised â??

 

Agree in principle with the commenter. We also update the relevant texts for QoS Map configure.

 

TGbe editor to make the changes shown in 11-24/0296r9 under all headings that include CID 22343

 

 

1) One or both of the following are true:

1a) A desire was expressed to send a frame using different ACs on different links.

1b) A desire was expressed to send frames of a flow using different ACs on different links.

 

2)

2a) If the ACs used for the frame are different then the TIDs used for the frame are different.

2b) If the ACs used for the frames are different then the TIDs used for the frames are different.

are different.

 

3)

3a) Basic MLD behavior enables a frame to be retried on a different link (or even sent in parallel or near-parallel on two links).

// And we are not going to change this behavior (aka undermine the MLD architecture) at this late stage.

// And indeed 1a) is only valuable if this behavior occurs.

 

4)

4a) Taking 2a) & 3a) together, the same frame could be sent on two links in different TIDs:

  • When sent in parallel or near-parallel
  • If transmitted on one link, and its delivery succeeds but its acknowledgement fails, then retried on a different link

4b) For 1b) to be valuable, frames in a flow will be sent on different links. Given 2b), the frames sent on different links will use different TIDs

 

5)

5a) When a frame is sent on a different TID, it takes its sequence number from a different sequence number space. Accordingly, it is impossible for the recipient to detect that the recipient has received a duplicate frame. Both copies of the frame will be sent to upper layers.

5b) When a flow of frames are sent across different TIDs, they take their sequence numbers from different sequence number spaces. Accordingly, it is impossible for the recipient to know which frames belong to the same flow, and then how to order the flow of frames. The frames will commonly be sent to upper layers out of order.

 

6)

The IEEE 802.11be project was approved based on its PAR and CSD. In the CSD we made the following commitment to IEEE:

 

1.2.2    Compatibility

 

Each proposed IEEE 802 LMSC standard should be in conformance with IEEE Std 802, IEEE 802.1AC, and IEEE 802.1Q. If any variances in conformance emerge, they shall be thoroughly disclosed and reviewed with IEEE 802.1 WG prior to submitting a PAR to the Sponsor.

 

a)      Will the proposed standard comply with IEEE Std 802, IEEE Std 802.1AC and IEEE Std 802.1Q? YES

If the answer to a) is no, supply the response from the IEEE 802.1 WG.

 

7)

7a) Meanwhile, 802.1Q requires negligible duplication of frames:

6.5.4 Frame duplication

The MAC Service (IEEE Std 802.1AC) permits a negligible rate of duplication of frames.

7b) As well, 802.1Q requires negligible out-of-order delivery:

6.5.3 Frame misordering

The MAC Service (IEEE Std 802.1AC) permits a negligible rate of reordering of frames with a given

priority for a given combination of destination address, source address, and flow hash, if present, transmitted on a given VLAN.

 

Summary:

Using a reductio ad absurdum approach in steps 2)-7), we see that both 1a) and 1b) are â??absurbâ?? positions. Assuming weâ??re not going to undermine the MLD architecture at this late stage, I donâ??t believe that the 802.11be project has any choice but to accept Po-Kaiâ??s comment resolution (or something essentially the same).

 

Best wishes

Brian

 


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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature