Subject: [Raw] Second pass: Rocco's comments on draft-ietf-raw-technologies-02 [WAS: Comments on section 4 in draft-ietf-raw-technologies-02]

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 24 Aug 2021 12:52:01 +0000

Hello Rocco:

I made some changes already in https://github.com/raw-wg/raw-technologies/ that are not yet published. I wanted to solve the outstanding issues before publishing again.
Can you ensure during this discussion that this remains the reference you are using? In copied the issues though they can still be found in context down the mail.
I added a few comments before Dave gets in, please see PT> below

[Rocco 2021-08-24 outstanding comment 1]

The idea behind the Comment 1 is seeking clarity. It seems that "identification", "filtering", "mapping", and "classification" may be used here as synonyms; however, some people interpret them differently. Perhaps an investigation point may be whether or not 802.11 uses the term "traffic class" exactly as 802.1Q. If yes, then "traffic classification" can be the right phrase. If not, then an alternative might be considered, e.g., "traffic identification".

[Rocco 2021-08-24 outstanding comment 2]

Even if it may have been demonstrated in some of the references with 802.11ac and 802.11ax that existing 802.1Qbv and 802.1CB can already work over 802.11, I propose to remove the sentence because 802.1Qbv and 802.1CB have not been formally incorporated in any published standard or amendment related to 802.11. In my understanding, it is with custom/ proprietary implementations that related features may be realized. Therefore, as the intention of this RAW document is to describe capabilities as defined by standards, it is not relevant to highlight that "802.1Qbv and 802.1CB can operate over 802.11" in this document.
PT> I disagree on that one, I mean the objective of the doc is not to make a summary of the standards but to focus on what is in place, what's possible and what's coming to provide L2 services that RAW can leverage to provide high availability and reliability. The "can do" by a layer above are as interesting as the standardized features inside the layer. As long as there is no ambiguity for the reader what's in the .11 standard and what's experimental.

[Rocco 2021-08-24 outstanding comment 3]

It would be beneficial for the readers to be clear on what is available. For example, being clear on P802.11be being an ongoing project, i.e., P802.11be features are not available yet. Different features have different status when it comes to what is within P802.11be. For instance, if something is at contribution level, then the RAW WG could decide whether or not it could be part of a RAW document. The idea is just to be clear on these type of aspects as well.
PT> Yes: The more clarity on the level of progress of the techniques, the best for us. We need to be able to figure if we can count on the feature in some future, or if it is a science experiment.

[Rocco 2021-08-24 outstanding comment 4]

If the text does not intend to suggest that 802.11 supports all TSN features, then perhaps it may be good to be clear on that, e.g., use "implement some TSN capabilities" or "implement selected TSN capabilities" instead of the current "implement TSN capabilities".
PT> Good one too; should we take TSN stricto sensu as being what 802.1 and 802.3 defined (like place a TM after TSN above) ? Or should we use TSN as anything that serves time sensitive traffic? The way I read it, TSN is really the 802.1 TM thing now.
Either we do the exact same TSN features as Ethernet in which case we can say "some TSN capabilities" - which is my book has the same meaning as the current text but I'm not native); or we turn that into "capabilities to serve time-sensitive traffic".

[Rocco 2021-08-24 outstanding comment 5]

The point that the text is about "available capabilities and standards" raises another important aspect: P802.11be is not a published standard but an ongoing project. Along this point, all 802.11be text could be then removed from this draft.

 PT> Then again this  misaligned objective for the document: we're certainly interested in getting the latest as long as it's clear that the .11be piece is WIP.

[Rocco 2021-08-24 outstanding comment 6]

OK, then let us have it as 'Traffic Stream Classification'.

Seems resolved: I Updated the github for that

[Rocco 2021-08-24 outstanding comment 7]

I believe that the text in this section is about what can be typically achieved (for example, for bounded latency) while operating using 802.11 in the wireless domain and is not  focused only toward TSN-capable networks. Also, as I understand it, this part of the text is about 802.11 and to help a reader understand the comparison between contention-based (i.e., without OFDMA) mode versus multi-user transmissions enabled by OFDMA mode. Therefore, I believe it would be beneficial for a reader to understand that while OFDMA mode can provide higher efficiency and improved performance when compared to the contention-based mode, there may be some underlying assumptions specific to 802.11 that need to be fulfilled. I propose the following modified text based on your response:

When the network is very lightly loaded, it is possible to achieve latencies under 1 msec when Wi-Fi is operated in contention-based mode (i.e., without OFDMA) mode [https://onestore.nokia.com/asset/207850]. It has also been shown that it is possible to achieve 1 msec latencies in a controlled environment with higher efficiency when multi-user transmissions are used (enabled by OFDMA operation) [Cavalcanti_2019]. One main requirement to achieve such optimized operation is that the AP is always aware of when and which STAs have UL traffic (e.g., if all STAs have periodic and deterministic traffic). This requirement may be inherently addressed when the use case corresponds to setting up a TSN-capable network using 802.1Qcc models. Another fundamental assumption is that the amount of data to transmit in UL is similar in all STAs so that inefficiencies due to padding do not induce additional delays (the length of the OFDMA packet  is determined based on the longest data transmission among all users served with a single OFDMA packet).. Another strict requirement is the absence of handovers between APs, e.g., which may be needed because of machine/robots moving in a factory.

It is better to be clear on what can be really provided under what circumstances

PT> for this I'll defer to Dave!

Pascal

From: RAW <[email-masked]> On Behalf Of Rocco Di Taranto
Sent: mardi 24 août 2021 12:29
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Subject: Re: [Raw] Comments on section 4 in draft-ietf-raw-technologies-02

Dear Pascal, All,

Perhaps many people are back from vacation and we might try to conclude the 7 outstanding items in my previous mail.

At least I have not seen any response to them

(I have seen Pascal's reply on the email on August 4th on 11ak, title: [Raw] about .11ak was: RE: Comments on section 4 in draft-ietf-raw-technologies-02, and I am OK with the new proposed formulation).

To help identify the 7 outstanding comments in the body of the email below I have marked them as [Rocco 2021-08-24 outstanding comment X].

Thank you.

Best Regards,

Rocco

From: RAW <[email-masked]<mailto:[email-masked]>> On Behalf Of Rocco Di Taranto
Sent: den 4 augusti 2021 03:42
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Raw] FW: Comments on section 4 in draft-ietf-raw-technologies-02

Dear Dave, Pascal, and All,

Thanks for your comments and proposed text.

I have added responses and alternative suggestions below to address a few comments for improving the text. Please let me know if something is not clear.

Best Regards,

Rocco

From: Cavalcanti, Dave <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, July 31, 2021 2:03:56 AM
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Rocco Di Taranto <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: Comments on section 4 in draft-ietf-raw-technologies-02

Hi Pascal and Rocco,

Thanks for the additional suggestions to improve the text. Please my responses below.

Thanks

Dave

From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 30, 2021 5:58 AM
To: Rocco Di Taranto <[email-masked]<mailto:[email-masked]>>; Cavalcanti, Dave <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on section 4 in draft-ietf-raw-technologies-02

Hello Rocco

Quick notes:

- Please use "IEEE Std 802.blah", it's actually the IEEE that asks us to spell it that way. Also, For each version of the standard that you mention, I'd need at least a URL to build the correct reference. See my mail to Dave in this thread. E.g., where are officially located IEEE Std 802.11-2012, 2016 and 2020, and ax-2021?

- The state of ak might be as you say, but what's the point on insisting on it in this draft? The draft is about capabilities not the state of implementations, and this would give the wrong impression that this is the only standard discussed in the doc that is not widely available.

[DC] The document is describing capabilities as defined by standards and it is not the intention to make an assessment of the market for implementations, which would be very hard to do. If there is a concern with the reference to 802.11ak, we could replace it with a reference to 802.11-2020, which already incorporates the changes in the 802.11ak amendment.

[Rocco]

The suggestion is not about making an assessment of the market for implementations. However, in general, if nobody implements a feature specified by a standard, then practically speaking the given feature is not available for the general public. Therefore, I believe it would be useful for the community to be clear on IEEE 802.11ak with this regard.

Also, it may be beneficial for the reader if we are more specific by referring to IEEE 802.11ak and not just the whole IEEE 802.11-2020.

- I see the sense of your proposal, and will wait for you and Dave to conclude before I make another pass

Keep safe

Pascal

From: Rocco Di Taranto <[email-masked]<mailto:[email-masked]>>
Sent: vendredi 30 juillet 2021 14:21
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: FW: Comments on section 4 in draft-ietf-raw-technologies-02

Dear Dave, Pascal, and All,

Thanks for your comments and proposed text.

I have also added below alternative suggestions to address a few comments. Please let me know if something is not clear.

Best Regards,

Rocco

From: RAW <[email-masked]<mailto:[email-masked]>> on behalf of Cavalcanti, Dave <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 29, 2021 12:49:18 AM
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Rocco Di Taranto <rocco.di.taranto=[email-masked]<mailto:rocco.di.taranto=[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Raw] Comments on section 4 in draft-ietf-raw-technologies-02

Dear Rocco, Pascal and All,

Thanks for the detailed comments. Most suggestions are clear and will help improve the document.

I've added below alternative suggestions to address a few comments. Please let me know if you have any questions.

Thanks,

Dave

From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 28, 2021 6:30 AM
To: Rocco Di Taranto <rocco.di.taranto=[email-masked]<mailto:rocco.di.taranto=[email-masked]>>; Cavalcanti, Dave <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Comments on section 4 in draft-ietf-raw-technologies-02

Dear Rocco and all

This is an impressive review, perfect for pre WGLC. It's very sad that we missed it due to tooling issues, great thing that you brought it back yesterday.

I reviewed the comments and  they all look like great clarification / tightening to my eye.

Since the comments apply to Dave's contribution (cc) and discuss deep IEEE activity, I'd like to see his advice before editing.

In the meantime, can you please check whether the mail below is complete? It may have been truncated deeper.

Keep safe;

Pascal

From: Rocco Di Taranto <[email-masked]<mailto:[email-masked]>>
Sent: Monday, June 21, 2021 10:17 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Comments on section 4 in draft-ietf-raw-technologies-02

Dear Authors, WG,

Please find below some comments and suggested changes to section 4 of the RAW technologies draft.

Best Regards,

Rocco Di Taranto

Section 4.1 Provenance and Documents

OLD TEXT:

   The IEEE 802.11 LAN

NEW TEXT:

   The IEEE 802.11 Wireless LAN (WLAN)

[OK]

OLD TEXT:

   While previous 802.11 generations, such as 802.11n and 802.11ac, have focused mainly on improving peak throughput, more recent generations are also considering other performance vectors, such as efficiency enhancements for dense environments in 802.11ax, and latency and support for Time-Sensitive Networking (TSN) capabilities in 802.11be.

NEW TEXT:

   While previous 802.11 generations, such as 802.11n and 802.11ac, have focused mainly on improving peak throughput, more recent generations are also considering other performance vectors, such as efficiency enhancements for dense  environments in 802.11ax, and latency and support for Time-Sensitive Networking (TSN) capabilities in P802.11be.

[DC] Suggested TEXT:

   While previous 802.11 generations, such as 802.11n and 802.11ac, have focused mainly on improving peak throughput, more recent generations are also considering other performance vectors, such as efficiency enhancements for dense  environments in 802.11ax, latency, reliability and enhancements supporting Time-Sensitive Networking (TSN) capabilities in P802.11be.

[Rocco]

Ok.

It would be beneficial for the readers to be clear on what is already supported by 802.11.

OLD TEXT:

    IEEE 802.11 already supports some 802.1 TSN standards and it is undergoing efforts to support for other 802.1 TSN capabilities required to address the use cases that require time synchronization and timeliness (bounded  latency) guarantees with high reliability and availability.

NEW TEXT:

    IEEE 802.11-2016 supports the TSN time synchronization standard (IEEE 802.1AS) and the Stream Reservation Protocol (IEEE 802.1Qat). No further TSN standards are supported up to IEEE Std. 802.11ax-2021. However, the IEEE 802.11 is undergoing efforts to support 802.1TSN capabilities required to address the use cases that require time synchronization and timeliness (bounded latency) guarantees with high reliability and availability.

[DC] Suggested NEW TEXT:

    IEEE 802.11-2012 introduced support for TSN time synchronization based on IEEE 802.1AS over 802.11 Timing Measurement protocol. IEEE 802.11-2016 extended the 802.1AS operation over 802.11 Fine Timing Measurement (FTM), as well as the Stream Reservation Protocol (IEEE 802.1Qat). 802.11 WLANs can also be part of a 802.1Q bridged networks with enhancements enabled by the 802.11ak amendment. Traffic classification based on 802.1Q VLAN tags is also supported in 802.11. Other 802.1 TSN capabilities such as 802.1Qbv and 802.1CB, which are media agnostic, can already operate over 802.11. The IEEE Std. 802.11ax-2021 adds new scheduling capabilities that can enhance the timeliness performance in the 802.11 MAC and achieve lower bounded latency. The IEEE 802.11be is undergoing efforts to enhance the support for 802.1 TSN capabilities especially related to worst-case latency, reliability and availability.

[Rocco]

I have comments to the Suggested NEW TEXT:

Comment 1: I propose we should not have "Traffic classification based on 802.1Q VLAN tags is also supported in 802.11" because classification in 802.11 is not the same as in 802.1Q VLAN tag where the Priority Code Point (PCP) field is the one doing the classification. Moreover, there are no guidelines for the mapping between the two classifications.

[DC] 802.11 has already defined a method to filter higher layer data based on the 802.1Q VLAN tags/PCP, which is the TCLAS mechanism. The point is that 802.11 can already identify the traffic using the TSN compatible methods. The TCLAS does exactly the mapping of the classification mechanisms.

[Rocco 2021-08-24 outstanding comment 1]

The idea behind the Comment 1 is seeking clarity. It seems that "identification", "filtering", "mapping", and "classification" may be used here as synonyms; however, some people interpret them differently. Perhaps an investigation point may be whether or not 802.11 uses the term "traffic class" exactly as 802.1Q. If yes, then "traffic classification" can be the right phrase. If not, then an alternative might be considered, e.g., "traffic identification".

Comment 2: I propose we should remove "Other 802.1 TSN capabilities such as 802.1Qbv and 802.1CB, which are media agnostic, can already operate over 802.11" because related aspects are still under discussion in IEEE P802.11be (and are not supported in IEEE 802.11ax or earlier).

[DC] 802.11be is defining enhancements that can make 802.1Qbv and 802.1CB to operate more efficiently with better performance, but it is important that this document states clearly that the existing 802.1Qbv and CB can already work, as it has been demonstrated in some of the references with 802.11ac, and 802.11ax.

[Rocco 2021-08-24 outstanding comment 2]

Even if it may have been demonstrated in some of the references with 802.11ac and 802.11ax that existing 802.1Qbv and 802.1CB can already work over 802.11, I propose to remove the sentence because 802.1Qbv and 802.1CB have not been formally incorporated in any published standard or amendment related to 802.11. In my understanding, it is with custom/ proprietary implementations that related features may be realized. Therefore, as the intention of this RAW document is to describe capabilities as defined by standards, it is not relevant to highlight that "802.1Qbv and 802.1CB can operate over 802.11" in this document.

The above comments would thus result in:

IEEE 802.11-2012 introduced support for TSN time synchronization based on IEEE 802.1AS over 802.11 Timing Measurement protocol. IEEE 802.11-2016 added support for the Stream Reservation Protocol (IEEE 802.1Qat) and extended the 802.1AS operation over 802.11 Fine Timing Measurement (FTM). 802.11 WLANs can also be part of a 802.1Q bridged networks with enhancements enabled by the 802.11ak amendment. The IEEE Std. 802.11ax-2021 adds new scheduling capabilities that can enhance the timeliness performance in the 802.11 MAC and achieve lower bounded latency. The IEEE P802.11be is undergoing efforts to enhance the support for 802.1 TSN capabilities especially related to worst-case latency, reliability and availability.

[DC] Suggest we keep the text as is in the draft, see comment above. We could add more references to how 802.1Qbv and CB are used with 802.11 if that helps. Please let me know.

[Rocco 2021-08-24 outstanding comment 3]

It would be beneficial for the readers to be clear on what is available. For example, being clear on P802.11be being an ongoing project, i.e., P802.11be features are not available yet. Different features have different status when it comes to what is within P802.11be. For instance, if something is at contribution level, then the RAW WG could decide whether or not it could be part of a RAW document. The idea is just to be clear on these type of aspects as well.

OLD TEXT:

     The IEEE 802.11 working group has been working in collaboration with the IEEE 802.1 group for several years extending 802.1 features over 802.11. As with any wireless media, 802.11 imposes new constraints and restrictions to TSN-grade QoS, and tradeoffs between latency and reliability guarantees must be considered as well as managed deployment requirements. An overview of 802.1 TSN capabilities and their extensions to 802.11 are discussed in [Cavalcanti_2019].

NEW TEXT:

     The IEEE 802.11 working group has been working in collaboration with the IEEE 802.1 working group for several years extending some 802.1 features over 802.11. As with any wireless media, 802.11 imposes new constraints and restrictions to TSN-grade QoS, and tradeoffs between latency and reliability guarantees must be considered as well as managed deployment requirements. An overview of 802.1 TSN capabilities and challenges for their extensions to 802.11 are discussed in [Cavalcanti_2019].

[OK]

Section 4.2 802.11ax High Efficiency (HE)

4.2.1 General Characteristics

It would be helpful to provide a bit more information on scheduled operation.

OLD TEXT:

     The OFDMA mode and trigger-based access enable scheduled operation, which is a key capability required to support deterministic latency and reliability for time-sensitive flows.

NEW TEXT:

     The OFDMA mode and trigger-based access enable the AP, after reserving the channel using the LBT procedure, to schedule operation for a limited period of time, which is a key capability required to increase latency predictability and reliability and reliability for time-sensitive flows.

[DC] Suggested NEW TEXT:

     The OFDMA mode and trigger-based access enable the AP, after acquiring the channel for a given duration, to schedule multi-user transmissions, which is a key capability required to increase latency predictability and and reliability for time-sensitive flows.

[Rocco]

I propose following modified version based on the Suggested NEW TEXT:

The OFDMA mode and trigger-based access enable the AP, after reserving the channel using the LBT procedure for a given duration, to schedule multi-user transmissions, which is a key capability required to increase latency predictability and reliability for time-sensitive flows.

 [DC]  new suggestion:

The OFDMA mode and trigger-based access enable the AP, after reserving the channel using the clear channel assessment procedure for a given duration, to schedule multi-user transmissions, which is a key capability required to increase latency predictability and reliability for time-sensitive flows.

[Rocco]

Ok.

4.2.1.1 Multi-User OFDMA and Trigger-based Scheduled Access

It would be helpful to provide a bit more information on scheduled operation.

OLD TEXT:

    This centralized scheduling capability gives the AP much more control of the channel, and it can remove contention between devices for uplink transmissions, therefore reducing the randomness caused by CSMA-based access between stations.

NEW TEXT:

    This centralized scheduling capability gives the AP much more control of the channel in its Basic Service Set (BSS) and it can remove contention between associated stations for uplink transmissions, therefore reducing the randomness caused by CSMA-based access between stations within the same BSS.

[OK]

It would be helpful to be clearer on what the higher priority is related to.

OLD TEXT:

    However, 802.11ax also includes a multi-user Enhanced Distributed Channel Access (MU-EDCA) capability, which allows the AP to get higher channel access priority.

NEW TEXT:

    However, 802.11ax also includes a multi-user Enhanced Distributed Channel Access (MU-EDCA) capability, which allows the AP to get higher channel access priority than other devices in its BSS.

[OK]

4.2.2 Applicability to deterministic flows

It would be better to be clear on what is already supported and what is ongoing or future work.

OLD TEXT:

     The 802.11 working group has already incorporated support for several TSN capabilities, so that time-sensitive flow can experience precise time synchronization and timeliness when operating over 802.11 links.

NEW TEXT:

     The 802.11 working group has incorporated support for absolute time synchronization to extend the TSN 802.1AS protocol so that time-sensitive flow can experience precise time synchronization when operating over 802.11 links. As IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802 architecture, 802.11 devices can directly implement TSN capabilities without the need for a gateway/translation protocol. Basic features required for operation in a 802.1Q LAN and 802.1AS time synchronization are already enabled for 802.11. Some TSN capabilities, such as 802.1Qbv, can already operate over the existing 802.11 MAC SAP [new REF]. Nevertheless, the IEEE 802.11 MAC/PHY requires further extensions to improve the operation of IEEE 802.1 TSN features and achieve better performance metrics. [https://mentor.ieee.org/802.11/dcn/19/11-19-1287]

[new REF]: Susruth S., et al, "Wireless Time Sensitive Networking for Industrial Collaborative Robotic Workcells",  17th IEEE International Conference on Factory Communication Systems (WFCS)<https://ieeexplore.ieee.org/xpl/conhome/9483577/proceeding>, July 2021.

[Rocco]

I propose not to have   "As IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802 architecture, 802.11 devices can directly implement TSN capabilities"  in the text because it is not specific and is not true in general for all the TSN features. Also the 802.1Qbv scheduled traffic is a particular way of scheduling. 802.11 does its own wireless scheduling. The two are not identical. 802.1Qbv is the TSN feature. It is therefore misleading to position 802.11 scheduling, e.g., as a direct TSN feature.

NEW TEXT:

     The 802.11 working group has incorporated support for absolute time synchronization to extend the TSN 802.1AS protocol so that time-sensitive flow can experience precise time synchronization when operating over 802.11 links. As IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802 architecture, 802.11 devices can directly implement TSN capabilities without the need for a gateway/translation protocol. Basic features required for operation in a 802.1Q LAN are already enabled for 802.11. Some TSN capabilities, such as 802.1Qbv, can already operate over the existing 802.11 MAC SAP [new REF]. Nevertheless, the IEEE 802.11 MAC/PHY requires further extensions to improve the operation of IEEE 802.1 TSN features and achieve better performance metrics. [https://mentor.ieee.org/802.11/dcn/19/11-19-1287]

[new REF]: Susruth S., et al, "Wireless Time Sensitive Networking for Industrial Collaborative Robotic Workcells",  17th IEEE International Conference on Factory Communication Systems (WFCS)<https://ieeexplore.ieee.org/xpl/conhome/9483577/proceeding>, July 2021.

Thus, based on the above, I propose the following modified text:

The 802.11 working group has incorporated support for absolute time synchronization to extend the TSN 802.1AS protocol so that time-sensitive flow can experience precise time synchronization when operating over 802.11 links. Some basic features required for operation in a 802.1Q LAN are available in 802.11, for example IEEE 802.11-2016 introduced support for Stream Reservation Protocol (IEEE 802.1Qat). Nevertheless, the IEEE 802.11 MAC/PHY requires further extensions to improve the operation of IEEE 802.1 TSN features and achieve better performance metrics. [https://mentor.ieee.org/802.11/dcn/19/11-19-1287]

[DC] The text is not suggesting that 802.11 supports all TSN features. It is true that 802.11 devices can implement TSN features without the need for gateways/translators. This should be emphasize and it is an important distinction between 802.11 and other non-IEEE wireless technologies, which will need a translator. 802.1AS is a very clear example of this and I've added a clarification above. I suggest we keep the text with the added clarification add above.

[Rocco 2021-08-24 outstanding comment 4]

If the text does not intend to suggest that 802.11 supports all TSN features, then perhaps it may be good to be clear on that, e.g., use "implement some TSN capabilities" or "implement selected TSN capabilities" instead of the current "implement TSN capabilities".

It is good to be clear what is meant by he support of 802.1Q bridges and the availability of the feature in reality.

OLD TEXT:

     2. Interoperating with IEEE802.1Q bridges

NEW TEXT:

     2. Interoperating with IEEE802.1Q bridges as per IEEE 802.11ak (which is yet to be seen implemented in practice)

[DC] Suggested NEW TEXT:

     2. Interoperating with IEEE802.1Q bridges as per IEEE 802.11ak.

[Rocco]

I propose to use the earlier proposed NEW TEXT itself:

    2. Interoperating with IEEE802.1Q bridges as per IEEE 802.11ak (which is yet to be seen implemented in practice)

Comment/question: If you want to remove the text in brackets, can you please point to an existing implementation of 802.11k?

[DC] Suggest to replace "802.11ak" with as per the IEEE 802.11-2020 specification. The text is not based on available implementation, which we can't ensure there is one or not. It's about available capabilities and standards.

[Rocco 2021-08-24 outstanding comment 5]

It may be beneficial for the reader if we are more specific by referring to IEEE 802.11ak and not just the whole IEEE 802.11-2020.

One confusing aspect here may be whether is it an "available capability" simply because is in  a standard published in 2018, but has not been implemented yet. Therefore, I believe it would be useful for the community to be clear on IEEE 802.11ak with this regard.

The point that the text is about "available capabilities and standards" raises another important aspect: P802.11be is not a published standard but an ongoing project. Along this point, all 802.11be text could be then removed from this draft.

It is good to be clear on what is meant. Stream identification has a very specific meaning in TSN. The TSN Stream identification options are standardized by 802.1CB. This section is about the classification provided by 802.11; therefore, it is better to reflect that in the section header.

OLD TEXT:

     3. Time-sensitive Traffic Stream Identification

NEW TEXT:

     3. Please rename to "Traffic Stream Classification" as in https://mentor.ieee.org/802.11/dcn/21/11-21-0628-00-00be-wireless-tsn-in-802-11-and-new-requirements-for-802-11be-and-802-1.pptx,  page 4, line 3, column 1 in the table

[DC] Suggested NEW TEXT:

     3. Time-sensitive Traffic Stream Identification and Classification

[Rocco]

Comment 1: Propose to remove "Time-sensitive" because that is misleading and may confuse the reader with TSN streams.

Comment 2: Propose to remove "Identification" because Wi-Fi devices cannot identify different types of TSN streams.

Therefore, I propose to rename as earlier proposed as NEW TEXT:

     3. Traffic Stream Classification

[DC] I've addressed this in a previous comment, but I'm OK to keep it traffic stream classification.

[Rocco 2021-08-24 outstanding comment 6]

OK, then let us have it as 'Traffic Stream Classification'.

OLD TEXT:

    The exiting 802.11 TSN capabilities listed above, and the 802.11ax OFDMA and scheduled access provide a new set of tools to better server time-sensitive flows.

NEW TEXT:

    The exiting 802.11 TSN capabilities listed above, and the 802.11ax OFDMA and AP-controlled access within a BSS provide a new set of tools to better serve time-sensitive flows.

[OK]

4.2.2.1 802.11 Managed network operation and admission control

It is not clear what the end of the sentence refers to, so it is better to remove it. It is not clear if and what admission control procedures are called out from the IEEE 802.11Qcc here.

OLD TEXT:

    Some of the random-access latency and interference from legacy/unmanaged devices can be minimized under a centralized management mode as defined in [IEEE8021Qcc], in which admission control procedures are enforced.

NEW TEXT:

    Some of the random-access latency and interference from legacy/unmanaged devices can be minimized under a centralized management mode as defined in [IEEE8021Qcc].

[OK]

4.2.2.2 Scheduling for bounded latency and diversity

It is better to be clear on what can be really provided under what circumstances.

OLD TEXT:

    Such flexibility can be leveraged to support time-sensitive applications with bounded latency, especially in a managed network where stations can be configured to operate under the control of the AP.

NEW TEXT:

    Such flexibility can be leveraged to support time-sensitive applications with bounded latency, especially in a managed network where stations can be configured to operate under the control of the AP and in a controlled environment (which contains only devices operating on the unlicensed band installed by the facility owner and where unexpected interference from other systems and/or radio access technologies only sporadically happens).

[DC] Suggested NEW TEXT:

    Such flexibility can be leveraged to support time-sensitive applications with bounded latency, especially in a managed network where stations can be configured to operate under the control of the AP, in a controlled environment (which contains only devices operating on the unlicensed band installed by the facility owner and where unexpected interference from other systems and/or radio access technologies only sporadically happens), or in a deployment where channel/link redundancy is used to minimize the impact of unmanaged devices/interference.

[Rocco]

I propose the following modified text based on the Suggested NEW TEXT:

Such flexibility can be leveraged to support time-sensitive applications with bounded latency, especially in a managed network where stations can be configured to operate under the control of the AP, in a controlled environment (which contains only devices operating on the unlicensed band installed by the facility owner and where unexpected interference from other systems and/or radio access technologies only sporadically happens), or in a deployment where channel/link redundancy is used to reduce the impact of unmanaged devices/interference.

Comment: Redundancy can help to reduce impact of interference. 'Minimize' is a well-defined mathematical concept that would not apply here.

[DC] replacing minimize with reduce sounds good to me.

[Rocco]

OK, then let us replace 'minimize' with 'reduce' as proposed.

It is better to be clear on what can be really provided under what circumstances. A detailed analysis is available on this, which seems to be a better reference.

OLD TEXT:

    As shown in [Cavalcanti_2019], it is possible to achieve latencies in the order of 1msec with high reliability in an interference free environment.

NEW TEXT:

    As shown in https://onestore.nokia.com/asset/207850 it is possible to achieve latencies in the order of 1 msec in an interference free environment, when Wi-Fi is operated in contention-based (i.e., without OFDMA) mode.

[DC] Suggested NEW TEXT:

    When the network in lightly loaded, it is possible to achieve latencies under 1 msec when Wi-Fi is operated in contention-based (i.e., without OFDMA) mode. It is also has been shown that it is possible to achieve 1 msec latencies in controlled environment with higher efficiency when multi-user transmissions are used (enabled by OFDMA operation) [Cavalcanti_2019] [new REF].

[Note, not to be included in the text] contention based mode is not very relevant here, but it is known that the latency in contention-based mode with legacy Wi-Fi (e.g. 11ac) in an interference free channel (not under congestion) will be even lower than 1 msec. The reference suggested above provides a very high level comparison between Wi-Fi 6 and 5G without enough details on the assumptions/scenarios. [Cavalcanti_2019] Provides detailed description of the analysis and it is applicable to 802.11 only, which is the main subject of this section.

[Rocco]

I propose the following modified text based on the Suggested NEW TEXT:

When the network is very lightly loaded, it is possible to achieve latencies under 1 msec when Wi-Fi is operated in contention-based mode (i.e., without OFDMA) mode [https://onestore.nokia.com/asset/207850]. It has also been shown that it is possible to achieve 1 msec latencies in a controlled environment with higher efficiency when multi-user transmissions are used (enabled by OFDMA operation) [Cavalcanti_2019]. However, one main requirement to achieve such optimized operation is that the AP is always aware of when and which STAs have UL traffic (e.g., if all STAs have periodic and deterministic traffic). Another fundamental assumption is that the amount of data to transmit in UL is similar in all STAs so that inefficiencies due to padding do not induce additional delays.

[DC] I'd suggest  to keep the current text and just add an additional refence.

Note that the fundamental assumption for any TSN-capable network is that all end devices will need to specify their traffic requirements up front (please review the 802.1Qcc models). Therefore, we don't need to make extra assumptions for 802.11, as the proposed text implies. This is already assumed when we talk about Ethernet TSN so it applies to Wi-Fi TSN as well. Also, there are no requirements on the same amount of UL data for all STAs. There will also be inefficiencies in scheduling traffic in Ethernet depending on the configuration of the traffic streams. This is not something specific to 802.11.

[Rocco 2021-08-24 outstanding comment 7]

I believe that the text in this section is about what can be typically achieved (for example, for bounded latency) while operating using 802.11 in the wireless domain and is not  focused only toward TSN-capable networks. Also, as I understand it, this part of the text is about 802.11 and to help a reader understand the comparison between contention-based (i.e., without OFDMA) mode versus multi-user transmissions enabled by OFDMA mode. Therefore, I believe it would be beneficial for a reader to understand that while OFDMA mode can provide higher efficiency and improved performance when compared to the contention-based mode, there may be some underlying assumptions specific to 802.11 that need to be fulfilled. I propose the following modified text based on your response:

When the network is very lightly loaded, it is possible to achieve latencies under 1 msec when Wi-Fi is operated in contention-based mode (i.e., without OFDMA) mode [https://onestore.nokia.com/asset/207850]. It has also been shown that it is possible to achieve 1 msec latencies in a controlled environment with higher efficiency when multi-user transmissions are used (enabled by OFDMA operation) [Cavalcanti_2019]. One main requirement to achieve such optimized operation is that the AP is always aware of when and which STAs have UL traffic (e.g., if all STAs have periodic and deterministic traffic). This requirement may be inherently addressed when the use case corresponds to setting up a TSN-capable network using 802.1Qcc models. Another fundamental assumption is that the amount of data to transmit in UL is similar in all STAs so that inefficiencies due to padding do not induce additional delays (the length of the OFDMA packet  is determined based on the longest data transmission among all users served with a single OFDMA packet).. Another strict requirement is the absence of handovers between APs, e.g., which may be needed because of machine/robots moving in a factory.

It is better to be clear on what can be really provided under what circumstances

OLD TEXT:

    For instance, smaller Resource Units (RU)s result in longer transmission durations, which may impact the minimal latency that can be achieved, but the contention latency and randomness elimination due to multi-user transmission is a major benefit of the OFDMA mode.

NEW TEXT:

    For instance, smaller Resource Units (RU)s result in longer transmission durations, which may impact the minimal latency that can be achieved, but the contention latency and randomness elimination in an interference-free environment due to multi-user transmission is a major benefit of the OFDMA mode.

[OK]

4.3 802.11be Extreme High Throughput (EHT)

4.3.1 General Characteristics

OLD TEXT:

    The [IEEE 802.11be WIP]is the next major 802.11 amendment (after [IEEE Std. 802.11ax]) for operation in the 2.4, 5 and 6 GHz bands. 802.11be is expected to include new PHY and MAC features and it is targeting extremely high throughput (at least 30 Gbps), as well as enhancements to worst case latency and jitter.

NEW TEXT:

    The ongoing [IEEE 802.11be WIP] project is the next major 802.11 amendment (after [IEEE Std. 802.11ax-2021]) for operation in the 2.4, 5 and 6 GHz bands. 802.11be is expected to include new PHY and MAC features and it is targeting extremely high throughput (at least 30 Gbps), as well as enhancements to worst case latency and jitter.

[OK]

4.4 802.11ad and 802.11ay (mmWave operation)

4..4.2 Applicability to deterministic flows

It is better to be clear on what can be really provided under what circumstances.

OLD TEXT:

     The 802.11ad standard include a scheduled access mode in which stations can be allocated contention-free service periods by a central controller. This scheduling capability is also available in 802.11ay, and it is one of the mechanisms that can be used to provide bounded latency to time-sensitive data flows.

NEW TEXT:

     The 802.11ad standard includes a scheduled access mode in which the central controller, after contending and reserving the channel for a dedicated period, can allocate to stations contention-free service periods. This scheduling capability is also available in 802.11ay, and it is one of the mechanisms that can be used to provide bounded latency to time-sensitive data flows in interference-free scenarios.

[OK]

---

From: "Cavalcanti, Dave" <[email-masked]>
Date: Tue, 24 Aug 2021 19:05:38 +0000

Hi Pascal and Rocco,

Thanks for the additional clarifications. I've added my input below, please see [DC].

Best,

Dave

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Tuesday, August 24, 2021 5:52 AM
To: Rocco Di Taranto <rocco.di.taranto=[email-masked]>; Cavalcanti, Dave <[email-masked]>
Cc: [email-masked]
Subject: Second pass: Rocco's comments on draft-ietf-raw-technologies-02 [WAS: Comments on section 4 in draft-ietf-raw-technologies-02]

Hello Rocco:

[DC] Not every 802.1 standards need media specific enhancements, we don't expect every 802.1 standard will require changes in 802.11.

[DC] I don't see the issue here, TSN is a set of tools, it is a fact that some TSN features have already been enabled over 802.11.

 PT> Then again this  misaligned objective for the document: we're certainly interested in getting the latest as long as it's clear that the .11be piece is WIP.
[DC] The reference to the 802.1be draft is already included and we should not ignore it.

[DC] The following three points in the suggested text seem a bit problematic:

One main requirement to achieve such optimized operation is that the AP is always aware of when and which STAs have UL traffic (e.g., if all STAs have periodic and deterministic traffic).
[DC] This is not a requirement for the operation of OFDMA, the spec provides the tools to help the AP acquire the traffic information and buffer status from STAs, and it is up to the implementation of the scheduling algorithm to decide how to use it. You can say that having information about the traffic is important for the optimization of the scheduler (which his implementation dependent) and this information is expected to be available in a TSN capable network or any network that expects determinism, which is the scope of RAW.

Another fundamental assumption is that the amount of data to transmit in UL is similar in all STAs so that inefficiencies due to padding
[DC] Again, padding is not an assumption for OFDMA. It may be required depending on the combination of STAs, MCSs and RU assignments. The reference to padding is not relevant here. But you could indicate that there are latency vs. reliability vs. overhead tradeoffs that will need to be made in any implementation in an OFDMA system.

Another strict requirement is the absence of handovers between APs, e.g., which may be needed because of machine/robots moving in a factory.
[DC] Wi-Fi does support handover between APs. Suggest to remove the sentence as it is suggesting that there is no handover in Wi-Fi. Also, it is not related to the OFDMA discussion in this paragraph.

Pascal

From: RAW <[email-masked]<mailto:[email-masked]>> On Behalf Of Rocco Di Taranto
Sent: mardi 24 août 2021 12:29
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Raw] Comments on section 4 in draft-ietf-raw-technologies-02

Dear Pascal, All,

Thank you.

Best Regards,

Rocco

Best Regards,

Rocco

Hi Pascal and Rocco,

Thanks

Dave

Hello Rocco

Quick notes:

[Rocco]

Keep safe

Pascal

Best Regards,

Rocco

Thanks,

Dave

Dear Rocco and all

Keep safe;

Pascal

Dear Authors, WG,

Best Regards,

Rocco Di Taranto

OLD TEXT:

   The IEEE 802.11 LAN

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[DC] Suggested TEXT:

[Rocco]

Ok.

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

 [DC]  new suggestion:

[Rocco]

Ok.

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[Rocco]

NEW TEXT:

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

[Rocco]

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[OK]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 26 Aug 2021 06:56:04 +0000

Thanks Dave:

I do not see actionable items for me.
Comment 7 is not resolved, ball in Rocco's camp.
Comment 4 I could add "some" but it does not really make a difference
For the other ones I see a discussion but no need for new text;

Rocco?

Pascal

From: Cavalcanti, Dave <[email-masked]>
Sent: mardi 24 août 2021 21:06
To: Pascal Thubert (pthubert) <[email-masked]>; Rocco Di Taranto <rocco.di.taranto=[email-masked]>
Cc: [email-masked]
Subject: RE: Second pass: Rocco's comments on draft-ietf-raw-technologies-02 [WAS: Comments on section 4 in draft-ietf-raw-technologies-02]

Hi Pascal and Rocco,

Best,

Dave

Hello Rocco:

Pascal

Dear Pascal, All,

Thank you.

Best Regards,

Rocco

Best Regards,

Rocco

Hi Pascal and Rocco,

Thanks

Dave

Hello Rocco

Quick notes:

[Rocco]

Keep safe

Pascal

Best Regards,

Rocco

Thanks,

Dave

Dear Rocco and all

Keep safe;

Pascal

Dear Authors, WG,

Best Regards,

Rocco Di Taranto

OLD TEXT:

   The IEEE 802.11 LAN

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[DC] Suggested TEXT:

[Rocco]

Ok.

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

 [DC]  new suggestion:

[Rocco]

Ok.

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[Rocco]

NEW TEXT:

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

[Rocco]

OLD TEXT:

NEW TEXT:

[DC] Suggested NEW TEXT:

[Rocco]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[OK]

---

From: Janos Farkas <[email-masked]>
Date: Fri, 27 Aug 2021 13:34:38 +0000

Hi,

From: RAW <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, August 24, 2021 2:52 PM
To: Rocco Di Taranto <rocco.di.taranto=[email-masked]>; Dave Cavalcanti <[email-masked]>
Cc: [email-masked]
Subject: [Raw] Second pass: Rocco's comments on draft-ietf-raw-technologies-02 [WAS: Comments on section 4 in draft-ietf-raw-technologies-02]

Hello Rocco:

Well, I am not sure.
Perhaps it would be useful to have clarifications on the view from the WG on what goes into our documents. Just purely thinking about principles here, not any particular technology.

My experience in SDOs has been that what is referred to as available technology is what is there in published standards.
(Not what is there in (individual) contributions, ongoing projects, labs, or proprietary solutions. Before the publication of a document, there is often a checkpoint on references, where ongoing work, i.e., draft standards get removed and only published standards remain because ongoing work is not a stable reference as it may take different direction and so on.)

I may be biased with this experience, but my read of Dave's point:
"It's about available capabilities and standards." in https://mailarchive.ietf.org/arch/msg/raw/5idNxm5L_VjNcCUkuh76_bKErCE/ is that it makes a somewhat similar point.
In order to claim a capability available, it has to be available in a published standard. Otherwise, multi-vendor interoperable solution/deployment is not possible/available.

I'd be glad for the view from the WG on this.

Regards,
Janos