Re: [Raw] Thoughts on Problem Statement draft

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Ethan :

Many thanks for the in depth review! Would you wish to co-author? The draft would immensely benefit from you DetNet eye and revisiting the language would be good too.

Let's see below:


  1.  "provide a Reliable and Available service" - I don't think this is a clearly defined term, particularly when capitalized as a proper name. In lower case each word could be parsed for a definition ("reliability" and "availability" each have definitions in this context, I would say, e.g. https://reliabilityweb.com/tips/article/understanding_the_difference_between_reliability_and_availability/). I think early in the draft we should carefully define what RAW means in practice, and how it differs from "deterministic", the word we are trying to avoid. Perhaps this definition could be based on the sentence from section 4: "[A] prerequisite is that an IP link can be established over the radio with some guarantees in terms of service reliability, e.g., it can be relied upon to transmit a packet within a bounded latency and provides a guaranteed BER/PDR outside rare but existing transient outage windows that can last from split seconds to minutes."

<Pascal>
Yes, we should have an early section in that. Would you be willing to propose that text? Your link is spot on and match the industrial terminology that we used to name the mailing list. The definitions, applied to wireless, could be added to the terminology section.

Proposal for this:




2.  Terminology



   RAW reuses terminology defined for DetNet in [DetNet-ARCH], e.g.,

   PREOF for Packet Replication, Elimination and Ordering Functions.



   RAW also reuses terminology defined for 6TiSCH in [6TiSCH-ARCH] such

   as Track.  6TiSCH defined the term Track for that complex path with

   associated PAREO operations.



   RAW defines the following terms:



   PAREO:  Packet (hybrid) ARQ, Replication, Elimination and Ordering.

      PAREO is a superset Of DetNet's PREOF that includes radio-specific

      techniques such as short range broadcast, MUMIMO, constructive

      interference and overhearing, which can be leveraged separately or

      combined to increase the reliability.



   This document reuses terms that are well-defined in the context of

   automation to networking and packet delivery, in particular for

   reliability and availability.  In the context of the RAW work, they

   are defined as follows:



   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.  RAW expresses reliability

      in terms of Mean Time Between Failure (MTBF) and Maximum

      Consecutive Failures (MCF).



   Availability:  Availability is a measure of the relative amount of

      time where a path operates in stated condition, in other words

      (uptime)/(uptime+downtime).  Because a serial wireless path may

      not be good enough to provide the required availability, and even

      2 parallel paths may not be over a longer period of time, the RAW

      availability implies a path that is a lot more complex than what

      DetNet typically envisages (a Track).



In more details:

RAW differs from TSN because the access to the medium at a precise time cannot be guaranteed, and the delivery is statistical. We cannot expect mechanism like pre-emption over the shared medium because we cannot interrupt a remote talker. MUMIMO and Time Slot/Resource Unit/Resource block allocation help a lot but that's still no guarantee. So there will be a latency and a loss budget at each hop, and there will be misses on an individual hop. Because a single path is not good enough to provide the required availability, and even 2 parallel paths may not be over a longer period of time, the RAW availability implies a path that is a lot more complex than what DetNet typically envisages. 6TiSCH defined the term Track for that complex beast. And the definition of reliability expressed in the paper needs adaptation to our use cases. 1) we need to define a "fault" for MTBF: the service that is expected is delivery within bounded latency and a failure is when this does not happen, either the packet is lost or delivered too late. The network must meet reliability criteria that include both MTBF and consecutive faults (losses-in-a-row), e.g., we SHOULD never see LIAR > 3.
</Pascal>


  1.  "getting traction in various industries including .. online gaming... ". Online gaming is explicitly out of scope for DetNet so even if it has some possible relevance it will just raise the wrong questions, please delete. I see that there is a reference to gaming at https://tools.ietf.org/html/draft-bernardos-raw-use-cases-00#page-10, and there the variants appear to be differentiated from "online" (which I interpret to mean Internet-based) gaming. Maybe one could say "wireless gaming", although in the interest of cleanliness I would rather drop it entirely for the Problem Statement.


<Pascal>
I made that a separate thread. Not ready to give up online gaming. Arguably not a focus for DetNet but a key application for RAW. Happy to rename as you suggest. Dropping implies losing the key Wi-Fi use case.
</Pascal>



  1.  "as a first approximation can ignore flapping" - is the meaning of "flapping" really understood outside the wireless community?

<Pascal>
It is well known at the Routing area, for sure. Fond memories from OSPF and the likes. But for wireless people, I'm not sure. Wireless does not flap like a misbehaving wired interface. We should probably create our definition in the terminology indicating short (typically sub-second) transients where the delivery drops to (almost) zero.

Proposal



   Flapping:  In the context of RAW a link flaps when the connectivity

      is interrupted for short transient times, typically of a subsecond

      duration.


</Pascal>


  1.   "This signaling enables relays to tune retries and replication to be met" - Somehow this sentence doesn't converge for me -  maybe you are trying to say "This signaling enables relays to tune retries and replication to meet the required QoS"?


<Pascal>

Applied

</Pascal>




  1.  Can Informative RFC/drafts be referenced Normatively as done here with the DetNet and RAW Use Case drafts?



<Pascal>

Yes: A normative reference denotes a spec that must be read to fully comprehend this. It is kind of a misnomer and not related to the track.
This draft is informational so it can refer normatively to others without a downref.

</Pascal>



  1.  It seems DLEP is rather close to what RAW needs, but extended (presumably by an independent layer/protocol) to include a more dynamic and interactive parameterization of the link? I would like to hear in a little more detail how DLEP could fit in with RAW.

<Pascal>
DLEP (to my best understanding) provides an abstract interface between a network layer and a radio, e.g. over a cable when the radio is deported, e.g. through a serial cable. It could be seen as a widely augmented L2 trigger, and it is local to a node. The OAM that we need is end to end along a track. It may capture and aggregate information learned through DLEP or other methods.

</Pascal>


  1.  Perhaps a diagram of how RAW would fit in with DetNet would be helpful? Like what would be the analogous diagram to https://tools.ietf.org/html/draft-ietf-detnet-ip-over-mpls-02, figure 1? I feel like I can see what RAW is trying to do, i.e. enable per-packet path decisions, but I don't quite see how that interface to DetNet would work, e.g. from a layering standpoint. Of course, this may all be perfectly obvious to one skilled in the art, but sadly I am not. Looking forward to item #14 below, perhaps we would be replacing the Forwarding plane shown in [the above mentioned ip-over-mpls figure] with the "RAW Forwarding plane"? If so, then what else would have to change in that diagram?


<Pascal>

  Could be useful and could be similar. But the key point is not the functional layout, it is the forwarding plane operation itself. Ideally the most interesting figure would the show the long term control at the controller plane as DetNet has it and the short term control at the forwarding plane that we introduce with RAW.

</Pascal>



  1.  Is the result to be a draft like "detnet-ip-over-raw"? Perhaps a sort of "imaginary" version of this might be constructed, almost as an appendix to the Problem Statement?  I mean, having some way(s) to let people visualize more precisely the desired outcome of the exercise I feel would be helpful to the cause.

<Pascal>

There could be a DetNet draft like that, yes. And some data models at CCAMP. And bits at BIER. But inside RAW we'll start with OAM and in-band datapath control flows, at least that's what we currently say in https://trac.tools.ietf.org/bof/trac/wiki/RAW

I'm not clear what the proposed version would be but you're most welcome to start some text.

</Pascal>



  1.  "RAW is to provide DetNet elements" - what would those elements look like? How would they differ from the currently defined elements? How are they layered and connected? I don't mean you have to solve the problem, just visualize what an "ideal" solution would look like.


<Pascal>



</Pascal>




  1.  Is "preserving energy and optimizing the use of the shared spectrum" too large of an ask here? Perhaps those can be orthogonal to "reliable and available transport", and thus we could simplify the problem? Perhaps they might come along as "free baggage" without having to address them directly?


<Pascal>

         Maybe optimizing is too strong? We want to avoid waste as much as can do. How would you word that? If you build many path with tons of redundancy across spectrum, space, time, code, etc..., you'll end up very close to Deterministic but with only minutes of battery.

</Pascal>


  1.  "possibly combined with wired Segments" - doesn't this just come for free with DetNet?


<Pascal>

       Hopefully, that is why we care for DetNet filiation. Again, all rewording welcome, including you taking the pen directly.


</Pascal>


  1.  "possibly sharing physical resources with non- deterministic traffic" - If this is going to happen below a DetNet flow, shouldn't this be out of scope? If it is at the level of DetNet flows, then why does RAW need to address this? Again I am just trying to simplify to focus the problem. I gather there is some concern about "is there enough work for a workgroup here" but I feel like the goals of this draft still seem a bit diffuse - I would rather see laser focus on the "just in time" per-packet path decisions, and how that could be interfaced to DetNet. To me that sounds like a substantial task, worthy of a WG (or not to be expected of the DetNet WG, anyway).


<Pascal>

          This is a must for DetNet so we inherit it. It's very hard to omit it since it is a central reason why people say radios are not deterministic.
           With wireless it also means uncontrolled collisions that needs to be combatted, e.g., with MUMIMO and scheduling.
           But I agree with you for now this is not easily tractable, hard to place an action point to match it.

</Pascal>



  1.  "a RAW  solution will need to address less consistent transmissions, energy  conservation and shared spectrum efficiency." - Same comment as above about teasing these apart. (Same comment for similar text elsewhere).

<Pascal>
         I agree on the intention, need a second pass on that.
</Pascal>


  1.  "it makes sense in the wireless case to  provide redundant forwarding solutions along a complex path and to leave it to the RAW Network Plane to select which of those forwarding solutions are to be used for a given packet based on the current conditions." - So we are to define the "RAW Network Plane"? Or is that still below us? I think expanding on this idea would be helpful. "leaves it to the forwarding plane to make the per-packet decision of which of these possibilities should be used". Is the "RAW Network Plane" the "forwarding plane"? If so we should clearly define this and then use this terminology consistently.

<Pascal>
         I agree on the intention, need a second pass on that too. Maybe add terminology as well?
</Pascal>



  1.  "RAW formalizes a routing time scale that is order of magnitude longer than the forwarding time scale" - I think this would be clearer if it were stated the other way around - "RAW formalizes a forwarding time scale that is an order(s) of magnitude shorter than the [wired DetNet] routing time scale".


<Pascal>
         Applied in the repo; [wired DetNet] became controller plane.
</Pascal>


  1.  "RAW needs feedback that flows on the reverse path and gathers instantaneous values from the radio receivers at each hop to inform back the source and replicating relays so they can make optimized forwarding decisions." - Perhaps this is the key to the whole thing? It is based on essentially specialized OAM in-band traffic? Maybe that could be shown in the [proposed] diagram?


<Pascal>
         Yes, this is key and a diagram will help. I'll need time.
</Pascal>


  1.  "There is a need for an observation method to provide the RAW forwarding plane with the specific knowledge of the state of the Track for the type of flow of interest (e.g., for a QoS level of interest).  To observe the whole Track in quasi real time, RAW will consider existing tools such as L2-triggers, DLEP, BFD and in-band and out-of-band OAM." - Again, maybe this starts to answer my questions? Somehow this key information should be front and center rather than buried late in the Gaps section of the draft? The following paragraphs (i.e. after the afore-quoted one) in the Gaps section all seem to me to be key, and should be up front in trying to describe the approaches considered to solve the problem. Again maybe this could be structured in the form of a "straw man" solution, to give the sense of what RAW is going for.

Anyway so much for my uninformed observations. Please make of it what you will.
Best,
Ethan.





<Pascal>
         Maybe we should rename the section because it is indeed the core of the document. We also need to elaborate in that section.
</Pascal>

Many, many thanks Ethan.

Pascal