Subject: Re: [Raw] Comments on section 4 in draft-ietf-raw-technologies-02

From: "Cavalcanti, Dave" <[email-masked]>
Date: Mon, 2 Aug 2021 14:57:23 +0000

Hi Pascal,

I also agree, we could add a clarification that in addition to the power saving benefits, the TWT mechanism can also help scheduling transmissions, which is relevant to RAW.

We could also add a sentence in the 802.11be section highlighting the restricted TWT feature under development in the current 802.11be draft, which aims to create service periods that can be prioritized for time-sensitive flows.

Do you need more than a few sentences/references?

Rute, feel free to add more details.

Thanks,
Dave

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Saturday, July 31, 2021 12:54 AM
To: Cavalcanti, Dave <[email-masked]>
Cc: Rute Sofia <[email-masked]>; [email-masked]
Subject: Re: Comments on section 4 in draft-ietf-raw-technologies-02

Hello Dave

I agree with Rute that we could elaborate more on the capabilities that tWT enable; the point is not whether the current text is accurate but what it does not say.

TWT enables things like low power devices (like a LoRa class B), TSCH operations (like 6TISCH), frequency diversity with a single module, all things that RAW is very interested in…

I’m not saying it is done now but we can present it as projected capabilities for future OT/IoT operations.

Are you interested in writing that text?

Maybe Rute has more in mind?

Keep safe,

Pascal

Le 30 juil. 2021 à 19:05, Cavalcanti, Dave <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal and Rute,

Please see my responses below.

Thanks
Dave

From: RAW <[email-masked]<mailto:[email-masked]>> On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, July 30, 2021 9:48 AM
To: Rute Sofia <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Raw] Comments on section 4 in draft-ietf-raw-technologies-02

Hello Rute
Many thanks for your review !
Please see below

Pascal

Le 30 juil. 2021 à 18:10, Rute Sofia <[email-masked]<mailto:[email-masked]>> a écrit :

Dear Pascal, and All,

this is a useful document. A few suggested changes and questions:

  *   Introduction. It would benefit from a more concrete objective concerning the goal of the draft, which seems to be to discuss features of different wireless technologies that allow to support deterministic guarantees in a way that matches Ethernet/TSN. Another confusing aspect concerns the identification of determinism and in particular time-based scheduling, with reliability. Reliability goes beyond this, so it would be good to clarify these aspects IMO.

Great points, will do. The tension is not to paraphrase the RAW architecture draft too much. In GitHub I already synchronized the terminology.

  *
  *   Three aspects are fundamental to integrate determinism à la Ethernet/TSN in the frequency domain (wireless): adequate traffic isolation; tight time synchronization; time-aware scheduling. In section 3 there is a debate on scheduling, but the other aspects are missing. Perhaps consider extending section 3 to these 3 aspects?

Makes sense; will do as well. Note that time sync and time triggered scheduling is not used by all shapers, see 802.1 Qcr (ATS). Even then, the capability to schedule transmission enables to control the resources used per queue in paternoster and the delay after a packet in ubs and Arinc so it’s necessary in all cases for all I know. Finally R and A does not necessarily mean bounded latency- Not all RAW cases are deterministic.

  *
  *   In the definitions, “deterministic flow” needs to be defined as well.
  *     “Applicability to deterministic flows” is IMO confusing as well. We have flows (traffic type perhaps, maybe a class and not necessarily a flow) that require deterministic guarantees from the infrastructure.

I agree it’s an abuse of language that we happen to we use it all the time. I can reword though.

  *
  *   4.2.2.2 mentions the use of RUs and scheduling. RUs are important for traffic isolation, but deterministic scheduling is not feasible just by handling RU assignment.

I guess that one is for Dave; what else would you think we should discuss?

[DC] The text is describing the OFDMA mode in 802.11, which includes the concept of RU assignment. In a controlled/managed network, assigning resources (RUs) is a key tool to achieving determinism, so I see no reasons to note mention it. Please feel free to suggest more detailed information, but I believe the current text is accurate.

  *

  *   In regards to the scheduling, both for IEEE802.11ax and IEEE802.11be, TWT is a relevant mechanism which is only mentioned for its original power-saving aspects.

Sure that should elaborated;

  *

For the next revision, I would gladly support a more in-depth development as contributor.

I’ll welcome text if you propose it. Rocco did and he is now mentioned as contributor in section 10.

Best Regards
Rute

Dr. Rute Sofia
Head of Competence Field

fortiss GmbH
Landesforschungsinstitut des Freistaats Bayern
für softwareintensive Systeme
An-Institut Technische Universität München

Guerickestraße 25, 80805 München, Germany

T: +49 (89) 3603522 170<tel:+49%20(89)%203603522%20170>
F: +49 (89) 3603522 50
[email-masked]<mailto:[email-masked]>
https://www.fortiss.org/

Amtsgericht München: HRB: 176633
USt-IdNr.: DE263907002, Steuer-Nr.: 143/237/25900
Rechtsform: gemeinnützige GmbH
Sitz der Gesellschaft: München
Geschäftsführer: Dr. Harald Rueß, Thomas Vallon
Vorsitzender des Aufsichtsrats: Dr. Manfred Wolter

From: RAW <[email-masked]<mailto:[email-masked]>> On Behalf Of Rocco Di Taranto
Sent: 30 July 2021 14:57
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 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.

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).

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.

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.

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 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.

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]

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?

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

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.

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].

[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.

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: Greg Mirsky <[email-masked]>
Date: Mon, 2 Aug 2021 12:11:40 -0700

Dear All,
I have a terminology clarification question. The following text refers to
the availability of TSN:

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.

Is the interpretation as defined in ITU-T Recommendation G.826? To me, that
seems unlikely as G.826 is applicable to constant bit-rate transmission. Is
that the case in RAW technologies? If that is not the case, how the
availability is defined, measured for RAW?

Regards,
Greg

On Mon, Aug 2, 2021 at 7:57 AM Cavalcanti, Dave <[email-masked]>
wrote:

> Hi Pascal,
>
>
>
> I also agree, we could add a clarification that in addition to the power
> saving benefits, the TWT mechanism can also help scheduling transmissions,
> which is relevant to RAW.
>
>
>
> We could also add a sentence in the 802.11be section highlighting the
> restricted TWT feature under development in the current 802.11be draft,
> which aims to create service periods that can be prioritized for
> time-sensitive flows.
>
>
>
> *From:* Pascal Thubert (pthubert) <[email-masked]>
> *Sent:* Saturday, July 31, 2021 12:54 AM
> *To:* Cavalcanti, Dave <[email-masked]>
> *Cc:* Rute Sofia <[email-masked]>; [email-masked]
> *Subject:* Re: Comments on section 4 in draft-ietf-raw-technologies-02
>
>
>
> Hello Dave
>
>
>
> I agree with Rute that we could elaborate more on the capabilities that
> tWT enable; the point is not whether the current text is accurate but what
> it does not say.
>
>
>
> TWT enables things like low power devices (like a LoRa class B), TSCH
> operations (like 6TISCH), frequency diversity with a single module, all
> things that RAW is very interested in…
>
>
>
> I’m not saying it is done now but we can present it as projected
> capabilities for future OT/IoT operations.
>
>
>
> Le 30 juil. 2021 à 19:05, Cavalcanti, Dave <[email-masked]> a
> écrit :
>
> 
>
> Hi Pascal and Rute,
>
>
>
> *From:* RAW <[email-masked]> *On Behalf Of *Pascal Thubert
> (pthubert)
> *Sent:* Friday, July 30, 2021 9:48 AM
> *To:* Rute Sofia <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Raw] Comments on section 4 in
> draft-ietf-raw-technologies-02
>
>
>
> Hello Rute
>
> Le 30 juil. 2021 à 18:10, Rute Sofia <[email-masked]> a écrit :
>
> 
>
> Dear Pascal, and All,
>
>
>
>    - Introduction. It would benefit from a more concrete objective
>    concerning the goal of the draft, which seems to be to discuss features of
>    different wireless technologies that allow to support deterministic
>    guarantees in a way that matches Ethernet/TSN. Another confusing aspect
>    concerns the identification of determinism and in particular time-based
>    scheduling, with reliability. Reliability goes beyond this, so it would be
>    good to clarify these aspects IMO.
>
>
>
> Great points, will do. The tension is not to paraphrase the RAW
> architecture draft too much. In GitHub I already synchronized the
> terminology.
>
>
>
>
>
>
>    -
>    - Three aspects are fundamental to integrate determinism à la
>    Ethernet/TSN in the frequency domain (wireless): adequate traffic
>    isolation; tight time synchronization; time-aware scheduling. In section 3
>    there is a debate on scheduling, but the other aspects are missing. Perhaps
>    consider extending section 3 to these 3 aspects?
>
>
>
> Makes sense; will do as well. Note that time sync and time triggered
> scheduling is not used by all shapers, see 802.1 Qcr (ATS). Even then, the
> capability to schedule transmission enables to control the resources used
> per queue in paternoster and the delay after a packet in ubs and Arinc so
> it’s necessary in all cases for all I know. Finally R and A does not
> necessarily mean bounded latency- Not all RAW cases are deterministic.
>
>
>
>
>
>
>    -
>    - In the definitions, “deterministic flow” needs to be defined as
>    well.
>    -   “Applicability to deterministic flows” is IMO confusing as well.
>    We have flows (traffic type perhaps, maybe a class and not necessarily a
>    flow) that require *deterministic guarantees* from the infrastructure.
>
>
>
>    -
>    - 4.2.2.2 mentions the use of RUs and scheduling. RUs are important
>    for traffic isolation, but deterministic scheduling is not feasible just by
>    handling RU assignment.
>
>
>
> *[DC] The text is describing the OFDMA mode in 802.11, which includes the
> concept of RU assignment. In a controlled/managed network, assigning
> resources (RUs) is a key tool to achieving determinism, so I see no reasons
> to note mention it. Please feel free to suggest more detailed information,
> but I believe the current text is accurate. *
>
>
>    -
>
>
>
>    - In regards to the scheduling, both for IEEE802.11ax and
>    IEEE802.11be, TWT is a relevant mechanism which is only mentioned for its
>    original power-saving aspects.
>
>
>
>    -
> *Dr. Rute Sofia*
> *fortiss GmbH*
> T: +49 (89) 3603522 170 <+49%20(89)%203603522%20170>
>
> F: +49 (89) 3603522 50
>
> [email-masked]
>
> https://www.fortiss.org/
>
>
>
>
>
> *From:* RAW <[email-masked]> *On Behalf Of *Rocco Di Taranto
> *Sent:* 30 July 2021 14:57
> *To:* [email-masked]; [email-masked]
> *Cc:* [email-masked]
> *Subject:* [Raw] FW: Comments on section 4 in
> draft-ietf-raw-technologies-02
>
>
>
> 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]> on behalf of Cavalcanti, Dave <
> [email-masked]>
> *Sent:* Thursday, July 29, 2021 12:49:18 AM
> *To:* Pascal Thubert (pthubert) <[email-masked]>; Rocco Di Taranto <
> rocco.di.taranto=[email-masked]>
> *Cc:* [email-masked] <[email-masked]>
> *Subject:* Re: [Raw] Comments on section 4 in
> draft-ietf-raw-technologies-02
>
>
>
> *From:* Pascal Thubert (pthubert) <[email-masked]>
> *Sent:* Wednesday, July 28, 2021 6:30 AM
> *To:* Rocco Di Taranto <rocco.di.taranto=[email-masked]>;
> Cavalcanti, Dave <[email-masked]>
> *Cc:* [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.
>
> Since the comments apply to Dave’s contribution (cc) and discuss deep IEEE
> activity, I’d like to see his advice before editing.
>
> *From:* Rocco Di Taranto <[email-masked]>
> *Sent:* Monday, June 21, 2021 10:17 AM
> *To:* [email-masked]; [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:
>
>    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]
>
> *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.
>
> *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).
>
> 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.
>
>
>
> 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]
>
> 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.
>
>
>
>
>
> *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 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.
>
> 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]
>
>
>
> *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 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 (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?
>
>
>
> *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. 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:
>
> *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.
>
>     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]
>
> 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.
>
>
>
> *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].
>
>
>
> [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]
>
> 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.
>
>
>
> *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]
>
> --
> RAW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/raw
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 3 Aug 2021 07:22:03 +0000

Yes, Dave, a few sentences would be perfect for what I see missing. Rute, what do you think?

From: Cavalcanti, Dave <[email-masked]>
Sent: lundi 2 août 2021 16:57
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Rute Sofia <[email-masked]>; [email-masked]
Subject: RE: Comments on section 4 in draft-ietf-raw-technologies-02

Hi Pascal,

Thanks,
Dave

From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, July 31, 2021 12:54 AM
To: Cavalcanti, Dave <[email-masked]<mailto:[email-masked]>>
Cc: Rute Sofia <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Comments on section 4 in draft-ietf-raw-technologies-02

Hello Dave

Keep safe,

Pascal

Hi Pascal and Rute,

Thanks
Dave

Hello Rute

Pascal

Dear Pascal, and All,

  *

  *

  *

  *

  *

Best Regards
Rute

Dr. Rute Sofia
Head of Competence Field

fortiss GmbH

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]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[OK]

OLD TEXT:

NEW TEXT:

[Rocco]

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]

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: Rocco Di Taranto <[email-masked]>
Date: Wed, 4 Aug 2021 01:42:02 +0000

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]>
 
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

 
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]>

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

OLD TEXT:
   The IEEE 802.11 LAN
 
NEW TEXT: 
 
OLD TEXT:
 
NEW TEXT:
 
[DC] Suggested TEXT:
 
[Rocco]
Ok.
 
It would be beneficial for the readers to be clear on what is already
supported by 802.11.
 
OLD TEXT: 
   
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]
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]
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]
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]

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.

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]

OLD TEXT: 
 
NEW TEXT:

It would be better to be clear on what is already supported and what is
ongoing or future work.
 
OLD TEXT:
 
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.

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]
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:
 
NEW TEXT:
 
[DC] Suggested NEW TEXT:
 
[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]
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:
 
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:
 
[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.

[DC] I've addressed this in a previous comment, but I'm OK to keep it
traffic stream classification. 
[Rocco]
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]

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]

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:
 
NEW TEXT:
 
[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].

[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]
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]

OLD TEXT:
 
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]

 
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: Rocco Di Taranto <[email-masked]>
Date: Tue, 24 Aug 2021 10:29:14 +0000

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

 
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: 
 
OLD TEXT:
 
NEW TEXT:
 
[DC] Suggested TEXT:
 
[Rocco]
Ok.

OLD TEXT: 
   
NEW TEXT: 
 
[DC] Suggested NEW TEXT: 
 
[Rocco]

[Rocco 2021-08-24 outstanding comment 1]

 
[Rocco 2021-08-24 outstanding comment 2]

[Rocco 2021-08-24 outstanding comment 3]
   
NEW TEXT: 
   
[OK]

 
OLD TEXT: 
 
[DC] Suggested NEW TEXT: 
 
[Rocco]
 
 [DC]  new suggestion:
 
[Rocco]
Ok.

 
OLD TEXT: 
 
NEW TEXT:
 
[OK]

OLD TEXT: 
 
NEW TEXT:

 
OLD TEXT:
 
NEW TEXT:

[Rocco]
 
NEW TEXT:

 
[Rocco 2021-08-24 outstanding comment 4]

OLD TEXT:
 
NEW TEXT:
 
[DC] Suggested NEW TEXT:
 
[Rocco]

[Rocco 2021-08-24 outstanding comment 5]

OLD TEXT:
 
NEW TEXT:
 
[DC] Suggested NEW TEXT:
 
[Rocco]

[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:
 
NEW TEXT:
 
[OK]

 
OLD TEXT: 
 
NEW TEXT: 

 
OLD TEXT:
 
NEW TEXT:

[DC] Suggested NEW TEXT:
 
[Rocco]

 
[Rocco]

OLD TEXT:
 
NEW TEXT:
 
[DC] Suggested NEW TEXT:

[Rocco]

[Rocco 2021-08-24 outstanding comment 7]
 
OLD TEXT:
 
NEW TEXT:
 
[OK]

OLD TEXT:
 
NEW TEXT: 
   
[OK]

 
 
OLD TEXT:
 
NEW TEXT:
 
[OK]