[Detnet] Re: [DetNet] A concern regarding slot-based solutions

[[e-mail]]

Hi Jinoo,

Thanks for your questions.
The "unfortunate" case in my previous reply is about admission check procedure, i.e., trying to assign a slot for the flow, instead of packet forwarding.
So, if a packet is assigned a slot successfully, it will not miss that slot during forwarding by slot-based solution.

As you know, we accept comments from Toerless and remove the controller plane content from this document and discuss it in a separate document (https://www.ietf.org/archive/id/draft-peng-detnet-tqf-controller-plane-00.txt)

Regards,
PSF



Original


From: JinooJoung <[e-mail]>
To: 彭少富10053815;
Cc: Janos Farkas <Janos.Farkas=[e-mail]>;DetNet WG <[e-mail]>;DetNet Chairs <[e-mail]>;
Date: 2026年01月17日 22:39
Subject: [DetNet] A concern regarding slot-based solutions








Hello Shaofu, 
I have a concern regarding your reply below.
In the slot-based solutions, there should be no "unfortunate" case that a packet misses its assigned slot, especially for deterministic networks.
A network configuration entity shall be able to guarantee such a scheduling, in large-scale, highly-utilized, arbitrary-topology, dynamic networks where numerous flows join and leave.

I suggest that the slot based solutions clearly specify their slot scheduling methodologies in the drafts.
Otherwise, it is like putting off a difficult task to someone else.

Best regards,
Jinoo




On Fri, Jan 9, 2026 at 11:28 AM <[e-mail]> wrote:



Hi Janos,

Thanks for your concerns about these two drafts and initiating the discussion.

Yes, you are absolutely right that these two mechanisms have a certain degree of commonality,  as  they both originated from TAS.
Actually, timeslot and cycle means the same thing, especially when TQF use Round Robin queues as that TCQF used, although TQF doesn't constraint it and may also use PIFO queues.

The purpose of developing TQF is to enhance the flow interleaving capability of slot-based mechanism.
Intuitively, TCQF that relies on ingress flow interleaving is like a string of beads welded with steel bars, where the meaning of steel bars is a FIXED cycle mapping, as below:
 O--------O--------O--------O--------O--------O--------O
hop-0   hop-1  hop-2   hop-3    hop-4   hop-4    hop-5
That is, for a flow i, if the out cycle-id at hop-0 is determined, then the cycles of all downstream hops will be forcibly determined based on the fixed mapping.
So, if flow i finds that it unfortunately conflicts with flow j on hop-3 (flow j arrives from another input interface of hop-3), TCQF can attempt to delay flow i to a later cycle on hop-0 for sending. But, if doing so, flow i may conflict with other flows on other hops (e.g, conflict with flow k at hop-2, although before doing so they don't conflct).

While TQF is like a string of beads connected by rubber bands, where the meaning of rubber band is a non fixed timeslot mapping, as below:

O~~~~~O~~~~~O~~~~~O~~~~~O~~~~~O~~~~~O
hop-0   hop-1  hop-2    hop-3     hop-4    hop-4     hop-5
That is, for a flow i, the out slot-id is determined independently on each hop.
So, if flow i finds that it unfortunately conflicts with flow j on hop-3 (flow j arrives from another input interface of hop-3), TQF just adjust to use another slot-id on hop-3 for flow i and not affect the slot allocation result of other hops.
However, the slot allocation rule of TQF can force outgoing timeslot to be offset by a fixed number of slots (e.g., 1) on the basis of the incoming timeslot, that is, TCQF may be seen as a special case of TQF.


From the above example, it can also be seen why there is a difference between the number of cycles designed by TCQF (e.g., 3 buffers to absorb the forwarding delay jitter within the node) and the number of slots designed by TQF (e.g., 10 buffers to  provide multiple timeslot offsets). 


In draft-ietf-detnet-dataplane-taxonomy we have defined Flow level, Flow aggregation level and Class level for traffic granularity. 
In that context, a Flow level based mechanism never means it need per flow states maintained in the core as ATS does, but  rather highlights the flow isolation and protection features during packet scheduling. So, there is no scalability issues. 
For example, a set of flows (such as i, j, k) may share the same slot #10 on a hop and been protected and isolated from other flows during scheduling. 
Each new flow can choose the corresponding timeslot, but it will not have any impact on the slot rotation process of the underlying operation.


Hope the above is helpful. Please let me know if there are any questions.


Regards,
PSF



Original

From: JanosFarkas <Janos.Farkas=[e-mail]>
To: DetNet WG <[e-mail]>;
Cc: DetNet Chairs <[e-mail]>;
Date: 2026年01月08日 20:07
Subject: [Detnet] Re: WG adoption poll: draft-peng-detnet-packet-timeslot-mechanism-13

_______________________________________________
detnet mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
 
Hi,
 
I've been wondering whether there are more commonalities between draft-peng-detnet-packet-timeslot-mechanism and draft-eckert-detnet-tcqf? 
 
(For instance, time slot vs cycle could be considered different terms for the same thing.)
 
Perhaps the main difference, if I get it right, is that draft-eckert-detnet-tcqf is class-based whereas draft-peng-detnet-packet-timeslot-mechanism is flow-based.
 
However, it has been claimed that flow-based mechanisms, like ATS, are not good enough to meet the scalability requirements.
 
What do you think?
 
Thanks and regards,
János
 
 


From: Janos Farkas 
 Sent: Friday, December 5, 2025 4:50 PM
 To: DetNet WG <[e-mail]>
 Cc: DetNet Chairs <[e-mail]>
 Subject: WG adoption poll: draft-peng-detnet-packet-timeslot-mechanism-13



 
Hi,
 
This email begins a 4-week adoption poll for:
https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechanism/13/
 
No IPR has been disclosed for this document.
 
Please voice your support or technical objections to adoption on the 
list by the end of the day (any time zone) January 2nd.
 
As a reminder this document is part of the larger set of adoption calls 
of the documents discussed at IETF 124:
 
https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/05
https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding/18
https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechanism/13
https://datatracker.ietf.org/doc/draft-eckert-detnet-tcqf/09
https://datatracker.ietf.org/doc/draft-eckert-detnet-glbf/06
https://datatracker.ietf.org/doc/draft-ryoo-detnet-ontime-forwarding/04
https://datatracker.ietf.org/doc/draft-ryoo-detnet-nscore/02
 
Thank you,
János (as Co-chair)
 
 









_______________________________________________
 detnet mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]