Subject: Re: [Raw] New Version Notification for draft-ietf-raw-technologies-04.txt

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

Dear all:

I pushed that as a result of Rocco and Dave's discussion so you can observe the diffs.
The discussion with Rute is still ongoing.

Keep safe,

Pascal

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: mardi 3 août 2021 12:03
> To: Corinna Schmitt <[email-masked]>; Dave Cavalcanti
> <[email-masked]>; Janos Farkas <[email-masked]>;
> Pascal Thubert (pthubert) <[email-masked]>; Xavier Vilajosana
> <[email-masked]>
> Subject: New Version Notification for draft-ietf-raw-technologies-04.txt
> 
> 
> A new version of I-D, draft-ietf-raw-technologies-04.txt
> has been successfully submitted by Pascal Thubert and posted to the IETF
> repository.
> 
> Name:		draft-ietf-raw-technologies
> Revision:	04
> Title:		Reliable and Available Wireless Technologies
> Document date:	2021-08-03
> Group:		raw
> Pages:		67
> URL:            https://www.ietf.org/archive/id/draft-ietf-raw-
> technologies-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-raw-
> technologies/
> Html:           https://www.ietf.org/archive/id/draft-ietf-raw-
> technologies-04.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-raw-
> technologies
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-raw-
> technologies-04
> 
> Abstract:
>    This document presents a series of recent technologies that are
>    capable of time synchronization and scheduling of transmission,
>    making them suitable to carry time-sensitive flows with high
>    reliability and availability.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Rute Sofia <[email-masked]>
Date: Wed, 4 Aug 2021 09:12:11 +0000

Dear Pascal,

text based on v4 (https://www.ietf.org/archive/id/draft-ietf-raw-technologies-04.txt). In case you want another format, let me know.

1. Introduction ....................................................
- would not capitalize "Deterministic Network"
- "In a real and imperfect world, a Deterministic Network must highly
   predictable, which is a combination of reliability and availability" -- a deterministic network must support high predictability/OR must be able to reach a high level of predictability in terms of the way time-sensitive/critical traffic is to be handled.
- On the one hand...meaning that it SHOULD perform ...
- the type of networks to be handled are heterogeneous. This means that the explanation provided in the intro should consider wired/wireless; wireless/cellular; wireless. In other words: networking environments where SOME segments are wireless (currently written as "wireless physical layer")
- wireless is already reliable and available; so IMO the point is not in making it reliable but in ensuring that the level of reliability that can be provided meets the level that we have with Ethernet/TSN. Again, With Ethernet we have (some) similar issues, and hence TSN 😊.

Proposed text:

   When used in math or philosophy, the term "deterministic" generally
   refers to a perfection where all aspect are understood and
   predictable.  A perfectly deterministic network would ensure that
   every packet reach its destination following a predetermined path
   along a predefined schedule to be delivered at an exact, pre-planned instant in time.
   In a real and imperfect world, a deterministic network must integrate a high level of predictability
, which is a combination of reliability and availability.
   On the one hand, the network must be reliable, meaning that it SHOULD
   perform as expected for all packets and in particular that it MUST
   always deliver the packet at the destination within a pre-configured time interval.  On the
   other hand, the network must be available, meaning that it SHOULD be
   resilient to any single outage, independently of the cause (application, network device, hardware of software, connectivity failure).

   RAW (Reliable and Available Wireless) is an effort to provide
   deterministic networking on across a path that includes wireless network segments. This implies that wireless networks MUST be able to support the strict reliability and availability levels that are currently being provided by applying TSN to wired networking, e.g., Ethernet, PROFINET.  In order to maintain a
   similar quality of service along a multihop path that is composed of
   wired and wireless hops, additional methods that are specific to
   wireless must be leveraged to combat the sources of loss that are
   also specific to wireless.

   Such wireless-specific methods include per-hop retransmissions (Hybrid Automatic Repeat Request, HARQ)
   and P2MP overhearing whereby multiple receivers are scheduled to
   receive the same transmission, which balances the adverse effects of
   the transmission losses that are experienced when a radio is used as
   pure P2P.  Those methods are collectively referred to as Packet
   (hybrid) ARQ, Replication, Elimination and Ordering (PAREO) functions
   in the "Reliable and Available Wireless Architecture/Framework"
   [I-D.ietf-raw-architecture].

The aim of this draft is to bring awareness to scheduling principles that can be used in wireless technologies, to provide a higher degree of availability and reliability in alignment with the standards available in wired networking (TSN). 

2. Terminology ......................................................................
- the introduction is not IMO clear. 
- I propose a few definitions that assist in understanding the document, and that are based on current standards-

Path: 

Deterministic flow: A tuple identified by a stream_handle, and provided by a bridge, in accordance with IEEE 802.1CB. The tuple has at least: <src MAC, dst MAC, VLAN ID, L2 priority>. Continuous streams are characterized by bandwidth and max packet size; scheduled streams are characterized by a repeating pattern of timed transmissions.

Uplink: Connection from end-devices to a data communication equipment. In the context of wireless, uplink refers to the connection between a station and a controller (AP

Downlink: A tuple identified by a stream_handle, and provided by a bridge, in accordance with IEEE 802.1CB. The tuple has at least: <src MAC, dst MAC, VLAN ID, L2 priority>. Continuous streams are characterized by bandwidth and max packet size; scheduled streams are characterized by a repeating pattern of timed transmissions.

Traffic type profile: Corresponds to the traffic classification identifier provided to a deterministic flow. Traffic classes receive an identifier numbered from 0 to 8 (N-1), where N is the number of outbound queues associated with a given Bridge port. Each traffic class as a one-to-ne correspondence with a specific egress/outbound queue for a port.

Reliability:  Reliability is a measure of the probability that an
      item will perform its intended function for a specified interval
      under stated conditions.  For RAW, the service that is expected is
      delivery within a bounded latency and a failure is when the packet
      is either lost or delivered too late. An objective measure concerns the percentage of packets expected to be received within the latency bound.

3. On Scheduling ....................................................
- Time sync is a must for the deterministic, time-aware scheduling. This is not completely handled and I can provide a specific sub-section if this makes sense for a future version. As this seems to be out of scope, here is a proposal for the text.

The operations of a deterministic network often rely on precisely
   applying a tight schedule, in order to avoid collision loss and
   guarantee the worst-case time of delivery.  To achieve this, there
   must be a shared sense of time throughout the network.  The sense of time is provided by time synchronisation mechanisms as defined in IEEE 802.1AS. An example is the Precision Time Protocol. Wireless carries also its time synchronisation mechanisms, e.g., Fine Time Measurement (FTM, IEEE 80211.mc and IEEE 802.1AS) which operate on the MAC Layer. The time synchronisation aspects are out of the scope of this draft and can be further checked in IEEE802.1AS.

3.1 speaks about wired networks, but mentions AP.

3.2, IoT instead of IOT

4. 2. 802.11ax

4.2.1.2 Traffic Isolation via OFDMA Resource Management and Resource Unit Allocation

IEEE 802.11ax relies on the notion of OFDMA Resource Unit (RU) to allocate frequency chunks to different STAs over time. RUs provide a way to allow for multiple stations to transmit simultaneously, starting and ending at the same time. The way this is achieved is via padding, where extra bits are transmitted with the same power level. The current RU allocation algorithms provide a way to achieve traffic isolation per station which while per se does not support time-aware scheduling, is a key aspect to assist reliability, as it provides traffic isolation in a shared medium. Rf. to IEEE802.11be for further and more flexible approaches concerning RU allocation.

Current 4.2.2 - TSN introduction should be done in section 3.1 IMO
- time sync is mentioned, but before has been said that is out of the scope of the draft. IMO this should actually be part of the scope...if this is the case, then I can contribute with a specific section to 3.

4.2.2.2, OFDMA RU was not discussed earlier - but the proposed section I send helps in achieving this.

4.3.2.2 Multi-AP coordination

Multi-AP coordination is one of the main new candidate features in
   802.11be.  It can provide benefits in throughput and capacity and has
   the potential to address some of the issues that impact worst case
   latency and reliability.  Multi-AP coordination is expected to
   address the contention due to overlapping Basic Service Sets (OBSS),
   which is one of the main sources of random latency variations.
   802.11be can define methods to enable better coordination between
   APs, for instance, in a managed network scenario, in order to reduce
   latency due to unmanaged contention.

Overall, multi-AP coordination algorithms consider three different phases: setup (where APs handling overlapping BSSs are assigned roles in a manual or automated way, e.g., coordinator and coordinated APs); coordination (where APs establish links among themselves, e.g., from a coordinating AP to coordinated APs; and then assign resources to served stations); transmission (where the coordinating APs handle transmission opportunities in a "best" way).
 
   Several multi-AP coordination approaches have been discussed with
   different levels of complexities and benefits, but specific
   coordination methods have not yet been defined. Out of the different categories, we cite as MAC-driven examples: coordinated OFDMA (Co-OFDMA); Coordinated TDMA (Co-TDMA); HARQ; as PHY-driven examples: Coordinated Spatial Reuse (Co-SR) and Coordinated Beamforming (Co-BF).

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
F: +49 (89) 3603522 50
[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
-----Original Message-----
From: RAW <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: 03 August 2021 13:08
To: Rocco Di Taranto <rocco.di.taranto=[email-masked]>; Corinna Schmitt <[email-masked]>; Dave Cavalcanti <[email-masked]>; Janos Farkas <[email-masked]>; Xavier Vilajosana <[email-masked]>
Cc: [email-masked]
Subject: Re: [Raw] New Version Notification for draft-ietf-raw-technologies-04.txt

Dear all:

Keep safe,

Pascal

> has been successfully submitted by Pascal Thubert and posted to the 
> IETF repository.
> 

--
RAW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/raw

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 Aug 2021 14:31:42 +0000

Dear Rute, Rocco, and Dave

Please check the diffs I made to Rute's points in
https://github.com/raw-wg/raw-technologies/commit/71bce5e8ebc9c8455a92eb02fcc54d88659e5873

I did not push another version, would like to ensure that we're in sync between Dave, Rute, and Rocco.

Rute: Many thanks for your comments! 

But then, and same with Rocco, I'm getting quite crazy trying to figure out what words you added or removed in the middle of sentences, and what is all new proposed text. 

Presented as you did makes my life of editor very hard and wastes a lot of time. Can you please, next time, suggest additions changes or deletion with a clear indication of exactly what is added removed or changed?

> text based on v4 (https://www.ietf.org/archive/id/draft-ietf-raw-
> technologies-04.txt). In case you want another format, let me know.
> 

Changed. I guess we need to at some places though in the intro I agree with you. The rationale would be that the upper case follows DetNet terminology (See https://datatracker.ietf.org/doc/html/rfc8655#section-4.1.2 whereas lowercase is abstract, which is the case in the intro.

>    predictable, which is a combination of reliability and availability" --
> a deterministic network must support high predictability/OR must be able
> to reach a high level of predictability in terms of the way time-
> sensitive/critical traffic is to be handled.

> - On the one hand...meaning that it SHOULD perform ...

I'm looking for something stronger. Why not " for all -but very few- packets "

This results in
"
   On the one hand the network must be reliable, meaning that it
   will perform as expected for all but very few packets and in particular
   that it will deliver the packets at the destination in due time.
"

> - the type of networks to be handled are heterogeneous. This means that
> the explanation provided in the intro should consider wired/wireless;
> wireless/cellular; wireless. In other words: networking environments where
> SOME segments are wireless (currently written as "wireless physical
> layer")

That was effectively the intention. I used your text.

> - wireless is already reliable and available; so IMO the point is not in
> making it reliable but in ensuring that the level of reliability that can
> be provided meets the level that we have with Ethernet/TSN. Again, With
> Ethernet we have (some) similar issues, and hence TSN 😊.
> 

True, and that's the point of the whole spec. Now how close we'll approach TSN is a mater of debate a resources. So it's hard in the introduction to set the expectation to exactly TSN. Also we're L3 so we compare to DetNet over wire rather than TSN, and then leverage L2 technologies that compare to TSN. I'm happy with the change above to convey that. Works?

>    In a real and imperfect world, a deterministic network must integrate a
> high level of predictability , which is a combination of reliability and
> availability.
>    resilient to any single outage, independently of the cause
> (application, network device, hardware of software, connectivity failure).
> 

Rute, as I said it is hard to diff out the pieces I'd like to keep and those I would not, same problem as with Rocco's comments. 

Please note: this is an informational doc, wo we do not mandate stuff and are not using uppercase (MUST) BCP 14-type of text. So it's not like I will necessarily take everything as you propose it.

Certainly I picked some of your proposed rewording, but maybe I lost important things in the process reading both side to figure the difference you suggested.

>    deterministic networking on across a path that includes wireless
> network segments. This implies that wireless networks MUST be able to
> support the strict reliability and availability levels that are currently
> being provided by applying TSN to wired networking, e.g., Ethernet,
> PROFINET.  In order to maintain a
> The aim of this draft is to bring awareness to scheduling principles that
> can be used in wireless technologies, to provide a higher degree of
> availability and reliability in alignment with the standards available in
> wired networking (TSN).
> 
> 
> 2. Terminology
> ......................................................................

Path is defined in many places and sometimes contradicting what we need (usually it is defined as serial). Rather than overloading it, I'd rather use the term Track. I copied a shorter definitions for Track from the RAW architecture, and use it for RAW "paths".

> 
> Deterministic flow: A tuple identified by a stream_handle, and provided by
> a bridge, in accordance with IEEE 802.1CB. The tuple has at least: <src
> MAC, dst MAC, VLAN ID, L2 priority>. Continuous streams are characterized
> by bandwidth and max packet size; scheduled streams are characterized by a
> repeating pattern of timed transmissions.

Picked 

> 
> Uplink: Connection from end-devices to a data communication equipment. In
> the context of wireless, uplink refers to the connection between a station
> and a controller (AP

Picked

> 
> Downlink: A tuple identified by a stream_handle, and provided by a bridge,
> in accordance with IEEE 802.1CB. The tuple has at least: <src MAC, dst
> MAC, VLAN ID, L2 priority>. Continuous streams are characterized by
> bandwidth and max packet size; scheduled streams are characterized by a
> repeating pattern of timed transmissions.

???

> 
> Traffic type profile: Corresponds to the traffic classification identifier
> provided to a deterministic flow. Traffic classes receive an identifier
> numbered from 0 to 8 (N-1), where N is the number of outbound queues
> associated with a given Bridge port. Each traffic class as a one-to-ne
> correspondence with a specific egress/outbound queue for a port.

Used, indicating IEEE
>       is either lost or delivered too late. An objective measure concerns
> the percentage of packets expected to be received within the latency
> bound.

I see that you added the last sentence; see my mail to Greg yesterday, there's a lot more in RAW than loss ratio. I'd rather remain silent here

> - Time sync is a must for the deterministic, time-aware scheduling. This
> is not completely handled and I can provide a specific sub-section if this
> makes sense for a future version. As this seems to be out of scope, here
> is a proposal for the text.
> 
>    must be a shared sense of time throughout the network.  The sense of
> time is provided by time synchronisation mechanisms as defined in IEEE
> 802.1AS. An example is the Precision Time Protocol. Wireless carries also
> its time synchronisation mechanisms, e.g., Fine Time Measurement (FTM,
> IEEE 80211.mc and IEEE 802.1AS) which operate on the MAC Layer. The time
> synchronisation aspects are out of the scope of this draft and can be
> further checked in IEEE802.1AS.

This is specific to Wi-Fi. In that section we are still tech agnostic.

I added a more generic variation taking it as example. You'll note that section 4 is very verbose on the matter already, I do not see a need to say more for IETF consumption.

"
    As an example, the Precision Time Protocol, standardized as
   IEEE 1588 and IEC 61588, has mapping to Ethernet but also to a number of
   industrial and Smartgrid protocols through profiles. Wi-Fi relies on
   IEEE Std 802.1AS, which incorporates a PTP profile, for Fine Timing    
   Measurement.
"
> 3.1 speaks about wired networks, but mentions AP.

Yes, that text was really common. I restructured.

> 3.2, IoT instead of IOT

done
> 4. 2. 802.11ax

? Do you wish to remove HE?

> IEEE 802.11ax relies on the notion of OFDMA Resource Unit (RU) to allocate
> frequency chunks to different STAs over time. RUs provide a way to allow
> for multiple stations to transmit simultaneously, starting and ending at
> the same time. The way this is achieved is via padding, where extra bits
> are transmitted with the same power level. The current RU allocation
> algorithms provide a way to achieve traffic isolation per station which
> while per se does not support time-aware scheduling, is a key aspect to
> assist reliability, as it provides traffic isolation in a shared medium.
> Rf. to IEEE802.11be for further and more flexible approaches concerning RU
> allocation.

? I read that as a proposed new section?

> - time sync is mentioned, but before has been said that is out of the
> scope of the draft. IMO this should actually be part of the scope...if
> this is the case, then I can contribute with a specific section to 3.

Time sync is out of scope for the RAW work but not for this document. This document describes work done outside of RAW, including L2 where time sync is effectively achieved, so talking about it here is OK. But talking about IEEE 802.1 / 802.11 specific stuff should stay in this section not 3. I'm happy with the text in section 4 intro.

> send helps in achieving this.

Yes, I picked it. RUs come back later in the doc 

> Overall, multi-AP coordination algorithms consider three different phases:
> setup (where APs handling overlapping BSSs are assigned roles in a manual
> or automated way, e.g., coordinator and coordinated APs); coordination
> (where APs establish links among themselves, e.g., from a coordinating AP
> to coordinated APs; and then assign resources to served stations);
> transmission (where the coordinating APs handle transmission opportunities
> in a "best" way).
> 

Incorporated. Then again quoting what is unchanged and tagging what is proposed addition would make my day

>    coordination methods have not yet been defined. Out of the different
> categories, we cite as MAC-driven examples: coordinated OFDMA (Co-OFDMA);
> Coordinated TDMA (Co-TDMA); HARQ; as PHY-driven examples: Coordinated
> Spatial Reuse (Co-SR) and Coordinated Beamforming (Co-BF).
> 

Added...

Again, many thanks Rute!

Pascal
> 
> 
> 
> 
> 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
> 
> Geschäftsführer: Dr. Harald Rueß, Thomas Vallon Vorsitzender des
> Aufsichtsrats: Dr. Manfred Wolter -----Original Message-----
> To: Rocco Di Taranto <rocco.di.taranto=[email-masked]>;
> Corinna Schmitt <[email-masked]>; Dave Cavalcanti
> Xavier Vilajosana <[email-masked]>
> Cc: [email-masked]

---

From: Rute Sofia <[email-masked]>
Date: Wed, 11 Aug 2021 13:05:34 +0000

Hi Pascal

The best way would be to edit directly but I am not sure you want this. Sure, for a next time I can also provide you with some different text, e.g., capitalizing

This does not seem to be working?

Rute

Dr. Rute Sofia
Head of Competence Field

fortiss GmbH

T: +49 (89) 3603522 170
F: +49 (89) 3603522 50
[email-masked]
https://www.fortiss.org/

-----Original Message-----
From: RAW <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: 05 August 2021 16:32
To: Rute Sofia <[email-masked]>; Dave Cavalcanti <[email-masked]>; Rocco Di Taranto <[email-masked]>
Cc: [email-masked]; Corinna Schmitt <[email-masked]>; Xavier Vilajosana <[email-masked]>; Janos Farkas <[email-masked]>
Subject: Re: [Raw] New Version Notification for draft-ietf-raw-technologies-04.txt

>    predictable, which is a combination of reliability and 
> availability" -- a deterministic network must support high 
> predictability/OR must be able to reach a high level of predictability 
> in terms of the way time- sensitive/critical traffic is to be handled.

This results in
"

> - the type of networks to be handled are heterogeneous. This means 
> that the explanation provided in the intro should consider 
> wired/wireless; wireless/cellular; wireless. In other words: 
> networking environments where SOME segments are wireless (currently 
> written as "wireless physical
> layer")

> - wireless is already reliable and available; so IMO the point is not 
> in making it reliable but in ensuring that the level of reliability 
> that can be provided meets the level that we have with Ethernet/TSN. 
> Again, With Ethernet we have (some) similar issues, and hence TSN 😊.
> 

>    In a real and imperfect world, a deterministic network must 
> integrate a high level of predictability , which is a combination of 

> support the strict reliability and availability levels that are 
> currently being provided by applying TSN to wired networking, e.g., 
> Ethernet, PROFINET.  In order to maintain a
> The aim of this draft is to bring awareness to scheduling principles 
> that can be used in wireless technologies, to provide a higher degree 
> of availability and reliability in alignment with the standards 
> available in wired networking (TSN).
> 
> 
> 2. Terminology
> - I propose a few definitions that assist in understanding the 
> document, and that are based on current standards-
> 
> Path:

> 
> Deterministic flow: A tuple identified by a stream_handle, and 
> provided by a bridge, in accordance with IEEE 802.1CB. The tuple has 
> at least: <src MAC, dst MAC, VLAN ID, L2 priority>. Continuous streams 
> are characterized by bandwidth and max packet size; scheduled streams 
> are characterized by a repeating pattern of timed transmissions.

Picked 

> 
> Uplink: Connection from end-devices to a data communication equipment. 
> In the context of wireless, uplink refers to the connection between a 
> station and a controller (AP

Picked

> 
> Downlink: A tuple identified by a stream_handle, and provided by a 
> bridge, in accordance with IEEE 802.1CB. The tuple has at least: <src 
> MAC, dst MAC, VLAN ID, L2 priority>. Continuous streams are 
> characterized by bandwidth and max packet size; scheduled streams are 
> characterized by a repeating pattern of timed transmissions.

???

> 
> Traffic type profile: Corresponds to the traffic classification 
> identifier provided to a deterministic flow. Traffic classes receive 
> an identifier numbered from 0 to 8 (N-1), where N is the number of 
> outbound queues associated with a given Bridge port. Each traffic 
> class as a one-to-ne correspondence with a specific egress/outbound queue for a port.

Used, indicating IEEE
>       is either lost or delivered too late. An objective measure 
> concerns the percentage of packets expected to be received within the 
> latency bound.

> - Time sync is a must for the deterministic, time-aware scheduling. 
> This is not completely handled and I can provide a specific 
> sub-section if this makes sense for a future version. As this seems to 
> be out of scope, here is a proposal for the text.
> 
>    must be a shared sense of time throughout the network.  The sense 
> of time is provided by time synchronisation mechanisms as defined in 
> IEEE 802.1AS. An example is the Precision Time Protocol. Wireless 
> carries also its time synchronisation mechanisms, e.g., Fine Time 
> Measurement (FTM, IEEE 80211.mc and IEEE 802.1AS) which operate on the 
> MAC Layer. The time synchronisation aspects are out of the scope of 
> this draft and can be further checked in IEEE802.1AS.

"

done

> IEEE 802.11ax relies on the notion of OFDMA Resource Unit (RU) to 
> allocate frequency chunks to different STAs over time. RUs provide a 
> way to allow for multiple stations to transmit simultaneously, 
> starting and ending at the same time. The way this is achieved is via 
> padding, where extra bits are transmitted with the same power level. 
> The current RU allocation algorithms provide a way to achieve traffic 
> isolation per station which while per se does not support time-aware 
> scheduling, is a key aspect to assist reliability, as it provides traffic isolation in a shared medium.
> Rf. to IEEE802.11be for further and more flexible approaches 
> concerning RU allocation.

> setup (where APs handling overlapping BSSs are assigned roles in a 
> manual or automated way, e.g., coordinator and coordinated APs); 
> coordination (where APs establish links among themselves, e.g., from a 
> coordinating AP to coordinated APs; and then assign resources to 
> served stations); transmission (where the coordinating APs handle 
> transmission opportunities in a "best" way).
> 

>    coordination methods have not yet been defined. Out of the 
> different categories, we cite as MAC-driven examples: coordinated 
> OFDMA (Co-OFDMA); Coordinated TDMA (Co-TDMA); HARQ; as PHY-driven 
> examples: Coordinated Spatial Reuse (Co-SR) and Coordinated Beamforming (Co-BF).
> 

Added...

Again, many thanks Rute!

Pascal
> > <[email-masked]>; Janos Farkas 
> > <[email-masked]>; Pascal Thubert (pthubert) 
> > <[email-masked]>; Xavier Vilajosana <[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Aug 2021 13:26:01 +0000

Hello Rute

You may for instance create your fork of the github repo below, and propose a pull request with proposed changes.
I can then review the diffs, selectively accept the changes or amend them.

That would certainly work.

Keep safe

Pascal

> From: RAW <[email-masked]> On Behalf Of Rute Sofia
> Sent: mercredi 11 août 2021 15:06
> To: Pascal Thubert (pthubert) <pthubert=[email-masked]>; Dave
> Cavalcanti <[email-masked]>; Rocco Di Taranto
> <[email-masked]>
> Cc: [email-masked]; Corinna Schmitt <[email-masked]>; Xavier
> Vilajosana <[email-masked]>; Janos Farkas <[email-masked]>
> The best way would be to edit directly but I am not sure you want this.
> Sure, for a next time I can also provide you with some different text,
> e.g., capitalizing
> 
> https://github.com/raw-wg/raw-
> technologies/commit/71bce5e8ebc9c8455a92eb02fcc54d88659e5873
> 
> To: Rute Sofia <[email-masked]>; Dave Cavalcanti
> <[email-masked]>; Rocco Di Taranto
> <[email-masked]>
> Cc: [email-masked]; Corinna Schmitt <[email-masked]>; Xavier
> Vilajosana <[email-masked]>; Janos Farkas <[email-masked]>
> https://github.com/raw-wg/raw-
> technologies/commit/71bce5e8ebc9c8455a92eb02fcc54d88659e5873
> 
> But then, and same with Rocco, I'm getting quite crazy trying to figure
> out what words you added or removed in the middle of sentences, and what
> is all new proposed text.
> 
> Presented as you did makes my life of editor very hard and wastes a lot of
> time. Can you please, next time, suggest additions changes or deletion
> with a clear indication of exactly what is added removed or changed?
> 
> 
> Changed. I guess we need to at some places though in the intro I agree
> with you. The rationale would be that the upper case follows DetNet
> terminology (See https://datatracker.ietf.org/doc/html/rfc8655#section-
> 4.1.2 whereas lowercase is abstract, which is the case in the intro.
> 
> 
> True, and that's the point of the whole spec. Now how close we'll approach
> TSN is a mater of debate a resources. So it's hard in the introduction to
> set the expectation to exactly TSN. Also we're L3 so we compare to DetNet
> over wire rather than TSN, and then leverage L2 technologies that compare
> to TSN. I'm happy with the change above to convey that. Works?
> 
> 
> > Proposed text:
> >
> >
> Rute, as I said it is hard to diff out the pieces I'd like to keep and
> those I would not, same problem as with Rocco's comments.
> 
> Please note: this is an informational doc, wo we do not mandate stuff and
> are not using uppercase (MUST) BCP 14-type of text. So it's not like I
> will necessarily take everything as you propose it.
> 
> Certainly I picked some of your proposed rewording, but maybe I lost
> important things in the process reading both side to figure the difference
> you suggested.
> 
> Path is defined in many places and sometimes contradicting what we need
> (usually it is defined as serial). Rather than overloading it, I'd rather
> use the term Track. I copied a shorter definitions for Track from the RAW
> architecture, and use it for RAW "paths".
> 
> >
> I see that you added the last sentence; see my mail to Greg yesterday,
> there's a lot more in RAW than loss ratio. I'd rather remain silent here
> 
> >
> >
> >
> I added a more generic variation taking it as example. You'll note that
> section 4 is very verbose on the matter already, I do not see a need to
> say more for IETF consumption.
> 
> "
> Time sync is out of scope for the RAW work but not for this document. This
> document describes work done outside of RAW, including L2 where time sync
> is effectively achieved, so talking about it here is OK. But talking about
> IEEE 802.1 / 802.11 specific stuff should stay in this section not 3. I'm
> happy with the text in section 4 intro.
> 
> 
> >

---

From: Rute Sofia <[email-masked]>
Date: Wed, 11 Aug 2021 13:57:13 +0000

Pascal

For a next time right? Can you please send the URL with the modified version?

BR
Rute

Dr. Rute Sofia
Head of Competence Field

fortiss GmbH

T: +49 (89) 3603522 170
F: +49 (89) 3603522 50
[email-masked]
https://www.fortiss.org/

-----Original Message-----
From: RAW <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: 11 August 2021 15:26
To: Rute Sofia <[email-masked]>; Pascal Thubert (pthubert) <pthubert=[email-masked]>; Dave Cavalcanti <[email-masked]>; Rocco Di Taranto <[email-masked]>
Cc: [email-masked]; Corinna Schmitt <[email-masked]>; Xavier Vilajosana <[email-masked]>; Janos Farkas <[email-masked]>
Subject: Re: [Raw] New Version Notification for draft-ietf-raw-technologies-04.txt

Hello Rute

Keep safe

Pascal

> To: Pascal Thubert (pthubert) <pthubert=[email-masked]>; 
> Dave Cavalcanti <[email-masked]>; Rocco Di Taranto 
> But then, and same with Rocco, I'm getting quite crazy trying to 
> figure out what words you added or removed in the middle of sentences, 
> and what is all new proposed text.
> 
> Presented as you did makes my life of editor very hard and wastes a 
> lot of time. Can you please, next time, suggest additions changes or 
> deletion with a clear indication of exactly what is added removed or changed?
> 
> 
> terminology (See 
> https://datatracker.ietf.org/doc/html/rfc8655#section-
> > predictability/OR must be able to reach a high level of 
> > predictability in terms of the way time- sensitive/critical traffic is to be handled.
> 
> 
> 
> > - wireless is already reliable and available; so IMO the point is 
> > not in making it reliable but in ensuring that the level of 
> > reliability that can be provided meets the level that we have with Ethernet/TSN.
> True, and that's the point of the whole spec. Now how close we'll 
> approach TSN is a mater of debate a resources. So it's hard in the 
> introduction to set the expectation to exactly TSN. Also we're L3 so 
> we compare to DetNet over wire rather than TSN, and then leverage L2 
> technologies that compare to TSN. I'm happy with the change above to convey that. Works?
> 
> 
> > Proposed text:
> >
> >
> Please note: this is an informational doc, wo we do not mandate stuff 
> and are not using uppercase (MUST) BCP 14-type of text. So it's not 
> like I will necessarily take everything as you propose it.
> 
> important things in the process reading both side to figure the 
> difference you suggested.
> 
> > network segments. This implies that wireless networks MUST be able 
> > to support the strict reliability and availability levels that are 
> > that can be used in wireless technologies, to provide a higher 
> > degree of availability and reliability in alignment with the 
> > standards available in wired networking (TSN).
> >
> >
> > 2. Terminology
> Path is defined in many places and sometimes contradicting what we 
> need (usually it is defined as serial). Rather than overloading it, 
> I'd rather use the term Track. I copied a shorter definitions for 
> Track from the RAW architecture, and use it for RAW "paths".
> 
> >
> > at least: <src MAC, dst MAC, VLAN ID, L2 priority>. Continuous 
> > streams are characterized by bandwidth and max packet size; 
> > scheduled streams are characterized by a repeating pattern of timed transmissions.
> 
> Picked
> 
> >
> > In the context of wireless, uplink refers to the connection between 
> > a station and a controller (AP
> 
> Picked
> 
> >
> > bridge, in accordance with IEEE 802.1CB. The tuple has at least: 
> > <src MAC, dst MAC, VLAN ID, L2 priority>. Continuous streams are 
> > characterized by bandwidth and max packet size; scheduled streams 
> > concerns the percentage of packets expected to be received within 
> > the latency bound.
> 
> > sub-section if this makes sense for a future version. As this seems 
> > to be out of scope, here is a proposal for the text.
> >
> > Measurement (FTM, IEEE 80211.mc and IEEE 802.1AS) which operate on 
> > the MAC Layer. The time synchronisation aspects are out of the scope 
> > of this draft and can be further checked in IEEE802.1AS.
> 
> I added a more generic variation taking it as example. You'll note 
> that section 4 is very verbose on the matter already, I do not see a 
> need to say more for IETF consumption.
> 
> "
> > starting and ending at the same time. The way this is achieved is 
> > via padding, where extra bits are transmitted with the same power level.
> > The current RU allocation algorithms provide a way to achieve 
> > traffic isolation per station which while per se does not support 
> > time-aware scheduling, is a key aspect to assist reliability, as it 
> > provides
> traffic isolation in a shared medium.
> > - time sync is mentioned, but before has been said that is out of 
> > the scope of the draft. IMO this should actually be part of the 
> > scope...if this is the case, then I can contribute with a specific section to 3.
> 
> Time sync is out of scope for the RAW work but not for this document. 
> This document describes work done outside of RAW, including L2 where 
> time sync is effectively achieved, so talking about it here is OK. But 
> talking about IEEE 802.1 / 802.11 specific stuff should stay in this 
> section not 3. I'm happy with the text in section 4 intro.
> 
> 
> >
> > coordination (where APs establish links among themselves, e.g., from 
> > a coordinating AP to coordinated APs; and then assign resources to 
> > examples: Coordinated Spatial Reuse (Co-SR) and Coordinated 
> > Beamforming
> (Co-BF).
> >
> 
> Added...
> 
> Again, many thanks Rute!
> 
> Pascal
> >
> >
> >
> >
> > Best Regards,
> > Rute
> >
> >
> >
> >
> >
> > Dr. Rute Sofia
> > Head of Competence Field
> >
> >
> > fortiss GmbH
> > To: Rocco Di Taranto 
> > <rocco.di.taranto=[email-masked]>;
> > <[email-masked]>; Xavier Vilajosana <[email-masked]>
> > Cc: [email-masked]
> > > has been successfully submitted by Pascal Thubert and posted to 
> > > the IETF repository.
> > >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Aug 2021 14:22:39 +0000

You lost me Rute

The URL you copied in your mail points in the main repo with the latest text. The repo is this https://github.com/raw-wg/raw-technologies. There's a link to the txt file.

When you pull or fork that, you'll see the changes I already made based on your comments.

If you scroll down https://github.com/raw-wg/raw-technologies/commit/71bce5e8ebc9c8455a92eb02fcc54d88659e5873 you'll see the diffs in the xml, and the diffs in the txt will be omitted because too large, but you can get them to, or run rfcdiff https://tools.ietf.org/tools/rfcdiff/

Keep safe,

Pascal

> From: Rute Sofia <[email-masked]>
> Sent: mercredi 11 août 2021 15:57
> To: Pascal Thubert (pthubert) <[email-masked]>; Dave Cavalcanti
> Subject: RE: New Version Notification for draft-ietf-raw-technologies-
> 04.txt
> 
> Pascal
> 
> To: Rute Sofia <[email-masked]>; Pascal Thubert (pthubert)
> <pthubert=[email-masked]>; Dave Cavalcanti
> You may for instance create your fork of the github repo below, and
> propose a pull request with proposed changes.

---

From: Rute Sofia <[email-masked]>
Date: Wed, 11 Aug 2021 14:31:26 +0000

Pascal

The issue is not how git works - that is clear. Neither how to update a draft nor an RFC. That is also clear to me.

The issue is that your URL for the latest commit gives a 404 - can you pl just confirm the URL?

My question was also: is my text integrated on this last URL or NOT? So that I can understand what needs to be done.

Rute

Dr. Rute Sofia
Head of Competence Field

fortiss GmbH

T: +49 (89) 3603522 170
F: +49 (89) 3603522 50
[email-masked]
https://www.fortiss.org/

-----Original Message-----
From: RAW <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: 11 August 2021 16:23
To: Rute Sofia <[email-masked]>; Dave Cavalcanti <[email-masked]>; Rocco Di Taranto <[email-masked]>
Cc: [email-masked]; Corinna Schmitt <[email-masked]>; Xavier Vilajosana <[email-masked]>; Janos Farkas <[email-masked]>
Subject: Re: [Raw] New Version Notification for draft-ietf-raw-technologies-04.txt

You lost me Rute

Keep safe,

Pascal

> > Sure, for a next time I can also provide you with some different 
> > text, e.g., capitalizing
> >
> > figure out what words you added or removed in the middle of 
> > sentences, and what is all new proposed text.
> >
> > Changed. I guess we need to at some places though in the intro I 
> > agree with you. The rationale would be that the upper case follows 
> > DetNet terminology (See
> > > predictability in terms of the way time- sensitive/critical 
> > > traffic is
> to be handled.
> >
> >
> >
> > > networking environments where SOME segments are wireless 
> > > (currently written as "wireless physical
> > > layer")
> >
> > > integrate a high level of predictability , which is a combination 
> > > of reliability and availability.
> > >    other hand, the network must be available, meaning that it 
> > > SHOULD
> be
> > Rute, as I said it is hard to diff out the pieces I'd like to keep 
> > and those I would not, same problem as with Rocco's comments.
> >
> > Please note: this is an informational doc, wo we do not mandate 
> > stuff and are not using uppercase (MUST) BCP 14-type of text. So 
> > it's not like I will necessarily take everything as you propose it.
> >
> > >    deterministic networking on across a path that includes 
> > > wireless network segments. This implies that wireless networks 
> > > MUST be able to support the strict reliability and availability 
> > > levels that are currently being provided by applying TSN to wired 
> > > networking, e.g., Ethernet, PROFINET.  In order to maintain a
> > >    similar quality of service along a multihop path that is 
> > > composed
> of
> > >    receive the same transmission, which balances the adverse 
> > > effects
> of
> > >    the transmission losses that are experienced when a radio is 
> > > used
> as
> > > The aim of this draft is to bring awareness to scheduling 
> > > principles that can be used in wireless technologies, to provide a 
> > > higher degree of availability and reliability in alignment with 
> > > the standards available in wired networking (TSN).
> > >
> > >
> > > 2. Terminology
> > > provided by a bridge, in accordance with IEEE 802.1CB. The tuple 
> > > has at least: <src MAC, dst MAC, VLAN ID, L2 priority>. Continuous 
> > > scheduled streams are characterized by a repeating pattern of 
> > > timed
> transmissions.
> >
> > Picked
> >
> > >
> > > In the context of wireless, uplink refers to the connection 
> > > between a station and a controller (AP
> >
> > Picked
> >
> > >
> > > identifier provided to a deterministic flow. Traffic classes 
> > > receive an identifier numbered from 0 to 8 (N-1), where N is the 
> > > number of outbound queues associated with a given Bridge port. 
> > > Each traffic class as a one-to-ne correspondence with a specific 
> > > egress/outbound
> > queue for a port.
> >
> > Used, indicating IEEE
> > >
> > >       under stated conditions.  For RAW, the service that is 
> > > expected
> is
> > I see that you added the last sentence; see my mail to Greg 
> > yesterday, there's a lot more in RAW than loss ratio. I'd rather 
> > remain silent here
> >
> > >
> > >
> > >
> > > sub-section if this makes sense for a future version. As this 
> > > seems to be out of scope, here is a proposal for the text.
> > >
> > >    must be a shared sense of time throughout the network.  The 
> > > sense of time is provided by time synchronisation mechanisms as 
> > > defined in IEEE 802.1AS. An example is the Precision Time 
> > > Protocol. Wireless carries also its time synchronisation 
> > > mechanisms, e.g., Fine Time Measurement (FTM, IEEE 80211.mc and 
> > > IEEE 802.1AS) which operate on the MAC Layer. The time 
> > > synchronisation aspects are out of the scope of this draft and can be further checked in IEEE802.1AS.
> >
> > > allocate frequency chunks to different STAs over time. RUs provide 
> > > a way to allow for multiple stations to transmit simultaneously, 
> > > time-aware scheduling, is a key aspect to assist reliability, as 
> > > it provides
> > time sync is effectively achieved, so talking about it here is OK. 
> > But talking about IEEE 802.1 / 802.11 specific stuff should stay in 
> > this section not 3. I'm happy with the text in section 4 intro.
> >
> >
> > >
> > >    802.11be.  It can provide benefits in throughput and capacity 
> > > and
> has
> > > coordination (where APs establish links among themselves, e.g., 
> > > from a coordinating AP to coordinated APs; and then assign 
> > > resources to served stations); transmission (where the 
> > > coordinating APs handle transmission opportunities in a "best" way).
> > >
> >
> > > Landesforschungsinstitut des Freistaats Bayern für 
> > > softwareintensive Systeme An-Institut Technische Universität 
> > > München
> > >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Aug 2021 14:50:02 +0000

That’s why you lost me!!! I could not figure what the problem was access. I made the repo public. The link should work for all.

The link shows my additions from your mail. I may have missed stuff. In my response you can see what I accepted and that should be in.

Also I invited you so you get write access but I’d rather you fork.

Regards,

Pascal

> Le 11 août 2021 à 16:31, Rute Sofia <[email-masked]> a écrit :
> 
> Pascal
>