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

[Jinoo Joung <[e-mail]>]

Hello Shaofu,
I think our opinions are getting closer. Thanks again.

No, it is not about after or before reservation.
It is about the predictability of the bound.
We agreed that the E2E bound can be expressed by a math expression.

Your expression: (o1 + o2 + o3 + ... o_n) * slot length
My expression: n * max_o * slot length

If my expression is used, then the bound is identical for flows with the
same TSpec, if accepted.
If your expression is used, then the bound is variable for flows with the
same TSpec.
It is also a variable even if the same source generates the same kind of
flow, at a different time.
Then can we say it is a bound? I doubt if any customer would accept that as
a bound.
How predictable it is based on the TSpec and network status, that is the
question.

Best regards,
Jinoo

On Wed, Jan 28, 2026 at 3:26 PM <[e-mail]> wrote:

>
> Hi Jinoo,
>
>
> In the following level-3 example, each link has allocated SPECIFIC slot
> for the given flow independently during admission control process.
>
> To select offset 4 slots on hop-2 just mean the selected slot is free and
> appropriate, as long as 4 is smaller than SPL.
>
> The number 4 is not the maximum allowed offset for hop-2, nor other hops.
>
>
> Seems that we have different understanding about BOUND.
>
> IMO, the E2E latency BOUND for a flow is determined after the DetNet path
> is set up and related resource is reserved, i.e., AFTER RESERVATIION.
>
>    -
>
>    for example, if SPECIFIC traffic class is selected, an ATS flow may
>    have a latency BOUND.
>
> Your opinion seems that the E2E latency BOUND for a flow is determined by
> the worst case of resource reservation, i.e., BEFORE RESERVATION.
>
>    -
>
>    for example, since there are serveral traffic class can be choosed for
>    an ATS flow, so the latency BOUND for the flow is determined by the worst
>    traffic class that has the lowest priority.
>
>
>
> Regards,
>
> PSF
>
>
>
> Original
> *From: *JinooJoung <[e-mail]>
> *To: *彭少富10053815;
> *Cc: *[e-mail] <[e-mail]>;
> *Date: *2026年01月28日 11:37
> *Subject: **Re: [DetNet] A concern regarding slot-based solutions*
>
> Hello Shaofu, thank you very much for the detailed response.
>
> Let's focus on your statement: "another level-3 may be to allocate mixed
> offset on each hop, such as 1 slot on hop-1, 4 sot on hop-2, 2 slot on
> hop-3"
>
> What is the maximum allowed offset for level-3 flows? If it is 4, then the
> E2E latency bound for this level is 4*slot length*number of hops.
> It is because you do not pre-determine the offsets of 1, 4, 2, for each
> link, before admission.
> Rather you just pick a random number between 1~4 at each link during the
> admission control process.
> That's why the BOUND is 4*slot length*number of hops, while the ACTUAL
> latency is what you described.
>
> Best regards,
> Jinoo
>
>
> On Wed, Jan 28, 2026 at 11:22 AM <[e-mail]> wrote:
>
>>
>> Hi Jinoo,
>>
>>
>> Maybe the word "level" is not a good term, but I think *multi-level *is
>> the basic capability for each EDP solution, because there are so many
>> service requirements with different RSpec.
>>
>> However, an EDP solution that provides multi-level service does not mean
>> it is class-based solution.
>>
>>
>> Take TQF as an example again:
>>
>>    -
>>
>>    one level-1 may be to allocate offset with 1 slot on each hop, the
>>    best E2E latency is hops * slot length - slot length, and the worst E2E
>>    latency is hops* slot length + slot length.
>>    -
>>
>>    another level-2 may be to allocate offset with 2 slot on each hop,
>>    the best E2E latency is hops * 2 slot length - slot length, andfo the
>>    worst E2E latency is hops* 2 slot length + slot length.
>>    -
>>
>>    another level-3 may be to allocate mixed offset on each hop, such as
>>    1 slot on hop-1, 4 sot on hop-2, 2 slot on hop-3, ..., the best E2E latency
>>    is sum(offsets) * slot length - slot length, and the worst E2E
>>    latency is sum(offsets) * slot length + slot length.
>>    -
>>
>>    ... ...
>>    -
>>
>>    So, flow i that applies slot allocation as level-1 will get latency
>>    bound by level-1, flow j that applies slot allocation as level-2 will get
>>    latency bound by level-2, and so on.
>>
>>
>>
>> Take C-SCORE as an example (please correct me if I misunderstand):
>>
>>    -
>>
>>    one level-1 may be to allocate service rate r1 on each hop, the best
>>    E2E latency is 0, and the worst E2E latency is hops * L/r1. (for
>>    simplicity, no link delay, no burst, i.e., B = L, and all flow with the
>>    same packet size L)
>>    -
>>
>>    another level-2 may be  allocate service rate r2 on each hop, the
>>    best E2E latency is 0, and the worst E2E latency is hops * L/r2.
>>    -
>>
>>    ... ...
>>    -
>>
>>    So, flow i that allocates r1 will get latency bound by level-1, flow
>>    j that allocates r2 will get latency bound by level-2.
>>
>>
>> However, TQF is flow-based, since the flows are protected in the
>> dedicated slot, and C-SCORE is also flow-based, since the the flows can be
>> guarenteed with the allocated service rate.
>>
>>
>> For comparison, the allocation granularity of ECQF (and also TCQF) is not
>> per slot, but per CQF instance.
>>
>> That is, for CQF instance with 3-bin (cycle a, b, c), it does not assign
>> cycle a to flow i, cycle b to flow j, cyle c to flow k as TQF does, but
>> assign flow i, j, k to the whole CQF instance and any cycle may be accessed
>> by all shared flows during runtime.
>>
>> So, the maximum allocation resource of that CQF instance is only one
>> cycle * C, where C is the service rate of the CQF instance (e.g, it may be
>> link speed).
>>
>> Wihle the maximum allocation resource of TQF is N slots * C.
>>
>> The intuitive reason for this difference is that TCQF adopts a fixed
>> offset, such as 1 slot (i.e., all flows expect to be transmitted within 1
>> slot), but the transmission capacity of the link within 1 slot is limited,
>> so only a limited number of flows can be admitted; While TQF adopts a non
>> fixed offset, allowing some flows to be sent within 1 slot, some flows to
>> be sent within 2 slots, and so on, so a larger number of flows can be
>> addmitted.
>>
>>
>> Hope the above can clarify your question.
>>
>>
>> Regards,
>>
>> PSF
>>
>>
>> Original
>> *From: *JinooJoung <[e-mail]>
>> *To: *彭少富10053815;
>> *Cc: *[e-mail] <[e-mail]>;
>> *Date: *2026年01月27日 18:51
>> *Subject: **Re: [DetNet] A concern regarding slot-based solutions*
>>
>> 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]
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>