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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]>
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.
>
>
>
> Do you need more than a few sentences/references?
>
>
>
> Rute, feel free to add more details.
>
>
>
> Thanks,
>
> Dave
>
>
>
>
>
> *From:* Pascal Thubert (pthubert) <[e-mail]>
> *Sent:* Saturday, July 31, 2021 12:54 AM
> *To:* Cavalcanti, Dave <[e-mail]>
> *Cc:* Rute Sofia <[e-mail]>; [e-mail]
> *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 <[e-mail]> a
> écrit :
>
> 
>
> Hi Pascal and Rute,
>
>
>
> Please see my responses below.
>
>
>
> Thanks
>
> Dave
>
>
>
>
>
> *From:* RAW <[e-mail]> *On Behalf Of *Pascal Thubert
> (pthubert)
> *Sent:* Friday, July 30, 2021 9:48 AM
> *To:* Rute Sofia <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]> 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
>
>
>
>
>
> <image001.png>
>
>
>
> *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: [phone] <+49%20(89)%203603522%20170>
>
> F: [phone]
>
> [e-mail]
>
> 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 <[e-mail]> *On Behalf Of *Rocco Di Taranto
> *Sent:* 30 July 2021 14:57
> *To:* [e-mail]; [e-mail]
> *Cc:* [e-mail]
> *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 <[e-mail]> on behalf of Cavalcanti, Dave <
> [e-mail]>
> *Sent:* Thursday, July 29, 2021 12:49:18 AM
> *To:* Pascal Thubert (pthubert) <[e-mail]>; Rocco Di Taranto <
> rocco.di.taranto=[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *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) <[e-mail]>
> *Sent:* Wednesday, July 28, 2021 6:30 AM
> *To:* Rocco Di Taranto <rocco.di.taranto=[e-mail]>;
> Cavalcanti, Dave <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]>
> *Sent:* Monday, June 21, 2021 10:17 AM
> *To:* [e-mail]; [e-mail]
> *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]
>
> --
> RAW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/raw
>