Re: [Detnet] review DetNet OAM framework draft - latency

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 12 May 2021 16:28 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513D23A0F0E; Wed, 12 May 2021 09:28:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.595
X-Spam-Level:
X-Spam-Status: No, score=-4.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=HPy/DP/1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=adFa59n0
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8haM1CxcCIBM; Wed, 12 May 2021 09:28:01 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1353A0ECC; Wed, 12 May 2021 09:28:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31546; q=dns/txt; s=iport; t=1620836881; x=1622046481; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XORb4oq/2B6QA4SmyDnmVO7Ru+5jUBvsRav54l1I60E=; b=HPy/DP/1TCqUnVMIELQRZzCVT7MxC9xXSreOLkGjwXLxOkOuVatD+0Q2 M8+6oH10bHvqqZuQ7oXHbNohrAa/eSo+RyDvSfEUeG6YL/8GWhIofLpYh fkv819+/w/+xD6ofjuzNPXGujj0T8e3zdqbJNMC+rA1FBQZUz1kbI+qAD 0=;
X-IPAS-Result: =?us-ascii?q?A0AnAAAxAZxgmIQNJK1aHAEBAQEBAQcBARIBAQQEAQGCB?= =?us-ascii?q?AYBAQsBgSIBLyMuflo2MQuEPINIA4U5iH4DijePJYEuFIERA1QLAQEBDQEBO?= =?us-ascii?q?gIEAQGETwIXgV0CJTUIDgIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBA?= =?us-ascii?q?QEBAWiFUA2GRAEBAQQjBAYTAQE3AQsEAgEIEQEDAQEhBwMCAgIfERQDBggCB?= =?us-ascii?q?A4FCIJpAYF+VwMvAZ5LAoofen8zgQGCBgEBBgQEhTcNC4ITCYE6AYJ6gnFTS?= =?us-ascii?q?AEBgROFRyccgUlEgRREgjAvPoIfgWo8JBCCYTaCLYFYEQFaawMNQlRIQTliA?= =?us-ascii?q?5B5gm1DiAMznW9bCoMVl3uFXBCDWJExkCuGVZ4Bj2MEhG0CBAIEBQIOAQEGg?= =?us-ascii?q?VUBNoFbcBWDJFAXAg5XjUgZg1eKXXM4AgYBCQEBAwl8iwMBgRABAQ?=
IronPort-PHdr: A9a23:Q3SinhFEJcSdBFKIgN6VrJ1Gfj4Y04WdBeZdwochiqlSaK3l8Y6xd EDc5PA4iljPUM2b7v9fkOPZvujmXnBI+peOtn0OMfkuHx8IgMkbhUosVciCD0CoMfjrdDAgF YJMTgwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=
IronPort-HdrOrdr: A9a23:ESRmaKulCjOtQwyb+judNTHS7skCoIMji2hC6mlwRA09TyXGra GTdaUguyMc1gx/ZJh5o6H/BEGBKUmskqKdkrNhTItKPTOW+VdASbsD0WKM+UyaJ8VxnNQtr5 uIH5IObeEYSGIK8voSgzPIU+rIouP3jZxA7N22pxwGIG0aCNAD0+46MHfmLqQcfnghOXNNLu vl2iMxnUvYRZ14VLXeOlA1G8z44/HbnpPvZhALQzQ97hOVsD+u4LnmVzCFwxY3SVp0sPQf2F mAtza8yrSosvm9xBOZ/XTU9Y5qlNzozcYGLNCQi/ISNi7nhm+TFcZcsvy5zXUISdOUmREXee r30lEd1gNImirsl1SO0F/QMs/boW4TAjHZuASlaDDY0LzErXoBerl8bMRiA0HkA45KhqAh7E qNtFjp6qa/RCmw7hjV9pzGUQpnmVGzpmdnmekPj2ZHWY9bc7NJq5cDlXklXKvoMRiKorzPKt MeQf00JcwmOG9yZEqp8VWHAObcFUjbOy32DHTqlvblpAS+rUoJh3fwnvZv6kvo3KhNPaWsyd 60R5hVqA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,293,1613433600"; d="scan'208,217";a="685250417"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 May 2021 16:27:57 +0000
Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 14CGRvmN010736 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 12 May 2021 16:27:57 GMT
Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 12 May 2021 11:27:57 -0500
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 12 May 2021 11:27:57 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Wed, 12 May 2021 11:27:57 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mkNofLHEvVO0TZnXG2NCiJ3lhhdYaPnXhBZBobfHVdpk60LhuwO/bCoDdste4y8SI34uehbwXVwDQ1nN8zuGlolB2pSye6ppZkPe29XY7s/eYC8/fu3hmTo66pE0OnrTWVh2kox4f4hHP7t3QRUkaIBsFxNvHxLoKKSib70CEtAbRSCeeuL1GnMpi4DFniSWWvlcu2ytL0UExYSAB4GLwK1FFCJWhmoTMlEbij/J6Ps8iPrnwGpIKyf/uP9N7Mr6+4/sm64X+5/1xDG2Z07u+UFvCmBflZT3Ok2q1g3ZHb7SBVCDddSDYTPO2YwpFpJeiiXUP0kROLZgQuXSxKdjGQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XORb4oq/2B6QA4SmyDnmVO7Ru+5jUBvsRav54l1I60E=; b=VxaxryGVkpZp5qWAKcBqE1GqlbxWpXBKy92L0tNn0/ctH8yRGvMXLQZh5Z3TLSamzOghonMDsPvAE4wSLfKR7AfyCoD1BL3rKLTreJV6g6HrxsQq+mpcrMFPUDE6g7bfR28thTh38Q2zNCxAbN70ktuuK1mS4NHQbpKnKvYENHV+pcricsudwJr1Ocfo+3khviiByk5IV7amWZSamXGQu2SSa1+u6CkpvCFMC2Rcn1KFrwGcxqeHU3Y425WDF7GKJRf2IaN3QXhlDksAcTYxHF3RswzFOv1YLjWW+glrdKbNteLMp0+6a151VxcgXl5qCf5u48o6QE1nMAM6LXj+AQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XORb4oq/2B6QA4SmyDnmVO7Ru+5jUBvsRav54l1I60E=; b=adFa59n0fhtLDZBlnNE/FkydE5Zd7UBQHhkSaPqWQoZ1O6pYuiP3Yb+p2KkJF46xyieX0V71a756OicR3P9immyOHWnbnRL6b2vQnMnCgJReImPxqX1syc0iM6lGZmw4JJcpAzkz060n0fbsX2VmBDXRwxggfWtBEKTJ4s/eRgQ=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB0032.namprd11.prod.outlook.com (2603:10b6:301:63::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.27; Wed, 12 May 2021 16:27:55 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::cd01:ffc9:6592:b1d5%6]) with mapi id 15.20.4108.031; Wed, 12 May 2021 16:27:55 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Fabrice Theoleyre <theoleyre@unistra.fr>
CC: Greg Mirsky <gregimirsky@gmail.com>, DetNet WG <detnet@ietf.org>, "DetNet Chairs" <detnet-chairs@ietf.org>
Thread-Topic: [Detnet] review DetNet OAM framework draft - latency
Thread-Index: AQHXRyZPdCtcaWTLmUGYS/Tiow9Hi6rfzZkQgAAywoCAAAbqAA==
Date: Wed, 12 May 2021 16:27:49 +0000
Deferred-Delivery: Wed, 12 May 2021 16:27:13 +0000
Message-ID: <CO1PR11MB488153F9AE6BEEFF416D7126D8529@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <AM9PR07MB7204DF42315052CE9C620692F2409@AM9PR07MB7204.eurprd07.prod.outlook.com> <CO1PR11MB488199682C35E517C0E2A444D85F9@CO1PR11MB4881.namprd11.prod.outlook.com> <CA+RyBmUsO3Qr9SwJELyd7JnkwWPnhCaji2X8WVHgVoD=JYuoNA@mail.gmail.com> <CA+RyBmUVq8KyL4gC+v_U9YKgx+vawueYukj2D0StD1eXWoUTGQ@mail.gmail.com> <CO1PR11MB4881E9A0CD5E2D3B5EAFC560D8539@CO1PR11MB4881.namprd11.prod.outlook.com> <38B22921-333E-4230-86D2-80DF4D69A027@unistra.fr> <CO1PR11MB4881E971D4E590D737135CB9D8529@CO1PR11MB4881.namprd11.prod.outlook.com> <F51EBE97-E4B0-4595-8802-7C6F9AF45EE4@unistra.fr>
In-Reply-To: <F51EBE97-E4B0-4595-8802-7C6F9AF45EE4@unistra.fr>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: unistra.fr; dkim=none (message not signed) header.d=none;unistra.fr; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.220.34]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 416b270b-35a2-4874-63ef-08d91562e59d
x-ms-traffictypediagnostic: MWHPR11MB0032:
x-microsoft-antispam-prvs: <MWHPR11MB0032E4CFF9B3000A5D272253D8529@MWHPR11MB0032.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: D57DDoI3DlXVlPKKT/i2jiuVASMmuTcsXlAFzEmQ0FNea0Hhcs9OvrlI4HB7tOJutDnsWsBf83GsQGscHF4ylOIYX2DRCg+KijeKzMb6BuDinAPDfeGZaPy+x5XgmyESboZc6MMTDSU3kjRprFUnMKZbUFGVui+NZ1+mB1aQ8Q7yTnkW6z4YArs0lfxWooOKHF8nz3yEo02u2WCNMRECMIH5kCBjVEd2csOYAXjoF7hI56F8O2TORJ5HYJYzC+zJUkkK5MlM/E3u7aoSFnmytettyKLDFNNrL7CknnIvSohz3u2G6XGA0rvi23N1vub1h82wimhNN8tUndZRcAt2u/FC+ynn4CB+HMDucnGjt/97AyhnFRJm/xyG/8sUnw+V8o/lHkIedXLSpHIhIdEq+bTi1D7At9+Q12192D6gAp6fSVeg725lR5+JhV1xvFDv1G4lh4HD7E1ajW+O4hqUH9ycknDXcuCzxXBoHiXeujyz8SMyiAQ/0gGMrAV+5xBjzbK0Hm6D5HKySfnciePbSZKiMXGPbWbKOXu4mcMJGm/ohLUsjtQSIaUb66hl+9qKASwH95h9LTMoGzNmCZW3q6Lg7L4rooP/yDAy+pQRubg=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(55016002)(2906002)(7696005)(64756008)(86362001)(8676002)(26005)(498600001)(52536014)(8936002)(66946007)(9686003)(66476007)(66556008)(186003)(76116006)(71200400001)(54906003)(6506007)(4326008)(66574015)(6916009)(122000001)(5660300002)(38100700002)(83380400001)(6666004)(66446008)(33656002)(53546011); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: QMzDm+SEvTaHfjQC/F0pnRAOZ9kcV2b+BrcoKZN3ZEtTBH6YJ2X5YSxCcrId4QOV4IzJvnohDZwh0Ws2ucNkRkmfxE7SIi+rutDZY/WLwUkBYNIgDOnop3gjoXObcskdMWV3AnChSfe6/uRnG/EaJ1epgqw2Gu5ZV+O2NCdXNnhB+FiosodSk8QTqqgdCWCvDgNaMkxe6GtjfewdQAfFeaRa51whX54TGxs0EBvCJ/aA7pAbViSzZeK3AyeowJkGnZ8851rHDxu9s9KXAY1HsUDiH8gK0cl1czLsFWOqvjFeMVJq4nKPDbGOdtfSPJCiVL+Ro+J+7R6Qg2L1OWnUmZYLmxhB9iw3WUlRZBCjskd+8EBqcEYdOpzp6Hb66UftyfzxlxofdmPIthofZxCJjlUw2Oy5im/gy3eAN7ihHQwWwdFxuWb+Usdi93CN5K8aqV3aKuV5zxmapsbAf7le7kJPTEW3jxwzZJkzXGAmKFmN4BpSqzn1uBnu3DpiylfZxCR3MERSMKHBottXZWFEx9YKN4Ow969Z2usO9SuYvZMSRwV0QF1n4QMsIhwRkRm5vxCRpTn/1IszJJRvnijnmz5Svytg5siY+JtZIRHrnFgFwz6QHWZa0RAYQ+Thmh5RaISATd0lwUgdcoRqiJCZSL14EWZ3LXF6TZbcLP0nDB/4Fq2gBnVCe3XZLqkXCnyS3Mq7DiYa2dKSSwp6h/M85Hat7Q1eUrLPkRimCzX/eSH6Tm4KTJX221mv0qnHm2Gk
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CO1PR11MB488153F9AE6BEEFF416D7126D8529CO1PR11MB4881namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 416b270b-35a2-4874-63ef-08d91562e59d
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2021 16:27:55.1348 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 00q8nj4a+BXDYDd647zsYmIMniI8FA/tCTYnJPHmLA4IaIL1eieZFcLB7fz5mUXEuXjaZ9HAFa9Q/+M2//5/tQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB0032
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/eIXeMT20gauYzdSWlzc0T-F6Ljc>
Subject: Re: [Detnet] review DetNet OAM framework draft - latency
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 May 2021 16:28:16 -0000

Hello Fabrice:

Using the term latency to refer to the time between 2 endpoint is consistent with RFC 8655 and avoids the risk of misinterpretation. Having 2 terms for the same thig can only create confusion. So I agree with your proposal not to use delay when latency is what’s intended.

There are some modern environment where the extra delay becomes a notion of importance, e.g., to take flow control actions in the DC fabric. In DetNet, it is significant to the network assurance and it may trigger some automation to ensure that the SLO is continuously met. OAM will typically measure that. So it would be cool to give it a name.

Take care,

Pascal


From: Fabrice Theoleyre <theoleyre@unistra.fr>
Sent: mercredi 12 mai 2021 17:56
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>om>; DetNet WG <detnet@ietf.org>rg>; DetNet Chairs <detnet-chairs@ietf.org>
Subject: Re: [Detnet] review DetNet OAM framework draft - latency

Hi Pascal,

-----Original Message-----
From: Fabrice Theoleyre <theoleyre@unistra.fr<mailto:theoleyre@unistra.fr>>
Sent: mercredi 12 mai 2021 13:59
To: Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>>
Cc: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>; DetNet WG <detnet@ietf.org<mailto:detnet@ietf.org>>;
DetNet Chairs <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: Re: [Detnet] review DetNet OAM framework draft - latency

Dear Pascal,

I separated the latency discussion, because I guess it desserves
additional explanations.


- Sadly RFC 8655 does not define either “latency” or “delay”. Reading
this draft, I now see it as an oversight. I’d suggest that we define them
in the terminology section. it is my sense that RFC 8655 uses “delay”
with the meaning of incremental flight duration, and uses “latency” for
the total time end-to-end time across the network, IOW, minimal_latency +
delay <= bounded_latency.

GIM>> Thank you, Pascal, for bringing this to the discussion. I agree
with you and I strongly believe that it is utterly important to set the
dictionary so that we can discuss technology and use cases based on the
common understanding of terms. I like your suggestion to provide
definitions of "latency" and "delay" in the Terminology section. Before
going into definitions, I'd like us to define the scope of these terms.
Would it be for the draft and all DetNet OAM documents or it can serve as
the clarification of the terminology used in DetNet in general since RFC
8655?

About the definitions. Do you think that the interpretation of "delay"
is close to the definition of the residence time (RFC 8169):

  Residence time is the sum of the difference between
  the time of receipt at an ingress interface and the time of
  transmission from an egress interface for each node along the
network

  path from an ingress node to an egress node.
Also, in RFC 8169 we've assumed that the e2e delay, i.e., e2e latency
consists of two parts - fixed propagation delay determined by the link
speed and variable portion, i.e., residence time. In your opinion, could
this model be applied to DetNet?



PT> Well the residence time seems like the latency of the network
transit, and I see the delay as the difference between the best possible
latency and the actual latency experienced by a packet. Like when I say,
I’ve been delayed by 30mn in a trip that takes 5 hours when all the
lights are green so the residence time in my car (aka latency) is 5H30mn.
The DetNet architecture seems consistent with that interpretation, at
least as far as I intended to write and can read the language.

FT> Actually, we reuse the latency as defined in rfc8655, end-to-end,
from source to destination.

Thus, along a path S-A-B-C-D, the end-to-end latency is the sum of:
- the residence time in S, A, B, and C
- the propagation delay S->A, A->B, B->C, C->D

Thus, the residence time corresponds to the time a packet stays in a
buffer for a specific forwarding node.

I guess your definition slightly differs (it corresponds rather to our
end-to-end latency).

If we all agree, we will detail the end-to-end latency, as I described
above.

I see what you're saying and we're not in full agreement yet. Not that it's pure terminology, not disagreement on how things work.

Agreed that you and RFC 8169 describe the residence time in each node. My example of residence time in the car was misleading. I'd still like to see a term for the residence time in the DetNet network, from ingress of the first DetNet router to egress of the last one, seeing the DetNet network as one big virtual box, if you like. Because that residence time in the network is the only thing that DetNet can guarantee.

What I tried to discuss was the term delay. Whether it is synonymous to "time it takes to do something" or "extra time it takes to do something" beyond the " minimal time it takes to do something".
I's rather use the latter. Meaning that in a zero-jitter network, there's never a delay, there's just a fixed latency. In your example, the propagation time over the wire is called a delay. I've seen that before but do not like it, because that gives us 4 terms to say the same thing (latency, time, duration and delay) and no term to indicate the positive jitter experienced by this packet above best possible transmission time, iow how much delay this packet incurred, how long it was delayed. I believe we need a term for that and I see that "delay" would suit that need just fine. If you scan RFC 8655, you should find that this is consistent. This is how I used it for the pieces I wrote. It occurs to me that we need our terminology. Ideally it will match the art but it does not have to if the art is unclear or overloaded.

As for latency, I see it as total time, and it must be used in cinjunction with the description of the end points, whether it is application - what we would like to guarantee but do not, NIC, DetNet-network or one-box edges - in which case it measures a residence time.

Do we have a path to converge?

Now, I catch your idea:
-> latency = time difference between entry / exit points (e.g., network (end-to-end) latency)
-> delay = extra time as a result of some cause (i.e., a packet has been *delayed* more than expected).

This distinction seems not very usual for me, but I’m fine if we find an interest for it, and if we have a consensus in the WG.

Another option would be to use uniquely the term ”latency” in the draft.

Best,
Fabrice