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

[Jinoo Joung <[e-mail]>]

Hi Shaofu, thanks for the reply.
I am glad to know the controller plane is now under consideration.

However, I am still concerned about the effectiveness of the time slot.
According to your controller plane document, an orchestration period is
composed of multiple time-slots.
If a flow can be assigned in any slot in an orchestration period, then
eventually, the per-hop latency bound is the orchestration period length
(OPL).
E2E latency will be the number of hops multiplied by OPL, if these OPs are
synchronized among the nodes.

Then I wonder what the role of time-slot is here.
Why don't you schedule flows into an orchestration period, rather than
schedule a flow into a slot?
This would make the network scheduling much easier, and would make TQF
similar to TCQF.

Best,
Jinoo


On Mon, Jan 19, 2026 at 6:10 PM <[e-mail]> wrote:

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