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

[Toerless Eckert <[e-mail]>]

On Sat, Oct 07, 2023 at 02:54:15PM +0800, [e-mail] wrote:
> Hi Toerless,
> 
> In the following forwarding example you provided, the router in the box 
> only contains two interfaces, one incoming and one outgoing, so it seems 
> that queueing work may need only be done on L2-switch in the same box.

Assumption in the pictures showing a Rtr component was always that the input and
output are on different IP subnets, so L3 forwarding is involved. But for each of the
IP subnets, there is also an (internal) L2 switch involved. Hence the option of
doing the latency/throughput guarantees at L2 and/or L3 (and you certainly would
love to avoid duplication of effort).

> However, there may be fan-in for each router, and IMO this is the main 
> reason that we need also consider L3 queueing.

yes, not shown.

> Not sure if I get your point, just a little comment.

These mixed L2/L3 devices are a mess, but as long as we stay below 100Gbps, i fear
it will be a big part of actual deployments for DetNet. So good to understand and
think what to do about them.

For about two decades i had hoped IETF would be intelligent enough to work on 
making IP work well enough so that deployments could avoid those built-in L2 switches
and their config and added complexity (think about a router whose built-in L2 switches
also need to do Spanning Tree *sigh*). 

Cheers
    Toerless

> Regards,
> PSF
> 
> 
> 
> Original
> 
> 
> From: ToerlessEckert <[e-mail]>
> To: Black, David <[e-mail]>;
> Cc: Florian Kauer <[e-mail]>;[e-mail] <[e-mail]>;
> Date: 2023年10月06日 00:40
> Subject: Re: [Detnet] TSN scheduling/queuing algorithms and DetNet
> 
> As i tried to explain in the last email reply to Florian:
> 
> I think for large-scale/high-speed detnets, that the TSN algorithms will not work well,
> but with proposal like we have on the tavble, i think we know how to adopt what we learned from TSN.
> (aka: TCQF/CSQF vs. CQF/ECQF).
> 
> Even if something like timed gates on ingres is something we could reuse directly from TSN, i still
> prefer we have IETF docs explaining how to adopt to IETF networks.
> 
> For low-speed/limited-bandwdith DetNet, such as in manufacturing floors, i wonder if we are going to see
> any insance where we need to adopt TSN mechanisms directly to L3:
> 
> I do not think we are going to see any such limited-scale networks without L2 switches involved. I for
> once am not aware of any campus/industrial environments where sender/receivers directly attach to
> a router. IETF has just done a (sh#$y - censored) job to make deployment of L3 easy. You immediately
> need an IP/IPv6 addrssing expert, manage addressing space, and if you want to have device mobility you
> need complex solutions that most likely will break any services guarantees (like TSN or DetNet).
> 
> Aka: between any sender/receiver and any router will be L2 switches whcih would then have to be TSN
> anyhow. And we have the RFCs explaining how to run DetNet "over" such L2 TSN subnets.
> 
> How about a larger industrial network/campus: 
> 
>     Src --- L2sw --- Rtr1 ---- backbone --- Rtr2 --- L2sw -- Rcvr
> 
> Would we not we need "DetNet only" between Rtr1 and Rtr2  - no TSN involved ?
> 
> No. Because any Rtr equipment that vendors would sell into such environment will already have an
> L2 switch integrated inyo any of these routers. So in reality the actual forwarding would be:
> 
>     Src --- L2sw --- [L2sw-Rtr1-L2sw] ---- backbone --- [L2sw-Rtr2-L2sw] --- L2sw -- Rcvr
> 
> In effect we do have 3 TSN domains where Rtr1 / Rtr2 really just need to do non-queuing
> forwarding, make sure that queuing happens on the outgoing TSN L2sw side on the same box,
> and the only DetNet job on the sending side is to aply the right L2 tagging to ensure the
> packet is put into th right TSN service instance.
> 
> Only when the "backbone" links become fast / lage enough that the L2sw approach on the box
> won't work would we need "direct L3" interface queuing. 
> 
> Cheers
>     toerless
> 
> 
> On Thu, Oct 05, 2023 at 01:46:44PM +0000, Black, David wrote:
> > Hi Florian,
> > 
> > Still posting as an individual - the two of us are on the same page ...
> > 
> > > 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.
> > 
> > I was drawing a distinction between the entire scope of TSN technology, which is a layer-2 subnet when fully deployed, versus just the TSN scheduling/queuing algorithms (e.g., Qbv) which are readily deployable at layer 3.
> > 
> > > 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.
> > 
> > +1 on "directly apply all TSN techniques (like Qbv and CQF) without any special consideration for them on L3" - and in particular, I believe that this direct application is possible now (i.e., no need to wait for IETF to publish a detnet RFC that says it's ok to do this obvious thing ...).
> > 
> > > 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?
> > 
> > I don't think you've missed anything major ...
> > 
> > Thanks, --David
> > 
> > -----Original Message-----
> > From: Florian Kauer <[e-mail]> 
> > Sent: Thursday, October 5, 2023 3:22 AM
> > To: Black, David; [e-mail]
> > Cc: Black, David
> > Subject: Re: [Detnet] TSN scheduling/queuing algorithms and DetNet
> > 
> > 
> > [EXTERNAL EMAIL] 
> > 
> > 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/detnet__;!!LpKI!nabqKqkaJqASqxUmFFXsdWshrCNzaQHg7m-v-hGX_vjxDkaPwEjaN_7LLu4bVsAoreoYzg2j8oO_zNFgpKpK_IqND_rO3Q$ [ietf[.]org]
> 
> -- 
> ---
> [e-mail]
> 
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet



-- 
---
[e-mail]