Subject: [Detnet] DetNet Use Case Statements - Latency matching

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

Statement:
Latency matching - single- or bi-directional. The Utilities use case needs this, but is this something we need to address in DetNet?

Discussion (oldest first):

Ethan Grossman wrote:
This came up because at least one use case mentioned a need for multiple outgoing paths (or the send and return paths) to have matched latencies. I suppose one way to do this is to specify a latency which is the minimum, and the add delay to the other path(s) to match it - but does this happen at the DetNet level or is it something the application layer would do?

Pascal Thubert wrote:
This seems related to the in-order packets delivery item.  A tight latency control can be useful to maintain that order. But doesn't this imply Time triggered operations?
We could also add that feature of voluntary latency addition, probably associated to jitter elimination.
---------------------------------------------------------

---

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

The architecture draft still mentions both minimum and maximum latency as specifiable.  In some sense, that solves the problem.  The issue, of course, is picking the minimum and maximum numbers.  Perhaps there is some way to provide clues to the app so it can pick suitable numbers.

Bit, as I think about it, bi-directional latency equality is not at all trivial to maintain.  The existing TSN standards report latency, instead of satisfying a requirement for latency.  The imagined use (by me, anyway) of a max latency parameter is to allow the network to change topology, or reroute a stream, or add higher-priority flows, and still guarantee the max latency is met.  If, by bidirectional latency matching, you mean, “make both slow if one is slow, and vice-versa,” I don’t know how to do that.  If you mean “meet min and max latency specifications for the flow”, then were on the right track, already.

— Norm

> On Oct 5, 2016, at 4:25 PM, Grossman, Ethan A. <[email-masked]> wrote:
> 
> Statement:
> Latency matching – single- or bi-directional. The Utilities use case needs this, but is this something we need to address in DetNet? 
>  
> This came up because at least one use case mentioned a need for multiple outgoing paths (or the send and return paths) to have matched latencies. I suppose one way to do this is to specify a latency which is the minimum, and the add delay to the other path(s) to match it – but does this happen at the DetNet level or is it something the application layer would do? 
>  
> Pascal Thubert wrote: 
> This seems related to the in-order packets delivery item. A tight latency control can be useful to maintain that order. But doesn’t this imply Time triggered operations? 
> _______________________________________________
> 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:16:04 +0200

Hi,
I have the feeling that expressing min latency in addition to max 
latency is a loose way to express jitter control.
There is a tradeoff between latency/jitter constraints and 
protection/paths redundancies: one could not expect having the same 
latency and jitter for one single path, than for multiple concurrent paths.
As such jitter should be dependent of level of protections i.e. more 
paths, higher acceptable jitter.

I do not see (yet) any reason for having similar latency on send and 
return paths.

Regards

Le 06/10/2016 à 03:43, nfinn a écrit :
> The architecture draft still mentions both minimum and maximum latency
> as specifiable.  In some sense, that solves the problem.  The issue, of
> course, is picking the minimum and maximum numbers.  Perhaps there is
> some way to provide clues to the app so it can pick suitable numbers.
>
> Bit, as I think about it, bi-directional latency equality is not at all
> trivial to maintain.  The existing TSN standards report latency, instead
> of satisfying a requirement for latency.  The imagined use (by me,
> anyway) of a max latency parameter is to allow the network to change
> topology, or reroute a stream, or add higher-priority flows, and still
> guarantee the max latency is met.  If, by bidirectional latency
> matching, you mean, “make both slow if one is slow, and vice-versa,” I
> don’t know how to do that.  If you mean “meet min and max latency
> specifications for the flow”, then were on the right track, already.
>
> — Norm
>
>> On Oct 5, 2016, at 4:25 PM, Grossman, Ethan A. <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Statement:
>> Latency matching – single- or bi-directional. The Utilities use case
>> needs this, but is this something we need to address in DetNet?
>>
>> This came up because at least one use case mentioned a need for
>> multiple outgoing paths (or the send and return paths) to have matched
>> latencies. I suppose one way to do this is to specify a latency which
>> is the minimum, and the add delay to the other path(s) to match it –
>> but does this happen at the DetNet level or is it something the
>> application layer would do?
>>
>> Pascal Thubert wrote:
>> This seems related to the in-order packets delivery item. A tight
>> latency control can be useful to maintain that order. But doesn’t this
>> imply Time triggered operations?
>> 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: Gordon Bechtel <[email-masked]>
Date: Thu, 6 Oct 2016 09:55:48 -0600

Seems to me that the question of latency metrics can be resolved in the
same way Norm suggested for timing and bandwidth: Let the network *report*
on what it is capable of (with whatever metrics this group feels makes
sense) and let the application *decide* how best to use (or not use) the
network.

In the particular case of matched latencies, the network should report the
latency metrics for each direction of the flow, and the application can
decide if this is sufficient.  Some applications need symmetric latencies
(it sounds like the utility applications do) and some don't.  But the
network doesn't know that.  Only the application does.

Gordy

On Thu, Oct 6, 2016 at 4:16 AM, Olivier Marce <[email-masked]>
wrote:

> Hi,
> I have the feeling that expressing min latency in addition to max latency
> is a loose way to express jitter control.
> protection/paths redundancies: one could not expect having the same latency
> and jitter for one single path, than for multiple concurrent paths.

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Tue, 1 Nov 2016 00:03:52 +0000

Hi Gordy, Norm, Olivier, WG,
I understand the consensus is:

1)      The network must be able to report its capabilities for latency (presumably both min and max, thus bounding jitter).

2)      The application must add its own delays to a “faster” path to match a “slower” path if it needs to.

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

Thanks,

Ethan.

From: detnet [mailto:[email-masked]] On Behalf Of Gordon Bechtel
Sent: Thursday, October 06, 2016 8:56 AM
To: Olivier Marce
Cc: [email-masked]
Subject: Re: [Detnet] DetNet Use Case Statements - Latency matching

Seems to me that the question of latency metrics can be resolved in the same way Norm suggested for timing and bandwidth: Let the network report on what it is capable of (with whatever metrics this group feels makes sense) and let the application decide how best to use (or not use) the network.

In the particular case of matched latencies, the network should report the latency metrics for each direction of the flow, and the application can decide if this is sufficient.  Some applications need symmetric latencies (it sounds like the utility applications do) and some don't.  But the network doesn't know that.  Only the application does.

Gordy

On Thu, Oct 6, 2016 at 4:16 AM, Olivier Marce <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
I have the feeling that expressing min latency in addition to max latency is a loose way to express jitter control.
There is a tradeoff between latency/jitter constraints and protection/paths redundancies: one could not expect having the same latency and jitter for one single path, than for multiple concurrent paths.
As such jitter should be dependent of level of protections i.e. more paths, higher acceptable jitter.

I do not see (yet) any reason for having similar latency on send and return paths.

Regards

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

Statement:

Ethan Grossman wrote:

Pascal Thubert wrote:
This seems related to the in-order packets delivery item. A tight
latency control can be useful to maintain that order. But doesn’t this
imply Time triggered operations?
We could also add that feature of voluntary latency addition, probably
associated to jitter elimination.
---------------------------------------------------------

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DQMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=nbdPXI6sYFWtvhdyVorpCWaMYVXEZvFRVRPreLIFLeA&s=MmeXCrNys9FflmVeWJMfWDyBye9ymf6RtQRl_NY_ycg&e=>

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DQMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=nbdPXI6sYFWtvhdyVorpCWaMYVXEZvFRVRPreLIFLeA&s=MmeXCrNys9FflmVeWJMfWDyBye9ymf6RtQRl_NY_ycg&e=>

--
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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DQMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=nbdPXI6sYFWtvhdyVorpCWaMYVXEZvFRVRPreLIFLeA&s=MmeXCrNys9FflmVeWJMfWDyBye9ymf6RtQRl_NY_ycg&e=>

---

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

I think we’re still talking about symmetrical latencies.

There are still multiple possibilities.  IF we assume that the network can provide both minimum and maximum latency guarantees, then I would ask the network what it’s max latency is in both directions, then pick max/min values to demand of the network that are not much larger than the slowest max latency of the two directions.  If the network has sufficient buffering, the network will do the work of matching the latencies.

If the network doesn’t have the buffering, then yes, the app has to do the buffering.

— Norm

> On Oct 31, 2016, at 5:03 PM, Grossman, Ethan A. <[email-masked]> wrote:
> 
> From: detnet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Gordon Bechtel
> Cc: [email-masked] <mailto:[email-masked]>
> On Thu, Oct 6, 2016 at 4:16 AM, Olivier Marce <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> On Oct 5, 2016, at 4:25 PM, Grossman, Ethan A. <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
> Statement:
> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> MailScanner has detected a possible fraud attempt from "urldefense.proofpoint.com" claiming to behttps://www.ietf.org/mailman/listinfo/detnet <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DQMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=nbdPXI6sYFWtvhdyVorpCWaMYVXEZvFRVRPreLIFLeA&s=MmeXCrNys9FflmVeWJMfWDyBye9ymf6RtQRl_NY_ycg&e=>
> 
> 
> 
> MailScanner has detected a possible fraud attempt from "urldefense.proofpoint.com" claiming to behttps://www.ietf.org/mailman/listinfo/detnet <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DQMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=nbdPXI6sYFWtvhdyVorpCWaMYVXEZvFRVRPreLIFLeA&s=MmeXCrNys9FflmVeWJMfWDyBye9ymf6RtQRl_NY_ycg&e=>
> 
> -- 
> Olivier Marcé
> Nokia Bell Labs France
> MailScanner has detected a possible fraud attempt from "urldefense.proofpoint.com" claiming to behttps://www.ietf.org/mailman/listinfo/detnet <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DQMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=nbdPXI6sYFWtvhdyVorpCWaMYVXEZvFRVRPreLIFLeA&s=MmeXCrNys9FflmVeWJMfWDyBye9ymf6RtQRl_NY_ycg&e=>
>