Re: [Raw] performance parameters / Error qualification in RAW architecture - G.826 was RE: Comments on section 4 in draft-ietf-raw-technologies-02

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Greg

RAW (and DetNet) serve industrial control loop use cases where a loss or 3 or 4 packets in a RAW cause an emergency stop, which is a mostly inacceptable condition. They also serve amusement parks where emergency stop is triggered by the loss of communication for a subsecond duration, and that entails evacuating the floor, rebooting the game, etc… not a nice thing.

Apart from the requirements from the flows, there are practical requirements to make the protocol implementable, e.g., the maximum distance between 2 packets received out of order expressed in volume or in time that cannot be too wide and impacts the cost of the system. This indicates the amount of resources like fast memory to be allocated for each flow which turn into the limits of the capacity for a system to guarantee that all flows can be reordered; it also dictates the span of the memory of be kept for elimination.

This tells us that RAW and DetNet will have unusual metrics.

Keep safe;

Pascal

From: [e-mail] <[e-mail]>
Sent: mercredi 4 août 2021 5:09
To: Pascal Thubert (pthubert) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re:[Raw] performance parameters / Error qualification in RAW architecture - G.826 was RE: Comments on section 4 in draft-ietf-raw-technologies-02


Hi Pascal,

thank you for thoughtfully spawning this topic into a separate discussion thread.

I agree that it is logical to discuss the "availability" of a RAW service in the architecture document. Adding the DetNet WG will likely add a more generic view of the subject, which is always good, IMHO.

Recommendations G.826, G.827, and G.828 apply to the media distinguished by using the constant bit-rate transmission techniques (SDH, SONET). In the case of the constant bit-rate, a receiver for the specified connection expects to have data at a specific interval even when there's no client data. That makes such media types less efficient for a user but easier for an operator (certainty and predictability). In a packet-switched network, a receiver cannot expect to receive data at specific intervals. In these networks, an active OAM can create the expectation of data at a particular interval. Then, using that active OAM protocol, we can define the error condition - Loss of the Path Continuity. If the service is not the best effort but has specific performance requirements (can call them Service Level Objectives), these should be included in the evaluation of the availability of the service. I have started a draft at IPPM WG on the EPM in PSN<https://datatracker.ietf.org/doc/draft-mirsky-ippm-epm/>. I much appreciate your thoughts on it (comments on IPPM mailing list are most welcome). Do you think the availability of a RAW and/or DetNet service should be interpretted differently from the general case of a PSN network?



Regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division


[cid:image001.gif@01D78921.9428B1E0]
[cid:image002.gif@01D78921.9428B1E0]
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<http://www.zte.com.cn/>
Original Mail
Sender: PascalThubert(pthubert)
To: Greg Mirsky;Cavalcanti, Dave;
CC: [e-mail];Rute<mailto:[e-mail];Rute> Sofia;
Date: 2021/08/03 00:20
Subject: [Raw] performance parameters / Error qualification in RAW architecture - G.826 was RE: Comments on section 4 in draft-ietf-raw-technologies-02
--
RAW mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/raw
Hello Greg:

I guess that this applies to the architecture doc rather than the technologies document; possibly to DetNet in general.
We have not used the ITU reference and derive our own high level qualification; as you know many radio links have an adaptive rate.

For RAW we can have 2 approaches:
- only reserve within a minimal bandwidth (classical stuff but it seems that G.826 evolved not to do that, is there a reason?)
- use more of the redundant path and distribute the load. This is where network coding becomes handy.

I changed the title to reflect the architecture question. Maybe we should include DetNet for the error qualification?

Keep safe;

Pascal



From: Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Sent: lundi 2 août 2021 21:12
To: Cavalcanti, Dave <[e-mail]<mailto:[e-mail]>>
Cc: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Rute Sofia <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Raw] Comments on section 4 in draft-ietf-raw-technologies-02

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]<mailto:[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]<mailto:[e-mail]>>
Sent: Saturday, July 31, 2021 12:54 AM
To: Cavalcanti, Dave <[e-mail]<mailto:[e-mail]>>
Cc: Rute Sofia <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[e-mail]>> a écrit :

Hi Pascal and Rute,

Please see my responses below.

Thanks
Dave


From: RAW <[e-mail]<mailto:[e-mail]>> On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, July 30, 2021 9:48 AM
To: Rute Sofia <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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]<mailto:[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]<tel:+49%20(89)%203603522%20170>
F: [phone]
[e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Rocco Di Taranto
Sent: 30 July 2021 14:57
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>> on behalf of Cavalcanti, Dave <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, July 29, 2021 12:49:18 AM
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; Rocco Di Taranto <rocco.di.taranto=[e-mail]<mailto:rocco.di.taranto=[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Wednesday, July 28, 2021 6:30 AM
To: Rocco Di Taranto <rocco.di.taranto=[e-mail]<mailto:rocco.di.taranto=[e-mail]>>; Cavalcanti, Dave <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Monday, June 21, 2021 10:17 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/raw