whow... that was a mayor coyp&paste blunder... No idea how that went through... apologies! Correct URL:
https://arxiv.org/pdf/1905.08478.pdf On Sat, Feb 27, 2021 at 07:19:08PM +0100, Toerless Eckert wrote: > 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 > > _______________________________________________ > detnet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/detnet -- --- [email protected] _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
