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

[Jinoo Joung <[e-mail]>]

Shaofu, please be aware that the worst case gives the E2E bound.
In this unfortunate case, the offset can be their maximum values, and this
gives the E2E latency bound of n * SPL * slot length.

That is, E2E latency bound = max [ (o1 + o2 + o3 + ... o_n) * slot length ]
= n * SPL * slot length.

Best,
Jinoo

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

>
> Hi Jinoo,
>
>
> I am fraid that your claim was not right.
>
> For a path contains n hops, a flow i sening along this path may allocate
> offset o1 on hop-1, o2 on hop-2, o3 on hop-3, and so on, as long as *each
> offset per hop is smaller than SPL*
>
> So the E2E latency bound for flow i equals to (o1 + o2 + o3 + ... o_n) *
> slot length, but not n * SPL * slot length.
>
>
> I guess you may consider a case that there is a flow j try to allocate the
> maximum offset on each hop, in this case, the E2E latency bound for flow j
> equals to n * SPL * slot length. But this is only for flow j, not for flow
> i.
>
>
> Regards,
>
> PSF
>
>
>
> Original
> *From: *JinooJoung <[e-mail]>
> *To: *彭少富10053815;
> *Cc: *[e-mail] <[e-mail]>;
> *Date: *2026年01月27日 16:43
> *Subject: **Re: [DetNet] A concern regarding slot-based solutions*
>
> 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]
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>