Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

tom petch <ietfc@btconnect.com> Fri, 28 May 2021 15:58 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4D93A2CD1 for <lsr@ietfa.amsl.com>; Fri, 28 May 2021 08:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 Vr0Js9tMaBWw for <lsr@ietfa.amsl.com>; Fri, 28 May 2021 08:58:38 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30125.outbound.protection.outlook.com [40.107.3.125]) (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 DF8383A2CCA for <lsr@ietf.org>; Fri, 28 May 2021 08:58:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K93ZiBrKxQGWseuid1eORJhi8Yj0phtlY8cSwWJ3OpdV3bnXQ6Zqv54i/cs5QeYWZYkS8lThGY3kDvgy+lVogi8YD3mNxTL0YQ0e1sJQYe8++XQgmKC/eWaYvpyq7Gjzlbq2nIbu58Tsy5YturGluf7WfBSIG0aHTey3UDPKpqs65IDMeghiLhooxVG+1vNMMZN/MC3cjZv5nWCfpJkzxN4UWWXVk0tLQOyiS5bbYso+9UcndsKSvECppdp2gMxbVmKiVCejY0HnWsRaIrKlfI3klxDjNzFJYsJg+UCcQuENB8mmutpp4JnfjbRx6Jfe1sfrbc78Miwmux0U6Bkivg==
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=tA3Pq67CT8ZjvKwgXSoI1QHaVnkJhRNg2inHqgaqcKI=; b=Q/sXWgeNUtkepRKd1q/sS/MFBHxOsM6EhKhT+FrdgmmP8j1+NgA1NXfQBTYegqKOjcYcB+/XbXNYo8VoV/9MmkGODMxwTTgdqqP6AEe+aeoUYtTmo5sWGeurIber3KmrVAZLtOlCuiFxomkr95BOUCNBHt7K+JUCQg6E0GPzu7+qXR67qSKp2G1WjnRankf3p+BlPX4uGzuPJ0NwoHb95ss4e9ObC87UkM9Sv3zJKqHU7YJOnwwIyTQvfQCgpKLGBdXFvdYBduZThukidiGrZs105GhZw5Swx5MleCmXvlzyZvKXbQT9vHKwCyS3lVGEa6dKkZWHiEtztiPyJ5rijg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tA3Pq67CT8ZjvKwgXSoI1QHaVnkJhRNg2inHqgaqcKI=; b=mvXDDacY14zvphhV2tF+rM1tKU1PWWhgJT91jpQnrBsmUV/UVQXO5VLy/ixkeKxitKV8mNteHLUhgayl6oNLnAuz0jVSHsOWk9fukzYvrXhChwVdAJ+IXtqYUImUy0wvO9p8BhOsazcC7bfXforgQjli38RtHEiwI+hxzrV2Mpo=
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AS8PR07MB7765.eurprd07.prod.outlook.com (2603:10a6:20b:396::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.12; Fri, 28 May 2021 15:58:35 +0000
Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::a05a:a474:bf78:f0a9]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::a05a:a474:bf78:f0a9%7]) with mapi id 15.20.4195.014; Fri, 28 May 2021 15:58:35 +0000
From: tom petch <ietfc@btconnect.com>
To: "gregory.mirsky@ztetx.com" <gregory.mirsky@ztetx.com>, "tony.li@tony.li" <tony.li@tony.li>
CC: "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
Thread-Index: AQHXUalbwBeGKIMHlUmJKVw1QbyD4Kr5EB3p
Date: Fri, 28 May 2021 15:58:34 +0000
Message-ID: <AM7PR07MB624859A828E5D04DA221BEDCA0229@AM7PR07MB6248.eurprd07.prod.outlook.com>
References: 202105251032405928718@zte.com.cn, 5988EFA2-CD6C-498B-9FB3-AE6E98D61A95@tony.li, <202105260502337009654@zte.com.cn>
In-Reply-To: <202105260502337009654@zte.com.cn>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: ztetx.com; dkim=none (message not signed) header.d=none;ztetx.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.143.250.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 368cdddf-ab2d-4e61-cbfe-08d921f17303
x-ms-traffictypediagnostic: AS8PR07MB7765:
x-microsoft-antispam-prvs: <AS8PR07MB7765170CCBCC269162A5FE97A0229@AS8PR07MB7765.eurprd07.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: zjNOSpgpCUvR/w/TwC46lAXSbCFG6EKenvAoUfSi6fyewmqBCJmKD/gVO70Da7nV9HLD0uGvEEKwxy4v2m3r7hp0B2IE1DidZMG0rkgQmLS1eMZOsg8KcgDBakXytcY3FzOw5bfO6Zq7JoJxyctbcn914rphjBVodPe2qAtbEpefd0+E8OEZwrKwH+cbtQ9ZPGlqnF5iEDghHRhC4YVJz6y/s46ogLuNQ8qPwhNhrUdaxSj3yB6PZX2jM7sMfGlhN9SoTtVDpLIg6X4qY5U/Azr4VwY0ZtdzUCASntwJ4D4ZFE0rFQttS3n6EPYaZyjn9kH1YJBms05WFDEnEC53sy02gqMLeWAo+qUK/sB5xyC8UD7er7Lr5WtiZEZjNNgx15T49lHrZQaHlKpnx8dcb5Vqgq3Ytlm/cUvlBtG3iiNfDAn9QFtNW6kE9fkJuWnMRB035BKhkAOtEZDR1xYAQOBSREEHCox2QZjaaRXAAGMibIxAu9iqWFuk73HZHqzikzVoI/Jf0cmK5uQ/4e2e/1wMgS8f/t4FKUcvNO8FUPeGURXvfGJT2MCO20wjicnaojFJawNGdmWeqc7G+JyBW08JjNNL9O2SmbUDxyNOE9Oq25A6M2+iskyhmBeUfu3xGLf3GZ5xsoRmYWsHqEse0CApT77pBjp4+lT2Qxt0BYOURvwTzza9I3Zl25WNG+K8C2hvG6WOy6Ki9QjgukAWeQTJMvBXEBf1PP/5AmI4c7U=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(366004)(376002)(396003)(136003)(71200400001)(15974865002)(110136005)(9686003)(316002)(8936002)(8676002)(33656002)(2906002)(7696005)(55016002)(186003)(38100700002)(64756008)(83380400001)(76116006)(66556008)(66476007)(91956017)(86362001)(99936003)(66576008)(66946007)(122000001)(66574015)(4326008)(26005)(6506007)(52536014)(478600001)(66446008)(5660300002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?gb2312?B?akYvSHBSdGxHeVBNSVF3YjdyZDNGN2tBM1VzOFJlRUNOdUJ6ZUU2VXZoMHN3?= =?gb2312?B?blY4ZlJuV1o5M2Jua2tGYXp0TEpXaWE1VmJtWjdxS2t2eW9MR1dOVTZ6L3Rz?= =?gb2312?B?VHBFY25KVVl2L3ZEZWQvOHR0RFJBR1d6bzZ1dFBBUEhlK202N3o2Yk1VWFRx?= =?gb2312?B?SU91MWI4M3hqb1hpS3VETmZqcDFLVG14cWV2Y2twS3lJK2VVVjR2cUttMDF2?= =?gb2312?B?QUNqOXZDTUZIL2h5MlhSZ3p1SHdnSW9hM09ub2ZSb2VubXA0anZqSit0dG8v?= =?gb2312?B?ZndNY0FkK25KSUh5NkIvak5WUEdjNm54RkE5MTM5cGc0OEpoYlpCbEJyNE8w?= =?gb2312?B?M3QxOUxBWWNpR0xwbi93cUxWY0t1a3l3MXh6SjdqemhQTHRsNXpNWWNxWHQ5?= =?gb2312?B?Qmcwak10S2hQam95M0hqL0pKOC9zZXBVOTdCdDB3UUhyNUJCZlJ1NEFHL2RY?= =?gb2312?B?ZnI3VUsrdnN5QTRXbUM5YmZvdEM1S1BCRVUrZkRCdzduRGp4a2ZyaFh4UXpm?= =?gb2312?B?dXJiNnkxV3pxa0x4Wm0xZzBpRGFLb3YyZUEwNDk3VTNRdVRmL0xZckR4Y0o5?= =?gb2312?B?a21pK2wxbGMzV3FmaUl4Q0JaWFpvaCtUQkhsWU9oM0dncEdBeHdwdFVVa0Yv?= =?gb2312?B?WFpocjJHTHcxVHA1RGZXazRMSks0MWlVMjZGcVpJS2ttalhDcFJwTitNd29q?= =?gb2312?B?UFZsM09CcGUwQ3p1VS9JYkgvVVdCK1pOWWpqSWN6VTRObngySm5DRkYwNUpo?= =?gb2312?B?WjNyU0o0MUFZdzBJajBtMTIvYzJqWDM2OGdUdjB2RUI3dlIyUnI0bEw5UWYy?= =?gb2312?B?QzQ3dW9sbDVCanhKZGNzQTJWdDVaT0pJbUZVeTFXVzJGcm1OSDZBTkhuVk1B?= =?gb2312?B?ZnU1OENFbFVtdFpubFhLL2pBTkJrYSs1c28vUWF5a3JWL1lxeHF4UndEUG4w?= =?gb2312?B?d2Z3VWw5QTZsNWdUQ1M1QXRNeEdSL3NXUG1ydW8xMjF3a2d6L1JIMFVrWXA2?= =?gb2312?B?UldrVjJ3WmNQWjVEbm1LRXNCUmNNaE1oK2x2ajlzL2FRWmY1bDRWaERLVkZX?= =?gb2312?B?WmIvWHJMRHQ5YWp3Lzk1bGJmM2tEVHp5bkRZM1dxRzNCd2p6TVhtYnJNc2N2?= =?gb2312?B?VlAxaVNycEVVT2VldjRnTTlxUFA4UFcyZ2MydUVPTm1DQnR2cGNHVmNqa0dY?= =?gb2312?B?eUdZVFU4Ty9nMHJrbkoxVStKeHc1bytLSnNHcXo5T0dRZlhmbW5XRkxVL0g1?= =?gb2312?B?dGN0ZkV1STM5ZVdhR0dvb3l6UjNPaVkwVnl1TjIxVG95VERiQUVETTFIVm5T?= =?gb2312?B?Z1J3WXlNNUlvaElacmNtV0tVVzYzN0ZQNENHYXVDcnVydU1IeU0ydjVoYzlj?= =?gb2312?B?Z0lBZzBTd2JUMGJWVUxYR2VDcUo4YTgvc1h3c0hpbFUya0Q3Y29Ta3BOdVZ0?= =?gb2312?B?elFFdDhSdUEzT1pVNFE4cFJzWnBDME1xWTlrdUhtY1Nqa2tLaVpFbmdMUXQw?= =?gb2312?B?TGk5a3lwWGVDYXQyZWlneHNGSzNEL1YzOGZsV0pBTTJFWlZiaERmOGRIWjg1?= =?gb2312?B?TC92WDVYb0FhN3lsRFEzODlSME9SenVYeVUvdS81UzJzdnNSdmc2T1Jxcm1k?= =?gb2312?B?dG1OSlpoTHoyazFXN2g1eFgxenhEb3hteTZoUFAwL2JnYjFBUlpNeEJVaWtE?= =?gb2312?B?NjFnTkJkdk4xekkwVU4zeERWbDBhbWcrNUV5bzlQN0FKcXVheHZoYlkyeFRZ?= =?gb2312?Q?kDLig2HCKGn48pqymA=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_003_AM7PR07MB624859A828E5D04DA221BEDCA0229AM7PR07MB6248eurp_"
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 368cdddf-ab2d-4e61-cbfe-08d921f17303
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2021 15:58:34.8844 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pZinnDWQFFMdxww67M+ME1ymyOoy9y5+NlqWeCPUep2iuHTMY8Bo80aGThkXJL4wS75Cxt4KlbzuvfwyEGLE5A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR07MB7765
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7ITMOTff-NpJyUGvDDnCCMR9gII>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 May 2021 15:58:44 -0000

From: Lsr <lsr-bounces@ietf.org> on behalf of gregory.mirsky@ztetx.com <gregory.mirsky@ztetx.com>
Sent: 25 May 2021 22:02

Inline under <tp>
Tom Petch

Hi Tony,

thank you for clarifying your view on this. Please find my notes in-line below under the GIM>> tag.


Regards,

Greg Mirsky


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


[cid:9ae3e214c17d49ed935d87c674ba3ee2]  [cid:24242e5637af428891c4db731e7765ad]
E: gregory.mirsky@ztetx.com<mailto:gregory.mirsky@ztetx.com>
www.zte.com.cn<http://www.zte.com.cn/>
Original Mail
Sender: TonyLi
Date: 2021/05/25 09:52

Hi Greg,

Firstly, I am not suggesting it be changed to a nanosecond, but, perhaps, 10 nanoseconds or 100 nanoseconds.

Ok.  The specific precision isn’t particularly relevant to me.  The real questions are whether microseconds are the right base or not, and whether we should shift to floating point for additional range or add more bits.

To Tony's question, the delay is usually calculated from the timestamps collected at measurement points (MP). Several formats of a timestamp, but most protocols I'm familiar with, use 64 bit-long, e.g., NTP or PTP, where 32 bits represent seconds and 32 bits - a fraction of a second. As you can see, the nanosecond-level resolution is well within the capability of protocols like OWAMP/TWAMP/STAMP. As for use cases that may benefit from higher resolution of the packet delay metric, I can think of URLLC in the MEC environment. I was told that some applications have an RTT budget of in the tens microseconds range.

It’s very true that folks have carried around nanosecond timestamps for a long time now.  No question there. My question is whether it is actually useful. While NTP has that precision in its timestamps, the actual precision  of NTP’s synchronization algorithms aren’t quite that strong.  In effect, many of those low order bits are wasted.

GIM>> What I see from deployment of active measurement protocols, e.g., TWAMP and STAMP, is the strong interest in using PTP, i.e. IEEE 1588v2, timestamp format in the data plane. And the requirement (actually, there are different profiles) for the quality of clock synchronization for 5G is, as I understand it, achievable with PTP. I have no information if that is the case with NTP.

That’s not a big deal, but when we make the base more precise, we lose range.  If we go with 32 bits of nanoseconds, we limit ourselves to a link delay of ~4 seconds. Tolerable, but it will certainly disappoint Vint and his inter-planetary Internet. :-)

GIM>> Agree. I would propose to consider 100 usec as a unit, which gets close to 7 minutes.

We could go with 64 bits of nanoseconds, but then we’ll probably only rarely use the high order bits, so that seems wasteful of bandwidth.

Or we can go to floating point. This will greatly increase the range, at the expense of having fewer significant bits in the mantissa.

Personally, I would prefer to stay with 32 bits, but I’m flexible after that.

GIM>> I think that we can stay with a 32 bit-long field and get better resolution at the same time.

<tp>

A related item.  I was looking at draft-ietf-detnet-yang which uses uint32 nanoseconds for latency so that is another where nanoseconds can be found.

Tom Petch

Tony