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

[Jinoo Joung <[e-mail]>]

Thanks Shoafu, for the clarification that
"You are right that for TQF there is an upper bound for offset value, which
depend on the Scheduling Period, i.e., M slots."

Back to my earlier concern:
"E2E latency will be the number of hops multiplied by OPL, if these OPs are
synchronized among the nodes."

If we change the OPL (orchestration period length) to SPL (scheduling
period length), my claim was right.
That is: For TCF (Case 2), the E2E latency bound is {hop counts * SPL},
given that the nodes are synched.

Now back to my previous suggestion:
"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."

I think this suggestion is still valid, if we change OP to SP.
What do you think?

Best regards,
Jinoo



On Tue, Jan 27, 2026 at 5:10 PM <[e-mail]> wrote:

>
> Hi Jinoo,
>
>
> The E2E jitter bound of TCQF (also for TQF) are not {offset * slot
> length}, but 2 * slot length.
>
> Please see the following figure that happened on each node, where, # i is
> the incoming slot, # (i+offset) is the outgoing slot.
>
>     # i                                            # (i+offset)
>
>  |_____|     ... ... ... ... ... ... ...    |_____|
>
>  |<----------------------------------->|
>
>                  offset
>
>            |<-------------------------->|
>
>                     best latency
>
>  |<-------------------------------------------->|
>
>                     worst latency
>
>
> The jitter equals to worst latency minus the best latency, i.e., 2 slot,
> that is independent of offset, whether it is fixed or variable.
>
> The E2E jitter also equal to 2 slot, e.g., a packet get best latency at
> current node will be impossible to also get best latency at the next hop
> node. That is, jitter does not accumulate with the number of hops for TCQF
> or TQF.
>
>
> You are right that for TQF there is an upper bound for offset value, which
> depend on the Scheduling Period, i.e., M slots.
>
>
> Regards,
>
> PSF
>
>
>
> Original
> *From: *JinooJoung <[e-mail]>
> *To: *彭少富10053815;[e-mail] <[e-mail]>;
> *Date: *2026年01月27日 09:49
> *Subject: **Re: [DetNet] A concern regarding slot-based solutions*
> Thanks, Shaofu, for the quick response.
> For TCQF (Case 1), the E2E latency bound is {hop counts * offset * slot
> length}. E2E jitter bound is {offset * slot length}, if all the nodes are
> synched.
> For TQF (Case 2), there MUST be an upper bound of the offset value,
> otherwise the E2E latency bound does not exist.
>
> Can you tell me the upper bound of the offset value, or that of {offset
> value * slot length}, for TQF?
>
> Thanks in advance.
> Jinoo
>
>
> On Tue, Jan 27, 2026 at 10:12 AM <[e-mail]> wrote:
>
>>
>> Hi Jinoo,
>>
>>
>> For case 1), TCQF applies it.
>>
>> For case 2), TQF applies it.
>>
>>
>> Regards,
>>
>> PSF
>>
>>
>>
>> Original
>> *From: *JinooJoung <[e-mail]>
>> *To: *彭少富10053815;
>> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
>> [e-mail]>;
>> *Date: *2026年01月27日 05:26
>> *Subject: **Re: [DetNet] A concern regarding slot-based solutions*
>>
>> 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]
>>>>>
>>>>
>>>>
>>>
>>
>