Subject: [Paw] Renaming

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Apr 2019 07:39:18 +0000

Dear all:

Before we finalize our renaming, another alternate came up, RAW, for reliable available wireless.
It's closer to PAW so it would be less of a surprise. I do not have a strong opinion. Since we already advertised SPAWN maybe it's better t stick to it.
Opinions?

Pascal

---

From: "Dr. Corinna Schmitt" <[email-masked]>
Date: Thu, 4 Apr 2019 10:09:42 +0200

Dear Pascal,

looking on the discussions in der session, especially that we look on so
many different communication standards, I would go for RAW, because it
is more general than SPAWN.

So +1 for RAW.

Regards, Corinna

Am 04.04.19 um 09:39 schrieb Pascal Thubert (pthubert):
> It’s closer to PAW so it would be less of a surprise. I do not have a
> strong opinion. Since we already advertised SPAWN maybe it’s better t
> stick to it.
>
> Opinions?
>
>  
>
> Pascal
>

-- 
******************************************************

Dr. Corinna Schmitt
Researcher and Laboratory Supervisor

Research Institute CODE
Universität der Bundeswehr München

Werner-Heisenberg-Weg 39
85577 Neubiberg, Germany

Phone: +49 (0)89 6004 7314
Email: [email-masked]
https://www.unibw.de/code
https://www.corinna-schmitt.de

---

From: Lou Berger <[email-masked]>
Date: Thu, 4 Apr 2019 10:50:23 -0400

Hi Pascal,

     I think it's good to ensure the name is well aligned with the 
objectives of the group/activity.  I left the BoF a little confused, is 
the scope of this work:

(a) DetNet over any wireless technology using a layered (sub-)networking 
model
     (i.e., each wireless network technology brings it's own
      management/provisioning/control plane)

(b) DetNet over any wireless technology using an integrated 
(sub-)networking model
     (i.e., the objective is a single integrated 
management/provisioning/control plane
      for DetNet and different wireless network technologies)

(c) A control(ler) plane for 6tisch

(d) something else

If (a) or (b), I see no reason to not use DetNet in the name so I like 
DoW (Detnet over Wireless) or DfW (DetNet for Wireless)

if (c) I'd include 6tisch in the name, maybe 6TC (6tisch Control)

Lou

---

From: "Venkatesan, Ganesh" <[email-masked]>
Date: Thu, 4 Apr 2019 15:10:47 +0000

My understanding is that it is mostly (a) with some common management/provisioning/control that you describe in (b). DoW would probably be more apt for what our objectives are.

Cheers --
ganesh
 
-----Original Message-----
From: Paw <[email-masked]> On Behalf Of Lou Berger
Sent: Thursday, April 4, 2019 7:50 AM
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Subject: Re: [Paw] Renaming

Hi Pascal,

     I think it's good to ensure the name is well aligned with the objectives of the group/activity.  I left the BoF a little confused, is the scope of this work:

(a) DetNet over any wireless technology using a layered (sub-)networking model
     (i.e., each wireless network technology brings it's own
      management/provisioning/control plane)

(b) DetNet over any wireless technology using an integrated (sub-)networking model
     (i.e., the objective is a single integrated management/provisioning/control plane
      for DetNet and different wireless network technologies)

(d) something else

If (a) or (b), I see no reason to not use DetNet in the name so I like DoW (Detnet over Wireless) or DfW (DetNet for Wireless)

Lou

On 4/4/2019 3:39 AM, Pascal Thubert (pthubert) wrote:
> It's closer to PAW so it would be less of a surprise. I do not have a 
> strong opinion. Since we already advertised SPAWN maybe it's better t 
> stick to it.
>
> Opinions?
>
> Pascal
>
>

--
Paw mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/paw

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 4 Apr 2019 16:31:44 +0000

I agree with that, that is mostly a), but sill would love to be able to express a multihop schedule possibly across technology.
Which means that we need an abstraction at layer 3 where we can express timing offsets, things like that.
6TiSCH comes into play because from there we already have experience on multihop scheduling, even if the group itself did not work on it beyond the architecture.
What the group would describe is complex path ala DetNet but with additional properties like overhearing, HARQ, and possibly constructive interference, for which we need to extend the detNet PREOF abstraction. Depending on the radio technology it could impose a time boundary to the transmission, or even dig into link selection which may abstract a radio channel or a beam.
If you look at LPWAN, we provided generic methods like SCHC, and then there are radio specific documents that explain how this is translates on a particular radio, mostly by constraining to the subset of the generic model that is meaningful on that radio. I'd like to stick to that model of making sure that what we do is generic enough for a covered set of radios. 
I do not know if the charter will go as far as enable the group to produce c). It is not my priority but it does not seem that complicated either. If it does, I'd like to see the same for the other technologies, understanding that for the most part the scheduling is done under the cover so L3 can at bets provide hints to be defined, like a transmission deadline in absolute time.

About the name, We cannot have Deterministic in it, even hidden in the DetNet abbreviation. "Deterministic" raises too much concern/discussion on the wireless piece. We has that discussion and concluded with SPAWN. RAW came later but I find it quite good so if there was a strong support from the group, I'd see no problem to swap. We'll also need to provide a definition of reliability and availability and as we discussed, 5nines is probably not the only or even best way to express any of that. Juliusz actually raised the point and I hope he continues on that path and even produces a spec for us.

At the moment the proposed charter is like this:
"

    The group will:

        1) Produce informational work describing deterministic wireless
           use cases, in continuation to the DetNet Use Cases document
		
         2) Produce informational work describing the technologies that the
            group will cover (e.g., URLLC, TSCH, EHT and LDACS) 

        3) Produce a Standards Track document to define the generic data models
           to install a SPAWN flow along a track providing packet replication, 
           elimination and ordering functions with spatial, frequency and time
           diversity in a scheduled FD/TDMA wireless network.

        4) Produce a Standards Track document to enable operations, 
           administration and maintenance (OAM) inside a SPAWN network, providing
           packet loss evaluation and automated adaptation to enable trade-offs
           between resilience and energy consumption.

"

Do you think we nee to change it to address better you're a, b or c question?

All the best,

Pascal

> From: Venkatesan, Ganesh <[email-masked]>
> Sent: jeudi 4 avril 2019 17:11
> To: Lou Berger <[email-masked]>; Pascal Thubert (pthubert)
> <[email-masked]>; [email-masked]
> Subject: RE: [Paw] Renaming
> 
> My understanding is that it is mostly (a) with some common
> management/provisioning/control that you describe in (b). DoW would
> probably be more apt for what our objectives are.
> 
> Cheers --
> ganesh
> 
>      I think it's good to ensure the name is well aligned with the objectives of
> the group/activity.  I left the BoF a little confused, is the scope of this work:
> 
> If (a) or (b), I see no reason to not use DetNet in the name so I like DoW
> (Detnet over Wireless) or DfW (DetNet for Wireless)
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 4 Apr 2019 12:51:10 -0400

Hi Pascal,

The core deliverables (3) and (4) are certainly much more centered on 
wireless (sub and cross) network specifics than I expected from a "DoW"  
perspective, so do agree that avoiding DetNet in at least the naming of 
this effort makes sense.

 > Do you think we nee to change it to address better you're a, b or c 
question?

 From you response, I think you're saying the planned work scope is 
perhaps closer to (d) i.e., something different.

Thanks,

Lou

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 05 Apr 2019 01:40:25 +0200

> We'll also need to provide a definition of reliability and availability
> and as we discussed, 5nines is probably not the only or even best way to
> express any of that. Juliusz actually raised the point and I hope he
> continues on that path and even produces a spec for us.

I'm flattered you think so, but I'm pretty sure I'm not competent.  You'd
need someone with more of a background in probability and statistics.

-- Juliusz

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 5 Apr 2019 08:55:02 +0000

Hello Juliusz:

Actually the theoretical work has been done a while ago, as  a response to your question at the mike when I suggested you dig for MTBF or similar (MTTF, MTBE...). We tend to express a network form of MTBF in a number of 9s. Like five 9s would indicate that the Mean Successful Transmissions Between Errors is 99999. A number of use cases would thrive on 1% loss as long as losses are always well spaced so the missing points can be recovered. This can be true for an industrial control loop, and false for burning a master video. The N 9s are there to make the occurrence of P (say, 4) losses in a row very rare, like a probability of 1/10^(N*P). But the 9s are for unrelated errors and fail to convey a rare burst of errors with a common cause, which is what really hurts. These things happen on radios and that's why we are after diverse paths etc..

There's enough stats for is in https://ftp.automationdirect.com/pub/Product%20Reliability%20and%20MTBF.pdf to take us a long way. Our problem is to migrate the concept from a product to a sequence of nodes and then to more complex structures. This could be refined in an academic paper, I expect that'd be a great topic, and then an RFC would summarize that.

What I'd like to see is an informational RFC that presents wireless reliability in a way that can be consumed by the IETF members, and provides terminology that can be referred in our specs. You seemed curious about the topic; that's quality number one for achieving great results : )

All the best,

Pascal

More links:
http://www.bb-elec.com/Learning-Center/All-White-Papers/Fiber/MTBF,-MTTR,-MTTF,-FIT-Explanation-of-Terms/MTBF-MTTR-MTTF-FIT-10262012-pdf.pdf
https://books.google.nl/books?id=rNLSBQAAQBAJ&pg=PA171&lpg=PA171&dq=reliability+MTBF+MTBE+papers&source=bl&ots=L7BsInfaO3&sig=ACfU3U0kYd1lGRyRR_aD5AET9LOI8ZfZWg&hl=fr&sa=X&ved=2ahUKEwisr-LirLjhAhWPZ1AKHe8yARwQ6AEwA3oECAgQAQ

https://www.dfrsolutions.com/blog/the-challenges-of-wireless-reliability

> From: Juliusz Chroboczek <[email-masked]>
> Sent: vendredi 5 avril 2019 01:40
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Venkatesan, Ganesh <[email-masked]>; Lou Berger
> <[email-masked]>; [email-masked]
> > We'll also need to provide a definition of reliability and
> > availability and as we discussed, 5nines is probably not the only or
> > even best way to express any of that. Juliusz actually raised the
> > point and I hope he continues on that path and even produces a spec for us.
> 
> I'm flattered you think so, but I'm pretty sure I'm not competent.  You'd need
> someone with more of a background in probability and statistics.
> 
> -- Juliusz

---

From: Hesham ElBakoury <[email-masked]>
Date: Fri, 5 Apr 2019 10:02:11 +0000

There is a good book on reliability by Michael Tortorella. The book is "Reliability, Maintainability, and Supportability: Best Practices for Systems Engineers". It is available from Wiley.

Hesham

-----Original Message-----
From: Paw [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Friday, April 5, 2019 1:55 AM
To: Juliusz Chroboczek <[email-masked]>
Cc: Lou Berger <[email-masked]>; [email-masked]; Venkatesan, Ganesh <[email-masked]>
Subject: Re: [Paw] Renaming

Hello Juliusz:

All the best,

Pascal

More links:

> From: Juliusz Chroboczek <[email-masked]<mailto:[email-masked]>>

> To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>

> Cc: Venkatesan, Ganesh <[email-masked]<mailto:[email-masked]>>; Lou Berger

> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> I'm flattered you think so, but I'm pretty sure I'm not competent.

> You'd need someone with more of a background in probability and statistics.

--

Paw mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 5 Apr 2019 08:50:57 -0300

Pascal,
           Shall we split this e-mail between the renaming
topic and the reliability metrics discussion? I think both
items are really relevant to the group and deserve their
individual space.
Regards,

                             Diego Dujovne

Le ven. 5 avr. 2019 à 07:03, Hesham ElBakoury <[email-masked]>
a écrit :

> There is a good book on reliability by Michael Tortorella. The book is "*Reliability,
> Maintainability, and Supportability: Best Practices for Systems Engineers*".
> It is available from Wiley.
>
> Hesham
>
>
>
> Actually the theoretical work has been done a while ago, as  a response to
> your question at the mike when I suggested you dig for MTBF or similar
> (MTTF, MTBE...). We tend to express a network form of MTBF in a number of
> 9s. Like five 9s would indicate that the Mean Successful Transmissions
> Between Errors is 99999. A number of use cases would thrive on 1% loss as
> long as losses are always well spaced so the missing points can be
> recovered. This can be true for an industrial control loop, and false for
> burning a master video. The N 9s are there to make the occurrence of P
> (say, 4) losses in a row very rare, like a probability of 1/10^(N*P). But
> the 9s are for unrelated errors and fail to convey a rare burst of errors
> with a common cause, which is what really hurts. These things happen on
> radios and that's why we are after diverse paths etc..
>
>
>
> There's enough stats for is in
> https://ftp.automationdirect.com/pub/Product%20Reliability%20and%20MTBF.pdf
> to take us a long way. Our problem is to migrate the concept from a product
> to a sequence of nodes and then to more complex structures. This could be
> refined in an academic paper, I expect that'd be a great topic, and then an
> RFC would summarize that.
>
>
>
> What I'd like to see is an informational RFC that presents wireless
> reliability in a way that can be consumed by the IETF members, and provides
> terminology that can be referred in our specs. You seemed curious about the
> topic; that's quality number one for achieving great results : )
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
> More links:
>
>
> https://www.ietf..org/mailman/listinfo/paw
> <https://www.ietf.org/mailman/listinfo/paw>
> --
> Paw mailing list
> [email-masked]

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125