Subject: Re: [Raw] [RAW] NOTES from Architecture/Framework meeting 2/2/2022

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Mar 2022 15:03:25 +0000

Hello Dave:

Many thanks for all this!

I published the proposed changes as 04 so you can easily watch them as https://www.ietf.org/rfcdiff?url2=draft-ietf-raw-architecture-04.txt

Please see below:

> Is there a specific problem that is not addressed by layer 2 TSN over wireless that can be addressed at layer 3 with RAW? Note that layer 2 solutions also control diversity in time/frequency/space domains on a link basis. It would be good to highlight the gaps with layer 2 that RAW helps to solve.

Makes sense; proposed update:
"
   To defeat those additional causes of transmission delay and loss in wireless
   transmission, RAW requires and leverages deterministic layer-2 capabilities.
   Operating at the layer-3, RAW can further increase diversity in the spatial,
   time, code, and frequency domains by enabling multiple link-layer wired and
   wireless technologies in parallel or sequentially, for a higher resilience
   and a wider applicability. RAW can also provide homogeneous services to
   critical applications beyond the boundaries of a single subnetwork, e.g.,
   controlling the use of diverse radio access technologies to optimize the
   end-to-end application experience.
"

> Why Wi-Fi 6 mesh is highlighted? Does RAW apply to the typical Wi-Fi 6 or 5G enterprise/infrastructure? A bit more information about what is the DetNet Network plane would be useful for completeness here.

Removed the example of Wi-Fi-6 mesh.  Added:
"
   The DetNet Network Plane is composed of a DetNet service sublayer that
   focuses on flow protection (e.g., using redundancy) and can be fully operated
   at layer-3, and a DetNet forwarding sublayer that associates the flows to the
   paths, ensures the availability of the necessary resources, and leverages
   layer-2 functionalities for timely delivery to the next Detnet system.
   The RAW Architecture extends the DetNet Network Plane, to accommodate one or
   multiple hops of homogeneous or heterogeneous wired and wireless technologies.
"

> It is not clear what types of wireless network topology can benefit from RAW. A figure to illustrate the wireless network topology and RAW scope would be useful.

Agreed. This was the intention of the text with the example of Wi-Fi 6  mesh and diverse access that I removed for your comment above.

Note that as an architecture, we cannot be exhaustive about the requirement served, just like you can never know what people will do with a hammer even if you're a nail specialist (but I'd wear a hard hat just in case). You'll find that the framework document (https://www.ietf.org/archive/id/draft-ietf-raw-framework-00.html#name-use-cases-and-requirements-) has use cases and scope, because the methods that it deploys serve those use cases.

Proposed update:
"
   The RAW Architecture extends the DetNet Network Plane, to accommodate
   one or multiple hops of homogeneous or heterogeneous wired and
   wireless technologies.  RAW adds reactivity to the DetNet service
   sublayer to compensate the dynamics for the radio links in terms of
   lossiness and bandwidth.  This may apply for instance to mesh
   networks as illustrated in Figure 2, or diverse radio access networks
   as illustrated in Figure 4.

"

> This implies that RAW is about providing redundant paths over wireless links. If this is the case, it could have been stated earlier, on top of this page.

True, though it's really the DetNet service layer that provides that. I mentioned "redundancy" in the new description of the service layer which keeps it vague enough to encompass what we need.

> what is a complex path? why is it complex? can we just say it is a route between routers including wired and wireless links?

I guess you found the response later in the terminology. A path in the art is the experience of the packet that went from A to B. Here a packet may be duplicated, network coded, and the various by products travel different paths that are not necessarily end to end A to B; that is complex, and does not fit the traditional description of a path.

In the context of your comment I tweaked the terminology as follows:
"
   It follows that the general acceptance of a path is a linear sequence
   of nodes, as opposed to a multi-dimensional graph, defined by the
   experience of the packet that went from a node A to a node B.

   With DetNet and RAW, a packet may be duplicated, fragmented and
   network-coded, and the various byproducts may travel different paths
   that are not necessarily end-to-end between A and B; we refer to that
   experience as a complex path.  The complex path does not fit the
   traditional description of a path, and is subject to change from a
   packet to the next.  This is why we introduce below the term of a
   Track as the overall topology where the possible complex paths are
   all contained.

   In the context of this document, a path is observed by following one
   copy or one fragment of a packet that conserves its uniqueness and
   integrity.  For instance, if C replicates to E and F and D eliminates
   on the way from A to B, a packet from A to B experiences 2 paths,
   A->C->E->D->B and A->C->F->D->B.
"
And later on tracks:
"

   A networking graph that can be followed to transport packets with
   equivalent treatment; as opposed to the definition of a path above, a
   Track represents not an experience but a potential, is not
   necessarily a linear sequence, and is not necessarily fully traversed
   (flooded) by all packets of a flow.  It may contain multiple paths
   that may overlap, fork and rejoin, for instance to enable the RAW
   PAREO operations.
"
I hope it's clearer now.

> It seems Track is an important concept used in the document, as such it should be defined more clearly. what is the difference between a route and a track?

Added a link to the terminology. I hope the text above helps.

> As commented above, the reference to mesh (and the reuse of TSCH features) implies that RAW is only applicable to mesh networks. Is that the case?

I do not read e.g., as limiting the set of application. I did not expect that it could be read that way. I expect now that the links earlier to the figs resolve that issue.

> this whole section seems just a generic discussion that is not specific to RAW, it could be deleted.

Agree it is generic, disagree to remove. I believe it is core to our work since we are defining here the terms of our acronym.
You'll note that we do not have a spec at the IETF that defines reliability. We have to spec our own.

> see previous comment. This doesn't seem to specify any device/protocol behavior. If not needed, you may want to consider deleting it. Some of the generic observations can be made in the introduction.

This is an architecture. It gives context (here), components and interactions. The goal is to provide a common understanding so the work can start. The goal is not to provide all the solutions and protocols. This will come with the framework document at WG completion time.

> This has been said previously. The reference to DLEP could be added earlier.

Hum, I tried but not easy. Added a forward reference

> this section seems to focus more on the wireless channel/propagation characteristics and causes of errors. It is not really about reliability. Perhaps "basic wireless communication effects" or something like that.
What about
"
Wireless effects affecting Reliability
"

> Up to this point, there is no illustration of the track concept applied to a wireless network topology. It would be useful to show what is track between an AP/BS and STA/UEs.

This illustration was moved to the framework but also shows in section 4.1 that is now referred in the introduction.

> Does each device need to have multiple radios to use RAW?
Adding a new figure in the Track definition, so we have more variety.

Note: the IP Links we form are P2P abstractions regardless of L2 connectivity; with a single radio you can form many of them and with that a graph. So the number of radios is not a precondition to form the graph.
I clarify that in the Track definition
"
    A Track is a layer-3 abstraction built upon P2P IP links between routers.
    A router may form multiple P2P links over a single radio interface.
"

Also a transit node (IOW operating at the DetNet forwarding sublayer only) will forward but not replicate so it is 1 in 1 out. Since RFC 8655 is a normative reference we do not need to elaborate too much on that. But I'll make sure that the figure 1 does not give the impression that all nodes are relays by adding more transit.

> this figure is not very clear. It is not easy to see a network in the figure.

Replaced the Zs which seem to cause trouble

> are these statistics collected by the RAW layer or do they need support from L2? Are there specific mechanisms/protocols to report statistics?

I improved the earlier text that mentions DLEP and discusses that point exactly.

"
   Those measurements are needed in the context of RAW to inform the
   controller and make the long term reactive decision to rebuild a
   complex path based on statistical and aggregated information.  RAW
   itself operates in the Network Plane at a faster time scale with live
   information on speed, state, etc...  This live information can be
   obtained directly from the lower layer, e.g., using L2 triggers, read
   from a protocol such as the Dynamic Link Exchange Protocol (DLEP)
   [DLEP], or transported over multiple hops using OAM and reverse OAM,
   as illustrated in Figure 6.
"

> this is a good figure to illustrate a practical application of RAW with multi radios, it would have been useful earlier in the document.

Yes, I added a forward reference in the introduction per your comment.

> The distinction between path computation and path selection is confusion. I wonder if the terminology is accurate. If a path is computed between source and destination, I assume it would be used until changed, but if the path selection is changing the path in a different time scale, does it change the original path computed? Perhaps path selection should be renamed to something specific to managing redundancy/links along the path on a per packet (or group of packets) basis.

Yes, this is because of the use of path computation and PCE in the art of IETF that we wanted to reuse.
Let's forget that if that causes confusion. The text becomes:

"

   RAW separates the long time scale at which a Track is elaborated and
   installed, from the short time scale at which the forwarding decision
   is taken for one or a few packets (see in Section 2.3) that will
   experience the same path until the network conditions evolve and
   another patyh is selected within the same Track.

   The Track computation is out of scope, but RAW expects that the
   Controller plane protocol that installs the Track also provides
   related knowledge in the form of meta data about the links, segments
   and possible subTracks.  That meta data can be a pre-digested
   statistical model, and may include prediction of future flaps and
   packet loss, as well as recommended actions when that happens.
"

> Some of these functions are part of the MAC, how can RAW control it? Is the idea to replicate these functions at the RAW layer?

Certainly not. But RAW can pass parameters to the lower layers. QoS is already one. We could improve the IOCTL or equivalent  to pass more.

What about
"
   RAW may control whether and how to use packet replication and
   elimination (PRE), fragmentation, and network coding, and how the
   lower layers performs Automatic Repeat reQuest (ARQ), Hybrid ARQ
   (HARQ) that includes Forward Error Correction (FEC), and other
   wireless-specific techniques such as overhearing and constructive
   interferences, in order to increase the reliabiility and availability
   of the end-to-end transmission.
"

> This seems very similar to L2 redundancy (802.1CB). Is the idea to do the same at layer 3? Should a reference to .1CB be included here?

In this case we discuss using overhearing to compensate lossiness, so no that's not .1CB. For redundancy,
.1CB did not invent the concept either. It has been present in industrial and A/V under names like 1+1, 1+N, PRP, HSR, live-live, and more.

> This would require change in the L2/MAC for each link. It may not feasible for RAW nodes.

This is an architecture; the overhearing method has been demonstrated on IEEE 802.15.4.
People / technologies may or may not use it but the architecture still needs to mention it.

> If the MAC layer is encrypting the packets, the neighbors may not be able to decode it. As indicated previously, this seems to require MAC support and it may raise security issues.

This assumes a certain form of hop by hop L2 crypto. The MAC payload may be encrypted such a way that intermediate nodes do not need to decrypt it. We may protect only L3 using IPSec.

Some meshes use a group key that all nodes will understand. Clearly the security has to be thought of. I added a section on that in the security section.
"
5.1.  Layer-2 encryption

   Radio networks typically encrypt at the MAC layer to protect the
   transmission.  If the encryption is per pair of peers, then certain
   RAW operations like promiscuous overhearing become impossible.
"

> As suggested, this requires enablement in the lower layers. Isn't it out of scope for RAW?

It does, but same goes for say, latency constraints. Either way RAW signals and the lower layer is really where it happens.

> This seems a very vague statement about security, some of the ideas may trigger security concerns.  If any specific/new RAW feature improves security, it would be good to highlight.

Yes, and we're a little light there. Suggestions welcome!

Many thanks, Dave

Keep safe

Pascal

---

From: "Cavalcanti, Dave" <[email-masked]>
Date: Mon, 7 Mar 2022 18:11:58 +0000

Hi Pascal,

Thanks for addressing the comments and providing the detailed response below.
I'll review and let you know if I see any outstanding item, but it seems you've addressed most of the suggestions.

Best,
Dave

From: Pascal Thubert (pthubert) <[email-masked]>
Sent: Friday, March 4, 2022 7:03 AM
To: Cavalcanti, Dave <[email-masked]>; Schooler, Eve M <[email-masked]>
Cc: Rick Taylor <[email-masked]>; [email-masked]
Subject: RE: [RAW] NOTES from Architecture/Framework meeting 2/2/2022

Hello Dave:

Proposed update:
"

"

What about
"

"

"

What about
"

Many thanks, Dave

Keep safe

Pascal