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-boun...@ietf.org> On Behalf Of Yaakov Stein Sent: Tuesday, February 23, 2021 2:14 PM To: det...@ietf.org; spr...@ietf.org; 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 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
