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

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 5 Oct 2016 23:09:28 +0000

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

---

From: nfinn <[email-masked]>
Date: Wed, 5 Oct 2016 18:30:59 -0700

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

---

From: Olivier Marce <[email-masked]>
Date: Thu, 6 Oct 2016 12:05:19 +0200

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]>> 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:
>> 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).
>>
>> 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 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.
>> 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.
>> https://www.ietf.org/mailman/listinfo/detnet
>
>
>
> [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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Oct 2016 11:29:05 +0000

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]
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 
>  This could be solved by configuring the network controller to 
> disallow domain crossings.  This could be handled by parameters in the 
> some reservations but not others.  I'll leave it to timing experts to 
> 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 
> - Norm
>> Statements that I would like clarity on. Here's the first, remaining 
>> 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:
>> 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:

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

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Mon, 31 Oct 2016 23:53:50 +0000

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]
Subject: Re: [Detnet] DetNet Use Case Statements - How to express app time accuracy and reliability needs?

Cheers,

Pascal

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

Hi,

Regards

---

From: nfinn <[email-masked]>
Date: Mon, 31 Oct 2016 23:59:09 -0700

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]> 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]>
>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>> Hi Folks,
>>> 
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>