Subject: [Raw] WG Last Call: Technologies draft

From: "Schooler, Eve M" <[email-masked]>
Date: Fri, 21 Jan 2022 18:22:42 +0000

Just a reminder, in case you didn't see this rolled into the summary...

We are officially in WGLC ending Jan 31, 2022 for the Reliable & Available Wireless Technologies internet draft, draft-ietf-raw-technologies.

Rocco and Dave and possibly Janos, please review the references to technologies in other SDOs, clarifying the references' maturation levels.

Eve & Rick

-----Original Message-----

From: RAW <[email-masked]<mailto:[email-masked]>> On Behalf Of Schooler, Eve M

Sent: lundi 20 décembre 2021 20:04

To: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

Subject: [Raw] RAW WG post-IETF 112 update

Hi All,

Just to let you know we published minutes for the IETF 112, and here is a link for your enjoyment to peruse:

https://datatracker.ietf.org/meeting/112/materials/minutes-112-raw-01.html.

A summary of the key take-aways:

  - The chairs have officially updated milestones for the key documents, notably several WGLCs upcoming (see below).

  - The authors have split the architecture/framework document into separate architecture and framework docs

       -  the chairs are exploring options for regular meetings to make forward progress on these docs

  - For the technologies doc:

       - Rocco and Dave and possibly Janos to please review the references to technologies in other SDOs, clarifying the references' maturation levels.

       - WGLC starting now

  - Pascal has requested review of the IPv6 Options for DetNet document.

  - Use cases doc  - WGLC starting now

  - LDACS - remains in IESG review and we await review by other Areas

Please consider this e-mail the official WGLC notice ending Jan 31, 2022 for the following documents:

  - Technologies

  - Use Cases

Happiest of Holidays!

Rick & Eve

Eve M. Schooler, PhD

Principal Engineer & Director

Intel | CSO & IoTG | Emerging IoT Networks

2200 Mission College Blvd., Santa Clara, CA, USA  95054

+1 650.868.7369

--

RAW mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/raw

---

From: Janos Farkas <[email-masked]>
Date: Fri, 21 Jan 2022 19:43:21 +0000

Hi,

Thank you for the reminder!

My take away is that I heard wide support for citing published standards and approved ongoing work in other SDOs.

Thanks and regards,
Janos

From: RAW <[email-masked]> On Behalf Of Schooler, Eve M
Sent: Friday, January 21, 2022 7:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Raw] WG Last Call: Technologies draft

Eve & Rick

-----Original Message-----

Hi All,

       - WGLC starting now

  - Technologies

  - Use Cases

Happiest of Holidays!

Rick & Eve

Eve M. Schooler, PhD

+1 650.868.7369

--

RAW mailing list

---

From: Rocco Di Taranto <[email-masked]>
Date: Sat, 22 Jan 2022 17:02:17 +0000

Hi Eve, 

Thanks for the reminder.

Please find below my five comments and a few typos.

Best Regards, 

Rocco Di Taranto

Section 4.1 Provenance and Documents

Comment 1: In “Adapting Wired TSN test specifications to testing of Wireless
TSN devices” (presented at TSN/A Conference 2021 by Alon Regev, Keysight
Technologies) page 12 states that “802.1Qbv functions including schedule &
management are defined at the 802.1Q layer, but the 802.11MAC does not have
a mapping for these. This limit functionality/performance. P802.11be is
addressing these”. Therefore, it can be concluded that 802.11Qbv cannot
operate on at least Wi-Fi generations prior to 802.11be.

Moreover, to the best of our knowledge, such mentioned support for 802.11Qbv
has not been added to IEEE P802.11be, the latest draft is D1.31 draft,
published in December 2021.

OLD TEXT 1:

Other 802.1 TSN capabilities such as 802.1Qbv and 802.1CB, which are media
agnostic, can already operate over 802.11.

NEW TEXT 1:

Another 802.1 TSN capabilities such as 802.1Qbv and 802.1CB can be combined
with 802.11.

Section 4.2.2 Applicability to deterministic flows

Comment 2: The text is not specific and is not true in general for the 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.

OLD TEXT 2:

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.

NEW TEXT 2:

As IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802
architecture, 802.11 devices can directly implement some TSN capabilities
without the need for a gateway/translation protocol.

Comment 3: As far as I know, 802.1Qbv has been designed for full duplex
media LAN, not for shared media LAN like WLAN.

Moreover, the work in [Sudhakaran2021] only shows that 802.1Qbv capability
in Wi-Fi can be enabled through proprietary solutions. Authors clearly state
this for example “to enable WTSN, wireless networking is introduced using a
Wi-Fi AP and two Wi-Fi stations for each robot. These three wireless nodes
are equipped with a WTSN software stack, which extends TSN features into the
Wi-Fi domain.” Proprietary solutions are not relevant in this document as
they are not generally available and not included in the ongoing IEEE
P802.11be project either. We propose to remove the text.

OLD TEXT 3:

Some TSN capabilities, such as 802.1Qbv, can already operate over the
existing 802.11 MAC/SAP [Sudhakaran2021].

NEW TEXT 3:

Some TSN capabilities, such as 802.1Qbv cannot operate over the existing
802.11MAC/SAP, unless proprietary (non-interoperable nor tested) features
are introduced.

Section 4.2.2.2 Scheduling for bounded latency and diversity

Comment 4: 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. More specifically,
on order to achieve 1 ms latencies in Wi-Fi 6, the following conditions must
be met at the same time:

1.	Operation in controlled environment.
2.	Absence of handovers (that may be caused by machine/robots moving in
a factory).
3.	APs awareness of when, and which, STAs have UL traffic to be sent.
4.	No delays induced by padding in MU UL transmissions.

OLD TEXT 4:

When the network is 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 TEXT 4:

When the network is very lightly loaded, it is possible to achieve latencies
under 1 ms 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] when a number of further
requirements are met at the same time. One main requirement to achieve such
operation is the absence of handovers between APs (e.g., which may be needed
because of machine/robots moving in a factory). Another requirement 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 PPDU sizes 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). 

Section 4.3 802.11be (Extremely High Throughput)

Comment 5: In July 2020, the IEEE 802.11 TGbe project has divided its work
into so called releases, although the standard will be published once in one
document incorporating the working releases (IEEE 802.11-20/1961r4, “Release
Guidelines: An Overview”, Jan. 2021,
<https://mentor.ieee.org/802.11/dcn/20/11-20-1961-04-00be-release-guidelines
-an-overview.pptx> link). However, the situation as of January 2022 is much
different.

• IEEE P802.11be Rel.1 (Draft P802.11be_D1.31, December 2021) is stable and
almost finalized. Its main features are for increasing throughput (ML
operation, Multi-RU allocation, 320 MHz channel, 4K QAM), however also a
feature for low latency is included (Restricted TWT (rTWT)).

• IEEE 802.11be Rel.2 should have included further features for latency and
reliability enhancement (e.g., integrating TSN extensions for low-latency
real-time traffic), along with 16 spatial streams and simple multi-AP
coordination. However, at the November 2021 IEEE meeting, concerns were
raised on the feasibility to add Rel. 2 features within the planned Wi-Fi 7
standardization timeline and it is not clear whether IEEE Std 802.11be will
contain any Rel.2 feature (see IEEE 802.11-21/1598r1, “Discussion on 11be R2
scope”, Nov. 2021,
<https://mentor.ieee.org/802.11/dcn/21/11-21-1598-01-00be-discussion-on-r2.p
ptx> link, and
<https://mentor.ieee.org/802.11/dcn/21/11-21-1888-02-00be-tgbe-nov-2021-meet
ing-minutes.docx> meeting minutes). Moreover, in the IEEE 802.11 Interim
Meeting in January 2022, new relevant presentations are to be discussed (
<https://mentor.ieee.org/802.11/dcn/21/11-21-1970-00-0wng-agenda-for-wng-sc-
2022-january.pptx> Agenda,
<https://mentor.ieee.org/802.11/dcn/22/11-22-0030-00-0wng-look-ahead-to-next
-generation.pptx> Huawei,
<https://mentor.ieee.org/802.11/dcn/22/11-22-0032-00-0wng-next-gen-after-11b
e.pptx> Broadcom,
<https://mentor.ieee.org/802.11/dcn/22/11-22-0046-01-0wng-next-generation-af
ter-802-11be.pptx> Intel,
<https://mentor.ieee.org/802.11/dcn/22/11-22-0059-00-0wng-beyond-be.pptx>
Qualcomm). By these presentations it seems very likely that there will not
be any significant new features Rel.2 for TGbe. The current belief is that
only minor tweaks and fixes to features in Rel.1 will be incorporated in
Rel.2. Therefore, features like Multi-AP coordination, HARQ, 16 streams and
MIMO enhancements that are currently mentioned in this section can be
removed.

Therefore, propose to rewrite completely Section 4.3 with up-to-date
information.

Typos

There are two typos in the first paragraph of Section 1 Introduction,

1) every packet reaches its destination

2) Deterministic network must be highly predictable

and a third typo in Section 2, Terminology, ARQ,

3)  It is typically avoided in end-to-end on deterministic flows

 

 

 

From: RAW <[email-masked]> On Behalf Of Schooler, Eve M
Sent: den 21 januari 2022 19:23
To: [email-masked]
Cc: [email-masked]
Subject: [Raw] WG Last Call: Technologies draft

Just a reminder, in case you didn't see this rolled into the summary…

We are officially in WGLC ending Jan 31, 2022 for the Reliable & Available
Wireless Technologies internet draft, draft-ietf-raw-technologies.

Rocco and Dave and possibly Janos, please review the references to
technologies in other SDOs, clarifying the references' maturation levels. 

Eve & Rick

-----Original Message-----

From: RAW < <mailto:[email-masked]> [email-masked]> On Behalf Of
Schooler, Eve M

To:  <mailto:[email-masked]> [email-masked]

Cc:  <mailto:[email-masked]> [email-masked]

Hi All, 

Just to let you know we published minutes for the IETF 112, and here is a
link for your enjoyment to peruse:  

<https://datatracker.ietf.org/meeting/112/materials/minutes-112-raw-01.html>
https://datatracker.ietf.org/meeting/112/materials/minutes-112-raw-01.html.

  - The chairs have officially updated milestones for the key documents,
notably several WGLCs upcoming (see below).

  - The authors have split the architecture/framework document into separate
architecture and framework docs

       -  the chairs are exploring options for regular meetings to make
forward progress on these docs

       - Rocco and Dave and possibly Janos to please review the references
to technologies in other SDOs, clarifying the references' maturation levels.

       - WGLC starting now

Please consider this e-mail the official WGLC notice ending Jan 31, 2022 for
the following documents:

  - Technologies

  - Use Cases 

Happiest of Holidays!

Rick & Eve

Eve M. Schooler, PhD

+1 650.868.7369

-- 

RAW mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/raw>
https://www.ietf.org/mailman/listinfo/raw

---

From: "Cavalcanti, Dave" <[email-masked]>
Date: Tue, 25 Jan 2022 01:53:10 +0000

Hi Rocco and all,

Regarding comment 5 on 11be, we could update the text to highlight the relevant features to TSN that have been included in the draft, mainly MLO and rTWT, and remove some of the other features mentioned (HARQ, 16 streams, multi-AP and MIMO enhancements).

I do not agree with the statement about Qbv not being able to operate over Wi-Fi, but I've already addressed these comments. The proposed new text below is inaccurate in several ways.

To help us move forward it, my suggestion at this point is to add a new reference that describes not only the implementation of 802.1AS and 802.1Qbv over Wi-Fi, but also describes 802.1CB over Wi-Fi. All based on standards and NOT proprietary solutions as some of the comments below are implying.

Ref: Juan Fang et al. "Wireless TSN with Multi-radio Wi-Fi", IEEE Conference on Standards for Communications and Networking (CSCN 2021), December 15-17, 2021.

In addition, existing industry standard organizations (e.g. Avnu and other partners) are already defining TSN interop test specs for 802.1AS and Qbv features over wireless including both Wi-Fi and 5G, all based on existing specifications. We can add more references, if it helps.

In summary, my recommendation is to reject the comments 1-4, and if the group is willing to add the new references above, I'll be happy to do it.

Thanks,

Dave

From: RAW <[email-masked]> On Behalf Of Rocco Di Taranto
Sent: Saturday, January 22, 2022 9:02 AM
To: Schooler, Eve M <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Raw] WG Last Call: Technologies draft

Hi Eve,

Thanks for the reminder.

Best Regards,
Rocco Di Taranto

Comment 1: In "Adapting Wired TSN test specifications to testing of Wireless TSN devices" (presented at TSN/A Conference 2021 by Alon Regev, Keysight Technologies) page 12 states that "802.1Qbv functions including schedule & management are defined at the 802.1Q layer, but the 802.11MAC does not have a mapping for these. This limit functionality/performance. P802.11be is addressing these". Therefore, it can be concluded that 802.11Qbv cannot operate on at least Wi-Fi generations prior to 802.11be.
Moreover, to the best of our knowledge, such mentioned support for 802.11Qbv has not been added to IEEE P802.11be, the latest draft is D1.31 draft, published in December 2021.
OLD TEXT 1:
Other 802.1 TSN capabilities such as 802.1Qbv and 802.1CB, which are media agnostic, can already operate over 802.11.
NEW TEXT 1:
Another 802.1 TSN capabilities such as 802.1Qbv and 802.1CB can be combined with 802.11.

Comment 2: The text is not specific and is not true in general for the 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.
OLD TEXT 2:
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.
NEW TEXT 2:
As IEEE 802.11 and IEEE 802.1 TSN are both based on the IEEE 802 architecture, 802.11 devices can directly implement some TSN capabilities without the need for a gateway/translation protocol.

Comment 3: As far as I know, 802.1Qbv has been designed for full duplex media LAN, not for shared media LAN like WLAN.
Moreover, the work in [Sudhakaran2021] only shows that 802.1Qbv capability in Wi-Fi can be enabled through proprietary solutions. Authors clearly state this for example "to enable WTSN, wireless networking is introduced using a Wi-Fi AP and two Wi-Fi stations for each robot. These three wireless nodes are equipped with a WTSN software stack, which extends TSN features into the Wi-Fi domain." Proprietary solutions are not relevant in this document as they are not generally available and not included in the ongoing IEEE P802.11be project either. We propose to remove the text.
OLD TEXT 3:
Some TSN capabilities, such as 802.1Qbv, can already operate over the existing 802.11 MAC/SAP [Sudhakaran2021].
NEW TEXT 3:
Some TSN capabilities, such as 802.1Qbv cannot operate over the existing 802.11MAC/SAP, unless proprietary (non-interoperable nor tested) features are introduced.

Comment 4: 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. More specifically, on order to achieve 1 ms latencies in Wi-Fi 6, the following conditions must be met at the same time:

  1.  Operation in controlled environment.
  2.  Absence of handovers (that may be caused by machine/robots moving in a factory).
  3.  APs awareness of when, and which, STAs have UL traffic to be sent.
  4.  No delays induced by padding in MU UL transmissions.

OLD TEXT 4:
When the network is 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 TEXT 4:
When the network is very lightly loaded, it is possible to achieve latencies under 1 ms 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] when a number of further requirements are met at the same time. One main requirement to achieve such operation is the absence of handovers between APs (e.g., which may be needed because of machine/robots moving in a factory). Another requirement 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 PPDU sizes 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).

Comment 5: In July 2020, the IEEE 802.11 TGbe project has divided its work into so called releases, although the standard will be published once in one document incorporating the working releases (IEEE 802.11-20/1961r4, "Release Guidelines: An Overview", Jan. 2021, link<https://mentor.ieee.org/802.11/dcn/20/11-20-1961-04-00be-release-guidelines-an-overview.pptx>). However, the situation as of January 2022 is much different.
* IEEE P802.11be Rel.1 (Draft P802.11be_D1.31, December 2021) is stable and almost finalized. Its main features are for increasing throughput (ML operation, Multi-RU allocation, 320 MHz channel, 4K QAM), however also a feature for low latency is included (Restricted TWT (rTWT)).
* IEEE 802.11be Rel.2 should have included further features for latency and reliability enhancement (e.g., integrating TSN extensions for low-latency real-time traffic), along with 16 spatial streams and simple multi-AP coordination. However, at the November 2021 IEEE meeting, concerns were raised on the feasibility to add Rel. 2 features within the planned Wi-Fi 7 standardization timeline and it is not clear whether IEEE Std 802.11be will contain any Rel.2 feature (see IEEE 802.11-21/1598r1, "Discussion on 11be R2 scope", Nov. 2021, link<https://mentor.ieee.org/802.11/dcn/21/11-21-1598-01-00be-discussion-on-r2.pptx>, and meeting minutes<https://mentor.ieee.org/802.11/dcn/21/11-21-1888-02-00be-tgbe-nov-2021-meeting-minutes.docx>). Moreover, in the IEEE 802.11 Interim Meeting in January 2022, new relevant presentations are to be discussed (Agenda<https://mentor.ieee.org/802.11/dcn/21/11-21-1970-00-0wng-agenda-for-wng-sc-2022-january.pptx>, Huawei<https://mentor.ieee.org/802.11/dcn/22/11-22-0030-00-0wng-look-ahead-to-next-generation.pptx>, Broadcom<https://mentor.ieee.org/802.11/dcn/22/11-22-0032-00-0wng-next-gen-after-11be.pptx>, Inte<https://mentor.ieee.org/802.11/dcn/22/11-22-0046-01-0wng-next-generation-after-802-11be.pptx>l, Qualcomm<https://mentor.ieee.org/802.11/dcn/22/11-22-0059-00-0wng-beyond-be.pptx>). By these presentations it seems very likely that there will not be any significant new features Rel.2 for TGbe. The current belief is that only minor tweaks and fixes to features in Rel.1 will be incorporated in Rel.2. Therefore, features like Multi-AP coordination, HARQ, 16 streams and MIMO enhancements that are currently mentioned in this section can be removed.
Therefore, propose to rewrite completely Section 4.3 with up-to-date information.

Typos

Cc: [email-masked]<mailto:[email-masked]>

Eve & Rick

-----Original Message-----

Hi All,

       - WGLC starting now

  - Technologies

  - Use Cases

Happiest of Holidays!

Rick & Eve

Eve M. Schooler, PhD

+1 650.868.7369

--

RAW mailing list

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 25 Jan 2022 09:25:25 +0000

Hello Dave:

The changes you propose make a lot of sense in any fashion. My suggestion is that you proceed and commit in github; then Rocco may examine the new text and assess if he still sees an issue. Maybe the result will be acceptable on his side?

Keep safe;

Pascal

From: RAW <[email-masked]> On Behalf Of Cavalcanti, Dave
Sent: mardi 25 janvier 2022 2:53
To: Rocco Di Taranto <rocco.di.taranto=[email-masked]>; Schooler, Eve M <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Raw] WG Last Call: Technologies draft

Hi Rocco and all,

Thanks,

Dave

From: RAW <[email-masked]<mailto:[email-masked]>> On Behalf Of Rocco Di Taranto
Sent: Saturday, January 22, 2022 9:02 AM
To: Schooler, Eve M <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Raw] WG Last Call: Technologies draft

Hi Eve,

Thanks for the reminder.

Best Regards,
Rocco Di Taranto

OLD TEXT 4:

Typos

Eve & Rick

-----Original Message-----

Hi All,

       - WGLC starting now

  - Technologies

  - Use Cases

Happiest of Holidays!

Rick & Eve

Eve M. Schooler, PhD

+1 650.868.7369

--

RAW mailing list

---

From: Janos Farkas <[email-masked]>
Date: Fri, 28 Jan 2022 12:51:49 +0000

Hi,

We suggest to update the 5G section a bit.
What we have in v04 stops at 3GPP Release 16.
In the meantime, Release 17 has been done, which includes further enhancements.
In addition, SA WG2 has approved the work for Release 18 at their last meeting last year.

Please find attached the suggested changes, which reflect the Rel-17 and Rel-18 additions and a few nit fixes.
I have provided the xml to Pascal.

Best regards,
Janos

Eve & Rick

-----Original Message-----

Hi All,

       - WGLC starting now

  - Technologies

  - Use Cases

Happiest of Holidays!

Rick & Eve

Eve M. Schooler, PhD

+1 650.868.7369

--

RAW mailing list