Subject: Re: [Raw] New Version Notification for draft-pthubert-raw-architecture-00.txt

From: Janos Farkas <[email-masked]>
Date: Sun, 17 May 2020 22:15:59 +0000

Hi Pascal,

Perhaps it may be good to write here another comment I made before in different forms:
It would be good to see whether or not PAREO is applicable to the RAW radio technologies or only to IEEE Std 802.15.4? This includes whether the concept of tracks is only applicable to 6TiSCH or other technologies as well? I think it would be beneficial if the authors could show that.

Thank you!

All the best,
Janos

-----Original Message-----
From: Pascal Thubert (pthubert) <[email-masked]> 
Sent: Thursday, April 2, 2020 2:29 PM
To: Janos Farkas <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: New Version Notification for draft-pthubert-raw-architecture-00.txt

Hello Janos:

I'll change the title to add /Framework in 01, no worries.

I have seen a lot of cross participation with DetNet, including you, so I'm reasonably sure that we have that side covered. RAW also attracts wireless experts that did not participate to DetNet. I do not take it as a requirement that what this resulting team produces is a subset of DetNet and is contained in the DetNet Architecture. I actually expect new approaches that are specific to RAW in addition to those inherited from DetNet and possibly extended. 

If that's correct we'll need a new architecture, and we want the wireless experts to help us produce it. I agree that the architecture is the beginning of a solution, which is composed of many components that the architecture outlines. That's the reason why it must come the best informed party, and hopefully RAW is the group that has formed for that at the IETF. 

All in all I believe that the charter makes  a lot of sense.

Keep safe,

Pascal
> -----Original Message-----
> From: Janos Farkas <[email-masked]>
> Sent: mercredi 1 avril 2020 22:10
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: RE: New Version Notification for 
> draft-pthubert-raw-architecture- 00.txt
> 
> Hi Pascal,
> 
> I like the approach reflected in the first two milestones in the RAW 
> charter. I found this multiple times a good way of working; namely, to 
> collect use cases and then collect the requirements out of the use 
> cases. I think this helps understanding the problem we are about to 
> solve. Perhaps requirements is close to problem statement. I'd be glad 
> to see then what can we do with current IETF technology to meet the 
> requirements / solve the problem and what are the gaps. This may help 
> seeing clearer what could be useful to include in a framework/architecture.
> I understand that these work items are not completely sequential but 
> run with some overlaps.
> 
> 
> Since you brought up the BoF, the consensus reached on the BoF:
> https://datatracker.ietf.org/doc/minutes-106-raw/
> " If do WG for only first 2 work items, informational, do poll again: 
> For/against was maybe 80 vs 20."
> where the work items were:
> "1) Produce informational documents describing deterministic wireless  
> use cases, in continuation to the DetNet Use Cases document
>  2) Produce informational documents describing the technologies that 
> the group will cover (e.g., URLLC, TSCH, 802.11ax/be and possibly LDACS)"
> 
> 
> As you asked feedback about architecture; honestly, I prefer framework 
> to architecture. Architecture for me is kind of a solution. I'm most 
> familiar with DetNet, so I'll take it as example. I think RFC 8655 
> DetNet Architecture outlines at a high level the DetNet solution to 
> the problem coming from RFC 8578 DetNet Use Cases and RFC 8577 DetNet 
> Problem Statement. Of course, RFC
> 8655 does not provide the solution details, they are provided by 
> individual drafts like the data plane drafts; but still RFC 8655 is a solution at high level.
> 
> The RAW charter says: "RAW is not chartered to work on a solution."
> 
> So, a framework seems to be better to me than architecture in order to 
> remain in the scope of the charter.
> 
> As for framework, the DetNet Controller Plane Framework draft comes to 
> my mind. In the DetNet WG we discussed with regards to this draft that 
> it is good, but it should not specify solution details.
> 
> I know, the charter uses "architecture/framework".
> I'm just expressing an opinion on which one I'd suggest out of the two 
> options for the reasons explained above.
> 
> Best regards,
> Janos
> 
> 
> -----Original Message-----
> From: RAW <[email-masked]> On Behalf Of Pascal Thubert 
> (pthubert)
> Sent: Wednesday, April 1, 2020 3:27 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Raw] FW: New Version Notification for draft-pthubert-raw- 
> architecture-00.txt
> 
> Dear all:
> 
> The collection of documents that we built for the BoF does not match 
> the list of deliverables that we have now committed with the RAW 
> charter. In particular, the charter expects a requirement draft and an 
> architecture draft but does not require a problem statement.
> 
> Georgios and I picked and restructured text from the PAREO 
> requirements and the PS draft, and started an architecture document. I 
> just pushed the first version to hint the group of where we wish to go and solicit early feedback.
> Please expect revisions soon to add more architecture text.
> 
> Comments welcome!
> 
> Keep safe...
> 
> Pascal
> 
> 
> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: mercredi 1 avril 2020 15:14
> To: Georgios Z. Papadopoulos 
> <[email-masked]>;
> Georgios Papadopoulos <[email-masked]>; 
> Pascal Thubert (pthubert) <[email-masked]>
> Subject: New Version Notification for 
> draft-pthubert-raw-architecture-00.txt
> 
> 
> A new version of I-D, draft-pthubert-raw-architecture-00.txt
> has been successfully submitted by Pascal Thubert and posted to the 
> IETF repository.
> 
> Name:		draft-pthubert-raw-architecture
> Revision:	00
> Title:		Reliable and Available Wireless Architecture
> Document date:	2020-04-01
> Group:		Individual Submission
> Pages:		16
> URL:            https://www.ietf.org/internet-drafts/draft-pthubert-raw-
> architecture-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-pthubert-raw-architecture/
> Htmlized:       https://tools.ietf.org/html/draft-pthubert-raw-architecture-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pthubert-raw-
> architecture
> 
> 
> Abstract:
>    Due to uncontrolled interferences, including the self-induced
>    multipath fading, deterministic networking can only be approached on
>    wireless links.  The radio conditions may change -way- faster than a
>    centralized routing can adapt and reprogram, in particular when the
>    controller is distant and connectivity is slow and limited.  RAW
>    separates the routing time scale at which a complex path is
>    recomputed from the forwarding time scale at which the forwarding
>    decision is taken for an individual packet.  RAW operates at the
>    forwarding time scale.  The RAW problem is to decide, within the
>    redundant solutions that are proposed by the routing, which will be
>    used for each individual packet to provide a DetNet service while
>    minimizing the waste of resources.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> --
> RAW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/raw

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 18 May 2020 07:57:43 +0000

Hello Janos

I'm working on the document 01 and thanks to you in particular there's a lot of work to be done : )

Conceptually, PAREO is not linked to a particular MAC / PHY; the most difficult of all is the constructive interference and you see it in 5G, Wi-Fi7 and TSCH. ARQ is also quite ubiquitous in LAN/WAN wireless at least for reasonable distances. Overhearing is less done in practice but I have not seen reasons that would absolutely bar it in the non-TSHC techs. Outside RAW, it is the foundation of the reliability in LoRa for instance.

Track is another thing. You could do it in a Wi-Fi mesh, and quite possibly you could use D2D to achieve it as well in 5G (at least one rebound). I've not seen any of that done in practice in the real world as of now. We should mention that in an applicability statement, but at the architecture level, since all is feasible and we are abstracting the MAC/PHY, what exactly would you wish to say?

Following our discussions, draft archi-framework 01 will separate the use cases where we protect one hop (the wireless access) and where we protect a limited wireless path (a Track). In the former case, we'll observe the first hop L2 Link and the end-to-end L3 SLA; as I see it now, but the debate has not even started, the rest of the path would be considered as infinitely good compared to the first hop, whatever metric you consider for reliability and availability, so we'd charge all end-to-end issue to the first hop and make it more reliable (like use more than one link) to cope with L3 end-to-end issues. 

Does that match your question?

Take care,

Pascal

> From: RAW <[email-masked]> On Behalf Of Janos Farkas
> Sent: lundi 18 mai 2020 00:16
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Raw] New Version Notification for draft-pthubert-raw-
> architecture-00.txt
> 
> Hi Pascal,
> 
> It would be good to see whether or not PAREO is applicable to the RAW radio
> technologies or only to IEEE Std 802.15.4? This includes whether the concept
> of tracks is only applicable to 6TiSCH or other technologies as well? I think it
> would be beneficial if the authors could show that.
> 
> Thank you!
> 
> All the best,
> Janos
> 
> 
> 
> I have seen a lot of cross participation with DetNet, including you, so I'm
> reasonably sure that we have that side covered. RAW also attracts wireless
> experts that did not participate to DetNet. I do not take it as a requirement
> that what this resulting team produces is a subset of DetNet and is contained
> in the DetNet Architecture. I actually expect new approaches that are specific
> to RAW in addition to those inherited from DetNet and possibly extended.
> 
> If that's correct we'll need a new architecture, and we want the wireless
> experts to help us produce it. I agree that the architecture is the beginning of a
> solution, which is composed of many components that the architecture
> outlines. That's the reason why it must come the best informed party, and
> hopefully RAW is the group that has formed for that at the IETF.
>

---

From: Janos Farkas <[email-masked]>
Date: Sun, 31 May 2020 20:46:10 +0000

Hi Pascal,

I'm sorry for the non-prompt reply. I guess too many balls in the air.

Well, what I'm after is how these concepts are really applicable to the existing and standardized RAW technologies. Perhaps in other words, how is the RAW layer applicable to the different RAW technologies, and how does the RAW layer interwork with the standard radio technologies below RAW?

As the concepts seem to be coming from 6TiSCH, I suppose the concepts work for IEEE Std 802.15.4. But, I'm afraid it is not so clear for IEEE Std 802.11 and 3GPP standards, for example.

For instance, ARQ is called out. 3GPP standards specify ARQ (and HARQ). Does RAW intend to influence 5G ARQ?
I think similar questions could be raised for other radio techniques used in WLAN and 5G.
 
All the best,
Janos

-----Original Message-----
From: Pascal Thubert (pthubert) <pthubert=[email-masked]> 
Sent: Monday, May 18, 2020 9:58 AM
To: Janos Farkas <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: New Version Notification for draft-pthubert-raw-architecture-00.txt

Hello Janos

Take care,

Pascal

> It would be good to see whether or not PAREO is applicable to the RAW 
> radio technologies or only to IEEE Std 802.15.4? This includes whether 
> the concept of tracks is only applicable to 6TiSCH or other 
> technologies as well? I think it would be beneficial if the authors could show that.
> 
> Thank you!
> 
> All the best,
> Janos
> 
> 
> 
> I have seen a lot of cross participation with DetNet, including you, 
> so I'm reasonably sure that we have that side covered. RAW also 
> attracts wireless experts that did not participate to DetNet. I do not 
> take it as a requirement that what this resulting team produces is a 
> subset of DetNet and is contained in the DetNet Architecture. I 
> actually expect new approaches that are specific to RAW in addition to those inherited from DetNet and possibly extended.
> 
> If that's correct we'll need a new architecture, and we want the 
> wireless experts to help us produce it. I agree that the architecture 
> is the beginning of a solution, which is composed of many components 
> that the architecture outlines. That's the reason why it must come the 
> best informed party, and hopefully RAW is the group that has formed for that at the IETF.
> 
> > charter. I found this multiple times a good way of working; namely, 
> > to collect use cases and then collect the requirements out of the 
> > use cases. I think this helps understanding the problem we are about 
> > to solve. Perhaps requirements is close to problem statement. I'd be 
> > glad to see then what can we do with current IETF technology to meet 
> > the requirements / solve the problem and what are the gaps. This may 
> > help seeing clearer what could be useful to include in a framework/architecture.
> > "1) Produce informational documents describing deterministic 
> > wireless use cases, in continuation to the DetNet Use Cases document
> > As you asked feedback about architecture; honestly, I prefer 
> > framework to architecture. Architecture for me is kind of a 
> > solution. I'm most familiar with DetNet, so I'll take it as example. 
> > I think RFC 8655 DetNet Architecture outlines at a high level the 
> > DetNet solution to the problem coming from RFC 8578 DetNet Use Cases 
> > and RFC 8577 DetNet Problem Statement. Of course, RFC
> > individual drafts like the data plane drafts; but still RFC 8655 is 
> > a solution at
> high level.
> >
> > So, a framework seems to be better to me than architecture in order 
> > to remain in the scope of the charter.
> >
> > As for framework, the DetNet Controller Plane Framework draft comes 
> > to my mind. In the DetNet WG we discussed with regards to this draft 
> > that it is good, but it should not specify solution details.
> >
> > I'm just expressing an opinion on which one I'd suggest out of the 
> > two options for the reasons explained above.
> >
> > Best regards,
> > Janos
> >
> >
> > charter. In particular, the charter expects a requirement draft and 
> > an architecture draft but does not require a problem statement.
> >
> > requirements and the PS draft, and started an architecture document. 
> > I just pushed the first version to hint the group of where we wish 
> > to go and
> solicit early feedback.