Return-Path: X-Original-To: detnet@mail2.ietf.org Delivered-To: detnet@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6567CA9D0D95 for ; Mon, 19 Jan 2026 03:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=smu-ac-kr.20230601.gappssmtp.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d61lMyOdnJ41 for ; Mon, 19 Jan 2026 03:30:08 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 7B41AA9D0D8E for ; Mon, 19 Jan 2026 03:30:08 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-59b6d5bd575so4157599e87.1 for ; Mon, 19 Jan 2026 03:30:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768822201; cv=none; d=google.com; s=arc-20240605; b=iWXiIu2ksCIkWhpwUxFONgqtIZv4KBJ8fA1emkiKGVgCiClAUdB7zCVRlb4EQr9XuH Mft8ZfOnGlMU+DiACBYvAbjrz2cqY3pZCHuS2I4px+3t/v094TJosblBdCxrfprqFf+u K4L3HwONEb7PPsxPMuK+7wFbNMA6t84CU1FRKn9KEb9t/pM6DJKKFNEoLAjTjG3Krxx+ mDNm3uNO7kalV64QaRhF7t7K9QYrP3TZr9EEASXiftXW8v5qrlbO1/xxIwLEkphUUgtF pQqRUo/JZ+FyJXHPRQrshHfXMopibfU7+T2mU7cT8YfkstB7kC8ebGylkgKh9C1+0Sfe +uZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Y8cuJ06vTafUTl/symIXGdB81JpcrixnRprUvdd8JT0=; fh=JuT5BXqrP76LSuhalozZ7gFCA95/ZCJMQ43ZDeI+l8U=; b=UryMUPSfq0Q/cvWt6wXUypyt395ZnasDqb7dVo/E08nefQn5OnOAN5buNoSbMmuhdr hRCTZVcjBCtMZvPnjDDcm25WtT0nOVAAtpF5BkF1BFMBEIrn6TH4vh54DTomiPlBTCiO I2Qw9A8AYJegtW72APwDdOs2eRraqXnccXT2ELV4FCC1nqnMZveV62kti6ORXP448R7r 5FbPgh8qGXxh8xkBl2s4SkR7JkRKEdhUGXET/ASs49euZgVYvQnNudu7h4Jqogp+5RfO 4/j/J1UX1f6eiZxa+EwsLePprduOILNUlaDx2yhGXNEfFCZKu/A5X71uwXuldC84mqMz w6Qw==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smu-ac-kr.20230601.gappssmtp.com; s=20230601; t=1768822201; x=1769427001; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Y8cuJ06vTafUTl/symIXGdB81JpcrixnRprUvdd8JT0=; b=C2N92PLrg8jNjiqxZQPEcew/UpZOlCPUFvsrueV1bJYCtO4o1MWFj2a09iN4IazZdw 3o/EV6DASq24SeHw+w1UjoW7hGcPsNYaNKSgXvH4DtVkyKUPB0KR47DrsYZWV71X/Jw9 cc8lZgOr6HlAI59dZ9eeBOB8rP82vUHUmOGPOLtw6mkgynZIclTpS5qXSmqvRKRNVTR8 imcHLLGt1S2g+OK3uaq0gKZoaxL30+AM6hr1OMkAxbBg0X6xT3Oz1M5ipmrj6rZeYMhR XjqakToV3TNL1AcB5U69YDrAVLusxGbjrGDWbmaOpWujYPvi2uF2Rkr5A2DVNJ8OdUvj WK7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768822201; x=1769427001; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Y8cuJ06vTafUTl/symIXGdB81JpcrixnRprUvdd8JT0=; b=UzmjsxYSXt4/2Vc/GXI7OU4iZl49rBO5q4DMOQz8ogzOG0Z66Cy0F8F9uShMHjOX2t tI7re+qxjsVjH1uYfWzRhc+W916k3yUZeSXRw1VzCRGHQLmicyoXD+56By4eJpDij5MT Opbzs6YcKYJoI08+bAOHhoNkLfTpiubPpgWKSLnA+hBjMvTmd0RRpGjcr2zhgvEVdcyK +IzSgZfrbZ/NLO0vDgYM9ezQAY2DneiIqgKhaaa/AWKdKGR7pchvtebWg59Tu3NKAu1t KfNA2kx194ayr0qSDlt7GQ2ZCJcXmsnwjaldONtKuYvo/dDsD7baWA02CqXJqfwXNbeF PALw== X-Forwarded-Encrypted: i=1; AJvYcCV+X+DdqYsWQ5wWXyscrBwKtESbtJQFW8B2x1dhLuoD9CbdJo4iAchXyRCrEt3mp3PxvH92GaU=@ietf.org X-Gm-Message-State: AOJu0Yy7QG4VamSU2Zy+gyumnd3cXb+1QcVXRbg4SbcgGKrdy+C82pY2 dQBb3PwBZkwh0a7raidyS+LzPG6eQ5MdsR+CW34geED/fcBkTTr/24FuRSlT9a6Gwee+vawipKw 3bw+hn+qKCnSeYN4+KWJHl8ekrdxjy9M/NMtKK6Azss5/UUfwZ5dZ X-Gm-Gg: AY/fxX5dH/2HB92RpiSa6Yzd1omANNfrljThAB2cOszRBuQIu2ESr0ge3vRzfjE3KBA 34Y/oh+QtqJw336PInKmDPn1+VQtc3tIAeXqNYM8R1qnH8aD/Urg9/xMbRVjAmrIJUfBalqHRBq c31HSR83BtITA8+Pi4D4DVecBA7OPcMzfhzgirE5G87s5eo9V+36YSt4ht3Xz/EbL6kwxv+DBVh yFajvq0iBvnvIRtORsTMDrobBsrQfER1pT0lvLDy3walOW0tv29jRDS85TVz1Vcg+TyTb95XA== X-Received: by 2002:a05:6512:3a94:b0:59b:7baa:2e62 with SMTP id 2adb3069b0e04-59baef0a202mr3447912e87.47.1768822200483; Mon, 19 Jan 2026 03:30:00 -0800 (PST) MIME-Version: 1.0 References: <20260119171038335bTTiNEx1z7O7X16zGFFQk@zte.com.cn> In-Reply-To: <20260119171038335bTTiNEx1z7O7X16zGFFQk@zte.com.cn> From: Jinoo Joung Date: Mon, 19 Jan 2026 20:29:49 +0900 X-Gm-Features: AZwV_Qj23vZ1WEL831GzT7rfNKfwQychIMI4HKwILNBsWt23sOfaR7yN2chb__Q Message-ID: To: peng.shaofu@zte.com.cn Content-Type: multipart/alternative; boundary="000000000000ee4e930648bc0239" Message-ID-Hash: QNDS2AXLR76SOJCKY7AFW4MBQG722ZOW X-Message-ID-Hash: QNDS2AXLR76SOJCKY7AFW4MBQG722ZOW X-MailFrom: jjoung@smu.ac.kr X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-detnet.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Janos.Farkas=40ericsson.com@dmarc.ietf.org, detnet@ietf.org, detnet-chairs@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BDetnet=5D_Re=3A_=5BDetNet=5D_A_concern_regarding_slot-based_sol?= =?utf-8?q?utions?= List-Id: Discussions on Deterministic Networking BoF and Proposed WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000ee4e930648bc0239 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM 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 > *To: *=E5=BD=AD=E5=B0=91=E5=AF=8C10053815; > *Cc: *Janos Farkas ;DetNet = WG > ;DetNet Chairs ; > *Date: *2026=E5=B9=B401=E6=9C=8817=E6=97=A5 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=E2=80=AFAM 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 constrain= t >> 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 t= he >> 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, fl= ow >> 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 allocati= on >> 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 incom= ing >> 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 t= he >> flow isolation and protection features during packet scheduling. So, the= re >> is no scalability issues. >> >> For example, a set of flows (such as i, j, k) may share the same slot #1= 0 >> 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 hav= e >> 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 >> *To: *DetNet WG ; >> *Cc: *DetNet Chairs ; >> *Date: *2026=E5=B9=B401=E6=9C=8808=E6=97=A5 20:07 >> *Subject: **[Detnet] Re: WG adoption poll: >> draft-peng-detnet-packet-timeslot-mechanism-13* >> _______________________________________________ >> detnet mailing list -- detnet@ietf.org >> To unsubscribe send an email to detnet-leave@ietf.org >> >> 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 fo= r >> 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=C3=A1nos >> >> >> >> >> >> *From:* Janos Farkas >> *Sent:* Friday, December 5, 2025 4:50 PM >> *To:* DetNet WG >> *Cc:* DetNet Chairs >> *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-mecha= nism/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-queui= ng/05 >> >> >> https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwar= ding/18 >> >> >> https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mecha= nism/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=C3=A1nos (as Co-chair) >> >> >> >> >> >> >> _______________________________________________ >> detnet mailing list -- detnet@ietf.org >> To unsubscribe send an email to detnet-leave@ietf.org >> > > --000000000000ee4e930648bc0239 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Shaofu, thanks for the reply.
I am glad to know the= controller plane is now under consideration.

Howe= ver, I am still concerned about the effectiveness of the time slot.
According to your controller plane document, an orchestration=C2=A0perio= d is composed of multiple time-slots.
If a flow can be assigned i= n any slot in an orchestration=C2=A0period, then eventually, the per-hop la= tency bound is the orchestration=C2=A0period length (OPL).
E2E la= tency will be the number of hops multiplied by OPL, if these OPs are synchr= onized among the nodes.

Then I wonder what the rol= e of time-slot is=C2=A0here.
Why don't you schedule flows int= o an orchestration=C2=A0period, rather than schedule=C2=A0a flow into a slo= t?
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=E2=80= =AFPM <peng.shaofu@zte.com.cn<= /a>> wrote:
<= div>


Hi Jinoo,


Thanks f= or your questions.

The &qu= ot;unfortunate" case in my previous reply is about admission check pro= cedure, i.e., trying to assign a slot for the flow, instead of packet forwa= rding.

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 do= cument and discuss it in a separate document (https://www.ietf.org/archive/id/draft-peng-detnet-tqf-controller-plane-= 00.txt).


Regards,

PSF



Or= iginal
<= div style=3D"padding:8px;background-color:rgb(245,246,248)">
Fr= om:=C2=A0JinooJoung <jjoung@smu.ac.kr>
To:=C2= =A0=E5=BD=AD=E5=B0=91=E5=AF=8C10053= 815;
Cc:=C2=A0Janos Farkas <Janos.Farkas=3D40ericsson.com@dmarc.ietf.org>;DetNet WG <detnet@ietf.org>;DetNet Chairs <detnet-chairs@ietf.org>;
Date:= =C2=A02026=E5=B9=B401=E6=9C=8817=E6=97=A5 22:39
=
Subject:=C2=A0[DetNet] A concern regard= ing slot-based solutions
<= div dir=3D"ltr">

Hello Shaofu,=C2=A0
I have a concern regarding your re= ply below.
In the slot-based solutions, there should be no "= unfortunate" case that a packet misses its assigned slot, especially f= or deterministic=C2=A0networks.
A network configuration entity sh= all 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 thei= r slot scheduling methodologies in the drafts.
Otherwise, it is l= ike putting off a difficult task to someone else.

Best regard= s,
Jinoo

On Fri, Jan 9, 2026 at 11:28=E2=80=AFAM <peng.shaofu@zte.com.cn= > wrote:
=


Hi Janos,


Thanks = for your concerns about these two drafts and initiating the discussion.

=


Yes, you are absolutely right that these two mecha= nisms=C2=A0have a certain degree of com= monality,=C2=A0=C2=A0as =C2=A0they both originated from TAS.

Actually, timeslot and cycle means the same thing, especially when TQF u= se Round Robin queues as that TCQF used, although TQF doesn't constrain= t it and may also use PIFO queues.


The p= urpose of developing TQF is to enhance the flow interleaving capability of = slot-based mechanism.

Intu= itively, 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 cy= cle mapping, as below:

=C2= =A0O--------O--------O--------O--= ------O--------O--------O

hop-0=C2=A0 =C2=A0hop-1=C2=A0 hop-2=C2=A0 =C2=A0hop-3=C2=A0 = =C2=A0 hop-4=C2=A0 =C2=A0hop-4=C2=A0 =C2=A0 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 det= ermined based on the fixed mapping.

So, if flow i finds that it unfortunately conflicts with flow j o= n hop-3 (flow j arrives from another input interface of hop-3), TCQF can at= tempt 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=C2=A0TQF is like a string of beads connected by r= ubber bands, where the meaning of=C2=A0ru= bber band is=C2=A0a non fixed timeslot mapping, as below:

O~~~~~O~~~~~O~~~= ~~O~~~~~O~~~~~O~~~~~= O

hop-0=C2=A0 =C2=A0ho= p-1=C2=A0 hop-2=C2=A0 =C2=A0 hop-3=C2=A0 =C2=A0 =C2=A0hop-4=C2=A0 =C2=A0 ho= p-4=C2=A0 =C2=A0 =C2=A0hop-5

That is, for a flow i, the out slot-id is determined independently o= n each hop.

So, if flo= w i finds that it unfortunately conflicts with flow j on hop-3 (flow j arri= ves 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 ot= her hops.

However, the slo= t allocation rule of TQF can force outgoing timeslot to be offset by a fixe= d 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.


Fro= m 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 forwar= ding delay jitter within the node) and the number of slots designed by TQF = (e.g., 10 buffers to =C2=A0provide multiple timeslot offsets).=C2=A0=


In=C2=A0draft-ietf-detnet-dataplane-taxonomy w= e have defined Flow level, Flow aggregation level and Class level for traff= ic granularity.=C2=A0

In that context, a Flow level based me= chanism never means it need per flow states maintained in the core as ATS d= oes, but=C2=A0=C2=A0rather highlights the flow isolation and protection fea= tures during packet scheduling. So, there is no scalability issues.=C2=A0

For example, a set of flows (such as i, j, k) may sh= are the same slot #10 on a hop and been protected and=C2=A0isolated from other flows during scheduling.=C2=A0=

Each new flow can choose the corresponding timeslot, but it will n= ot have any impact on the slot rotation process of the underlying operation= .



Hope the above is helpful. Please let me know if=C2=A0there are any questions.

Regards,

PSF



Original
From:=C2=A0Ja= nosFarkas <Janos.Farkas=3D40ericsson.com@dmarc.ietf.org>
To:=C2=A0DetNet WG <detnet@ietf.org>;<= /div>
Cc:=C2=A0DetNet C= hairs <detne= t-chairs@ietf.org>;
Date:=C2=A0202= 6=E5=B9=B401=E6=9C=8808=E6=97=A5 20:07
Subject:=C2=A0[Detnet] Re: WG adoption poll: draft-peng-detnet-packet-timesl= ot-mechanism-13
__________________________________= _____________
detnet=C2=A0mailing=C2=A0list=C2=A0--=C2=A0detnet@ietf.org
To=C2=A0unsubs= cribe=C2=A0send=C2=A0an=C2=A0email=C2=A0to=C2=A0detnet-leave@ietf.org

Hi,

=C2=A0

I've been wondering whether there = are more commonalities between draft-peng-detnet-packet-timeslot-mechanism = and draft-eckert-detnet-tcqf?

=C2=A0

(For instance, time slot vs cycle could be considered diffe= rent terms for the same thing.)

=C2=A0

Perhaps the main difference, if I get it right, is that dr= aft-eckert-detnet-tcqf is class-based whereas draft-peng-detnet-packet-time= slot-mechanism is flow-based.

=C2=A0

However, it has been claimed that flow-based mechanisms, li= ke ATS, are not good enough to meet the scalability requirements.

=C2=A0

What do you think?

=C2=A0

Thanks and regards,<= /span>

J=C3=A1nos<= /span>

=C2=A0

=C2=A0

From: Janos Farkas
Sent: Friday, De= cember 5, 2025 4:50 PM
To: DetNet WG <detnet@ietf.org>
Cc: DetNet Chairs <detnet-chairs@ietf.org>
Subject: WG adoption poll: draft-peng-detnet-packet-timeslot-mechanism-13<= /p>

=C2=A0

Hi,

=C2=A0

This email begins a 4-week adoption poll for:

https://datatracker.ietf.org/doc/draft-peng-detnet-packet-times= lot-mechanism/13/

=C2=A0

No IPR has been disclosed for this document.

=C2=A0

Please voice your support or technical= objections to adoption on the

list by the end of the day (any time zone) January 2nd= .

=C2=A0

As a reminder= this document is part of the larger set of adoption calls

of the documents discussed= at IETF 124:

=C2=A0

<= a href=3D"https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fai= r-queuing/05" target=3D"_blank">https://datatracker.ietf.org/doc/draft-joun= g-detnet-stateless-fair-queuing/05

https://data= tracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding/18

https://datatracker.ietf.org/doc/draft-peng-detnet-pac= ket-timeslot-mechanism/13

https://datatracker.ietf.org/doc/draft-= eckert-detnet-tcqf/09

https://datatracker.ietf.org/doc/draft-ecker= t-detnet-glbf/06

https://datatracker.ietf.org/doc/draft= -ryoo-detnet-ontime-forwarding/04

https://datatracker.ietf.org/doc= /draft-ryoo-detnet-nscore/02

=C2=A0

Thank you,

J=C3= =A1nos (as Co-chair)

=C2=A0

=C2=A0

=


________________________________________= _______
detnet mailing list -- detnet@ietf.org
To unsubscribe send an email to detnet-leave@ietf.org<= /a>
=


--000000000000ee4e930648bc0239--