Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Nov 2016 14:04:49 +0000

+1 : )

From: detnet [mailto:[email-masked]] On Behalf Of nfinn
Sent: mardi 1 novembre 2016 07:59
To: Grossman, Ethan A. <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; Olivier Marce <[email-masked]>
Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs?

I think that’s a very good summary of my preferred approach.  Is it satisfactory for you?

— Norm

On Oct 31, 2016, at 4:53 PM, Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>> wrote:

Hi Pascal, Olivier, Norm, WG,
So the consensus is, to paraphrase Norm:

1) Make sure that the time protocols are able to report, along with the time, the accuracy provided.
2) The application will decide whether that is sufficient.
3) The accuracy reported will likely consist of several parameters (frequency accuracy, absolute accuracy, etc.).
4) Different time protocols may have different parameters for accuracy.
5) An application might care about one or more of those parameters.
6) An application might then operate in one of various modes, depending on the accuracy provided.

If anyone has any other understanding or input, please reply.
Thanks,
Ethan.

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, October 11, 2016 4:29 AM
To: Olivier Marce; [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs?

This is my understanding too, Olivier.

Also, time-related work is done elsewhere, whether one thinks of IETF or outside the IETF. We do not want to be taken in the middle of that storm.
Best can do is probably state requirements, but for all I know we are using time as an information provided by external means, as opposed to managing it.

Cheers,

Pascal

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Olivier Marce
Sent: jeudi 6 octobre 2016 12:05
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs?

Hi,
I'm in favor of Norm' position: DetNet should concentrate on  reliable, on-time delivery of packets. Time accuracy is required for DetNet but out of scope, as many solutions exist and is not only a networking topic.
At most, DetNet could provide some reference examples on how providing required time accuracy.

Regards

Le 06/10/2016 à 03:30, nfinn a écrit :

Interesting question.

It seems more useful to me to make sure that the time protocols are
able to report, along with the time, the accuracy provided.  The
application can then decide whether that is sufficient.  The accuracy
reported will likely consist of several parameters (frequency
accuracy, absolute accuracy, etc.).  Different time protocols may have
different parameters for accuracy.  The application might worried
about one or the other of those parameters.  It might operate in
different modes, depending on the accuracy provided.  I don't see the
value in moving the decision point anywhere else.

With DetNet, one can imagine a bandwidth reservation crossing a
boundary between two different master clock domains.  My inclination
would be to disallow that, at least for now.  Given an application
that runs for long enough, any frequency difference between source and
sink will eventually cause starvation or overflow.

All that said, let's suppose that you have a solid use case that is
expected to *try* to run across clock domain boundaries, and we want
to prevent that when it won't work.  This could be solved by an
application-level protocol that exchanges clock domain information.
This could be solved by configuring the network controller to
disallow domain crossings.  This could be handled by parameters in the
reservation protocol, as you suggest, so that the controller can allow
some reservations but not others.  I'll leave it to timing experts to
pick some number of appropriate parameters.

One last consideration - Are you sure that all applications that have
these timing requirements also require bandwidth reservations?  I'm
not sure of that.  And, if not, a protocol separate from the bandwidth
reservation might be indicated.

- Norm

On Oct 5, 2016, at 4:09 PM, Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

Hi Folks,

As of our IETF 96 meeting there were still a couple of Use Case
Statements that I would like clarity on. Here's the first, remaining
to follow in separate emails.

Question:
How will an application express its time accuracy and reliability
needs? Is that within scope of DetNet?

Discussion:
In AVB/TSN when an application (talker) attempts to make a stream
reservation it must state how much bandwidth that stream reservation
requires. Presumably in a LAN this is sufficient since a LAN
presumably has consistent time accuracy and reliability metrics.

For DetNet, in which we support interconnected DetNet networks and
have widely varying requirements for timing accuracy and reliability
depending on the use case, it appears to me that we need to allow an
application to provide this kind of information to the network, and a
way for the network to either agree or decline to provide the
requested service (analogous to AVB/TSN accepting or declining a
stream reservation based on the bandwidth requested).

We have had some discussion about this (see below) but nothing near
consensus. Other thoughts from anyone?
Ethan.

--------------------------------
Discussion, oldest item first:

Ethan Grossman wrote:
Timekeeping - the only explicit DetNet Ask for this is in the use
cases is in M2M as "Precise time synchronization accuracy (1us)" and
I think the intent (as in other use cases) is that the DetNet Ask is
for a way to specify the required accuracy, not how to achieve that accuracy.

Norm Finn wrote:
Timekeeping is an essential part of many, probably most, of the
applications that also find DetNet useful.  That having been said, so
is protection against EMI and electrical power saving. Let's
concentrate DetNet on reliable, on-time delivery of packets.  I'm not
even sure that "a way to specify the required accuracy" need be in scope.

Rodney Cummings wrote:
I rarely disagree with Norm, but on this point I'll have to quibble a bit.
I agree that we don't need DetNet to specify how time sync is
accomplished. There are plenty of IEEE 1588 techniques (and similar)
for that purpose.
I also agree that we should concentrate on reliable, on-time delivery
of packets (i.e. worst-case latency).
If I don't know how accurate my time sync is, then how do I know when
a packet is delivered on time? If I don't know the reliability of my
time sync, how can I reliably measure that packet delivery?
Almost all (if not 100%) of DetNet use cases require time sync at the
end systems to some degree of accuracy. I agree that we don't need to
address the implementation of that time sync, but the application
requirements are needed for time sync (including reliability) just as
much as for packet delivery.
--------------------------------

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet

--
Olivier Marcé
Nokia Bell Labs France
"we need to guard against increased levels of reporting and other requirements that distract you from doing what you really need to be doing." Rajeev Suri, Nokia CEO, April 2016

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 2 Nov 2016 08:43:46 -0700

looks good to me.

- jouni

> On Oct 31, 2016, at 11:59 PM, nfinn <[email-masked]> wrote:
> 
>> On Oct 31, 2016, at 4:53 PM, Grossman, Ethan A. <[email-masked]> wrote:
>> 
>> To: Olivier Marce; [email-masked]
>> To: [email-masked]
>>>> On Oct 5, 2016, at 4:09 PM, Grossman, Ethan A. <[email-masked] 
>>>> [email-masked] <mailto:[email-masked]> 
>>> [email-masked]
>> [email-masked]
>> [email-masked]
>> [email-masked]
> [email-masked]

--
Jouni Korhonen, Broadcom Ltd.
M: +1-408-391-7160

---

From: "Patrick Wetterwald (pwetterw)" <[email-masked]>
Date: Wed, 2 Nov 2016 15:51:33 +0000

I’m just wondering if this has to be reported to the application or to the PCE in case of central computing?

Application asks for the accuracy then the PCE answers if this is possible or not.

We may have both cases.

Thanks,

Patrick

On 02/11/2016, 16:43, "detnet on behalf of Jouni Korhonen" <[email-masked] on behalf of [email-masked]> wrote:

    looks good to me.
    
    - jouni

---

From: nfinn <[email-masked]>
Date: Wed, 2 Nov 2016 09:58:08 -0700

Patrick,

If you want to work on this approach, I don’t want to stop you.  But, it looks to me that it increases the number of options (and thus, everyone’s work load) with no benefit gained.

If the application has time requirements, I assume that it is able to synchronize its clock using one or more specific protocols, and therefore knows how to interpret each of those protocols’ accuracy information.  Problem solved.  Teaching the application to ask the PCE 1) requires that a PCE b e present, and 2) requires the application to implement a query/response of some kind to express its requirements and understand the answer.  Keep in mind that the answer is not always “yes/no”.  Perhaps the application can operate in different modes, depending on clock accuracy.

Of course, if you or any expert in the time protocols tell us that only a centralized controller can make the determination for a significant class of use cases, I’m ready to change my mind.

— Norm

> On Nov 2, 2016, at 8:51 AM, Patrick Wetterwald (pwetterw) <[email-masked]> wrote:
>

---

From: "Patrick Wetterwald (pwetterw)" <[email-masked]>
Date: Thu, 3 Nov 2016 16:00:45 +0000

Hi Norm,

I agree that Detnet should not spend too much time on time synchronization and time accuracy. I just wanted to express that if we want / need to report time accuracy, the application is not the only one interested in such information. In case of a PCE based Detnet, the PCE is one of the recipient of this information.

Some applications may have their own time reference (based on GPS for instance).  What the application expects from a Detnet network is guarantee of delivery in a maximum latency with a bounded jitter and it differs to the PCE to handle all that is needed to ensure it.

Does it make sense?

Thanks,

Patrick

On 02/11/2016, 17:58, "nfinn" <[email-masked]> wrote:

    Patrick,

    
    
    — Norm

---

From: nfinn <[email-masked]>
Date: Thu, 3 Nov 2016 10:43:57 -0700

Agreed!

— Norm

> On Nov 3, 2016, at 9:00 AM, Patrick Wetterwald (pwetterw) <[email-masked]> wrote:
> 
> Hi Norm,
>

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Mon, 7 Nov 2016 23:24:28 +0000

In starting this thread I inadvertently included two topics - 1) expressing timing accuracy, and 2) expressing reliability, so I am spinning out the latter into this new thread.  

My question here is "Is the reliability (e.g. number of 9's) a fixed property of the given DetNet, or is it something that can be configured on a per-flow basis via an API?"  
For example a DetNet might provide one redundant path, or two redundant paths, resulting in two distinct levels of reliability, and that could be be "for all flows" or on a "per-flow" basis. 
I would assume that the app should be able to query the network for the reliability figure (or range, or options), then based on that, specify the choice to the network for a given flow? 
Is there an existing API for that? 

Thanks,
Ethan.

________________________________________
From: nfinn <[email-masked]>
Sent: Thursday, November 3, 2016 10:43 AM
To: Patrick Wetterwald (pwetterw)
Cc: Jouni Korhonen; Grossman, Ethan A.; Pascal Thubert; [email-masked]; Olivier Marce
Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs?

Agreed!

— Norm

---

From: Yu KANEKO <[email-masked]>
Date: Tue, 8 Nov 2016 15:19:51 +0900

Hi Ethan, Folks,

IMO, reliability is a property for "per-flow". I think most of industrial automation systems (e.g. building automation) require the same reliability for each redundant path, but considering reliability as a per-flow property is more flexible approach.

I assume that application has a reliability requirement (e.g., 99.999%) and the app or a controller translate it to data plane parameters (buffer allocation size, packet transfer schedule, etc.), and configures DetNet nodes.

Regards,
Kaneko

> 2016/11/08 8:24、Grossman, Ethan A. <[email-masked]> のメール：
>

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 8 Nov 2016 06:25:38 +0000

Hi,

Good topic. :--)) So far DetNet work focused mainly on forwarding parameters (delay, jitter and loss),
but service parameters (e.g., availability, MTBF, etc.) are also important for a DetNet use-case.

Reliability (availability) provided in a given DetNet depends on several factors (e.g., location of endpoints, 
network topology, supported redundancy methods, maintenance processes, etc.). The usual approach of 
service providers is to define some availability values the customers can select for their service. 

The same should apply for DetNet service, therefore reliability must be a per-flow service parameter. 
And as You wrote it may impact the number of required redundant paths.

Cheers
Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Grossman, Ethan A.
Sent: Tuesday, November 08, 2016 12:24 AM
To: [email-masked]
Subject: [Detnet] DetNet Use Case Statements - How to express app reliability needs?

Thanks,
Ethan.

Agreed!

- Norm

>    If you want to work on this approach, I don't want to stop you.  But, it looks to me that it increases the number of options (and thus, everyone's work load) with no benefit gained.
>
>    If the application has time requirements, I assume that it is able to synchronize its clock using one or more specific protocols, and therefore knows how to interpret each of those protocols' accuracy information.  Problem solved.  Teaching the application to ask the PCE 1) requires that a PCE b e present, and 2) requires the application to implement a query/response of some kind to express its requirements and understand the answer.  Keep in mind that the answer is not always "yes/no".  Perhaps the application can operate in different modes, depending on clock accuracy.
>
>    Of course, if you or any expert in the time protocols tell us that only a centralized controller can make the determination for a significant class of use cases, I'm ready to change my mind.
>
>    - Norm
>
>> I'm just wondering if this has to be reported to the application or to the PCE in case of central computing?
>>
>>> I think that's a very good summary of my preferred approach.  Is it satisfactory for you?
>>>
>>> - Norm
>>>
>>>>> It seems more useful to me to make sure that the time protocols 
>>>>> are able to report, along with the time, the accuracy provided.  
>>>>> The application can then decide whether that is sufficient.  The 
>>>>> accuracy reported will likely consist of several parameters 
>>>>> (frequency accuracy, absolute accuracy, etc.).  Different time 
>>>>> protocols may have different parameters for accuracy.  The 
>>>>> application might worried about one or the other of those 
>>>>> parameters.  It might operate in different modes, depending on the 
>>>>> accuracy provided.  I don't see the value in moving the decision point anywhere else.
>>>>>
>>>>> boundary between two different master clock domains.  My 
>>>>> inclination would be to disallow that, at least for now.  Given an 
>>>>> application that runs for long enough, any frequency difference 
>>>>> between source and sink will eventually cause starvation or overflow.
>>>>>
>>>>> All that said, let's suppose that you have a solid use case that 
>>>>> is expected to *try* to run across clock domain boundaries, and we 
>>>>> want to prevent that when it won't work.  This could be solved by 
>>>>> an application-level protocol that exchanges clock domain information.
>>>>> disallow domain crossings.  This could be handled by parameters in 
>>>>> the reservation protocol, as you suggest, so that the controller 
>>>>> can allow some reservations but not others.  I'll leave it to 
>>>>> timing experts to pick some number of appropriate parameters.
>>>>>
>>>>> One last consideration - Are you sure that all applications that 
>>>>> have these timing requirements also require bandwidth 
>>>>> reservations?  I'm not sure of that.  And, if not, a protocol 
>>>>> separate from the bandwidth reservation might be indicated.
>>>>>
>>>>> - Norm
>>>>>
>>>>>> Statements that I would like clarity on. Here's the first, 
>>>>>> remaining to follow in separate emails.
>>>>>>
>>>>>> Question:
>>>>>> reservation it must state how much bandwidth that stream 
>>>>>> reservation requires. Presumably in a LAN this is sufficient 
>>>>>> since a LAN presumably has consistent time accuracy and reliability metrics.
>>>>>>
>>>>>> For DetNet, in which we support interconnected DetNet networks 
>>>>>> and have widely varying requirements for timing accuracy and 
>>>>>> reliability depending on the use case, it appears to me that we 
>>>>>> need to allow an application to provide this kind of information 
>>>>>> to the network, and a way for the network to either agree or 
>>>>>> decline to provide the requested service (analogous to AVB/TSN 
>>>>>> accepting or declining a stream reservation based on the bandwidth requested).
>>>>>>
>>>>>> We have had some discussion about this (see below) but nothing 
>>>>>> near consensus. Other thoughts from anyone?
>>>>>> Ethan.
>>>>>>
>>>>>> cases is in M2M as "Precise time synchronization accuracy (1us)" 
>>>>>> and I think the intent (as in other use cases) is that the DetNet 
>>>>>> Ask is for a way to specify the required accuracy, not how to achieve that accuracy.
>>>>>>
>>>>>> Norm Finn wrote:
>>>>>> applications that also find DetNet useful.  That having been 
>>>>>> said, so is protection against EMI and electrical power saving. 
>>>>>> Let's concentrate DetNet on reliable, on-time delivery of 
>>>>>> packets.  I'm not even sure that "a way to specify the required accuracy" need be in scope.
>>>>>>
>>>>>> Rodney Cummings wrote:
>>>>>> accomplished. There are plenty of IEEE 1588 techniques (and 
>>>>>> similar) for that purpose.
>>>>>> I also agree that we should concentrate on reliable, on-time 
>>>>>> delivery of packets (i.e. worst-case latency).
>>>>>> If I don't know how accurate my time sync is, then how do I know 
>>>>>> when a packet is delivered on time? If I don't know the 
>>>>>> reliability of my time sync, how can I reliably measure that packet delivery?
>>>>>> Almost all (if not 100%) of DetNet use cases require time sync at 
>>>>>> the end systems to some degree of accuracy. I agree that we don't 
>>>>>> need to address the implementation of that time sync, but the 
>>>>>> application requirements are needed for time sync (including 
>>>>>> reliability) just as much as for packet delivery.
>>>> "we need to guard against increased levels of reporting and other 
>>>> requirements that distract you from doing what you really need to 
>>>> be doing." Rajeev Suri, Nokia CEO, April 2016
>>>>

---

From: Norman Finn <[email-masked]>
Date: Tue, 8 Nov 2016 08:56:30 -0600

Others have given good answers to this question.  Here’s my $0.02.

My first thought (in an IEEE contribution a few years ago) was that an application could specify its reliability requirement for a given flow, and the network would meet it or say, “No.”  And, ultimately, that may be achievable.  But, not easily.

For example — does you application *really* know whether it needs 10^-12 or 10^-13 loss rate?  Does the network *really* know whether it can deliver 10^-12 or 10^-13?  

I’m leaning, at this time, towards:

  • The network operator defines some small number of classes of delivery reliability, based on number of paths, whether the paths have wireless links, or whatever other variables are present in the network.  Note that these classes may have criteria other than simply, "probability of loss".  At the very least, there are a range of loss rates for different time scales, that take MTTR into account.

  • The app owners decide which class of reliability is required for each flow, and how to balance network reliability against application-level mitigation of failures.

  • At run time, a reservation request includes a reliability class specifier.

  • The app owners and network administrators have to find network design, app design, and class structure that gives a cost-effective solution to the overall problem.

This is not dissimilar to the DiffServ situation.  We (DetNet) might or might not be able to define some useful guidelines for reliability classes that are widely applicable.

Having this paradigm in mind might help us define useful ways to parameterize the problem.

— Norm

> On Nov 7, 2016, at 17:24, Grossman, Ethan A. <[email-masked]> wrote:
>

---

From: Balázs Varga A <[email-masked]>
Date: Tue, 8 Nov 2016 16:33:15 +0000

Hi Norm,

Agree the direction except one particular part, namely how you have defined loss.
> ... At the very least, there are a range of loss rates for different time scales, that 
> take MTTR into account.
We should not couple loss and availability so tight via MTTR. It is more usual to define 
service parameters as follows:
- Loss rate: ratio of lost and forwarded packets when the service is available. 
- Availability: when forwarding parameters (BW, delay, etc.) are meet. 
For example if you have a network outage then service is not available. During that
period of time the loss rate is 100 percent. Furthermore operators usually extract 
some time periods (e.g. predefined maintenance time, etc.) when calculating 
availability.

Therefore the application should require two set of parameters:
- transport parameters (BW, delay, jitter, loss, etc.)
- service parameters (availability, MTTR, etc.)

Cheers
Bala'zs

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Norman Finn
Sent: Tuesday, November 08, 2016 3:57 PM
To: Grossman, Ethan A. <[email-masked]>
Cc: [email-masked]
Subject: Re: [Detnet] DetNet Use Case Statements - How to express app reliability needs?

— Norm

>>>>>> parameters.  It might operate in different modes, depending on 
>>>>>> the accuracy provided.  I don't see the value in moving the decision point anywhere else.
>>>>>> 
>>>>>> inclination would be to disallow that, at least for now.  Given 
>>>>>> an application that runs for long enough, any frequency 
>>>>>> difference between source and sink will eventually cause starvation or overflow.
>>>>>> 
>>>>>> is expected to *try* to run across clock domain boundaries, and 
>>>>>> we want to prevent that when it won't work.  This could be solved 
>>>>>> by an application-level protocol that exchanges clock domain information.
>>>>>> disallow domain crossings.  This could be handled by parameters 
>>>>>> in the reservation protocol, as you suggest, so that the 
>>>>>> controller can allow some reservations but not others.  I'll 
>>>>>> leave it to timing experts to pick some number of appropriate parameters.
>>>>>> 
>>>>>>> How will an application express its time accuracy and 
>>>>>>> reliability needs? Is that within scope of DetNet?
>>>>>>> 
>>>>>>> Discussion:
>>>>>>> In AVB/TSN when an application (talker) attempts to make a 
>>>>>>> stream reservation it must state how much bandwidth that stream 
>>>>>>> -------------------------------- Discussion, oldest item first:
>>>>>>> 
>>>>>>> Ethan Grossman wrote:
>>>>>>> Timekeeping - the only explicit DetNet Ask for this is in the 
>>>>>>> use cases is in M2M as "Precise time synchronization accuracy 
>>>>>>> (1us)" and I think the intent (as in other use cases) is that 
>>>>>>> the DetNet Ask is for a way to specify the required accuracy, not how to achieve that accuracy.
>>>>>>> 
>>>>>>> Norm Finn wrote:
>>>>>>> Almost all (if not 100%) of DetNet use cases require time sync 
>>>>>>> at the end systems to some degree of accuracy. I agree that we 
>>>>>>> don't need to address the implementation of that time sync, but 
>>>>>>> the application requirements are needed for time sync (including

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Tue, 8 Nov 2016 13:59:27 -0300

Dear all,
              I wonder if you have included burstiness as a measure of the
number of consecutive packet loss.
Regards,

         Diego

El nov 8, 2016 1:33 PM, "Balázs Varga A" <[email-masked]>
escribió:

> My first thought (in an IEEE contribution a few years ago) was that an
> application could specify its reliability requirement for a given flow, and
> the network would meet it or say, “No.”  And, ultimately, that may be
> achievable.  But, not easily.
>
> For example — does you application *really* know whether it needs 10^-12
> or 10^-13 loss rate?  Does the network *really* know whether it can deliver
> 10^-12 or 10^-13?
>
>   • The network operator defines some small number of classes of delivery
> reliability, based on number of paths, whether the paths have wireless
> links, or whatever other variables are present in the network.  Note that
> these classes may have criteria other than simply, "probability of loss".
> At the very least, there are a range of loss rates for different time
> scales, that take MTTR into account.
>
>   • The app owners decide which class of reliability is required for each
> flow, and how to balance network reliability against application-level
> mitigation of failures.
>
>   • The app owners and network administrators have to find network design,
> app design, and class structure that gives a cost-effective solution to the
> overall problem.
>
> This is not dissimilar to the DiffServ situation.  We (DetNet) might or
> might not be able to define some useful guidelines for reliability classes
> that are widely applicable.
>
> > In starting this thread I inadvertently included two topics - 1)
> expressing timing accuracy, and 2) expressing reliability, so I am spinning
> out the latter into this new thread.
> >
> > My question here is "Is the reliability (e.g. number of 9's) a fixed
> property of the given DetNet, or is it something that can be configured on
> a per-flow basis via an API?"
> > For example a DetNet might provide one redundant path, or two redundant
> paths, resulting in two distinct levels of reliability, and that could be
> be "for all flows" or on a "per-flow" basis.
> > I would assume that the app should be able to query the network for the
> reliability figure (or range, or options), then based on that, specify the
> choice to the network for a given flow?
> >> I agree that Detnet should not spend too much time on time
> synchronization and time accuracy. I just wanted to express that if we want
> / need to report time accuracy, the application is not the only one
> interested in such information. In case of a PCE based Detnet, the PCE is
> one of the recipient of this information.
> >>
> >> Some applications may have their own time reference (based on GPS for
> instance).  What the application expects from a Detnet network is guarantee
> of delivery in a maximum latency with a bounded jitter and it differs to
> the PCE to handle all that is needed to ensure it.
> >>
> >> Does it make sense?
> >>
> >> Thanks,
> >>
> >> Patrick
> >>
> >>   If you want to work on this approach, I don’t want to stop you.  But,
> it looks to me that it increases the number of options (and thus,
> everyone’s work load) with no benefit gained.
> >>
> >>   If the application has time requirements, I assume that it is able to
> synchronize its clock using one or more specific protocols, and therefore
> knows how to interpret each of those protocols’ accuracy information.
> Problem solved.  Teaching the application to ask the PCE 1) requires that a
> PCE b e present, and 2) requires the application to implement a
> query/response of some kind to express its requirements and understand the
> answer.  Keep in mind that the answer is not always “yes/no”.  Perhaps the
> application can operate in different modes, depending on clock accuracy.
> >>
> >>   Of course, if you or any expert in the time protocols tell us that
> only a centralized controller can make the determination for a significant
> class of use cases, I’m ready to change my mind.
> >>
> >>   — Norm
> >>
> >>> On 02/11/2016, 16:43, "detnet on behalf of Jouni Korhonen" <
> [email-masked] on behalf of [email-masked]> wrote:
> >>>
> >>>  looks good to me.
> >>>
> >>>  - jouni
> >>>
> >>>>> 3) The accuracy reported will likely consist of several parameters
> (frequency accuracy, absolute accuracy, etc.).
> >>>>> Also, time-related work is done elsewhere, whether one thinks of
> IETF or outside the IETF. We do not want to be taken in the middle of that
> storm.
> >>>>> Best can do is probably state requirements, but for all I know we
> are using time as an information provided by external means, as opposed to
> managing it.
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Pascal
> >>>>>
> >>>>> I'm in favor of Norm' position: DetNet should concentrate on
> reliable, on-time delivery of packets. Time accuracy is required for DetNet
> but out of scope, as many solutions exist and is not only a networking
> topic.

---

From: Norman Finn <[email-masked]>
Date: Tue, 8 Nov 2016 13:32:52 -0600

Yours sounds like a more useful way to characterize the requirements.

— Norm

> On Nov 8, 2016, at 10:33, Balázs Varga A <[email-masked]> wrote:
> 
> Hi Norm,
>

---

From: Norman Finn <[email-masked]>
Date: Tue, 8 Nov 2016 13:34:35 -0600

Good question, Diego.  I think that Balázs’s availability / loss rate does, in effect, give that, doesn’t it?  A burst of errors would, presumably, be counted as a loss of availability.  Or, were you thinking of something more complex?

— Norm
 
> On Nov 8, 2016, at 10:59, Prof. Diego Dujovne <[email-masked]> wrote:
> 
> Dear all,
>               I wonder if you have included burstiness as a measure of the number of consecutive packet loss.
> Regards,
> 
>          Diego
> 
> El nov 8, 2016 1:33 PM, "Balázs Varga A" <[email-masked] <mailto:[email-masked]>> escribió:
> Hi Norm,
> 
> From: detnet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Norman Finn
> To: Grossman, Ethan A. <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> > On Nov 7, 2016, at 17:24, Grossman, Ethan A. <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > From: nfinn <[email-masked] <mailto:[email-masked]>>
> > Cc: Jouni Korhonen; Grossman, Ethan A.; Pascal Thubert;
> > [email-masked] <mailto:[email-masked]>; Olivier Marce
> >> On Nov 3, 2016, at 9:00 AM, Patrick Wetterwald (pwetterw) <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> Hi Norm,
> >>
> >> On 02/11/2016, 17:58, "nfinn" <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >>   Patrick,
> >>
> >>> On Nov 2, 2016, at 8:51 AM, Patrick Wetterwald (pwetterw) <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>> On 02/11/2016, 16:43, "detnet on behalf of Jouni Korhonen" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>>  looks good to me.
> >>>
> >>>  - jouni
> >>>
> >>>> On Oct 31, 2016, at 11:59 PM, nfinn <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>
> >>>>> On Oct 31, 2016, at 4:53 PM, Grossman, Ethan A. <[email-masked] <mailto:[email-masked]>> wrote:
> >>>>>
> >>>>> From: detnet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Pascal
> >>>>> Thubert (pthubert)
> >>>>> To: Olivier Marce; [email-masked] <mailto:[email-masked]>
> >>>>> From: detnet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Olivier
> >>>>> Marce
> >>>>> To: [email-masked] <mailto:[email-masked]>
> >>>>>>> On Oct 5, 2016, at 4:09 PM, Grossman, Ethan A. <[email-masked] <mailto:[email-masked]>
> >>>>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >>>>>>>
> >>>>>>> Hi Folks,
> >>>>>>>
> >>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >>>>>>> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Olivier Marcé
> >>>>> Nokia Bell Labs France
> >>>>> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
> >>>>>
> >>>>> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
> >>>>>
> >>>>> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
> >>>>
> >>>> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
> >>>
> >>>  --
> >>>  M: +1-408-391-7160 <tel:%2B1-408-391-7160>
> >>>
> >>>  https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
> >>>
> >>>
> >>> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
> >>
> >>
> >>
> >> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
> >
> >
> > https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
> 
> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>
> https://www.ietf.org/mailman/listinfo/detnet <https://www.ietf.org/mailman/listinfo/detnet>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Tue, 8 Nov 2016 16:48:29 -0300

Norman,
             In fact, this is one of the characteristics
of the statistical distribution of packet loss, obtaining the probability
of having a sequence of <n> packets lost in a row.
Although this is typical on wireless links, it may arise in other types
of physical layers.

Thinking about Balázs' availability rate (I cite his text):

"Therefore the application should require two set of parameters:
- transport parameters (BW, delay, jitter, loss, etc.)
- service parameters (availability, MTTR, etc.)"

I think a short burst of lost packets should be interpreted as normal
behavior of the link
instead of a lack of availability, which is the result of a network failure
and the consequent repair time.

My one and a half cent.

Regards,

                                    Diego

2016-11-08 16:34 GMT-03:00 Norman Finn <[email-masked]>:

> Good question, Diego.  I think that Balázs’s availability / loss rate
> does, in effect, give that, doesn’t it?  A burst of errors would,
> presumably, be counted as a loss of availability.  Or, were you thinking of
> something more complex?
>
> — Norm
>
>
>>   • The app owners and network administrators have to find network
>> design, app design, and class structure that gives a cost-effective
>> solution to the overall problem.
>>
>> > [email-masked]; Olivier Marce
>> >>   If you want to work on this approach, I don’t want to stop you.
>> But, it looks to me that it increases the number of options (and thus,
>> >>   If the application has time requirements, I assume that it is able
>> to synchronize its clock using one or more specific protocols, and
>> therefore knows how to interpret each of those protocols’ accuracy
>> information.  Problem solved.  Teaching the application to ask the PCE 1)
>> requires that a PCE b e present, and 2) requires the application to
>> implement a query/response of some kind to express its requirements and
>> understand the answer.  Keep in mind that the answer is not always
>> “yes/no”.  Perhaps the application can operate in different modes,
>> depending on clock accuracy.
>> >>

-- 
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