Hi Yaakov, Thanks for your clarification. Again I think this is an interesting work. Please see inline.
Cheers, Tianran From: Yaakov Stein [mailto:yaako...@rad.com] Sent: Friday, February 26, 2021 1:09 PM To: Tianran Zhou <zhoutian...@huawei.com> Cc: det...@ietf.org; spr...@ietf.org; 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. 2. 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. 3. 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-boun...@ietf.org<mailto:detnet-boun...@ietf.org>> On Behalf Of Tianran Zhou Sent: jeudi 25 février 2021 9:14 To: Yaakov Stein <yaako...@rad.com<mailto:yaako...@rad.com>>; det...@ietf.org<mailto:det...@ietf.org>; spr...@ietf.org<mailto:spr...@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-boun...@ietf.org] On Behalf Of Yaakov Stein Sent: Tuesday, February 23, 2021 9:14 PM To: det...@ietf.org<mailto:det...@ietf.org>; spr...@ietf.org<mailto:spr...@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
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
