Subject: [Raw] Comments on draft-ietf-raw-architecture-02

From: Fabrice Theoleyre <[email-masked]>
Date: Wed, 12 Jan 2022 16:29:31 +0100

Dear Pascal, 

First of all, I wish you all a Happy and Healthy new Year. 

As promised, I proof read the current version of your draft.
Here are my comments. Great work, I guess you are close to something final.

Best regards,
Fabrice

******

*/ "over deterministic short-range radio”:  you only consider this kind of networks? In particular, I would probably not classify LDACS as short-range
+ I’m not sure to envision why RAW would be different if you also consider long (or medium) range radio technologies.

*/ the sentence " that that require a particular treatment to a path that was provisionned to procure that treatment.” Seems for me confused. Is it possible to reformulate it?

*/  "Network Plane measurement protocols for Operations,  Administration and Maintenance (OAM)” shall you cite the corresponding RAW and detnet drafts? 

*/ the enumerate in section 1 is very clear. Great work!

*/ "It is typically avoided end-to-end” may be reformulated into ”ARQ is typically implemented hop-by-hop and not end-to-end in wireless networks. Else, it introduces […]”?
(I found the current formulation not very clear)

*/ "such as short range broadcast, MUMIMO, constructive interference and overhearing”: does RAW also consider rate adaptation (e.g. Wi-Fi), Spreading Factor selection, etc.?
They may be part of the PAREO feature.

*/ shall you define unidirectional and bidirectional flows in the terminology section?

*/  "A Track is reversible, meaning that packets can be routed against
      the flow of data packets, e.g., to carry OAM measurements or
      control messages back to the Ingress."
Do you assume here that control packets MUST be in-band (even in the inverse directions)? 
Actually, it does not represent a requirement in the detnet-oam draft (https://datatracker.ietf.org/doc/html/draft-ietf-detnet-oam-framework-05):
" 5.   OAM methods MAY combine in-band monitoring or measurement in the
        forward direction and out-of-bound notification in the reverse
        direction, i.e., towards the ingress MEP.
”

*/  "to use the highest possible degree of diversity” -> perhaps to cite here examples (e.g., frequency and/or temporal diversity, etc.)

*/  (the medium speed depends dynamically on the PHY mode and the number of users sharing the spectrum)”: while I agree on the fact that the modulation impacts the bitrate and thus the bandwidth, "the number of users sharing the spectrum” seems for me more confusing. In a deterministic environment, I would expect orthogonal access, and thus a single user that gains the medium access. Am I wrong with this interpretation? Do you want to address also the case with multiple users with a random access?
Or I misinterpreted something?

*/ shouldn’t section 4 be merged with the end of section 1?
They seem to strongly overlap;

*/ in section 8, you seem considering only promiscuous mode. You discard explicitly link-layer anycast or at least multicast transmissions? (Techniques such as Block Acknowledgement of Wi-Fi 6 may help to have acknowledged multicast transmissions).

typos
*/ budgetted -> budgeted
*/ associate application[s]
*/ provisionned -> provisioned
*/  of the end-to-end transmission[s]?
*/  A Track as a complex -> has
*/  the the direction
*/ Track Track is 
*/  The IPv6 flow label is not used [.] for that purpose.
*/  A service level objective (SLO) is one term in the SLO -> in the SLA
*/  complience -> compliance
*/  The reliability criteria of a critical system pervade[s]
*/  till the something moves that changes the reflection patterns
*/  RAW observes and control[s]
*/  in actioned -> is actioned
*/  but that needs to be advertised -> need to
*/  many different paths are possible [for] to
   traverse the network

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Jan 2022 15:44:58 +0000

A huge thanks Fabrice!

Let’s see below

From: RAW <[email-masked]> On Behalf Of Fabrice Theoleyre
Sent: mercredi 12 janvier 2022 16:30
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: [Raw] Comments on draft-ietf-raw-architecture-02

Dear Pascal,

Best regards,
Fabrice

******

> I wanted to avoid things like satcom. I can remove the short range I guess.

> what about
> “    RAW and DetNet route application flows that require a special treatment along the paths that will provide that treatment.”

> Including the expired one I guess ; ) Well, the idea is that the architecture comes before solution drafts are elaborated, so we moved those references to the framework draft. Here we’d stay very high level. In particular the architecture should ship soon, and hopefully there would be very few WIP references there. At least, not in normative.

> : )

> done

> added “ PHY rate and other Modulation Coding Scheme (MCS) adaptation  ”

> I do not feel that’s much need; what do others think?

> no, because the return packet are not subject to the same treatment. But it is important to follow the return path is data is captured at each hop.

> out of band in terms of treatment but may need to be congruent in terms of path. Maybe that can be clarified?

> added (time, space, code, frequency, channel width)

> I meant exactly that. Trying a rewording:
“
                                          Example Link-Layer metrics include
   typical Link bandwidth (the medium speed depends dynamically on the
   PHY mode), number of flows (bandwidth that can be reserved for a
   flomw depends on the number and size of flows sharing the spectrum)
   and average and mean squared deviation of availability and
   reliability figures such as Packet Delivery Ratio (PDR) over long
   periods of time.
“

> They do; the list in section 1 is a summary / intro of all this. I suggest to place a forward pointer to section 4 in the end of section 1, e.g.,
“
   This document presents the RAW problem and associated terminology in
   Section 2, and elaborates in Section 4 on the OODA loop based on the
   RAW conceptual model presented in Section 3.
“

> Section 8?
I added
“
     Variations on the same idea such as link-layer anycast and multicast
     may also be used to reach more than one next-hop with a single frame.
“
In 4.4.3.

You lay review the diffs in the newly published 03 at https://www.ietf.org/rfcdiff?url2=draft-ietf-raw-architecture-03
A great many thanks for all this and the typos as well!

Pascal

---

From: Fabrice Theoleyre <[email-masked]>
Date: Mon, 17 Jan 2022 14:47:45 +0100

Dear Pascal,

Please find my replies inline.

> > I wanted to avoid things like satcom. I can remove the short range I guess.
FT> Cool.

> > “    RAW and DetNet route application flows that require a special treatment along the paths that will provide that treatment.”

FT> ok. I thought just that the repetition of treatment tended to complicate the sentence.

> > Including the expired one I guess ; ) Well, the idea is that the architecture comes before solution drafts are elaborated, so we moved those references to the framework draft. Here we’d stay very…

FT> got it! Sounds great.

> Actually, it does not represent a requirement in the detnet-oam draft (https://datatracker.ietf.org/doc/html/draft-ietf-detnet-oam-framework-05 <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-oam-framework-05>):

FT> clear with these additional explanations

>    reliability figures such as Packet Delivery Ratio (PDR) over long
FT> ok

> You lay review the diffs in the newly published 03 at https://www.ietf.org/rfcdiff?url2=draft-ietf-raw-architecture-03 <https://www.ietf.org/rfcdiff?url2=draft-ietf-raw-architecture-03>

Many thanks Pascal !

Fabrice