Many thanks Toerless! Pascal
> Le 27 févr. 2021 à 22:12, Toerless Eckert <[email protected]> a écrit : > > 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] > > _______________________________________________ > detnet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/detnet _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
