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

Tianran Zhou <> Fri, 26 February 2021 11:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 620A53A13F4; Fri, 26 Feb 2021 03:55:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.799
X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fAr5WEBKWk54; Fri, 26 Feb 2021 03:55:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17D7A3A13F1; Fri, 26 Feb 2021 03:55:31 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4Dn7FY5zSwz67rjq; Fri, 26 Feb 2021 19:48:01 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 26 Feb 2021 12:55:27 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 26 Feb 2021 19:55:25 +0800
Received: from ([]) by ([]) with mapi id 15.01.2106.006; Fri, 26 Feb 2021 19:55:25 +0800
From: Tianran Zhou <>
To: "Pascal Thubert (pthubert)" <>, Yaakov Stein <>
CC: spring <>, detnet <>, pce <>
Thread-Topic: [Detnet] new draft on segment routing approach to TSN
Thread-Index: AdcJ5AjgmuXpLt94R1Stsoh/vUDwUABaAaLAAAtVwoAADcpzUAADGHv+AA+9AOAAA02UYAAHar3AAAHfxMoAAf+ENw==
Date: Fri, 26 Feb 2021 11:55:24 +0000
Message-ID: <>
References: <> <> <>, <> <> <> <>, <>, <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_5eaec6aa07bb4a65aed63036699c1244huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Detnet] new draft on segment routing approach to TSN
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Feb 2021 11:55:36 -0000

Yes, Pascal, that is exactly the case I mentioned.



Sent from WeLink
发件人: Pascal Thubert (pthubert)<<>>
收件人: Yaakov Stein<<>>
抄送: Tianran Zhou<<>>;spring<<>>;detnet<<>>;pce<<>>
主题: Re: [Detnet] new draft on segment routing approach to TSN
时间: 2021-02-26 18:58:40

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



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


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.


From: Tianran Zhou <>
Sent: 26/02/2021 10:20
To: Yaakov Stein <>
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.


From: Yaakov Stein []
Sent: Friday, February 26, 2021 1:09 PM
To: Tianran Zhou <<>>
Subject: RE: new draft on segment routing approach to TSN


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.


From: detnet <<>> On Behalf Of Tianran Zhou
Sent: jeudi 25 février 2021 9:14
To: Yaakov Stein <<>>;<>;<>;<>
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.


From: Pce [] On Behalf Of Yaakov Stein
Sent: Tuesday, February 23, 2021 9:14 PM
Subject: [Pce] new draft on segment routing approach to TSN


I would like to call your attention to a new ID<>
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.


detnet mailing list