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 7A40CA905C1B for ; Sat, 17 Jan 2026 06:39:12 -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 cjBBryc_UYuw for ; Sat, 17 Jan 2026 06:39:08 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 70E39A905C03 for ; Sat, 17 Jan 2026 06:39:07 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-3831c18b23bso23288481fa.2 for ; Sat, 17 Jan 2026 06:39:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768660746; cv=none; d=google.com; s=arc-20240605; b=RiQUJLmTG3zPQQiiFpNrrxXx5Clc51O2JkFQUyafE27+yb/g3iRLcxDM7XX1qeZYjk uOvEO8sScK4lE3GU8491kOjq7xBIvZzOIWMRfkJkmT+5pJrPbmJiCuX1O3SQzNuTdlPt qWslc8rqccE2Kv4rTdaj/6C8pvtyhi9QWZY/eawxawzYt1aqCXfMexbtjzQ2JVTsfwTT tvjNoUX3vRbeKDEmVYghL0QO2puNOBkIv8j8mnKu0H+qlIfuKp74dpK6w6NK7eCC2AKz YIZLs6+ynmqUKA8Y9SXGoP0FAl9AXuUUUif9QdHT32NN1l6loYZtp6zAYgnRVTmJ/SAo Y1eQ== 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:mime-version:dkim-signature; bh=GEfNkx4FEay/c4a4bpkHn3O+cOAwpaYVIHcrdFqWktA=; fh=Ro1HQ4gnY+30KEZPek1GcIHPKtZIfnE6ySgumlg8nYc=; b=WTJfoBo4GUa+ArBVA5nQbwBYSpVaUqlRGR7Sn+7oCnvYcqVTMO5LPJG7oKAF9jNypH rQZl3oFUR7Y49yek5GXy6bf/TueEE9n7563HnQkaB0mLYYI2kN7WROc2mG2u6sSbRPwx tkQnaVB++tlPbjiE69CEjOe6gx3Z4RRcbZOokLXWXjpRenouLHBZuEuj01bnxDY/+O+2 3FW2q6fB4wPH1Dp19uxhP3QV4dqPzSuOESu3Y+b7zedZ/rxHqH86R1j0k1FTMA/RPgnS ovIjqC9mOJmUJParUyMur/Oc9ucB2NTCnidNWHc1quA0ZZZSCgse3DWrSBNSbDBqqJiP QOow==; 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=1768660746; x=1769265546; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=GEfNkx4FEay/c4a4bpkHn3O+cOAwpaYVIHcrdFqWktA=; b=rvobiDcHch6KfxPkf4j1V44wljSReCTOk7cbJTezHwALOTSAwwiOTjMXPljomvvqHI LQrhei0Yy8UKk7Ws0ilPiFf0vE54GDlSDK3E7dQLDD2VtdbqFbAn93+QK7oNMa75KJJR hSYI5Hb08/r2SHg70iIMBJDoYWINeFz53iVXzPLJ+RR8HxrGoX9Haenonq8XJQpmHxCG BIKTItSRTO+rLMv+qhTJHiiyfzXoVP5lA2j94U8VoTJaPHleZxn+JrNXwHnt4228BTEt FIZlzY1sk1SO1W2qOcujxu9OrwLjl0DCSTlsLN54R5amFLCWs+Ryuy8i0slitR47OqN8 RgkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768660746; x=1769265546; h=cc:to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GEfNkx4FEay/c4a4bpkHn3O+cOAwpaYVIHcrdFqWktA=; b=bJx65MKD8Ur5UZKxMHUDJ0EL9yNTa3kovbLoTWsaUIM08vfnkUkOMyP9YJV1T4y5/r OutpEJw6mICNorQSEBEdfcCF3FoQAOifrz2ZWIU9R4LGc4peishQx1VloJL0Mzhew4kU agp2KhHOtUxhxLa0jH0vnh84JtenrHmaK1isQGhLtYGnYIuJDRWGLqG8gcu2DrrLvQH8 owNFYzAbJ9AQ/sONKPys5vwHyGl65NMnb23/r/R9rl9/PAXpQXBY2unpAk453Di5jkjU w+lRRWHwAHbzX0cXVYKUKi7kMJWx1k39Y4W4K1fOzzbxo1gliT5xvGX5r8ew6QDDSuGn ctgA== X-Forwarded-Encrypted: i=1; AJvYcCVBOssW6izaOH7mpBupY6Km2LjXIQGPZSO1t+Ap4OWkrSGFwifsXnpRrNAdq+9YU2X+t8Dxd1M=@ietf.org X-Gm-Message-State: AOJu0YwypOajPelOYfN93xgeGM2WfS8VCneLeee43dSXs7fPXbWhcNCr HUeafb7vB18iOJntHww0xfSmSi8JdvhCtQdFbQmrwuIJ2aGsEoh1th3bmdZfTBQwPY9g4Ip4xdl Ub8Ios8sWEGKX0t8oECPbG7BYCemwdA2I9+9/Yc7rq63HDCXj3zWw X-Gm-Gg: AY/fxX5/G5RQv+kt7VXgma29G8mTvA+8qFGHtqbox0ZjX01f6E/wGPQE/VV04MjAOZd Mz69IvzqWI3zVJV4uG5g4VHLvWLv2/vSicEbdwdnXZQEWmkW/cTdTv3BW0deDa2NrQo/Iqy7/3p 27W5KsFfjsI4fX1U6pD5K1xJdeoRDxpr9GWTbR9r04so4p8PTlDwnUsOhn02f/3Ao3+3XkkG4MH 4Vak5dbalcvOPvIRagmAUFlOFrvfuGnJ8wtAgeXYvE+W6nrvjgkZokJgp+SBKTueHNxQ7CKrA== X-Received: by 2002:a2e:b8c8:0:b0:37b:9539:9d1 with SMTP id 38308e7fff4ca-3838431d980mr19291741fa.37.1768660746441; Sat, 17 Jan 2026 06:39:06 -0800 (PST) MIME-Version: 1.0 From: Jinoo Joung Date: Sat, 17 Jan 2026 23:39:00 +0900 X-Gm-Features: AZwV_Qj4NHEBr53CEUvn7mrJ-wE_7-YJL47jpeWk8kBbiGRT0faURaP0YEI0Fg0 Message-ID: To: Shaofu Peng Content-Type: multipart/alternative; boundary="00000000000085294a0648966b81" Message-ID-Hash: KZ6DQNFQNG44PE5EHT6PGIH27BEKXXGF X-Message-ID-Hash: KZ6DQNFQNG44PE5EHT6PGIH27BEKXXGF 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 , DetNet WG , DetNet Chairs X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BDetnet=5D_=5BDetNet=5D_A_concern_regarding_slot-based_solutions?= List-Id: Discussions on Deterministic Networking BoF and Proposed WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000085294a0648966b81 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 us= e > 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 i= s > 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 th= e > 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, flo= w > 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 eac= h > 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 t= o > use another slot-id on hop-3 for flow i and not affect the slot allocatio= n > result of other hops. > > However, the slot allocation rule of TQF can force outgoing timeslot to b= e > 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 flo= w > states maintained in the core as ATS does, but rather highlights the flo= w > 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 > *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 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 no= t > 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-mechan= ism/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-queuin= g/05 > > > https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forward= ing/18 > > > https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechan= ism/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 > --00000000000085294a0648966b81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello Shaofu,=C2=A0
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=C2=A0n= etworks.
A network configuration entity shall be able to guarante= e such a scheduling, in large-scale, highly-utilized, arbitrary-topology, d= ynamic networks where numerous flows join and leave.

I suggest that the slot based solutions clearly specify their slot sched= uling 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 <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=A0JanosFarkas <Ja= nos.Farkas=3D40ericsson.com@dmarc.ietf.org>
To:=C2= =A0DetNet WG <detnet@ietf.org>;
Cc:=C2=A0DetNet Chairs &l= t;detnet-chairs= @ietf.org>;
Date:=C2=A02026= =E5=B9=B401=E6=9C=8808=E6=97=A5 20:07
Subject:=C2= =A0[Detnet] Re: WG adoption poll: draft-peng-detnet-= packet-timeslot-mechanism-13
______________= _________________________________
detnet=C2=A0mailing=C2=A0list=C2=A0--= =C2=A0detnet@ietf.org<= /a>
To=C2=A0unsubscribe=C2=A0send=C2=A0an=C2=A0email=C2=A0to=C2=A0detnet-leave@ietf.org<= /a>

Hi,

=C2=A0=

I've been won= dering whether there are more commonalities between draft-peng-detnet-packe= t-timeslot-mechanism and draft-eckert-detnet-tcqf?

=C2=A0

(For instance, time slot vs cycle coul= d be considered different terms for the same thing.)

=C2=A0

Perhaps the main difference, if I get= it right, is that draft-eckert-detnet-tcqf is class-based whereas draft-pe= ng-detnet-packet-timeslot-mechanism is flow-based.

=C2=A0

However, it has been claimed that flow-= based mechanisms, like ATS, are not good enough to meet the scalability req= uirements.

= =C2=A0

What= do you think?

=C2=A0

= Thanks and regards,

J=C3=A1nos

=C2=A0

=C2=A0

From: Janos Farkas
Sent:= Friday, December 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

=C2=A0

Hi,

=C2=A0

This email begins a 4-week adoption pol= l for:

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

= =C2=A0

No IPR has been disclosed for this document.

=C2=A0<= /p>

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

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

=C2=A0

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

of the= documents discussed at IETF 124:

=C2=A0

https://datatracker.ie= tf.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

<= span style=3D"font-size:11pt">https://datatracke= r.ietf.org/doc/draft-ryoo-detnet-ontime-forwarding/04

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

=C2=A0

Thank you,

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

=C2=A0

=C2=A0<= /p>


_________________________= ______________________
detnet mailing list -- detnet@ietf.org
To unsubscribe send an email to detnet-leave@ietf.org
--00000000000085294a0648966b81--