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

[Jinoo Joung <[e-mail]>]

Hello Shaofu, thanks for your explanation and sorry for this late reply.
I am still struggling to understand what you mean by the "unfortunate case"
in the original email.

Let's define "offset" to be the difference between the slot numbers in
adjacent nodes.
There can be only three cases:
Case 1) A flow is assigned with a fixed constant offset (e.g. 2 for every
link) during admission control.
Case 2) A flow is assigned with a variable offset during admission control
(e.g. 2 in link A but unfortunately 4 in link B) but keeps that offsets
after the admission.
Case 3) A flow is assigned to a variable offset even after admission.

Which one is it?
I think 3) is not the actual case, but I just list it for completeness.

Thanks again,
Jinoo

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

>
> Hi Jinoo,
>
>
> There are two periods, Orchestration Period (OP) and Scheduling Period
> (SP).
>
> OP is a logic period that facilitates: 1) communication among all nodes in
> a network, regardless of whether their SP are the same or not; 2) constant
> slot mapping between adjacent nodes.
>
> SP is a physical period that depends on hardware capabilities. Different
> links may enable SP with different lengths, and even with different slot
> length.
>
> For example, link-A instantiate SP including 8 slots (with slot length 100
> us), link-B instantiate SP including 16 slots  (also with slot length 100
> us), it is impossible to establish a constant slot mapping between link-A
> and link-B if without OP and only based on slot id within SP, e.g, slot 0
> of link-A may map to two slots of link-B.
>
>
> In fact, a flow can not be assigned in any slot in OP, but with the
> constraint of slot number of SP. Considering if an arrived packet is
> assigned a far away slot in OP, there is no place to store this packet.
>
> Even with the above constraint, the per-hop latency bound is not SPL, but
> the offset between the incoming slot and reserved outgoing slot, e.g, a
> flow may ask offset 1 slot on each node, that is a key difference from rate
> based solution.
>
>
> So the answer to your question "Why don't you schedule flows into an
> orchestration period, rather than schedule a flow into a slot?" is obvious,
> a flow want to obtain expected slot offset, instead of OPL per-hop latency.
>
>
> Regards,
>
> PSF
>
>
> Original
> *From: *JinooJoung <[e-mail]>
> *To: *彭少富10053815;
> *Cc: *Janos.Farkas=[e-mail] <Janos.Farkas=
> [e-mail]>;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> *Date: *2026年01月19日 19:30
> *Subject: **Re: [DetNet] A concern regarding slot-based solutions*
> 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]
>>>
>>
>>
>