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

[Abdussalam Baryun <[e-mail]>]

Hi Janos,

On Thu, Apr 2, 2020 at 10:33 PM Janos Farkas <Janos.Farkas=
[e-mail]> wrote:

> Hi Pascal,
>
> Reliability and Availability are unfortunately controversial terms as
> different industries, or even sub-groups of industries have defined them
> independently of each other, hence, very much unfortunately differently. A
> lot of discussion is now happening on it in multiple fora with the
> convergence of Operations Technology, Information Technology, and
> Telecommunications networking. I would not try to redefine them in RAW. We
> may consider taking one of the existing or converged definitions.
>

I think it is better to define them for each technology.

>
> When it comes to packet loss, I have the same information as you: there is
> no tolerance of n consecutive packets in industrial automation for the
> reasons you described. The numbers I heard is no 2 or 3 consecutive packets
> are allowed to be lost.
>

IMO packet lost is not measure for reliability because we still can repeat
is any protocol, the most important issue is packet error rate, receiving
packets with error is a problem, because in wireless there is possibilities
of packet errors and bit errors per packet which could not be corrected. So
we need packet error rate most likely.


> This is also captured in the DetNet use cases:
> https://tools.ietf.org/html/rfc8578#section-7.4
> In DetNet, we did not try to convert this requirement to X nines, but
> introduced new parameter for it:
>
> https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-07#section-5.9.5
>
> As it was also pointed out on the DetNet list, it actually often means
> zero packet loss requirement:
> https://mailarchive.ietf.org/arch/msg/detnet/nkoqM-cBlmIhBoyvs4u6nv-q-t0/


I agree that the packet loss should not be an issue, we need all packets to
be received on time even it was re-sent.


>
>
> So, we need service protection to meet this requirement as described in
> DetNet Architecture:
> https://www.rfc-editor.org/rfc/rfc8655.html#name-service-protection.
>

agree

AB