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 <[email protected]<mailto:[email protected]>> On Behalf Of Tianran Zhou Sent: jeudi 25 février 2021 9:14 To: Yaakov Stein <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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:[email protected]] On Behalf Of Yaakov Stein Sent: Tuesday, February 23, 2021 9:14 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/pce
