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

[Jinoo Joung <[e-mail]>]

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]
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>