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

Yaakov Stein <yaakov_s@rad.com> Fri, 26 February 2021 05:09 UTC

Return-Path: <yaakov_s@rad.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 BD6B13A0C30; Thu, 25 Feb 2021 21:09:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-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=rad365.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 i35n346eN24q; Thu, 25 Feb 2021 21:09:07 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60066.outbound.protection.outlook.com [40.107.6.66]) (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 26A4A3A0C2F; Thu, 25 Feb 2021 21:09:06 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=keVrVCC1BHtErthlRcDhXbQ2fUXDDcxJuoUvzogw0oNQRb9EH0LSrCN/5ZMfI0tdv9lCPqVwICNSO2afGlYwNvUBecwN9gGaqZlPn0MQC+3zRn4god1s0wgNUrN81KLQSx3g5cPRtA62YtHZfH7rxZKbxH9mIa5935bqpPI9yGf0FUk/cdhq2DLS2xlAvD19Jd7pXean/og13PfMlwHYaiKoh1ECuBQ9xylwc7XS1rvEi2784pZ27m58P5+L7IJhzv6WUO8swrC5c2Ap6vJlbf9YPq63TFu83hRly1egww6SncRrnCrgIaNikjxvA0GYqtcCwYk7ukh4YI8dugVKxA==
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=vAgYtQA0pEy/kS5/6gZs8nbdlLZhIq6HZkEWcXVzauo=; b=FepzjQp1CG98/YyrnNizFLAmJBiAPh9zqShhUW9esaLTJ1Led/89fKivdYVcqZ8jNqnAkb6Mu22ez7Qff2yM6MySdw0Og0g449TxiKO6+AqI8pP46shbWeqdtqwaDC60HFBA8hKpXphiqOEs0ncOy0IEaJkGHFkwfjZTJy+EjIH//D113822Gp3bNgPBPFSbj5BvV3Qa6Q+KDhcMwLxwQD3npCGsx07CR98/6n9a17eE3Sc3O0b0SC7oxuyRN9SSkaUh/uhJzzYeszj27aNitldk1pHd9w/2xJGT2HWzEKVnpe7ZxM2Uiw74R7MKKqK2nwGrRnB8YR2Uy149Jv2UvA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rad.com; dmarc=pass action=none header.from=rad.com; dkim=pass header.d=rad.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rad365.onmicrosoft.com; s=selector1-rad365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vAgYtQA0pEy/kS5/6gZs8nbdlLZhIq6HZkEWcXVzauo=; b=DIEMsDRg1gp8eBTIxZmyfWiLxdmfYDm4ab9Lha70x5jWoqItpfSqtKbJrcEMwwTzOg/cjaE9vAVLHIzBGNChMHmyQeM80t9m9ebbyclqUHM0nH9y7DDk2rlGm+lDMzR9oIspM1onxKXrvx8ckYq1vU5YGuTRXqcvYujXQ2rb8cI=
Received: from AM0PR03MB3522.eurprd03.prod.outlook.com (2603:10a6:208:42::23) by AM0PR03MB3827.eurprd03.prod.outlook.com (2603:10a6:208:71::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27; Fri, 26 Feb 2021 05:09:03 +0000
Received: from AM0PR03MB3522.eurprd03.prod.outlook.com ([fe80::10eb:24f4:1a5e:bc0a]) by AM0PR03MB3522.eurprd03.prod.outlook.com ([fe80::10eb:24f4:1a5e:bc0a%4]) with mapi id 15.20.3890.020; Fri, 26 Feb 2021 05:09:03 +0000
From: Yaakov Stein <yaakov_s@rad.com>
To: Tianran Zhou <zhoutianran@huawei.com>
CC: "detnet@ietf.org" <detnet@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: new draft on segment routing approach to TSN
Thread-Index: AdcJ5AjgmuXpLt94R1Stsoh/vUDwUABaAaLAAAtVwoAADcpzUAADGHv+AA+9AOA=
Date: Fri, 26 Feb 2021 05:09:03 +0000
Message-ID: <AM0PR03MB3522AFA92FF2CA7DC61DF9ABE59D9@AM0PR03MB3522.eurprd03.prod.outlook.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>
In-Reply-To: <89EBAF5C-558F-4723-BD05-65E87FD7CB16@cisco.com>
Accept-Language: en-US
Content-Language: en-US
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=rad.com;
x-originating-ip: [176.230.181.21]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 800b9780-a60b-4c9c-6980-08d8da14a2c4
x-ms-traffictypediagnostic: AM0PR03MB3827:
x-microsoft-antispam-prvs: <AM0PR03MB3827502D0B9793E29F2BE7D0E59D9@AM0PR03MB3827.eurprd03.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: GQbARuW9geIWTBxVxj/1p2IVA2rDOgk0R5X77XMSUwx0ZqfAr7QPSpq/BnvaCLX7sGxXfpWKjuaZH03iVXTsXuCIaAnFOaoqapqKRVtwzfrDmykTaSUs2/tNopTY/YTJjio8+jYZKsivHiUEkZPfkOh9X3LSnJkPGUO+dKqUeWFRCLY25wZ90Mn228DClLSm61o2UOvBSBOKZ9H/BUIyQjFBRBZIb7u0whMMkBmH0rfV8I57NQc5UQQuSY4hqgOLSFI/LB2xhu+yB8T5JYpSa+B2ZH3MTn03GZjSw7Z9PrYEVI9NopbJPVf/M4db2PByADHcGJzOxaM6/ILlZl/8Txbqa5JjffJmbaAB3iJwJQ5DGNHWEtDtncOcCa4gsTwB9vy825NTiGxMH6qsQ7lEwu7IvSD1NsWVEg5iKGHZFwHAd7jaQiuAsi9egOxSB46oE24B8j/0V8pZn2CJ8H0TOM47qcLgnNEjVYF7D+/l6q6dV9Dwt0jk/8SnZ3c3Xg5xbwgvptDRm2FkqPhENYF+sk9nKNMm/43llybeFQv+s3POOQSafOpBvlM9glfo5TjtLOgQV8ETLzKR7RfN3sYAyqZ25un0AOMNpFAGwmavEw4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR03MB3522.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(39850400004)(376002)(136003)(366004)(6916009)(66446008)(478600001)(966005)(64756008)(2906002)(71200400001)(52536014)(26005)(33656002)(6506007)(166002)(76116006)(9686003)(7696005)(66556008)(66476007)(86362001)(5660300002)(66946007)(66574015)(83380400001)(54906003)(8936002)(53546011)(4326008)(8676002)(186003)(316002)(55016002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?Zm11QytQcWNKUFM5U1JnZlFPNGN0dU81b3IwNjNUZ204OS8wNk02d3hwdmVG?= =?utf-8?B?d2ZYU2VNb3VmTTNRdDB0MkhRMFFuWUo0d2RjZSt5YVQyQVBqV005MjNxaVdG?= =?utf-8?B?ZmtRM2tQWVZVYmtZUmRQZUs5bndBd01Sa0xjQ0gyL1JmaUFCUi9XbWF6QllX?= =?utf-8?B?b0szSWRGamZ6NWE3VVl3Y1JFV284VFl2ZlFRbytwc3VzMmNmVW9uR0w1dUFG?= =?utf-8?B?dnJvNW02YUVyU05OVE1POGlRTElPQU4vNERtZmkySFlYMUJrc2FBTm96UjVp?= =?utf-8?B?NUV3b1dIbUN6ZW9oMmNhQzFuTzNzTEZBd3MwOWFHekRMZjh2a1RLejJZNW01?= =?utf-8?B?VTlCZ21UUU15K20rTVArc1owVitnVVlWRStFZE9VTitHNFNpUUFHNzNXUWdE?= =?utf-8?B?RXBIMU5JWHpVV2pPMDRCM2NLcGdvMXo2MmpwQmltVlI3TStBOHVJS0lHY3Zx?= =?utf-8?B?VFF3SlNMbDlidVE4bEdPd1dqMDNVak4yckVmNllZaWdvdk1wa1d0eXVScUZz?= =?utf-8?B?a0ZKSS9XRDhPRHZkOFlEdTE2OUc0OEJHczMzRFBNRVBDcGJPbTdWTGdpTHFX?= =?utf-8?B?dTAxMjlQdWp6YTdqWmt5MUhiVFNRb2xLRUVNYmNBQzBnak8weXF1MTVRelFY?= =?utf-8?B?aDZGc2I1Rmo4QlNlUHhmdkJCRnl5K3g4WTVlL2lLS09CbjFlWmpvZEx4aXJa?= =?utf-8?B?Ym04aVJwdmJsMW84R0FsdmlpdE5XYW5WdnhxL1B2QTN5NlVleXd2cFFaM0Ev?= =?utf-8?B?L0d4SVZCdjBhcTVoU1lyYm1nbTR6UWlCTkhPd0FWNStJUXp3TUFPSGkyR2hp?= =?utf-8?B?VXJsN1hWWmhzS3NCZFV3UDhkTkRlWVh5elI2dXNMeUpVaFhzUStNMnpqaGVB?= =?utf-8?B?b2JOYXU5ZFpaMXFwUDJvYXlJazJRdXVLdEllNjJrUlc0Ykd3QU5WVldrU2hD?= =?utf-8?B?MXlhYUwyb0xXdEVIZk8zaVNldUpYVzRtVDVDamJWMEF5cGxSallkU1NyVENG?= =?utf-8?B?bzZITzJvQjArY010a29rK2xVL2tZNnFJdEdXMFAxSlM0RUI0elFmSHozUDJw?= =?utf-8?B?eUYwSHdhZEE1a1dxTHNRakJsVml6TmxlL3B6RGpVNUN5clFPQmlGakl2MnVm?= =?utf-8?B?ZkVaZUpvTGlGdE1kWUxMeERRSDJTWFpqeHduSzJsRktrVm5EOUphQWduVUUx?= =?utf-8?B?aW9LaWp0ck5jU2tmdHJYdXJocGpuR2IwVnV1S0R2QmxMQS9GZnAvc0I5M0pL?= =?utf-8?B?Z2gzVUVFa3J4YVcxSjNWaGpmK3VLNGt6OFphZXEybG5ValJPZ0taZm1vNEFV?= =?utf-8?B?eUx2cDZQZmlQeEllaTRuamUyL2xUcGRSVEEwbFdISUxhdHBUNWwreTY1UEhy?= =?utf-8?B?MXlGSDVlVmJCVmloc20vdHY2cGJlazc4ZkNDUEk2NnJ0eElKNngvZTRHMW5o?= =?utf-8?B?QmI0NFlPZEQ0K1FZMTJhbjR2cjdJQmExOHlMY2xuZnh3UnRnUGtpQmtSNzBK?= =?utf-8?B?YTRBb3p2NmxqYXU4V0oxdEE0dS9Ua09lYWViSkYxQUVvdGtXci96Z1NKdy8y?= =?utf-8?B?aFdaVnU0aUtJb1d6RldJeENTZlFEK1gwd21mNWFoRHc1WWtTclFHNGpvSHlE?= =?utf-8?B?YWhSVzR1bmM0SHBpUkRLTGJWamhpbTJESTFmdUlNdjRNc3dscWgvY2lhZzNr?= =?utf-8?B?cE9qbHBET1lmN29BUlpsQUtFZnRScmhqclphMDV2aEtaUG1vMFhPZDdkQWda?= =?utf-8?Q?rT6KjL+RhS7P0H6gSelGng3rQLMX0e2BBHSlHSH?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR03MB3522AFA92FF2CA7DC61DF9ABE59D9AM0PR03MB3522eurp_"
MIME-Version: 1.0
X-OriginatorOrg: rad.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR03MB3522.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 800b9780-a60b-4c9c-6980-08d8da14a2c4
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2021 05:09:03.7387 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f9047108-cc2c-4e48-97a3-43fad1b3bf9d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Fq7fxZORBQtLc+unspxrfeRvez6yfaqb3LS6Xx8eM23JarCOV0yUvQhFXamLudVTLtBHSxEjnBHrERtiHMFKlg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB3827
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/YNXmUWnjJHPh4oPcgIAkn3P6NGI>
Subject: Re: [Detnet] new draft on segment routing approach to TSN
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, 26 Feb 2021 05:09:10 -0000

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!

  1.  I gave a specific algorithm in the draft and pointed to Andrews and Zhang who give another one.
  2.  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.
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%7C0f58b1362ad8426a72fc08d8d9d41ec1%7Cf9047108cc2c4e4897a343fad1b3bf9d%7C1%7C0%7C637498852383345583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xs2g3OnkF18VI6ZFHO5LIg5EmJW0m%2BLUHzflSq0I1DY%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