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

"BRUNGARD, DEBORAH A" <db3546@att.com> Fri, 14 May 2021 16:47 UTC

Return-Path: <db3546@att.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 B06C53A38B6; Fri, 14 May 2021 09:47:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.204
X-Spam-Level: ***
X-Spam-Status: No, score=3.204 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com
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 PI10J5b-2k_a; Fri, 14 May 2021 09:47:15 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230593A3827; Fri, 14 May 2021 09:47:15 -0700 (PDT)
Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 14EGiWaf004061; Fri, 14 May 2021 12:47:13 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 38htfgkhn8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 14 May 2021 12:47:13 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 14EGlAKD000335; Fri, 14 May 2021 12:47:12 -0400
Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 14EGl2kX032643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 14 May 2021 12:47:02 -0400
Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id 4AED1403072E; Fri, 14 May 2021 16:47:02 +0000 (GMT)
Received: from MISOUT7MSGEX2CC.ITServices.sbc.com (unknown [135.66.184.218]) by zlp27126.vci.att.com (Service) with ESMTP id 1A57D4030723; Fri, 14 May 2021 16:47:02 +0000 (GMT)
Received: from MISOUT7MSGEX2CC.ITServices.sbc.com (135.66.184.218) by MISOUT7MSGEX2CC.ITServices.sbc.com (135.66.184.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Fri, 14 May 2021 12:47:01 -0400
Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGEX2CC.ITServices.sbc.com (135.66.184.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4 via Frontend Transport; Fri, 14 May 2021 12:47:01 -0400
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.176) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Fri, 14 May 2021 12:46:52 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GalTHWcDcOeHsl74lxn5B1CIrbbp5NLW3QJblG63lVy7pfZnuqX0eqhZuIMzJVPRXwAym4J5MCaHDK0gGnPmE3dwU35aT4Ko3E4VEDdvni+7z03Zuz7Th3YlERMjCiyRyGDAU6+XfEbi9FCMjfq5ph+oZpoiutG3eg+7lU7oAZXaDdU/RezKAY97vcaq27jkhrNg+Kq1UIjjQCn3TsozRX+a86yw9k5KA9Hk20pOA87lkjFIEnJjU0MbmR7m1J2ciwcOoEavpg+cTD1pk97FM++GgtZBa3UcITFOWmFYIM/xX+un65cJFZxJ+Ms9SGhf+jFnQ9F3VA1MONwwrOdW5w==
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=CK8wKftW3SPgz45/b8eq/6gth/E5JoCOr9/mjqTJ1pA=; b=Ui04ys4oWOnczIq1fcR92yRpTkE+u1AJ4MMaN5CrtLh5Zf4Eu8l2Mbf4HzSoxZ6XIAnwW2eQ3rIyt86zDJl7chircM8H0K4+LoR1jdej3CkF9lsws+tqbmvNd8lSseGlzRsN5syEld1OoBkuYCJ5x+k5Y4XiMwpISqpSt/NwwikKqRyvx3Pbp5MCDzZX6htN9glE8r9LLje9Z8hQpFEvuwA9A9Mt/UxclxZfORIAoMHDJ29/3SIbmc0j4Xw4SFeNLld9upWvBmpvlRhnkjQ+3/64DT7Yld0iDTYFRxqQk6v/Ftros1E+OZmhUnYWhSkd52QCo3nBji8gTgTxxpPzZQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CK8wKftW3SPgz45/b8eq/6gth/E5JoCOr9/mjqTJ1pA=; b=z7NsQ2irrgK1DkryzLY89JHo4TKLsimACI60XUqMGXTVEAhW1/ogfyPU0OpN1+V6hwTFvL+alBbjXFfAtz5Rrkpn+5vbdrX9JpORfCDN+9eC4OwDSniLIAYgEFmatds5bzrwCJQ0dzvQGdQbrA+AulnMqVab6bmthqSBRnRial0=
Received: from CH2PR02MB6424.namprd02.prod.outlook.com (2603:10b6:610:12::30) by CH2PR02MB6523.namprd02.prod.outlook.com (2603:10b6:610:34::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Fri, 14 May 2021 16:46:50 +0000
Received: from CH2PR02MB6424.namprd02.prod.outlook.com ([fe80::e2:9775:f780:2f9e]) by CH2PR02MB6424.namprd02.prod.outlook.com ([fe80::e2:9775:f780:2f9e%3]) with mapi id 15.20.4065.027; Fri, 14 May 2021 16:46:50 +0000
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= <balazs.a.varga=40ericsson.com@dmarc.ietf.org>, "gregory.mirsky@ztetx.com" <gregory.mirsky@ztetx.com>, "pthubert=40cisco.com@dmarc.ietf.org" <pthubert=40cisco.com@dmarc.ietf.org>, "theoleyre@unistra.fr" <theoleyre@unistra.fr>
CC: "gregimirsky@gmail.com" <gregimirsky@gmail.com>, "detnet@ietf.org" <detnet@ietf.org>, "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>
Thread-Topic: [Detnet] review DetNet OAM framework draft - latency
Thread-Index: AQHXR/9SYEHjtZ/KVUufGgmhbpXfnKrjK+7g
Date: Fri, 14 May 2021 16:46:50 +0000
Message-ID: <CH2PR02MB6424727CD648B56514BE53FBD6509@CH2PR02MB6424.namprd02.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 <202105130528045292146@zte.com.cn> <AM0PR0702MB3603BC8078824C1BA379B88CAC519@AM0PR0702MB3603.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR0702MB3603BC8078824C1BA379B88CAC519@AM0PR0702MB3603.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=att.com;
x-originating-ip: [71.172.98.137]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d3831da8-b0a3-44b0-a7be-08d916f7df56
x-ms-traffictypediagnostic: CH2PR02MB6523:
x-microsoft-antispam-prvs: <CH2PR02MB6523030697C85C57F9780D6CD6509@CH2PR02MB6523.namprd02.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: VGRaGD+GfhaEO4dUoSuiyyScDNAFAZ1GZ8iXsR91JxROAiK7x8T8u1GhqhHyEs2z9MnIyKfil6IQsB1RtXBzZGnPlr6Vdyzh7i60bC9GquVaVe/2YNzZLhwe9l7a66hoy/plV5J3eiMTaWi2SjZ0B+vf9exwnw20FtNOLL+/ZLDmQRiFPcK0Ys4DMykI9xdqbdWJOLZ3uGeXzdlweVOXeNHzxaAjb/gRGwoLMCB222fg0dCabkC3huNbIgz70xkPdR/OUtIyt5Ypnl3jz/WwYEq77g4bd1+9vdBvYewPUzTodUIyYMh1VnZolZhDlLL9QCPe+4h+3Bo2bzbswCqbjyvRlSSuHJfj6iUIAmXQgicwYT+DjFq9uyGZioIkMjNfentUIC4a0vT6nzXmhZkpICLxVALuAj4yHo5U2EHuXeA19ByXf3dltwFW1w6cEPEXXd+mCQnFIQD2UJGCQGEiCIxNqHWKUznstjLkKq3AA4jyk0+Xrx82Ss5Lcu5Eu/qsfUWkc8f9i0zQwO94BHxaO+g57579ZksrNiAMY7wlYYnQW9RqonfI8bTJ1q9TQbVwq3kYrKUuvXyOMZoGAPnhhm5w32xWocZcTO8acyR8npWlEUSNiB1caUx1WSFc0MP0p8eAEOfpF54J3405/cQs6kdB3gft4uXgTDz9kFFTNuEAnRO6YATFklE01iFxUk5f
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR02MB6424.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(498600001)(9686003)(33656002)(83380400001)(55016002)(4326008)(66446008)(9326002)(71200400001)(2906002)(122000001)(38100700002)(53546011)(64756008)(66476007)(166002)(66574015)(8936002)(186003)(30864003)(99936003)(26005)(110136005)(54906003)(82202003)(5660300002)(7696005)(86362001)(76116006)(6506007)(66556008)(52536014)(966005)(8676002)(66576008)(66946007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bWJ0cDJLUHN2aXhGcDZ3WGkvazVmbkJsVW1jSHRnMVpmaXdNRThuR25BUmtO?= =?utf-8?B?SnpBL0RoYlgvazRHWk5Udjl2cmoxN09Ob2U5YlVNMTNNc050MTI2MWpSUmlZ?= =?utf-8?B?aThVVDVEdDV5eEZGMmJLZW9vbVFGUkp5WVIrNGF4NUFvU3lSMlMvZVpxSkxi?= =?utf-8?B?eUgrZ20rZzJwWFMyZDNPSERoYTZaUmtwdE4zNGZDY0d5VEY0emZYOUc1RURm?= =?utf-8?B?MWZCOW5aUWtQdVFqNGszcnRlbXlmeFlWd2hJRXVRMXFLWE16NklTL0UwZzJt?= =?utf-8?B?Y1p1enp1Ym9sb08zUEhPNkFDdUVEdDdENEcwVlEwVVVBWER6YlFEWHlIRXQ0?= =?utf-8?B?L3dOeDNmVXZxUE9nZHQ2OUwrZ3BFYTQ3TUcwUmVZclE3a0N6Vm1lOWxiNGN6?= =?utf-8?B?UDBiQVMzM1MwVyt1Tm1POExXZjdxLzlUaWRHN0ZNY2NESk9TTkVzODQ1ZEVo?= =?utf-8?B?YkRIR2RWUC9UaHV3T2MwdFN5R2lQRW4xR0NPb0JPZzNqekVoOFdydnZDSTFi?= =?utf-8?B?N2c3NythYjdoV28reUdvdXo1ZTl3SUhSYjZvSUJYS1d2N1VDRHdYNWNkRFVT?= =?utf-8?B?Zjk2RjJFWUVIYzFsV2xsVkNPMGlwT09OdFFoelc2RzczYnl2TXZzeGV3dWZs?= =?utf-8?B?aW9uMnlCQ0dha2QxdEJ4SEd6UEdMSzB1ZGlSVklKRGNKS2wySDNhL01lMTRo?= =?utf-8?B?TFNGbGpDN09mNHlidk4ydURxSXBncmFQcGxHVmFMMTJjcURuNCtmSUlTeXJ6?= =?utf-8?B?TDUyMXJRY3gwbUFCL013ZmsyeWdiUmNzams3REhGY3RKSlNZM2cvYnpPSWdD?= =?utf-8?B?ZUVCSzlJS2dWM3VWTlBoditPKy9UWHlTZnhzQm9rTjdIQ2NBSVlWNklpNllF?= =?utf-8?B?TEZ1ZjNoK2N6ODhPKzN3ajNPR2p3enJLdnRHRXN1UUpwb0YwUGhKS1ExNys3?= =?utf-8?B?czgxbU1aVUNGellVM3BoR2tWNDJwaldqZTU3RlNQeFVxc3JTYlgwamUrYlRr?= =?utf-8?B?RHNWNjBheEtOT3FVNElsVzF2UVRuRkNzL2ZrYXpyQkNoZldIQVQ4UUd3dWQ4?= =?utf-8?B?RUdNRFZiaUppcmpBUksxV2Vod0ppZXE1NENwZHEvc1UvZk8yblVkT3ZmZkQ5?= =?utf-8?B?cmlhbU1PY3ZtMzM5UndTV3BZZFRhRzY0VjAzOUlBTExOQWw0ZnppNXNVdGdW?= =?utf-8?B?YTNCMzlhbndIbEszY1hmQ3Z2dllIcGRCd3BWSDZNRkxHZVlTMG1RRDZqenNK?= =?utf-8?B?M0p6elRBSDBYOFJONVlQUU1GclVoN2NaaGpUY1l1RTFuQm0zanBKOHRNdXlt?= =?utf-8?B?VUNRV3E3M1ZLMUcrRXJkeStLVEt6OXc0MVc5QTJiVUZqQmNtb05TZ0NXZG0w?= =?utf-8?B?WU5MV0NmaVNBTmRtZWUwVUFVVlN1ZWY2WGRDcWhlYWVyRS9rS3NQRm5COUVT?= =?utf-8?B?ZVFFenU5ejZYWkhwUVRUNm14S3FkelBYQmh6bVhwUEFFYWRWZG5pV3kxSkV4?= =?utf-8?B?eUVQeERvTnUrWVVCYS9udE9xK2R2cndoZ1hFbS9QRVNrU3grdldEbHBURkZi?= =?utf-8?B?UlN0NmdFdDNGK2NQN3ljQXB0RHJ6YkdsZFEwTXhPb1NuV1RZME0rVTVHdE5R?= =?utf-8?B?Q3ZDM2J6cDc1SENwMEtta3J6QzlYbzU2UWNJL3l4S2JJcFVrcjZ4RHM1dlh2?= =?utf-8?B?NmM1SXBISlhpdVN5NFRJc2c1TVNKZTdKZUpKL2Q2dzFnZUwyZEdvcElPU05k?= =?utf-8?Q?/eDpgBflwcOANk6EhfVWjSLVgwaYR9P8a/dxYUh?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_005_CH2PR02MB6424727CD648B56514BE53FBD6509CH2PR02MB6424namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR02MB6424.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d3831da8-b0a3-44b0-a7be-08d916f7df56
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2021 16:46:50.8127 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: s+0tEUGyu8iErbStHSnCFSmnu+IhjKX9Sgys6uk/om40tObpdnrA5A6z+1nYBZ/n
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR02MB6523
X-OriginatorOrg: att.com
X-TM-SNTS-SMTP: B14E30CD7DD3B31A0C3F8A873836DCE19807521E3BB8F094A32987EA7E943C022
X-Proofpoint-ORIG-GUID: JuJukOoTl1dXMHxSp5VfAh-zUvhRQuDW
X-Proofpoint-GUID: JuJukOoTl1dXMHxSp5VfAh-zUvhRQuDW
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-14_07:2021-05-12, 2021-05-14 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 spamscore=0 clxscore=1011 suspectscore=0 mlxscore=0 adultscore=0 phishscore=0 impostorscore=0 mlxlogscore=999 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105140133
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/RR5WGZFrkramkfngUpwApUNNBZQ>
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: Fri, 14 May 2021 16:47:21 -0000

Hi,

Agree with Greg on this one – there’s lots of terms used – services/SLAs, gamers. I asked my in-house ITU-T/IETF performance expert and he noted the SDOs do not use latency for metrics, the metrics are named “delay”. While latency/delay have been used interchangeably in our RFCs, I don’t think anyone has been confused yet as the context clarifies.

So I agree with Greg, if this OAM document is based on defined metrics, let’s not rename them. If we think we need to invent any new ones, we should consult with other IETF experts. And we should consult as we progress so no negative surprises when go for publication.

Some additional hints: The relevant IETF RFCs for IP-layer: 3393 and 5481. If referring to Y.1731, then Y.1563 should also be looked at.

Thanks,
Deborah


From: detnet <detnet-bounces@ietf.org> On Behalf Of Balázs Varga A
Sent: Thursday, May 13, 2021 9:52 AM
To: gregory.mirsky@ztetx.com; pthubert=40cisco.com@dmarc.ietf.org; theoleyre@unistra.fr
Cc: gregimirsky@gmail.com; detnet@ietf.org; detnet-chairs@ietf.org
Subject: Re: [Detnet] review DetNet OAM framework draft - latency

Hi,

As this is an OAM document and performance measurement uses the terminology “delay”, I would expect
to stick to the OAM related terms..

Frame/packet delay is well defined.
Frame delay (Y.1731)
Frame delay can be expressed as a one-way delay for a frame, where one-way frame delay is
defined as the time elapsed since the start of transmission of the first bit of the frame by a
source node until the reception of the last bit of the same frame by the destination node. …

Similar definition is used for IP.

In my view we should use the term “delay”. (“Latency” when used has the same meaning.)

Cheers
Bala’zs

From: detnet <detnet-bounces@ietf.org<mailto:detnet-bounces@ietf.org>> On Behalf Of gregory.mirsky@ztetx.com<mailto:gregory.mirsky@ztetx.com>
Sent: Wednesday, May 12, 2021 11:28 PM
To: pthubert=40cisco.com@dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>; theoleyre@unistra.fr<mailto:theoleyre@unistra.fr>
Cc: gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>; detnet@ietf.org<mailto:detnet@ietf.org>; detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>
Subject: Re: [Detnet] review DetNet OAM framework draft - latency


Hi Fabrice and Pascal,

thank you for the great discussion and presenting your thoughts clearly. I've taken the liberty to top-copy Pascal notes on the terms as I think they very well reflect the issue. I've added my notes tagged GIM>> in-line. I hope my notes help the discussion.

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.

GIM>> I think that RFC 8169 uses the residence time (RT) as two metrics - nodal and path, i.e., end-to-end. Nodal RT is measured on each node supporting the specification. Path RT is the sum of all nodal RTs collected in the Scratch Pad field, and is used by the egress node to adjust PTP control message.

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.

GIM>> It seems that what we really need is "jitter", a.k.a., "delay variation". Perhaps we are not need interpacket delay variation (measured as delta between two consecutive delays) but rather delay variation relative to the delay determined by the law of physics, i.e., minimal possible delay. We can define the new metric and how it is calculated using a set of measured delays. Is that close to what you'd like to have?

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.

GIM>> I think that we need to specify where DetNet MEPs (logically) are. I'd expect that we need to specify in the DetNet OAM Framework where the DetNet MEP is for DetNet forwarding and DetNet service sub-layer respectively.





Best regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division


[cid:image001.gif@01D748BD.75342750]
[cid:image002.gif@01D748BD.75342750]
E: gregory.mirsky@ztetx.com<mailto:gregory.mirsky@ztetx.com>
www.zte.com.cn<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=4a9fa1c7-150498fb-4a9fe15c-86b1886cfa64-c66234771f55db2c&q=1&e=de2f305a-f1e9-4ab5-8a0b-2080bd4cd503&u=http*3A*2F*2Fwww.zte.com.cn*2F__;JSUlJQ!!BhdT!wRxOFss6QHaLXwUlm5jRz4xkrkG-OxxazzfEUhW7TCgDZsx3fOGjcF43Yb-WQXI$>
Original Mail
Sender: PascalThubert(pthubert)
To: Fabrice Theoleyre;
CC: Greg Mirsky;DetNet WG;DetNet Chairs;
Date: 2021/05/12 06:14
Subject: Re: [Detnet] review DetNet OAM framework draft - latency
Hello Fabrice



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

Pascal













_______________________________________________
detnet mailing list
detnet@ietf.org<mailto:detnet@ietf.org>
https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/detnet__;!!BhdT!wRxOFss6QHaLXwUlm5jRz4xkrkG-OxxazzfEUhW7TCgDZsx3fOGjcF43W0qFpvA$>