Re: [Pce] [Detnet] new draft on segment routing approach to TSN

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 26 February 2021 10:58 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26A73A12F4; Fri, 26 Feb 2021 02:58:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.497
X-Spam-Level:
X-Spam-Status: No, score=-9.497 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ZX6UtgcS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lWqToGwO
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 XRkcv6dOOWd1; Fri, 26 Feb 2021 02:58:18 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140FC3A12F3; Fri, 26 Feb 2021 02:58:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47525; q=dns/txt; s=iport; t=1614337098; x=1615546698; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fI36yBPin/X+tHjoox5alQn8vnbB7nDWZMSxyHhy4H4=; b=ZX6UtgcS7R5gEEsFMw9oAQ0puAavgmcLoDmytLcajl7C6Xpu4JB/WN9a JUyUNZNcBL+Ep62ZAQlAdt59qv52uoKOZRiNtoBiEIdaQV0i33tdfNiGl WCbuk0ngBnWtIMu4Un60hwyIWVEaZc9VEcY5r9f6uysvxUGvIR+Nn9uFQ U=;
IronPort-PHdr: =?us-ascii?q?9a23=3AGwifjBxtfTzWSRrXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWBt/VwhUDEXMPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoMVVcB8v/IVbVpy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAABY0zhg/49dJa1iGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBgX4CAQEBAQsBgSIwKSgHdlo2MQOEPoFfgWk?= =?us-ascii?q?DhTmIZQOZIYFCgREDTwULAQEBDQEBHQEJCwIEAQGBb4IaRAIXgWMCJTcGDgI?= =?us-ascii?q?DAQELAQEFAQEBAgEGBHGFYQ2GRAEBAQQBASEKEwEBBScLAQ8CAQgRBAEBIQE?= =?us-ascii?q?GAwICAiULFAkIAgQOBYJrBAEBgX5XAy8BDqUaAolpPHaBMoMEAQEGMIRrAxW?= =?us-ascii?q?CEgMGgTgBgVuBGoQGAQGGRSYcgUVCgTgcgVlQLj6CXQEBAheBCAoBEgEJLxU?= =?us-ascii?q?BCYJgNIIrgVklRgJsHTZXBDZFAwQBNCAZKYtAhG8Jgx+HR4xTkDmBFAqCfIk?= =?us-ascii?q?/jD6GIwMfgzeKT4RWkHqyGxGERgIEAgQFAg4BAQaBaiQNWnBwFTsqAYI+Ez0?= =?us-ascii?q?XAg1WjSciDBaBAQEIAoJBhRSFRXMCAQEBMwIGAQkBAQMJfIo5XgEB?=
X-IronPort-AV: E=Sophos;i="5.81,208,1610409600"; d="scan'208,217";a="596811278"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Feb 2021 10:58:16 +0000
Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 11QAwGG4001290 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 26 Feb 2021 10:58:16 GMT
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 26 Feb 2021 04:58:16 -0600
Received: from xfe-rcd-004.cisco.com (173.37.227.252) 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; Fri, 26 Feb 2021 04:58:15 -0600
Received: from NAM04-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Fri, 26 Feb 2021 04:58:15 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G6kMoi1DkEEBmQ53p3GBEPx8UOGB6cCdXHryadiMXAXoufdijDenxmRkWdEN+VEvUqr8COsgqIS7+JMl58oDztNh8gNvxnw9a23U2pMP0zPXwV3r5VT5bRFd/+V4mShoHkGZIEbgTmp2DaRg39HQT9MnVOuPBf4nzVACGsWqCFqach8AUI3ihNP36oU3rBlSHotlDjwVHlfB7h76+X1tJl91tn3WwWlfCM8qHgllaafDFzy++QUsDduyaHkx4FMA4HFSGnSAOwN0B2gapLrlKM0PlA/qrL76XPLlXzcYkpOc2y8+Tp7WM+9nMtKWaYlF8ekctdPciKd/O2g1NnlsRA==
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=fI36yBPin/X+tHjoox5alQn8vnbB7nDWZMSxyHhy4H4=; b=Q01YYAW6w0nxaY8X1uw0r9mWsFljgqpaKF00uM5NRLpfo/IkTQ2mW7jiB3BSIehSUpCaPekywBgP6+LkbnTP/UUEKu4c5an9AeJbI/TUDKgFSAcXMOLFZqCN8vdnFs5wAVho4/KMTvKIPKRkwARqI6J0h3SSGeqYoTOTOPerx5/0eNR7vUCaN3Nhxa/h+XX40wsVJqYyjwFCj0XIhOu3HAVca7CuKRnt+xpA7WVqRKmXfkiJIQ1QcOECOjQydk+lE+WuDzpnN7iFZSdS3uWP8wFrs3RMbbMfWTjJmcat7dfcivyMXQlBu9ndeoM45Hfo4fN9TRAZ3ezHz7hTfm67yQ==
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=fI36yBPin/X+tHjoox5alQn8vnbB7nDWZMSxyHhy4H4=; b=lWqToGwOBtYP1u25IGXuJCAiHfmA//5z/YIB3m9GJtPJyQ0Ay8jbuE9Y7D/uOq4xrVFd5BcIMaaF5JLTrnhW97em8UvP8FCbSK2oa4sIsmngD+YuVaxRmyWvD6gajptAHRbFxEC+782FgwALYBlQjYCQbYPiA4GvB18toXa2/HI=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4980.namprd11.prod.outlook.com (2603:10b6:303:98::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19; Fri, 26 Feb 2021 10:58:12 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::14a1:29eb:e708:d7e6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::14a1:29eb:e708:d7e6%7]) with mapi id 15.20.3890.023; Fri, 26 Feb 2021 10:58:12 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Yaakov Stein <yaakov_s@rad.com>
CC: Tianran Zhou <zhoutianran@huawei.com>, "spring@ietf.org" <spring@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: [Detnet] new draft on segment routing approach to TSN
Thread-Index: AdcJ5AjgmuXpLt94R1Stsoh/vUDwUABaAaLAAAtVwoAADcpzUAADGHv+AA+9AOAAA02UYAAHar3AAAHfxMo=
Date: Fri, 26 Feb 2021 10:58:12 +0000
Message-ID: <4803C949-F985-4CF4-BFDC-250993F1ABE3@cisco.com>
References: <AM0PR03MB35228092287B38B95D7056F7E5809@AM0PR03MB3522.eurprd03.prod.outlook.com> <3c69571d0bcb4a6ea1d08bee53c0277d@huawei.com> <CO1PR11MB488181838180DBE6F5DB3B5BD89E9@CO1PR11MB4881.namprd11.prod.outlook.com>, <AM0PR03MB35227928249020BC6D0B6806E59E9@AM0PR03MB3522.eurprd03.prod.outlook.com> <89EBAF5C-558F-4723-BD05-65E87FD7CB16@cisco.com> <AM0PR03MB3522AFA92FF2CA7DC61DF9ABE59D9@AM0PR03MB3522.eurprd03.prod.outlook.com> <92b5f0bbde5149b69f4700846481e2e2@huawei.com>, <VI1PR03MB3535E496EB602958385AF6AAE59D9@VI1PR03MB3535.eurprd03.prod.outlook.com>
In-Reply-To: <VI1PR03MB3535E496EB602958385AF6AAE59D9@VI1PR03MB3535.eurprd03.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb15:262:d900:69ad:4fc4:29ee:f1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a343d9e6-4eb2-4bfe-2332-08d8da45692a
x-ms-traffictypediagnostic: CO1PR11MB4980:
x-microsoft-antispam-prvs: <CO1PR11MB49805658F99F49414047C0A1D89D9@CO1PR11MB4980.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: h0WVyRgYRuXphs4EtIYfsZXv3ZBdPNrGiXcQIGZZC0J7ecLSQ/KFzZsjFRUJNri2Ia2QCa0nlhxnQA2eFN7zS2rV76s7Vq9l1Jv2al8GX3TcaDKsMoWeLrt5aNfCS32obwQPWqmLKEWOyw/TocdTvUQ1CDk+u9Xygjnz88cj8aGU2z9DihCEIyVD4WkK0HXOgOKWnMJvL/cX/lVel9KkWUfWPSp4kmVAs5Vq06OUf+nqt0aekDydVLv9N/44scXOaynNUGaWU26/M3PG2qWbgGkUMrQ9pnuSXzQtzmwn3f4UWd0Sv0eg3vCLsDDsBXOY3khtwLSwocj9kN08JjXLWgkUt5VzhEKqh2ctS0qj727JEn1JFqljZEAjPuku5WfkU062Hl8cIU+6MIgVWJOLtDVFylOC4oJ1ysS5pAseKahd4o1vukLfsIR20SjmB1h6ydTcIYR+utytsJXNVVMPC8ifETjYpgePgm/rDqjLZOjObxrF+0tugKPTCRESjFoV+Fh4SKSREfL4Xc3u8LgBwkU0uFXOHSjSn1ymdiP6snA4vlusHIxYMes5rr2ksCxDe9s/b3LnLIxkhTUwLf5VFivZ58DEPAZhlLYDP4sLYg825+6k60LaMyvN4laxaU/NMFVbLYN76C3JgfM9T68NiBDfnpAR69gBa601Qf+bQ0VDrF9dGPXPBvE16wPJNZVJ
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:(136003)(396003)(366004)(39860400002)(376002)(346002)(83380400001)(66556008)(54906003)(316002)(6486002)(66574015)(53546011)(33656002)(86362001)(166002)(8936002)(4326008)(66946007)(5660300002)(66476007)(36756003)(6506007)(6916009)(76116006)(2906002)(91956017)(64756008)(2616005)(6512007)(8676002)(186003)(478600001)(71200400001)(966005)(66446008)(45980500001)(244885003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?amVqcFJ3M0l4MXU1OTcrR1JPM01sK2Z3VmZrTjRFL1hrbzVGNVlYRi9Xb1Jh?= =?utf-8?B?b1JRQmxhSngvU3hxM1ppdHJjak1RS2FFMGFiNDdwb1VvaWhidWNETVc1L0tE?= =?utf-8?B?cll5ajVVcGxPb2FaWGV6QzBTbXlZaXVhYkl2YlZTMWR3bTlSZkJSR0xhdlF1?= =?utf-8?B?dnRBalhXYmQ4RGYydVMxTk5ISmtCMmlSUVdYZk1QcUU4RG5MekJvT2IrblJB?= =?utf-8?B?Ly9scCt4eGlYc2JyeDJDOTAycExpVjZBVWJMVmVmckhGSDB5dTBiZE9RSjZK?= =?utf-8?B?TWtseEVSWVRUS1J4OFBhYXo2ck45akY0MmFtUTdXVGE3TmZCOFptNS9leUNM?= =?utf-8?B?RDJDNUhEN0lhcjJneGprbFdhV2Y1ZFZvdTNRL3gzYm01Y3kyNXBYbHZBMHl4?= =?utf-8?B?Nm5WNkMvMGZEMU9oREozaGZqM0gvNC9uck9idWhXS09BQlc4Sk9aeUxLa2tZ?= =?utf-8?B?SmErODdSTnJJVHZpQmwwVHhCNFZSMTBjdWppNUhjeHBaOC9ibG02VUNvQ1Jq?= =?utf-8?B?L0RxM0hvQTNLUGRTVWNnZ3lBUENyOTFmcXhDRTBsUVVjT3hpN0MzbFJoeDll?= =?utf-8?B?TUczQnlWR2J4NFpRNXBQS0hXbWJjNFhNSlB1YytaOGdJWGtrVUUrMnVDOEZs?= =?utf-8?B?dC9RUENjNE1XMTJPbkd4aHdCa0NpRm1sUElQMzVvQTVUUUNieUd5MldUM0dY?= =?utf-8?B?Y1FLQU1tZkNyS3hFM0t4bjIvWXp4QnJFd3psc1dDY0I4Sm5yd0dtSXNkME8x?= =?utf-8?B?U0pJRFZJaW9uSmlnR0FVeHl1ZHZZM1o4YmEzbG5SaDJNS1pvYnJlOEsrd0w2?= =?utf-8?B?VHRiVy83L05SYUdtUUlxWElwbjg5NzZPVHEycU9VWTMrK2NSSTczdDc5aThk?= =?utf-8?B?RGd1QXdJNFM1Q2RNOUk3SURlMjJrdDl2dmZ3MGVsanpKcEZpUlJ1YkFYRmg0?= =?utf-8?B?RDhWNitVUlJDVEFTNEtqNUxFcU5wUmF4aENiYnN0RlpaVFZCTGdscU1NdVBG?= =?utf-8?B?MUpVTTF3M3N1T21qc2hMR3l0NERzZVZ0RnJWclVuV2dMemxIMFVSWjFXb0RG?= =?utf-8?B?djc2SkNzRWpweGFWaU5Sb2EyNEdBV01tbVZxYlhpM1NSRzdQckRhclVFZ09J?= =?utf-8?B?ZVFBZTlPNzN1TkVhWmlLRlJDcUY4SVplWVhBdE5WZzZNeDJDb3ZPTWVSRHRD?= =?utf-8?B?aWQ2ZHRPWXdtWmhyTElPZVZncnozdjJLcHJLMkFPYmVpcjdTQzJ3QXF3Qnor?= =?utf-8?B?bXYwckRtUUYyOEVrOWFSZ25VUDNWNEFSK0xFYUYrSHJVbjdaOVlxMmR2bkJk?= =?utf-8?B?T3I2OGtCRnZuWjVUdmxNNnJSZmExQStOU3FLbmZ2MEt0aCs3YUxvSGJMYkZo?= =?utf-8?B?UTIvbERaNVBnNWRtZDhrRE1BemFpSnlyQUR0RGhkRHFocWZkYUErTmt1VGlT?= =?utf-8?B?WGVsNjBBWjhsNXRjUWRmZ2IwVkZMbWR2OC9qenh3cGxaYlB5U1NuU050a2xF?= =?utf-8?B?eVRTZDJlVU5UTWxMUkRxMk1ESXpwM0d4dElFcWZ1RkVteHhyejdTU1ZlRm5B?= =?utf-8?B?SlBSRWw3d1BRL2hraHR1anJrZWJRcHBFRGNTcWlCbE05MkROYXJ2UC9jamF1?= =?utf-8?B?SUVBcDlqTHFoa2tyTEhFQ3VnT0N0aEx4SXdyeCt4Y0NoSE03aGFHWS9WYkx0?= =?utf-8?B?cXZVcmk3ZlJQY3BtTUNWdGRTUzJWYThzdW5CV3k2QmxLRmpZT2JHTkhWb1d5?= =?utf-8?B?ZGpVTTBRTS9HeTN4dWY3VkY1Smk1MjFqS2FPNGdBcFNFeUJVbDJVQURCQ29H?= =?utf-8?B?Ym0wYXhKUWxqdHUwMXdSTXVxMnVwenF6bjlMenBUVEVYRHdST01mVUdZemoz?= =?utf-8?Q?vDiggTqHV8m9H?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_4803C949F9854CF4BFDC250993F1ABE3ciscocom_"
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: a343d9e6-4eb2-4bfe-2332-08d8da45692a
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2021 10:58:12.3977 (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: JSGjAN9edtcH1A+dHIjyevrx5UVmFuiXAIrnbpGcQ7KABLqNJpkZ8o2MVaYQYp0DsUezA208ULR1prb38Bj1rg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4980
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/Z6x1apR1wZ93I90kt3nVzCsjDiM>
Subject: Re: [Pce] [Detnet] new draft on segment routing approach to TSN
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2021 10:58:21 -0000

Your RFC should be able to signal drop dead but I believe that it would not be the decision of an intermediate hop. Missing a deadline between b and c may be recoverable between c and d...


Regards,

Pascal

Le 26 févr. 2021 à 11:14, Yaakov Stein <yaakov_s@rad.com> a écrit :


Tianran,

All valid points.

I do not doubt that there are RT cases with drop-dead deadlines,
but even they must live with rare losses (which is what a failure to meet deadline becomes).

As I said earlier the stack mechanism can replicate time gating behavior.
But time gating loses bandwidth efficiency and is really hard to scale up.

EDF in general will beat calendaring (i.e., has a lower expected latency),
but has a longer tail (which will be the aforementioned losses).
Given some statistics of packet transmission times one can calculate the percentage of packets
in that tail for a simple-to-setup approach with EDF.
It might be the case that some loss is better than not being able to calculate the schedule
and having to devote a lambda to each flow.

Y(J)S


From: Tianran Zhou <zhoutianran@huawei.com>
Sent: 26/02/2021 10:20
To: Yaakov Stein <yaakov_s@rad.com>
Cc: detnet@ietf.org; spring@ietf.org; pce@ietf.org
Subject: RE: new draft on segment routing approach to TSN


CAUTION: External sender. Do not click links or open attachments unless you know the content is safe.
Hi Yaakov,

Thanks for your clarification.
Again I think this is an interesting work.
Please see inline.

Cheers,
Tianran

From: Yaakov Stein [mailto:yaakov_s@rad.com]
Sent: Friday, February 26, 2021 1:09 PM
To: Tianran Zhou <zhoutianran@huawei.com<mailto:zhoutianran@huawei.com>>
Cc: detnet@ietf.org<mailto:detnet@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: new draft on segment routing approach to TSN

Tianran,

For some reason I didn’t see your email and thus never responded to it. My apologies.


1.       I believe that I address this question at the beginning of my draft.

Using a single deadline per packet at is suboptimal at any particular switch.

For example, say two packets arrive at a switch, one with only 20 microseconds left on its deadline

and one with 50. The switch would naturally schedule the 10 microsecond one first.

But what the switch doesn’t know is that it is the last hop for the 10 microsecond one

and there are only 2 microseconds from it to destination,

while the 50 microsecond packet still has 45 microseconds of physical time ahead of it!



ZTR> Yes, you provided a valid use case in some sense.

But I have to say, IMO, the real-time system cares more about whether the deadline could meet.

So in practice, the task set is fixed, and all the latencies are calculated and guaranteed to meet the dead line. I do not care whether the packet could arrive earlier or not.

So, an deterministic and easy schedule make the evaluation/plan easier. And It’s better to see all the tasks could be accommodated in the plan.



ZTR> I can provide an use case, say a task could meet the 20 end to end deadline within 2 hops, one hop for 14, and the other for 6.

If we give split hop by hop deadlines, 10 for each.  That means the first hop with 14 delay cannot meet the 10 local deadline.

So for the first schedule, this task could be accommodated. But for the second one, this task cannot be accommodated.



  1.  I gave a specific algorithm in the draft and pointed to Andrews and Zhang who give another one.

ZTR> Thanks for the pointer, I would like to look into them.


  1.  I don’t think a service needs to support EDF, but perhaps a switch does.

I haven’t seen EDF support since the ATM days, but am proposing that perhaps the time has come to re-evaluate it.

However, I am not advocating for EDF in this draft, just for the stack.

I mention a variant of EDF which I believe is better, and am working on another variant which is even better.

They can all be built into hardware, although admitted are more complex than a simple queue.

But they may be simpler than a set of queues with time schedules like Qbv

and are much much simpler than monstrosities like MEF 10.3 token bucket with cross-color/cross-CoS sharing and coupling.



ZTR> Not sure if my thoughts are common sense or not. ☺

IMO, the merit of Qbv, or TAS, is to isolate hard real-time, soft real-time, best effort tasks. So that they can accommodate in one switch.

This is one critical requirement for IT/OT integration.

EDF does not conflict with TAS. I worked on some hierarchical scheduling mechanisms many years ago, EDF is used in the time slot for hard real-time tasks.


Y(J)S



From: detnet <detnet-bounces@ietf.org<mailto:detnet-bounces@ietf.org>> On Behalf Of Tianran Zhou
Sent: jeudi 25 février 2021 9:14
To: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>; detnet@ietf.org<mailto:detnet@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Detnet] new draft on segment routing approach to TSN

Hi Yaakov,

This is an interesting topic.
After a quick review, there are several questions as follows:
1. It’s clear to me to have a deadline for each packet. So that router can schedule the packet based on the urgency. But what’s the motivation to split the end to end deadline to several local ones?
2. How to divide an end to end deadline into several local deadlines? Is there any example algorithm that could be used by the controller?
3. As far as I know, most devices do not support edf. I am not sure whether your proposal based on edf could really be useful.

Cheers,
Tianran


From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Yaakov Stein
Sent: Tuesday, February 23, 2021 9:14 PM
To: detnet@ietf.org<mailto:detnet@ietf.org>; spring@ietf.org<mailto:spring@ietf.org>; pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] new draft on segment routing approach to TSN

All,

I would like to call your attention to a new ID https://www.ietf.org/archive/id/draft-stein-srtsn-00.txt<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-stein-srtsn-00.txt&data=04%7C01%7Cyaakov_s%40rad.com%7Cad8cd800d9504f145a9a08d8da2f6322%7Cf9047108cc2c4e4897a343fad1b3bf9d%7C1%7C0%7C637499244365725326%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xBIZ5ReTMzcAfx1TafhEl5wBlIzK6M8KskAQG%2BdtSZY%3D&reserved=0>
which describes using a stack-based approach (similar to segment routing) to time sensitive networking.
It furthermore proposes combining segment routing with this approach to TSN
resulting in a unified approach to forwarding and scheduling.

The draft is information at this point, since it discusses the concepts and does not yet pin down the precise formats.

Apologies for simultaneously sending to 3 lists,
but I am not sure which WG is the most appropriate for discussions of this topic.

  *   DetNet is most relevant since the whole point is to control end-to-end latency of a time-sensitive flow.
  *   Spring is also directly relevant due to the use of a stack in the header and the combined approach just mentioned.
  *   PCE is relevant to the case of a central server jointly computing an optimal path and local deadline stack.
I’ll let the chairs decide where discussions should be held.

Y(J)S

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet