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

[Jinoo Joung <[e-mail]>]

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]
>