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

[Jinoo Joung <[e-mail]>]

Hello Shaofu,

It is frustrating that your argument changes over time.
Please note the following excerpts from your previous email:
"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.."

and the one you just wrote:
"(o1 + o2 + o3 + ... o_n) * slot length, if each o_i is specified for a
flow, then the latency bound for that flow is predictable"

Then, do you argue that the offsets, o1=1, o2=4, o3=3.., are specified
before the flow requests the admission?
If so, then the bound is predictable. But it is not.. in the unfortunate
case a flow is assigned a longer offset.
So the offset is random and not predictable. I think that this is what we
have already agreed.

Jinoo

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

>
> Hi Jinoo,
>
>
> For expression: (o1 + o2 + o3 + ... o_n) * slot length, if each o_i is
> specified for a flow, then the latency bound for that flow is predictable,
> i.e.,* the best latency is (o1 + o2 + o3 + ... o_n) * slot length - slot
> length, and the worst latency is (o1 + o2 + o3 + ... o_n) * slot length +
> slog length*.
>
> Different flow may specify different o_i, so obtain different latency
> bound, even these flows have the same TSpec.
>
> Please note flows with the same TSpec may in general have different RSpec,
> e.g, one require E2E latency 10 ms, the other require E2E latency 20 ms.  Your
> expression does not meet this diff-serv requirements.
>
>
> How to specify o_i for a flow, is based on RSpec of that flow. The RSpec
> is predictable.
>
> For example, flow i require E2E latency 1 ms, the calculated path contains
> 10 hops, and slot length is 100us, then PCE has to assign each o_i = 1 for
> flow i.
>
> For example, flow j require E2E latency 2 ms, the calculated path
> contains 10 hops, and slot length is 100us, then PCE may assign each o_i =
> 2 for flow j.
>
> ... ...
>
>
> In brief, once the slot resource is reserved for the flow, the latency
> bound is determined (Please refer to the above bold font).
>
>
> Regards,
>
> PSF
>
>
>
> Original
> *From: *JinooJoung <[e-mail]>
> *To: *彭少富10053815;
> *Cc: *[e-mail] <[e-mail]>;
> *Date: *2026年01月28日 16:23
> *Subject: **Re: [DetNet] A concern regarding slot-based solutions*
>
> 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]
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>