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

[[e-mail]]

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]