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

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

So there "could" be a way for an app to "demand" a given min/max latency of the network (in addition to being able to query the network for min/max values), in which case the network *would* be able to provide symmetrical latencies without extra buffering on the part of the app, but it sounds like it is still under discussion in Architecture. So I conclude we don't have a consensus on this topic yet, still working on it.

Ethan.

________________________________
From: nfinn <[email-masked]>
Sent: Monday, October 31, 2016 11:57 PM
To: Grossman, Ethan A.
Cc: Gordon Bechtel; Olivier Marce; [email-masked]
Subject: Re: [Detnet] DetNet Use Case Statements - Latency matching

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

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]<mailto:[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

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]>
<mailto:[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?

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

_______________________________________________
detnet mailing list
[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=>

_______________________________________________
detnet mailing list
[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=>

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

_______________________________________________
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=KUV0irxuI32ilbailzLuxtfsw8IkKe1p0BpmooQPsxk&s=1OPsmgJnOtYkGDrZoHvw6m2exF_MECgdG737_f_L3yY&e=>

---

From: Olivier Marce <[email-masked]>
Date: Tue, 8 Nov 2016 11:24:08 +0100

Hi all,

"symmetrical latencies", i.e. joint specification/enforcement of 
latencies values on symetrical paths is not in the scope of the network, 
then not in scope of DetNet.
If an app needs "symetrical latencies", it must manage it by itself, 
relying on DetNet for latency on the 2 symetrical paths that the app 
will use.

Le 08/11/2016 à 00:02, Grossman, Ethan A. a écrit :
> So there "could" be a way for an app to "demand" a given min/max
> latency of the network (in addition to being able to query the network
> for min/max values), in which case the network *would* be able to
> provide symmetrical latencies without extra buffering on the part of the
> app, but it sounds like it is still under discussion in Architecture. So
> I conclude we don't have a consensus on this topic yet, still working on it.
>
>
> Ethan.
>
>
> ------------------------------------------------------------------------
> *From:* nfinn <[email-masked]>
> *Sent:* Monday, October 31, 2016 11:57 PM
> *To:* Grossman, Ethan A.
> *Cc:* Gordon Bechtel; Olivier Marce; [email-masked]
> *Subject:* Re: [Detnet] DetNet Use Case Statements - Latency matching
>
> 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.
>
>> 1)      The network must be able to report its capabilities for
>> latency (presumably both min and max, thus bounding jitter).
>> *From:* detnet [mailto:[email-masked]] *On Behalf Of *Gordon
>> Bechtel
>> *Sent:* Thursday, October 06, 2016 8:56 AM
>> *To:* Olivier Marce
>> *Cc:* [email-masked] <mailto:[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
>>
>> 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.
>> <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
>> be*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=>
>>
>>
>>
>>
>> [email-masked] <mailto:[email-masked]>
>> *MailScanner has detected a possible fraud attempt from
>> "urldefense.proofpoint.com" claiming to
>> be*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
>> requirements that distract you from doing what you really need to be
>> doing." Rajeev Suri, Nokia CEO, April 2016
>>
>>
>> [email-masked] <mailto:[email-masked]>
>> *MailScanner has detected a possible fraud attempt from
>> "urldefense.proofpoint.com" claiming to
>> be*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=>
>>
>> [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=KUV0irxuI32ilbailzLuxtfsw8IkKe1p0BpmooQPsxk&s=1OPsmgJnOtYkGDrZoHvw6m2exF_MECgdG737_f_L3yY&e=>
>
>
>
> [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