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

[Jinoo Joung <[e-mail]>]

Shaofu,
if there is a concept of 'Level" in your draft,
and the flows with the same level have the same E2E latency bound,
I would like to point out that this concept of priority level is already
defined, e.g, in P802.1Qdv ECQF.
ECQF is a class-based solution, not flow-based.
It allocates multiple flows with the same priority into a timeslot, not a
flow.

My point is: Your TQF can be much more simplified. And it is class-based in
essence.

Best regards,
Jinoo

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

>
> Hi Jinoo,
>
>
> The worst case in the context is related with the particual level of the
> provided resources (e.g,, priority, traffic class, time slot, delay level,
> FT or service rate, etc).
>
> That is, for a particual level, what is the best case of the E2E latency,
> and what is the worst case of the E2E latency.
>
> For example, for level-1, the best latency is 1 ms, the worst latency is 2
> ms, so for any flows (such as *flow i*) mapped to level-1, it can be
> guaranteed with latency bound 2 ms.
>
> Wihle for level-2, the best latency is 10 ms, the worst latency is 20 ms, so
> for any flows (such as *flow j*) mapped to level-2, it can be guaranteed
> with latency bound 20 ms.
>
>
> Yes, level-2 is worst than level-1, and perhaps  level-n is more worst
> than level-1, but for flow i, the E2E latency bound is not determined by
> the worst level-n but by the mapped level-1.
>
>
> Regards,
>
> PSF
>
>
>
> Original
> *From: *JinooJoung <[e-mail]>
> *To: *彭少富10053815;
> *Cc: *[e-mail] <[e-mail]>;
> *Date: *2026年01月27日 17:16
> *Subject: **Re: [DetNet] A concern regarding slot-based solutions*
> 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]
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>