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

Yaakov Stein <yaakov_s@rad.com> Mon, 08 March 2021 11:45 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 2472D3A0C03; Mon, 8 Mar 2021 03:45:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, 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 K2PWawMwH-8Z; Mon, 8 Mar 2021 03:45:24 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30043.outbound.protection.outlook.com [40.107.3.43]) (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 9EF9D3A0C01; Mon, 8 Mar 2021 03:45:23 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CKktFyNbf7Rg685J2RpbyLUogzKjKVxfC6bpFdipWcL6o8kxJcNxRwBNEoE9csecNtgudTWZiG67ZflKI08ZtAhWSISNvzG1R3w9AXyOMaV3UNTHF3lqHfIEdGxCgOmbGLnyVQlO0CnLJ77C6AOJ+55ISNPI0xQWoa2/ZrjvkK8jaf6nK+E0PPtSAHTdNgKDdW5u748YkQak30b0LdY9jGmWQYWRRz9CGJjZz+dB/mcepKyqFfK5rKQY2taiFGTXg9J/R1L+nXj9teAtZSrGyKm3Egy2etiI0MN4P+OlsG6fTMc/6T1GNGVdoGQRWjR5m0Uf6PRphnwKIH2b/p2hmw==
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=Lr93Zn5KF5Zyo8cEcX59h630M9Cjr140u0Q2GAqX3qg=; b=bMSaUPURsUbU1s9SBl0pGO86mvP412zW2glYmb2Tn5ghIe5qNGVx5UmG2/F3ac6GtcdfxtJta2lHT3upfix6uN2j2CMabc22oeLn57FhCzBfXUj8ABIh/dHrXWb5nDOag13sfZTyZR1dlKkgmMeVYEnPW3ixeHelKJnE4Sksw6LrBn7HL5GB5ERxpcqDkO2KU/7n50+YnsR9Ppxtms2YnwTFsd4++xiK/yuwhVxEBAuwpGRfykT6zLsceccomZc6YWeKU1AYK4Eou2HICZSdzIUSL02+7y7GhlDTkvCcUZjt5+Wu90yMciOuXl06bMKHBK/CTd8ruHct3aETBkd8Nw==
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=Lr93Zn5KF5Zyo8cEcX59h630M9Cjr140u0Q2GAqX3qg=; b=SWnAQsqSrDwpEFpIA2I7IHM/6e3e9A0xO3UScpcUV5PW6QbcW656xPTwRr8unhslMGOOsdd8BFp1bSz2gOaaBGR+sdCrFnFL6IgFuJNdHUzIlNTgi+e2TWGRjHzowzPuPsEuO58T2Lq8J+eoshhicJl4qgEoZfPueqp4lzPP1rk=
Received: from AM0PR03MB3522.eurprd03.prod.outlook.com (2603:10a6:208:42::23) by AM0PR03MB5492.eurprd03.prod.outlook.com (2603:10a6:208:173::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.20; Mon, 8 Mar 2021 11:45:20 +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.3912.027; Mon, 8 Mar 2021 11:45:20 +0000
From: Yaakov Stein <yaakov_s@rad.com>
To: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= <balazs.a.varga@ericsson.com>, "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/vUDwUACYqgyAAeeRYCAAAGQfkAAGXwiQAAPETvA=
Date: Mon, 8 Mar 2021 11:45:20 +0000
Message-ID: <AM0PR03MB35224845605B31C5C53198D4E5939@AM0PR03MB3522.eurprd03.prod.outlook.com>
References: <AM0PR03MB35228092287B38B95D7056F7E5809@AM0PR03MB3522.eurprd03.prod.outlook.com> <AM0PR0702MB3603D0F358046B8F75BD6001AC9D9@AM0PR0702MB3603.eurprd07.prod.outlook.com> <AM0PR0702MB3603772CE3B68FBB0F3F5D23AC939@AM0PR0702MB3603.eurprd07.prod.outlook.com> <AM0PR03MB3522FFDD0AE3080389660D86E5939@AM0PR03MB3522.eurprd03.prod.outlook.com> <AM0PR0702MB3603D780FAD4BA967CC89D08AC939@AM0PR0702MB3603.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR0702MB3603D780FAD4BA967CC89D08AC939@AM0PR0702MB3603.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=rad.com;
x-originating-ip: [176.230.181.29]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 568fc3b9-d03e-4693-4c26-08d8e227a6f3
x-ms-traffictypediagnostic: AM0PR03MB5492:
x-microsoft-antispam-prvs: <AM0PR03MB5492934BEA37DD35D31C02B0E5939@AM0PR03MB5492.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5236;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: NhWHFh5xPhwGi5L8QI0fCCm0GpyNC/l3t+JB/xzJeVXoaoWZpcc6yej9C1i+4KjNfquaxeKXb15Qn5hQvXZfUO6Ova+hw+STGxP7EEDepccDtT1PdAhegmskotWLWkKH/+dyDqCE38e3km2aD+5IsZ8Ycim7d/075HZ9pdMUsxeS42s84fmq566o0I/eqQEGQGpFN/s6gy2oN4HjpaKH/J2Y9Te6RlVVeMZ5WCP+Xg2ioi+DzrihY2SdGkjPckgXdExIhZrAIi2CB9hyNt/xwaFuvQRW+Zu0FZCiHJ8Rc+HuDfAS/uRKtcly6qWJOyrAdNDMxter9DQbkLxAd93dhqXWUaBHLJzOtGhVQQloNu8cR6T9cAeUzKLCXIj0cCje9K1x4ImOTRd1EBrNJxFFL8fEsP8X8XZoxFub9T5F01CcrseMm2sU+a0SBbHZBWYLeG/Wwe/b83V9aaS6gTpj2mkvdfsOzvTzjDr4KYjU6Ag3wZTvS6I/QjPk9Ow9BHB/zmRea5/IaTBamSPm2wJH4obK2F1M9NZjgD82vvwmxfdHPVo7l4i9sYEtxDAvVZmp+ODpIrkxVU63/GoTusYI43Fkko2mR1qjkM3++Xqgndo=
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)(39850400004)(376002)(346002)(366004)(136003)(8936002)(52536014)(7696005)(186003)(55016002)(9686003)(966005)(26005)(66446008)(6506007)(66476007)(64756008)(53546011)(66556008)(66946007)(83380400001)(76116006)(478600001)(33656002)(86362001)(66574015)(166002)(5660300002)(110136005)(30864003)(8676002)(2906002)(71200400001)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?nAxfUe4YCz0CpEquA0jZA3cHJ+KMSaYQx7WbFR5e9US9dcF6U8d5gKk1Lh?= =?iso-8859-1?Q?KpMoIfPL4olS65UpKT+DVELiPGRGyoToFM1ZrhAr10AbTYge/qya9mIwqR?= =?iso-8859-1?Q?NJCtnFk5tC9cdka3r0vxCxt8AOZTwsFCqGcF2URw7FeXiOcYMXk8T5eI8k?= =?iso-8859-1?Q?uo7x4A9V5OsXQ0nj14xJRyrGMvZWNsslGYv/4sYHOmqu8bfO17hkZagv/K?= =?iso-8859-1?Q?T8r6QcgkOYLwoRPrgWoqctOvmRLiUqf7uB3WsaD35fVpCedFAWlzTrq3ew?= =?iso-8859-1?Q?8rqnxcOZv3mqA/bW/vFc3OW+xBm5Gtm9snSYuKsFnHuKs6Q/yvCkhtUB62?= =?iso-8859-1?Q?C6dPTwWq1sObSPJUPKs+GZeB2PMuUFrOTHEvVVogZ/CSQypoS/TY8Ykd0p?= =?iso-8859-1?Q?xtESDYq8MRk5mb9JoVCPUBq5WOUGZsxyHBjsKZ1qNv7RwftJQAPoo5egAc?= =?iso-8859-1?Q?j98igdu/lESjK1+mXvTWNN6xRR78tuAnQ0C591TujVbyDnbvWotVTjliHa?= =?iso-8859-1?Q?25mAfbvWHitk274oAs+OFI3EfXhJwmW+XTzGKg4kCdPDXNc4BDocoS73D1?= =?iso-8859-1?Q?wTQljfJ2acFfPzl3lxdoXuRy5oDdSMGfvuTnsH4Iucu959y4AuGI/h+i/l?= =?iso-8859-1?Q?4z911XhYn/3AyhH2IkDz8BRJlY1BMu6qefNhA+K5T9/nNJz1dnMtnDS3do?= =?iso-8859-1?Q?qZTfkUtee5UY+QfBARF0ZvCae+UUgKUhDBIJE+WNBWijRomn4EkYsGgoFE?= =?iso-8859-1?Q?8SQkRs6IJZ/3bPKN4YQDjrmYSfR4luws2rQL8FGKTRQJgPG/o4g/Mwsphj?= =?iso-8859-1?Q?RhOPZRplSc6E/HJ2djJpSt23vajIUUby6qIOgQa9YD2TqZkhci5IlOOG5E?= =?iso-8859-1?Q?cckrRMkmoHvYnIarfYUUVRWtkw1nNRu9I2SLiFrqyZn9fo2cW7mUO26Fhb?= =?iso-8859-1?Q?VM4iaVBOCQ4Khm1kBDbn63VkbEMFsWg4rraDKZvbeBKqaZU5VJbRcRQzlB?= =?iso-8859-1?Q?libp7uQIeQxSCrUOkRAMA3BHfjWi+GyiwKrPM+Egpg7YS7E/PqOda5eF6Q?= =?iso-8859-1?Q?bt7o/mgnntMhHl00Bfq4pY6lRzXPLoPx7ibaN/U9M71yPZ/xSNZNJwWf5X?= =?iso-8859-1?Q?QvdJPz4gh2QEH0Wn0dFT12fUMX1FJl1Ow3Ld5nLVd5PMgHhXD+8aXbUyyY?= =?iso-8859-1?Q?cn9xiCf0+0H6MmqMn37fdVehQo4kMj8Nd+isTEU809pKGpWV95WgLFMum4?= =?iso-8859-1?Q?lQJu7RZqvf0KpsPpSzotpe2bRiLl5cHO2AsSa6vlkP0BsM2DyvDlMo1w03?= =?iso-8859-1?Q?VfeAyXt2/okCBZkPxwESY/R5xPKvrp+OhTN5Ul/1LIxwiG3zyIz3U5mZn3?= =?iso-8859-1?Q?j5Hj5RDGXq?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR03MB35224845605B31C5C53198D4E5939AM0PR03MB3522eurp_"
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: 568fc3b9-d03e-4693-4c26-08d8e227a6f3
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2021 11:45:20.4890 (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: /bFk68j6d621s73AR3fSlTzjSf7RpHT7HJmUJAFfs+XkBZusS16008noRqk/YYQdA6ehrm5iXdRlZy0ic6/egg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5492
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/3ewWKO4oUoDsY1KjHxm-mPw1lcQ>
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: Mon, 08 Mar 2021 11:45:28 -0000

Bala'zs,

The IEEE definition of TSN mentions determinism, but defines it not as constant delay as in a TDM service, but rather as
to provide deterministic services through IEEE 802 networks,
i.e., guaranteed packet transport with bounded latency, low packet delay variation, and low packet loss.
So "determinism" in this context means bounded latency, low PDV and low PLR.

DetNet is aligned with this definition. From the charter:
deterministic data paths that operate over Layer 2 bridged and Layer 3 routed segments, where such paths can provide bounds on latency, loss, and packet delay variation (jitter), and high reliability.
So it is the path that is deterministic, but the packet parameters need to be bounded.

In Carrier grade Ethernet "determinism" is usually taken to mean that a flow is pinned to a path,
that is, we know precisely which network elements a packet will traverse,
although delay, PLR, etc. are parameters to be set and/or measured.

When I say that a packet or flow is "time sensitive" I merely mean that there is a time budget to be attained.

However, SRTSN by any other name smells as sweet to me.
Stack-based Time-sensitive Enhancements for Immediate-delivery Networking (STEIN) could also work :) .

Y(J)S

From: Balázs Varga A <balazs.a.varga@ericsson.com>
Sent: 08/03/2021 11:59
To: Yaakov Stein <yaakov_s@rad.com>om>; detnet@ietf.org; spring@ietf.org; pce@ietf.org
Subject: RE: new draft on segment routing approach to TSN

Hi Yaakov,

Thanks for the clarifications, that helps a lot to position correctly your draft.
As You have wrote: "Determinism is not the main goal of this draft" what
was not clear from the text.

I may be somewhat mis-leaded by the name You have used for the concept.
TSN is widely used in IEEE as "Time-Sensitive Networking" and its main target
is deterministic communication.

You may consider to use a different abbreviation to avoid that confusion. E.g.,
"srtsc" (segment routing time sensitive communication) or anything else You like.

Many thanks
Bala'zs



From: Yaakov Stein <yaakov_s@rad.com<mailto:yaakov_s@rad.com>>
Sent: Monday, March 8, 2021 8:27 AM
To: Balázs Varga A <balazs.a.varga@ericsson.com<mailto:balazs.a.varga@ericsson.com>>; 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

Bala'zs,

Sorry that I never got back to you on this.
It is much easier to shoot back replies to shorter emails :)

> 1, What is the node behavior if deadtime expires?
Nothing special is done if a local deadline is exceeded. There is still hope that the time can be made up.
If too many packets fail to conform to their overall budget,
then maybe something has changed and reoptimization (or realizing that the application budget is not feasible) is required.

> 2, Do I understand it correctly that the described solution is practically a new per-hop-behavior?
Well, new to here but hardly "new" (similar things were done in ATM...)
The new per-router behavior requires a new data structure in the router instead of a FIFO queue,
but there is no absolute requirement for other tools.
As I just hinted and have mentioned in a previous email, later on we may need some OAM to see if configuration needs to be updated.
I have already experimented with periodic RSVP-like synthetic packets that collect timestamps along the path.

> 3, Design of a guaranteed upper bound usually requires deterministic arrival at each node along the path.
Here is where we differ (or at least put different emphasis on the word "usually".

Determinism is not the main goal of this draft. Meeting challenging delay budgets is.
Sometimes absolute determinacy is required (e.g., in some forms of "teleprotection" in some electricity distribution networks)
in which case either TDM/Qbv/calendaring can be used, or this method coupled with a differential delay compensation buffer.

I agree that PDV increases from hop to hop to an extent, but when the delay budget is really challenging you simply can't allow that many hops.
In mixed 5G xHaul cases in which I have been involved there are no more than 4 hops (usually fewer).

If you wish something more deterministic then look at the Andrews-Zhang strategy.
They gate at the ingress router and EDF at all the following ones.
They show that (statistically) they ride "green waves" and thus the PDV doesn't increase significantly
(see their graphs). This comes at the expense of a long cycle time for the initial gate, which means the budget can't be too tight.

> 4, Wire-speed timestamping and calculation
I come from the PTP world where hardware timestamping with submicro resolution is common.
Since the timestamp is on the rising edge of the first bit, i.e., before the classifier,
it is carried out and placed in the packet metadata for every packet whether or not it is PTP.
I always shed tears over throwing out this information.
The RSVP-like method just mentioned simply copies it into the packet.
The SRTSN packets use this information in the scheduler.
I have consulted my ASIC people about the use of priority heaps and insert-queues
and they ensure me that they can put something like that into our 100G chip.

> 5, Time gated Queuing [802.1Qbv]
I didn't say that in principle you can't build a Qbv system that does great things.
It is flexible enough to do anything you want.
The problem is the scalability.
I have played around with optimizing it and haven't found a good "on line" algorithm,
that is, a way of adding a new flow to an existing optimized design.
And even in the "off line" case (clean slate with all flows known) slight changes and even bad clocks in the user equipment ruins things.

But the main idea of this draft is that even given a good on-line algorithm for Qbv
you would need to distribute the changes in the all the schedules to all the routers.
What happens in the meantime? What happens when one router is already updated but another isn't?
With the stack method only a single ingress router needs to be updated and consistency is ensured!

> 6, Deadtime calculation is also complex if impact of other DetNet flows must be considered.
Of course! The offset vector needs to be optimized.
I have several such methods and am running simulations of various strategies.
As stated in the ID the specific calculation was for illustration purposes -
the stack mechanism is much more generic.

> 7, Impact of some DetNet functions
I have not yet gotten to the point where I have considered this.

>  8, The ever-green topic ( and not the green-wave :--))) ): label stack size.
Yes, I didn't want to bring this up yet, but have been forced to.
I have to admit that I am not a fan of SRv6 for just this reason.
But, the SRTSN stack can be really small!
SR stack entries need only be ceil ( log2 (number of routers) ) in size (requires a little local information base in the router)
assuming once the stack is popped you use the original DA. If you are not willing to use this additional information
you still only need sufficient suffixes, which is still small.
The deadline entries can be miniscule since the wraparound constraint is derived from the maximum flight time of a packet in the network.
In my designs I have gotten away with 16-32 bits per entry, which means 4-8 hop stacks only require the room of a single IPv6 address.

Hope this answers your questions and kicks off a fruitful discussion.

Y(J)S

From: Balázs Varga A <balazs.a.varga@ericsson.com<mailto:balazs.a.varga@ericsson.com>>
Sent: 08/03/2021 08:35
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: 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,
Any view on these comments?
Thanks
Bala'zs

From: detnet <detnet-bounces@ietf.org<mailto:detnet-bounces@ietf.org>> On Behalf Of Balázs Varga A
Sent: Friday, February 26, 2021 3:03 PM
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,

many thanks for this well-written and information-rich draft.
I have enjoyed to read it (and also the discussions on the lists). :--)))


Conceptual (clarification) questions:
1, What is the node behavior if deadtime expires? Drop? That requires a quite good design/allocation of the latency budget. Otherwise it may result in unnecessary loss of a packet being relative late at a hop, however that might be compensated by the remaining hops. (E.g., see your Figure 2, getting 35 microsecond at R1 instead of the designed 25, but R2,R3,R4 adds only 10-10-10 extra microseconds). You may consider to add a "late flag" to the packet instead of a drop ...

2, Do I understand it correctly that the described solution is practically a new per-hop-behavior? Does it have no tools to "influence" the arrival time at the next hops? In end-to-end latency design the DetNet/TSN functions are often used to "adapt" the arrival of packets belonging to a DetNet flow/TSN stream at given network points. If "latency design" requires such a "time shift" then the described method has to be combined with other DetNet/TSN tools.

3, Design of a guaranteed upper bound usually requires deterministic arrival at each node along the path. In this solution the flow becomes less-an-less deterministic as it reaches the destination. I mean e.g., as per Figure 2, arrival time range at R1 is 2-2 usec, at R2 is 26-51 usec, at R3 is 70-120 usec and at R4 is 92-167 usec. So, the flow is getting less-and-less deterministic at each hop. That can make deterministic design of other flows passing R4 more difficult or even impossible in some scenarios. Have I missed something here?

4, Wire-speed timestamping and calculation: I would be interested in your view regarding how realistic are (1) the wire speed timestamping capability and (2) adding multiple calculated deadline to packets. Both are required for this solution. DetNet flows can have high bandwidth, not like 1588 packets.


Specific comments (Section 2-3):
5, Time gated Queuing [802.1Qbv] allows multiple gates to be open simultaneously. Furthermore preemption [802.1Qbu] can be combined with Qbv. So I cannot fully agree with your evaluation of time-aware scheduling. (Section 2, "However, time-aware scheduling suffers from two major disadvantages.") Of course with a bad design one may shoot in his/her own leg, but in well-designed scenarios efficiency loss can be eliminated without expensive computation.

6, Deadtime calculation is also complex if impact of other DetNet flows must be considered. The pre-calculation of individual "local" deadlines may need to be re-calculated when flows added to the network and they are using some common links. So I cannot agree with your statement. (Section 3, "... Since the ingress router inserts the deadline stack into the packet headers, no other router needs to be aware of the requirements of the time sensitive flows.  Hence admitting a new flow only requires updating the information base of the ingress router."). Adding a flow may result in updating many ingress routers' configuration.


Some topics for further discussions/considerations:
7, Impact of some DetNet functions (e.g., PREOF [RFC8655]) needs further discussions. The usage of replication/elimination impacts the deadline calculation. Disjoint paths used by member flows requires different label stack and deadlines. Furthermore, these path specific labels+deadlines must be added by the replication node (PRF). So at least, a combination of PRF with B-SID and computing/adding deadlines (ingress SRTSN function) seems to be necessary in your solution.

8, The ever-green topic ( and not the green-wave :--))) ): label stack size. You need multiple labels per hop and the label stack contains them for each hop. Could result in a quite big label stack to be pushed at the ingress (nx10s of labels).


I am happy to have further discussions on this interesting idea

Thanks & Cheers
Bala'zs

From: detnet <detnet-bounces@ietf.org<mailto:detnet-bounces@ietf.org>> On Behalf Of Yaakov Stein
Sent: Tuesday, February 23, 2021 2: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: [Detnet] 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%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dc3902149-9c0b184c-c39061d2-86d2114eab2f-ba16ddb9b86334c8%26q%3D1%26e%3D25a393fd-8aca-4a3b-914c-6ce612f6740b%26u%3Dhttps%253A%252F%252Feur01.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ietf.org%25252Farchive%25252Fid%25252Fdraft-stein-srtsn-00.txt%2526data%253D04%25257C01%25257Cyaakov_s%252540rad.com%25257C270d392bafcf4742c92d08d8e1fc5c56%25257Cf9047108cc2c4e4897a343fad1b3bf9d%25257C1%25257C0%25257C637507821310056080%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C1000%2526sdata%253Do332wbi4u5fb%25252BKtUW1CsB3jz9OEd32h%25252BazNaEDnDHJY%25253D%2526reserved%253D0&data=04%7C01%7Cyaakov_s%40rad.com%7C1b7b95bc875e48d5a3fe08d8e218cc62%7Cf9047108cc2c4e4897a343fad1b3bf9d%7C1%7C0%7C637507943449085449%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Q%2BfWafpslb%2BsCSQrmBzcA2fhopPw3GAj9me0v7xqdk0%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