Re: [Raw] Montréal and Chartering

["Cavalcanti, Dave" <[e-mail]>]

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:[e-mail]] On Behalf Of Grossman, Ethan A.
Sent: Friday, May 03, 2019 1:02 PM
To: Pascal Thubert (pthubert) <[e-mail]>; Xavi Vilajosana Guillen <[e-mail]>
Cc: [e-mail]; Lou Berger ([e-mail]) <[e-mail]>
Subject: Re: [Raw] Montréal and Chartering

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) <[e-mail]<mailto:[e-mail]>>
Sent: Friday, May 3, 2019 6:21 AM
To: Xavi Vilajosana Guillen <[e-mail]<mailto:[e-mail]>>; Grossman, Ethan A. <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Lou Berger ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Raw] Montréal and Chartering

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 <[e-mail]<mailto:[e-mail]>>
Sent: vendredi 3 mai 2019 11:00
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Lou Berger ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
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
([phone]
[e-mail]<mailto:[e-mail]>
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=>

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]
­