To add to Pascals reading list, check out: https://www.ietf.org/archive/id/draft-stein-srtsn-00.txt
This isn't meaning to endorse all the opinions and conclusions offered, but while probably not being complete, i found it to be is AFAIK the most comprehensive survey for large scale network bounded latency. On Thu, Feb 25, 2021 at 05:40:29PM +0000, Pascal Thubert (pthubert) wrote: > Hi Yaakov and all: > > Whereever Yaakov decides to place it I'll be there supporting the work. The > draft itself is incredibly well-written and information-rich. > Note that there's also work in RAW that mentions SR operation DetNet related > operations > (draft-pthubert-raw-architecture<https://tools.ietf.org/html/draft-pthubert-raw-architecture-05>). > RAW has vested interest in intelligent forwarding decision, that would be > the trademark vs. DetNet. With this draft, the forwarding is not based on Qbv > schedule but the forwarder has some latitude as long as it matches the hop > deadline. So RAW may be a good place. > And then there's > draft-chen-detnet-sr-based-bounded-latency<https://tools.ietf.org/html/draft-chen-detnet-sr-based-bounded-latency-01>. > Ideally all these related items would progress in the same room. > > Also a few notes on the draft itself: > - maybe use latency instead of delay; it would be nice to maybe define delay > as something else, e.g., the delay representing the time the packet spends > queued in one hop vs. the latency that is end to end? > - not sure the term green wave is well understood by the public here; the > draft gives the impression that the TSN path is faster than the best effort > and involves no queueing. For the most part that is untrue; the latency is > bounded but for most flows it is longer than best effort. Best effort can be > really fast with passthrough in an empty network. The problem is the long > tail and possibly congestion loss. For TSN, there can be very special flows > that will traverse the city with all the lights green, but usually there'll > be queuing. The difference is that the queueing latency is constant and the > overall latency is withing bounds. > - Time triggered is not the only TSN operation. I wonder what the draft would > become with asynchronous shaper in mind. We designed (and as I must announce, > patented as US9602420<https://patents.google.com/patent/US9602420>) a system > very similar to the one proposed in the draft, but that is designed to adapt > QoS depending on whether the packet is early or late vs. its schedule, and > not tagging the schedule in the since the latency is considered end to end > not hop by hop. The use case is slightly different since we apply this > without a global controller and a provable guarantees all flows will meet the > deadline - so not really detnet-, but more like a best effort that all flows > meet their deadline in a stochastic environment. If Yaakov is interested, we > can contribute on that aspect. > > Good luck with the draft, > > Pascal > > > From: detnet <[email protected]> On Behalf Of Tianran Zhou > Sent: jeudi 25 février 2021 9:14 > To: Yaakov Stein <[email protected]>; [email protected]; [email protected]; > [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 > 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 > > _______________________________________________ > detnet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/detnet _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
