Subject: Re: [Raw] Montréal and Chartering

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 May 2019 13:20:45 +0000

Agreed: let’s look at the charter

What we have right now is:

        3) Produce a Standards Track document to define the generic data models
           to install a RAW flow along a track providing packet replication,
           elimination and ordering functions with spatial, frequency and time
           diversity in a scheduled FD/TDMA wireless network.

We could change it to:

        3) Produce a Standards Track document to define a generic data model
           to install a RAW flow along a Track in a scheduled wireless network.
           The data model will describe extended DetNet Service Functions such
           as Packet ARQ, Replication, Elimination and Ordering functions, which
           require the logical correlation of one or more receptions with one or
           more transmissions. It will also enable to commit resources in the
           network and request diversity in the spatial, frequency and time
           domains. Programming the specifics of how a particular technology
           schedules its resources is a non-goal and often the object of a local
           optimization within the technology.

All the best,

Pascal

From: Xavi Vilajosana Guillen <[email-masked]>
Sent: vendredi 3 mai 2019 11:00
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; Lou Berger ([email-masked]) <[email-masked]>
Subject: Re: [Raw] Montreal and Chartering

Hi Pascal,

I am in favour of going through the generic model (we could consider and see how URLLC, EHT (11ax/be) flows are managed) and extend to 6TiSCH later when having addressed the 2-hop gaming scenarios with EHT.

Our experience says that the charter should be focused and concise.

regards
Xavi

Missatge de Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> del dia dj., 2 de maig 2019 a les 18:13:
Dear all:

It’s probaly time to start preparing for a WG forming both in Montreal. The key element will be the proposed charter. It must justify a group but not attempt to boil the ocean.

Though the BoF in Prague went really well, there was an uncertainty in the end on what we should aim for I the charter, that Lou expressed in a question.

       Lou: You clarified what 6TiSCH does, can you clarify what PAW is to do?
       Pascal: We expect this group to complete the dot of the 6TiSCH architecture, which describes both stochastic and deterministic flows. But 6TiSCH WG was focused on stochastic flows, and we expected to inherit from the work of detnet for deterministic flows. As we thought about it we decided to disband 6TiSCH and start a new group to do the deterministic part since 6TiSCH was not the right group to do it.
       * Lou: would be good to clarify if this is going to be deterministic for 6TiSCH or for other type of radios.
       * Pascal: Not just for 6TiSCH. Another reason that 6TiSCH is not appropriate for this work is that we want to extend the work to other radio technologies. We are presenting here four different radio technologies that we are addressing.

Basically there is a duality: trying to adapt/extend DetNet and CCAMP to a generic scheduled wireless network in the one hand, and providing data models to program a deterministic track, which is an ask that we got at 6TISCH but does not generalize well to other radios. The difference is that on EHT and URLLC we do not program the physical resources (e.g., a resource block), but in all cases we ask for a guaranteed periodic resource to perform on hop, and then we assemble the hops with DetNet.

6TiSCH is special because we could configure down to the time slot, and use the time slot in/out as a G-MPLS switching resource..

Seems to me that we could separate the G-MPLS piece as an extension to what we’d do on all radios, that is program a periodic resource for a flow identified by a flow ID in the packet. A 6TiSCH-specific draft could then explain how the PCE can program the timeslots and use that to elide the flow ID, in which case this is only a variation of the generic model that we’d define, a sort of compression. We can even leave it off charter on the first round if the charter seems confused or too greedy otherwise.

What do you think?

Pascal
--
Raw mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/raw

--
Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
[email-masked]<mailto:[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu

Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

[Universitat Oberta de Catalunya]  [https://ferranadelantado.files.wordpress.com/2014/05/wine_logo_small2-e1453363995864.png?w=330&h=123]

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Fri, 3 May 2019 20:01:34 +0000

Hi Pascal,
I like the charter changes below, as we are starting to make a clearer delineation between what is the responsibility of DetNet vs the specific wireless technology. I still am not exactly clear on the language, so some comments/questions:

I think I understand “a generic data model to install a RAW flow along a Track in a scheduled wireless network” – that means that the wireless network will expose some parameters about the QoS that it provides, equivalent to the QoS info provided by a wired network segment, such that the DetNet PCE can install a flow the same way, agnostic of wired/wireless.  Right?

Then there is:  “[The proposed data model] will also enable [the DetNet PCE] to commit resources in the network and request diversity in the spatial, frequency and time domains.”

I am still questioning whether the DetNet PCE should be concerned at all in any way about “spatial, frequency and time domains”.

Given that a DetNet network has “a PCE” that configures resources in the network to accommodate flows, is our intent that this same PCE deal with the spatial, frequency and time diversity aspects of specific wireless links within that network?

What I’m thinking is maybe a more “layered” approach might be (for example, since I am not a network architect) to have a “Wireless Path Control Element” that would deal with the wireless specific things independent of the DetNet PCE. Then there would then be some API (presumably as expressed by the proposed data model) that would allow the DetNet PCE to configure flows across any wireless segments in such a way as to treat them just the same as any other (wired)  path.  That is, the wireless segment would communicate its QoS properties using the same set of parameters that a wired path would.

Perhaps that means that the generic (i.e. wired/wireless agnostic) lexicon of segment QoS parameters would have to be extended to include some parameters specific to wireless which might just be left at “zero” for a wired link; but ideally not, i.e. the point is to have the wireless segment act just like a wired segment for the purpose of allocating resources for forwarding flows over it.

Other factors regarding e.g. electrical interference to the wireless signal would be outside the scope of what DetNet is expected to deal with, although if the service degraded (packets unexpectedly getting lost or late) then the DetNet controller would react in the usual way, i.e. throw up a flag or whatever.

Am I making any sense here?
Thanks,
Ethan.

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Friday, May 3, 2019 6:21 AM
To: Xavi Vilajosana Guillen <[email-masked]>; Grossman, Ethan A. <[email-masked]>
Cc: [email-masked]; Lou Berger ([email-masked]) <[email-masked]>
Subject: RE: [Raw] Montréal and Chartering

We could change it to:

All the best,

Pascal

From: Xavi Vilajosana Guillen <[email-masked]<mailto:[email-masked]>>
Sent: vendredi 3 mai 2019 11:00
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Lou Berger ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Raw] Montreal and Chartering

Hi Pascal,

regards
Xavi

What do you think?

Pascal
--
Raw mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/raw<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_raw&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=LyuUjzxkAnvqL2Q4Oe2F3H5XTaIeRPD5HAC7iXutSnk&s=fR1FY4Xxry9CbIIKqawkfZlxFLmkVP8-tECY0yAOaKE&e=>

--
Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
[email-masked]<mailto:[email-masked]>
http://xvilajosana.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__xvilajosana.org&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=LyuUjzxkAnvqL2Q4Oe2F3H5XTaIeRPD5HAC7iXutSnk&s=nXtm2qtmw0xzovRrLGRs8o-sv8becpulAm5-s5xSYiA&e=>
http://wine.rdi.uoc.edu<https://urldefense.proofpoint.com/v2/url?u=http-3A__wine.rdi.uoc.edu&d=DwMGaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=LyuUjzxkAnvqL2Q4Oe2F3H5XTaIeRPD5HAC7iXutSnk&s=8e4di9mKXlLEFL-ossR9xsn04w55eCst4gsSJpRMf3w&e=>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 6 May 2019 11:28:08 +0000

Hello Ethan

Please se below:

From: Raw <[email-masked]> On Behalf Of Grossman, Ethan A.
Sent: vendredi 3 mai 2019 22:02
To: Pascal Thubert (pthubert) <[email-masked]>; Xavi Vilajosana Guillen <[email-masked]>
Cc: [email-masked]; Lou Berger ([email-masked]) <[email-masked]>
Subject: Re: [Raw] Montréal and Chartering

Hi Pascal,

Ø    I meant “generic” enough for the technologies that we’d support. But not agnostic else what’s the point of having RAW?  The PCE would need to be aware of the RAW extensions and which hops are concerned. The extension would enable to ask for  diversity for instance.

Ø    That would be the RAW-enabled DetNet PCE

Ø    Very much

Ø    Makes sense to me. The layers would be like sub-functions of a PCE. We cannot standardize the way it is implemented in the PCE but we can standardize the interface of that thing to the world, that is the extensions to the data model that it will compute.

Ø    My view exactly

Ø    I think that the controller needs to be aware of the wireless hops and their reliability and availability parameters. That way, the controller can decide to add more P(A)REO Functions and use the improved OAM that we’d provide.

  *   Full sense to me

All the best;

Pascal
From: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, May 3, 2019 6:21 AM
To: Xavi Vilajosana Guillen <[email-masked]<mailto:[email-masked]>>; Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Lou Berger ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Raw] Montréal and Chartering

We could change it to:

All the best,

Pascal

Hi Pascal,

regards
Xavi

What do you think?

Pascal

---

From: "Cavalcanti, Dave" <[email-masked]>
Date: Mon, 6 May 2019 16:02:25 +0000

Hi Pascal and All,

According to the current scope, the RAW layer is to enable establishment and management of time-sensitive flows (data flows with certain QoS needs) over wireless networks. This process may include several steps:

1)      The RAW layer will provide the QoS requirements of a RAW flow (e.g. in some form of time constraints metrics, reliability/redundancy metrics, etc …) to the radio layer, which will be used as input to some form of admission control.

2)      Assuming that the radio layer can admit the flow, it will use QoS requirements to schedule resources in space/frequency/time to serve the RAW flow as agreed. The scheduling the decision is implementation specific, and the specific diversity mechanisms used at the MAC/PHY layer is technology specific. The RAW layer doesn’t need to be involved in the radio specific aspects of providing diversity.

3)      The RAW layer needs to monitor the performance of the RAW flow and it may adapt its QoS requirements. This will require an interface with the radio layer to update the RAQ flow parameters.

I understand there is a lot more to be defined, but these seem basic steps required.

Is my understanding of the RAW scope and basic capabilities correct?

Thanks,
Dave

From: Raw [mailto:[email-masked]] On Behalf Of Grossman, Ethan A.
Sent: Friday, May 03, 2019 1:02 PM
To: Pascal Thubert (pthubert) <[email-masked]>; Xavi Vilajosana Guillen <[email-masked]>
Cc: [email-masked]; Lou Berger ([email-masked]) <[email-masked]>
Subject: Re: [Raw] Montréal and Chartering

Hi Pascal,

We could change it to:

All the best,

Pascal

Hi Pascal,

regards
Xavi

What do you think?

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 May 2019 15:37:19 +0000

Hello Dave:

Please see below:

  1.  The RAW layer will provide the QoS requirements of a RAW flow (e.g. in some form of time constraints metrics, reliability/redundancy metrics, etc …) to the radio layer, which will be used as input to some form of admission control.

Ø    I’m not sure it is a layer per se. More of a management interface. A RAW-capable controller manages an end-to-end flow that traverses a particular wireless hop.

Ø    The controller must talk to the intelligence that drives the abstract AP to allocate  a periodic resource for the flow. Compared to DetNet/CCAMP, RAW would provide additional control parameters like “up to 5 retries, max latency all retries included is blah, please provide frequency diversity for the retries”.

Ø    It gets more hairy when doing replication. The controller might say “send a replicated frame to STA 1 and STA 2”. Might turn out that STA 1 and STA 2 are on the same or different APs – hopefully they do not roam, when that happens is next problem. How do we model that? Should there be a DetNet between AP1 and AP2 and AP1 does replication? Or should the previous switch called SW replicate? In which case APs do not do any DetNet service layer?

Ø    Another case is STA1 sends to AP1 and AP2, AP2 being a promiscuous listener? So a single transmission is already a natural replication. This model exists in ISA100.11a, could we have it in other technologies? If so we could model it in our management interface?

  1.  Assuming that the radio layer can admit the flow, it will use QoS requirements to schedule resources in space/frequency/time to serve the RAW flow as agreed. The scheduling the decision is implementation specific, and the specific diversity mechanisms used at the MAC/PHY layer is technology specific. The RAW layer doesn’t need to be involved in the radio specific aspects of providing diversity.

Ø    Well RAW may know how a particular technology schedules its resources in details, that was the discussion in this Thread. i.e., RAW may not control the allocation of resource blocks / subchannels. But maybe it can still ask for something more specific than a meaningless QoS of 5. The abstraction might be half specific like 5 tries or more abstract like 99.99 reliability, either way with a deadline in time. We have to define that based on what APIs the technologies are willing to  open. We need you in the room for that!

  1.  The RAW layer needs to monitor the performance of the RAW flow and it may adapt its QoS requirements. This will require an interface with the radio layer to update the RAQ flow parameters.

Ø    Absolutely

Ø    Looks like it is so; depends if you liked my answer or not : )

All the best,

Pascal

---

From: "Cavalcanti, Dave" <[email-masked]>
Date: Tue, 7 May 2019 18:44:07 +0000

Hi Pascal,

Thanks for the clarifications and please see my responses in line.

Best,
Dave

From: Raw [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, May 07, 2019 8:37 AM
To: Cavalcanti, Dave <[email-masked]>; Grossman, Ethan A. <[email-masked]>; Xavi Vilajosana Guillen <[email-masked]>
Cc: [email-masked]; Lou Berger ([email-masked]) <[email-masked]>
Subject: Re: [Raw] Montréal and Chartering

Hello Dave:

Please see below:

[DC] One option is for the RAW controller to configure some of the radio parameters that will impact QoS (e.g. retries, max latency, etc). It would be good to have a way to describe diversity/reliability requirements from the RAW side that is independent of the radio layer implementation. The RAW controller may not have enough information to decide that frequency diversity is the best option to be used. The AP has better knowledge of the network and it can decide what type of diversity it can provide to a certain flow in order to meet the target requirement. If the AP can provide the required reliability with link adaptation or time diversity, for instance, it should be able to make the best choice.  There are different ways to get diversity (frequency, time, space), and it would be good to abstract that at the RAW layer, and let the radio decide what option to use.

[DC] I assume that packet replication will be done at a layer above the radio (MAC/PHY). Is it part of RAW or another higher layer? With this assumption, the radio layer (AP) would get two packets from the higher layer addressed to two STAs (STA 1 and STA 2) and it would just try to deliver the packets while meeting the RAW diversity requirements.

[DC] It is not very clear what you mean by knowing how a particular technology schedules its resources in details. For instance, RAW may know that an 802.11ax network operates with a certain channel bandwidth, OFDMA mode, available RU sizes, etc. Similar information for a 5G network, e.g. URLLC mode is enabled. But the resource allocation strategies will be a black box (implementation specific). We can look into opening additional information, such as bounded latency, packet error rates, etc.

Ø    Absolutely

All the best,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 May 2019 11:59:16 +0000

Hello Dave

From: Cavalcanti, Dave <[email-masked]>
Sent: mardi 7 mai 2019 20:44
To: Pascal Thubert (pthubert) <[email-masked]>; Grossman, Ethan A. <[email-masked]>; Xavi Vilajosana Guillen <[email-masked]>
Cc: [email-masked]; Lou Berger ([email-masked]) <[email-masked]>
Subject: RE: [Raw] Montréal and Chartering

Hi Pascal,

Best,
Dave

To: Cavalcanti, Dave <[email-masked]<mailto:[email-masked]>>; Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>>; Xavi Vilajosana Guillen <[email-masked]<mailto:[email-masked]>>

Hello Dave:

Please see below:

[DC] One option is for the RAW controller to configure some of the radio parameters that will impact QoS (e.g. retries, max latency, etc). It would be good to have a way to describe diversity/reliability requirements from the RAW side that is independent of the radio layer implementation. The RAW controller may not have enough information to decide that frequency diversity is the best option to be used. The AP has better knowledge of the network and it can decide what type of diversity it can provide to a certain flow in order to meet the target requirement. If the AP can provide the required reliability with link adaptation or time diversity, for instance, it should be able to make the best choice.  There are different ways to get diversity (frequency, time, space), and it would be good to abstract that at the RAW
layer, and let the radio decide what option to use.

PT >> Agreed. The controller owns DetNet-service level diversity (e.g. path redundancy and coding at the source), could control some time diversity, and may only abstractly suggests other forms that are in the Layer-2 domain. It may or may not know which diversity the radio can do and what works best for it (this could be offloaded from the AP or not). If it does not know we need an abstraction of the results that are expected (e.g., loss ratio and deadline).

PT >> It is RAW service sub-layer, and it may be a waste of resources if both STAs could capture the same transmission by one AP. The other way around, a single transmission of a packet by a STA may be received by 2 APs, one acting as a shadow of the other in order to combat effects of location such as interferers near the AP or multipath fading. Even if Wi-Fi does not have that model, other standards such as ISA100.11a already do. And maybe all this is a potential topic for EHT to work on.

PT >> This is what I meant. In TSCH those functions could be offloaded to the controller. We want to start working on the former but in a way that can be extended for the latter.?

All the best,

Pascal