Re: [Detnet] TSN scheduling/queuing algorithms and DetNet

[Toerless Eckert <[e-mail]>]

Florian,

As i tried to explain in draft-eckert-detnet-bounded-latency-problems, and as we now try to formalize
better in draft-ietf-detnet-scaling-requirements, there is a huge difference in problems between
what i would call the typical TSN deployment target and what we would need to allow SPs to operate
DetNet in a shared services network with e.g.: 400Gbps interfaces across e.g. a metropolitan area.

Taking CQF at high-speed for example: The cost of putting bounded latency mechanisms into high-speed ASIC/FPGA
of maybe 400 Gbps speed based queuing is not necessarily the same as in 1/10 Gbps interfaces. Relative to
individual frames/packets there is a lot more propagation variation, and the integration of clock synchronization
is equally posing different challenges. This is specifically whay we proposed to decouple the clock synchronization
from the cycle timing much better by putting the cycle-identifier into the packet. Thats the one core
simplification over th TSN approaches, but it is crucial for ease of adoption in high-speed hardware.

I have also recently come to a better understanding that the strict cycle aproach of *CQF should not only
be seen as a problem, but that instead it can serve very much as a benefit, because it does allow
to do a lot easier flow-interleaving (draft-eckert-detnet-flow-interleaving) to raise utilization of
DetNet traffic in the network while simultaneously minimizing per-hop queuing latency.

This flow-interleaving consideration is btw. not fundamentally different from the logic that made TAS
an attractive option in TSN deployments, except that in those deployment it is possible to calculate the
timing of packets such that they can be passed through multiple switches without any queue building, and
hence with pass-through-switches one can get really low end-to-end latencies. Luckily, if speed-of-light
propagation latency of a DetNet path is already in the order of 1msec, then we do have relatively
speaking some usec that we can use for queuing, so we do not need to get that fancy (and complex),
but still: there are some IMHO simple high-level criteria why i think we would want to pick some
specific DetNet queuing mechanism - such as TCQF/CSQF...

Cheers
    Toerless

On Thu, Oct 05, 2023 at 09:22:10AM +0200, Florian Kauer wrote:
> Hi David,
> thanks for bringing up this point!
> Since I was not able to attend the meeting and I can not find any minutes or recording, I would love to get more background about this question, especially why you explicitly marked **algorithms** as bold.
> 
> For the use cases I am currently considering for DetNet (industrial control/vPLC and pro audio) the scaling requirements (time asynchrony, propagation latency...) are IMHO of lower importance at the moment. And for those scenarios my current working assumption is actually that all DetNet nodes that route on L3 between L2 TSN networks would be able to directly apply all TSN techniques (like Qbv and CQF) without any special consideration for them on L3. The only exception is that the L3 processing MIGHT take more time than L2 bridging and this might have to be taken into account e.g. when calculating a Qbv schedule. Do you agree or is there something I overlook?
> 
> Thanks,
> Florian
> 
> On 04.10.23 23:30, Black, David wrote:
> > For clarity, this is posted as an individual contributor …
> > 
> >  
> > 
> > In the most recent open working meeting, Toerless and I had a discussion about whether DetNet nodes could use the TSN scheduling/queuing algorithms.
> > 
> >  
> > 
> > Checking the DetNet RFCs, what I believe I see is:
> > 
> >   * Toerless’s assertion that all DetNet RFC references to TSN refer to layer-2 TSN subnets appears to be correct.
> >   * OTOH, I did not see anything that prohibits implementation and use of the TSN scheduling/queuing **algorithms** at layer 3 in DetNet nodes.
> > 
> >  
> > 
> > I would hope that it’s not necessary to publish an RFC to bless the use of the TSN scheduling/queuing algorithms at layer 3 in DetNet Nodes …
> > 
> >  
> > 
> > Thanks, --David
> > 
> > * *
> > 
> > *David L. Black, *Sr. Distinguished Engineer, Technology & Standards
> > 
> > Infrastructure Solutions Group,*Dell Technologies*
> > 
> > mobile [phone] [e-mail] <mailto:[e-mail]>
> > 
> >  
> > 
> > 
> > _______________________________________________
> > detnet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/detnet
> 

-- 
---
[e-mail]