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 669C6C3DAB55 for ; Tue, 3 Mar 2026 18:06:54 -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=ham 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 SeKGqFUAIciZ for ; Tue, 3 Mar 2026 18:06:51 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 8A4F0C3DAB3E for ; Tue, 3 Mar 2026 18:06:51 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-389fac627c9so96777101fa.0 for ; Tue, 03 Mar 2026 18:06:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772590010; cv=none; d=google.com; s=arc-20240605; b=edfyBSNYsw8QjcFSygkj5A+vUSXEpsntD/Dyr7iDQSNA/z4B/pXTcQL5KI0U3Qfteo 0NvMjmqXDj5QbJd+ABrz0HyvVShv/HEPJLDBwY2JomMlXuLDT9BR7rCRvObzWT3YWT4S I/eHW+9ario/DH56BrVZrLsKxJjMThQm7bxVy16unsKPPu3xfbM7g06wzjJtNwDLFaJC 15wdMOQ2ENmX1qs5D1LsqKfWauysf92MarCYptHaO/+7XT49Y+mN7Ez6DCvjU78GXU8r S46a3CmbLD4T4EPz449lpYvkOEKIVxuKuOXniRTKE4EfR+x4p6mYUpXN44zjEFAPNTrg Mqlw== 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=IXRf6i6adrJ4tYkv/DlVyzqvRxzAZ/mnlDFfrO1wraM=; fh=JnQFPUqwdfnJeiWOgOmaFIaHu5O88jz/u6vR6fexuQU=; b=VHvygUbRq12Mt7M7pVlwayocVv6WeTRILG2XQV8IbrHvBhvjGFt/Uz0QLgNnkRmt1f gW9jcXkx8vNh5ZwZL405HUI1pcyRgEVYpE6iNhkxgcypV0gGqAbwEsrAhIi94ONXjOGb F2xFZzb16oeA4gN4k8GuyeVUobfPhVaxc+yu0Zp514m9XGTLOmJ+V4boE+s7TJHEim7U 5/uJNFp+Fx/5jSv3Bzbh1Ke2tGildJGEcqkDuUVIUi9C+TxYli7ckxpLUjT35vzLxaCV eRbwd9cMSmIcFQvEz+WmRb562qrzMX+8wX/iuY/drQJxukaZu2Cm8LsIiUZ4/X4Poe5g tRlw==; 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=1772590010; x=1773194810; 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=IXRf6i6adrJ4tYkv/DlVyzqvRxzAZ/mnlDFfrO1wraM=; b=lgB6/x/qvTW7N/pQeiEB00J6YvxB9RPpVuWLPqNlaMfnB1QUfF39dXplOxd5yjn4ti /lYYN9fMHR0wPTwCF0QhfHHU5otqzw4WpnEGKoZ2S2A8e17Iq8nkqt1euhBk/baTnau3 4gzKC32R1WBa7bmGKuFSiHYz5Skfm1YtzJ7NHu6e3I1jdogq6ZYr86SIQs49/MilrOob gvvyM2xqjGCMsTL0d+h5T0qQ3sK7o5S7O0HwIKmIHdbkcicnY9nX6SmJY47PIJu3pJP4 SRL3lHHwVxO57qoZv+6JKKTfExQp3lLINtMqIx1ATOfc+8uxXPtaPt7+HT+LHFCwGz6W 0r6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772590010; x=1773194810; 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=IXRf6i6adrJ4tYkv/DlVyzqvRxzAZ/mnlDFfrO1wraM=; b=UFJt3xr4sdoSdJwzX8bsA+AcYx0O5QHuSMAx+l4jhk+6UdytD5qiYIOMsGMd04CXWq +X6noZQFGbikj1sZny45GNqZp55MBViXIv53TdIEA9T+J/Bv4Jj+V9qFP+w4QunFzoQd k5sSIKXYG7bskZASycwrSs7xqjJtgapPKqW9B1pG/TkWiFxPff4PkucgGGFa8AUvrU62 2JzgzsldfrH0AnjVlEOq9ZIxuc3Y27g00Cs8pXrmSWHfXIdHxFcfUp4VybGflG01g+/I MlUM8COSZbJJKDrBbwDQnJvBqlR6aazm7skM32WOrA1/WYFeptk/QGvZ5sM1qwKMXHJ2 1j6Q== X-Forwarded-Encrypted: i=1; AJvYcCUFWxogKzid17H0qS0jcEWXfN5L4szm+q0dzIFlBYjbmu9i4vZnC49UQmFW9l9D5R57BRO+Y/s=@ietf.org X-Gm-Message-State: AOJu0YxRYRqhf2QJmLviGSx/iVvyV4O2Ifsv4MFJaiDa2PWK1GyNdylQ vbfQO2NxgKvuskphfuXuQ4C4dISzamvp1bOct1gB4Ha/XmuyRTlcaW3J146K7+kMIVhzFFvv9C2 D0+ntNygXyzGQW7ZbfNJmg71JsT488gknVrBAV6RXLA== X-Gm-Gg: ATEYQzyh4j1ElIPlWTOJ5Z6p3UbLw5+gWu124Qxw9TPfv8VwNRej8X6nJi5/4HSG+Ec +txTwQMXCANzG80DsouD2cei19+QfrJAAlY7gjh28FcOWGHC6htYKpAUAKpW3zlId7slJ8pIgYq BA95i2L3s0K8gFv9mZoko91FauK/5a7or6CbF1zj4jiOjeotQtaCTac7mNGUIaGQ9k18+7Ol4Ct D4pA6tXb/Jx6d4z1rgoq/PjEFpUJLpQvsWc4Qd05GOYAmh+MeO2yz+Lm80/eN1xUVVG3cEpoPly HQJCuqUEmA== X-Received: by 2002:a05:651c:19aa:b0:37f:a216:e473 with SMTP id 38308e7fff4ca-38a2c4eb781mr4675761fa.0.1772590010122; Tue, 03 Mar 2026 18:06:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jinoo Joung Date: Wed, 4 Mar 2026 11:06:39 +0900 X-Gm-Features: AaiRm50xvC60WTyUzWSgjxGvYchjNYSTZ99pN5ApZTnkNEQskSrAezfIl558VCU Message-ID: To: Mike Blanche Content-Type: multipart/alternative; boundary="000000000000e2cf0d064c294594" Message-ID-Hash: WRGZJ2UIUP6TJHOI5WV4IZ7AABWLDCKI X-Message-ID-Hash: WRGZJ2UIUP6TJHOI5WV4IZ7AABWLDCKI 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@ietf.org" , DetNet Chairs , Scott Mansfield X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BDetnet=5D_Re=3A_WG_adoption_poll=3A_joung-detnet-stateless-fair?= =?utf-8?q?-queuing-05?= List-Id: Discussions on Deterministic Networking BoF and Proposed WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000e2cf0d064c294594 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Mike, for your careful consideration and comments. We will try our best to align this work with ITU-T standards. Please see our answers in-line marked JJ. Best regards, Jinoo (on behalf of authors) On Tue, Mar 3, 2026 at 9:00=E2=80=AFPM Mike Blanche = wrote: > > Hi Jinoo, authors, and the WG, > > Thank you Jinoo and the authors for updating this draft. > > I think the "meat" of what is new in the proposal is in 6.3.2.1 (IPv6 > header format) and 6.3.2.2 (MPLS label format), and possibly 6.3.3, the > admission procedure. > JJ: Right, and Section 7 (Approximate C-SCORE) too. > > Most of the other content appears to summarize or restate what is in ITU-= T > Y.3129 and Y.3148, albeit with discrepancies. > > For example Section 4 appears to be a condensed version of section 6 of > ITU-T Y.3129, although it still appears to include specifications already > defined in Y.3129, e.g. > section 4 of this I-D: "Instead of deriving a new FT at each core node, w= e > will specify a method of deriving the FT at downstream nodes by using the > initial FT calculated at the entrance node." > section 6 of Y.3129: "This Recommendation presents requirements and a > framework for generation and update of FT..." > JJ: To provide necessary context for the reader, this draft retains the core principles of Y.3129. > > Section 6.1 has five requirements but Y.3129 has nine. > JJ: Right. But the context of the requirements remains identical. For example, the first two requirements in Y.3129 states: R1: The entrance node of a flow is required to manage the flow state. R2: The entrance node is required to determine initial FTs for packets according to the flow state. These requirements are summarized as Requirement 1 below in the draft. Requirement 1: In the entrance node, it is REQUIRED to obtain the FTs with the following equation. 0 denotes the entrance node of the flow under observation. F0(p) =3D max{F0(p-1), A0(p)}+L(p)/r. Overall, the texts in Y.3129 are high-level, while those in the draft are specific. If you think the texts for the requirements should be identical, I will gladly change them. > The equations in section 6.2 include clock discrepancy adjustment which > appears absent from the equivalent equations in section 8.2 of Y.3129. > JJ: We will add the equation in the future version. However, this version has been refined for brevity, retaining only the critical elements necessary. > > The metadata proposal appears to conflict with the ITU Recommendations. > The I-D suggests two pieces of metadata to be carried, Fh(p) and L/r. > However Y.3129 and Y.3148 refers to three pieces of metadata, Fh(p), L an= d > r. > JJ: What is required to fulfill the requirements and framework is the metadata L/r. Making two (L and r) to one (L/r) can be seen as an improvement. However, if necessary we will specify both cases in the draft. > Section 6.3.4 is almost word-for-word identical to Y.3129 section 8.4, > with the difference being the I-D suggests writing two pieces of metadata > whereas Y.3129 suggests three. > > Section 6.3.5 similarly to Y.3129 section 8.5. > > Section 6.3.6 similarly to Y.3129 section 8.6. > JJ: Right. These are the critical elements and the summarized texts. > > If I have misunderstood any of the above please let me know, it's entirel= y > possible. > > We must ensure the work aligns with existing standards. If we refer to > those standards we should not seek to recreate them in our drafts for ris= k > of introducing confusion. > > The abstract and introduction should also be updated to reflect what is > "new" in this proposal. > JJ: OK. We will update them as suggested. > > Thank you all for your continued efforts here. > > Mike > > > > > On Fri, 27 Feb 2026 at 14:28, Janos Farkas 40ericsson.com@dmarc.ietf.org> wrote: > >> Hi Jinoo, Authors, >> >> >> >> Thank you for the updates! >> >> >> >> Prior to publication as a WG document, we ask that you add a section tha= t >> describes the relationship of this work to the ITU-T work. >> >> >> >> Thank you, >> >> Lou and Janos >> >> >> >> >> >> *From:* Jinoo Joung >> *Sent:* Friday, February 20, 2026 12:11 PM >> *To:* Janos Farkas >> *Cc:* Scott Mansfield ; >> detnet@ietf.org >> *Subject:* Re: [Detnet] Re: WG adoption poll: >> joung-detnet-stateless-fair-queuing-05 >> >> >> >> Hello Chairs, Scott, and WG, >> >> >> >> Please note that draft-joung-detnet-stateless-fair-queuing is revised an= d >> uploaded as 07. >> >> In line with Scott's suggestions, the new version includes: >> >> 1) Abbreviations >> >> 2) New references including RFC8200, MPLS-related IETF drafts, and two >> ITU-T Recommendations. >> >> 3) Minimized 6.1. Framework and other content that are duplicative with >> ITU-T Recommendations. Only those that are essential to understand the >> whole picture are left. >> >> 4) Elaborated 6.3.1 Metadata; 6.3.2. Header format; 6.3.3. Admission >> control; 7. Approximate C-SCORE >> >> >> >> In 6.3.1 and 6.3.2, the methods for carrying metadata with IPv6 and MPLS >> MNA Sub-stack are described in detail. >> >> 6.3.3 delineates two distinct admission control methodologies, providing >> for the selection of either procedure based on specific implementation >> requirements. >> >> Section 7. Approximate C-SCORE specifies the nodal architecture and >> algorithms to approximate C-SCORE with rotating strict priority schedule= rs. >> >> The E2E latency bound, in a complete math expression, is also given. >> >> This approximation serves to alleviate the sorting bottleneck intrinsic >> to C-SCORE, >> >> bypassing the intensive priority queue operations while maintaining >> near-optimal alignment with theoretical Finish Time objectives. >> >> >> >> Best regards, >> >> Jinoo (on behalf of authors) >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> Internet-Draft draft-joung-detnet-stateless-fair-queuing-07.txt is now >> available. It is a work item of the Deterministic Networking (DETNET) WG >> of >> the IETF. >> >> Title: Latency Guarantee with Stateless Fair Queuing >> Authors: Jinoo Joung >> Jeong-dong Ryoo >> Taesik Cheung >> Yizhou Li >> Peng Liu >> Name: draft-joung-detnet-stateless-fair-queuing-07.txt >> Pages: 23 >> Dates: 2026-02-20 >> >> Abstract: >> >> This document specifies the framework and the operational procedure >> for deterministic networking with a set of rate based work conserving >> packet schedulers. The framework guarantees end-to-end (E2E) latency >> bounds to flows. The schedulers in core nodes do not need to >> maintain flow states. Instead, the entrance node of a flow marks an >> ideal service completion time according to a fluid model, called >> Finish Time (FT), of a packet in the packet header. The subsequent >> core nodes update the FT by adding the delay factor, which is a >> function of the flow and the nodes. The packets in the queue of the >> scheduler are served in the ascending order of FT. This mechanism is >> called the stateless fair queuing. The result is that flows are >> isolated from each other almost perfectly. The latency bound of a >> flow depends only on the flow's intrinsic parameters such as the >> maximum burst size and the service rate, except the link capacities >> and the maximum packet length among other flows sharing each output >> link with the flow. Furthermore, this document specifies an >> approximation of stateless fair queuing implemented via a strict >> priority (SP) scheduler. This approach maintains a guaranteed end- >> to-end (E2E) latency bound. >> >> The IETF datatracker status page for this Internet-Draft is: >> >> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queui= ng/ >> >> There is also an HTMLized version available at: >> >> https://datatracker.ietf.org/doc/html/draft-joung-detnet-stateless-fair-= queuing-07 >> >> A diff from the previous version is available at: >> >> https://author-tools.ietf.org/iddiff?url2=3Ddraft-joung-detnet-stateless= -fair-queuing-07 >> >> Internet-Drafts are also available by rsync at: >> rsync.ietf.org::internet-drafts >> >> >> >> >> >> On Fri, Jan 23, 2026 at 10:52=E2=80=AFPM Janos Farkas >> wrote: >> >> Hi, >> >> >> >> Scott, >> >> Thank you very mush for your guidelines! Much appreciated. >> >> >> >> Jinoo, >> >> Great to see agreement. >> >> Could you please revise the draft along the guidelines provided? Once >> updated per the discussion below, we can publish it as a WG document. >> >> >> >> Thank you, >> >> Lou and Janos >> >> >> >> *From:* Jinoo Joung >> *Sent:* Tuesday, January 20, 2026 4:23 PM >> *To:* Scott Mansfield >> *Cc:* detnet@ietf.org >> *Subject:* [Detnet] Re: WG adoption poll: >> joung-detnet-stateless-fair-queuing-05 >> >> >> >> Hello Scott, >> >> Thanks for your valuable suggestions. >> I deeply appreciate your efforts to resolve this issue in a fair and >> reasonable manner. >> I agree with your proposed action. >> >> I have answered your guidelines in-line marked with JJ. Please take a >> look. >> >> In short, there is a clear gap between the ITU-T work and the IETF >> document. >> While ITU-T work focuses on the requirements and framework, the IETF >> document will elaborate on IP/MPLS specific information for deployment, >> including header fields and formats, protocols for admission control and >> time-difference compensation. >> It will also include implementation details for approximating fair >> queuing with a strict priority scheduler. >> >> Many thanks and best regards, >> Jinoo >> >> >> >> On Tue, Jan 20, 2026 at 6:11=E2=80=AFAM Scott Mansfield > 40ericsson.com@dmarc.ietf.org> wrote: >> >> Hi, >> >> >> >> Speaking as a liaison manager between the IETF and ITU-T, it is importan= t >> to note a few guidelines. Following this discussion, I observe there is >> concern that there is work being duplicated. In order to make all parti= es >> comfortable I would suggest the following: >> >> >> >> Potential Action: >> >> The process of =E2=80=9Cgap analysis=E2=80=9D is used a lot in the ITU-T= to ensure new >> work items do not duplicate work already done by the industry recognized >> center of competence. The reverse is true as well. I would want to see >> the gap that the IETF is filling here and how it augments or modifies wh= at >> the ITU-T has already done. If there are modifications to the ITU-T wor= k >> needed, I would like to see the authors plans to progress that work in t= he >> ITU-T. >> >> >> >> JJ: There is a clear gap, as I stated in the main text of this mail. The >> IETF draft will augment the ITU-T work. There is no need to modify the >> ITU-T work. It serves as a solid foundation for the IETF draft. In my >> opinion, the implementation specific issues in the IETF draft are not >> appropriate for standardization in ITU-T. >> >> >> >> Guidelines To Note: >> - It is appropriate for the IETF to take ITU-T work and augment it as >> long as the augmentation is in the scope and mandate of IETF. Also, the >> work should not fundamentally change (or be backwards incompatible). It= is >> imperative that the IETF document be clear what ITU-T work it is using a= nd >> properly reference the work. >> >> >> >> JJ: I believe the IP/MPLS issues, protocols, and implementation >> specifications are well within the scope of IETF. While the work proceed= s >> in IETF, no changes will be introduced. The ITU-T works will be referenc= ed >> as well. >> >> >> >> - If there is anything being added in the IETF that requires a >> fundamental change to the ITU-T work, that work needs to be >> liaised/coordinated with the ITU-T. If what the IETF is doing is >> explaining how to use the ITU-T work in the context of IETF (profiles et= c.) >> that is ok. >> >> >> >> JJ: Again, the ITU-T work won't be changed. The IETF draft will explain >> how to use the fundamentals described in the ITU-T work. >> >> >> >> - If the IETF work is really changing the math, that should be >> coordinated too. If the ITU-T work missed something, or is not appropri= ate >> for the IETF use-case, again, coordination is needed. Since (at least) >> some of the authors are the same in both groups, this is the best way to >> gain consensus by ensuring the process of each group is followed. >> >> >> >> JJ: I definitely agree with you. >> >> >> >> I find coordination and cooperation is best handled when people work >> together and have people that attend each organization and follow the >> processes of the organization when progressing the documents. Liaison c= an >> be used, but they tend to be slow. The IETF DetNet mailing list is the >> proper place to have this discussion especially if there are participant= s >> in this working group that need clarity to ensure work is not duplicated= . >> >> >> >> Many thanks, >> >> -scott. >> >> >> >> >> >> >> >> [Detnet] Re: WG adoption poll: joung-detnet-stateless-fair-queuing-05 >> >> Jinoo Joung Fri, 02 January 2026 22:16 UTCShow header >> >> >> Hello Mike, it's great to hear from you. >> >> Thanks for the valuable feedback. >> >> It seems that your major concern is the discrepancy between the standard= s. >> >> >> >> But I assure you that there is no conflict. >> >> Because ITU-T did not allow math equations in the Requirements section, >> >> I had to divide one equation into two or three sentences. >> >> That is why it seems the number of requirements are different. >> >> If you find any discrepancies, just let me know. >> >> >> >> Y.3148 also deals with considerations for metadata, but it still is at a= n >> >> academic level. >> >> These two ITU-T standards are strictly based on the paper: >> >> https://ieeexplore.ieee.org/document/10261190 >> >> >> >> Best regards, >> >> Jinoo >> >> >> >> >> >> >> >> >> >> On Sat, Jan 3, 2026 at 4:09=E2=80=AFAM Mike Blanche >> wrote: >> >> >> >> > >> >> > Hi Jinoo and all, >> >> > >> >> > Although the C-SCORE approach may be an appropriate solution within th= e >> >> > agreed taxonomy, I am still concerned about duplicating work already >> done >> >> > elsewhere. >> >> > >> >> > What happens if the IETF draft diverges from the ITU Recommendation? >> >> > Y.3129 makes 9 "requirements", whereas the current draft has 5 >> requirements >> >> > and 3 conditions. There is already one discrepancy between the two >> >> > documents in the description of the maths. This may lead to >> inconsistent or >> >> > incompatible implementations depending on which document implementers >> >> > follow. >> >> > >> >> > I see the new draft (-06) focuses more on the necessary metadata. Thi= s >> is >> >> > also already documented in ITU-T Y.3148, which covers metadata creatio= n >> and >> >> > updating procedures in depth. Again, how will it be ensured that this >> draft >> >> > does not diverge from or conflict with the existing ITU Recommendation= ? >> >> > >> >> > The latest draft still does not cite either ITU Recommendation Y.3129 = or >> >> > Y.3148. >> >> > >> >> > Thanks, >> >> > >> >> > Mike >> >> > >> >> > On Tue, 23 Dec 2025 at 00:08, Jinoo Joung wrote: >> >> > >> >> >> >> >> >> Hello Mike, thanks for the comment regarding the work in ITU-T. >> >> >> I understand your concern. >> >> >> >> >> >> Hello WG and Mike, >> >> >> >> >> >> The C-SCORE draft, as indicated in the version 6, will have the >> following >> >> >> details in the future, once accepted as the WG draft. >> >> >> 1) MPLS and IP specific protocol details: This includes the header >> >> >> fields/formats, interactions between nodes and between control/data >> planes. >> >> >> 2) Implementation issues regarding the priority queue, which is >> currently >> >> >> required to sort the packets in FT orders: This includes an >> approximation >> >> >> technique based on strict priority schedulers. >> >> >> >> >> >> Y.3129 is focused on the requirements and provides theoretical >> >> >> justifications but the C-SCORE draft targets on the solution. >> >> >> Some framework texts are covered in both. But they are necessary >> >> >> information for readers in order to understand the design principles >> of the >> >> >> solution in the C-SCORE draft. >> >> >> >> >> >> C-SCORE is not a new invention. >> >> >> It is an outcome of the numerous researches conducted during late '90= ~ >> >> >> early '00s, which was the peak period of Internet research. >> >> >> There are more than hundreds of papers that are related to the fair >> >> >> queuing, after all. >> >> >> >> >> >> I believe it is worth being standardized by such virtues: >> >> >> 1) flow isolation capability, which protects from other flows' >> >> >> join/leave, bursts, or even malicious behaviours >> >> >> 2) scalability due to its stateless nature >> >> >> 3) flexibility from network asymmetry such as link capacity variation= s >> >> >> and uneven propagation delays >> >> >> 4) simple admission criteria, which allows incremental flow acceptanc= e, >> >> >> without modifying existing network setup >> >> >> 5) small average delay due to work conserving nature, >> >> >> just to mention a few. :-) >> >> >> >> >> >> Best regards, >> >> >> Jinoo (on behalf of authors) >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Dec 12, 2025 at 12:10=E2=80=AFAM Mike Blanche >> >> >> wrote: >> >> >> >> >> >>> >> >> >>> Hi all, >> >> >>> >> >> >>> This proposal appears very similar to ITU-T Recommendation Y.3129, >> which >> >> >>> I believe was developed by some of the same authors. >> >> >>> >> >> >>> https://www.itu.int/rec/T-REC-Y.3129-202404-I/en >> >> >>> >> >> >>> The abstract text of the I-D is virtually identical to the summary o= f >> >> >>> Y.3129. In addition, significant parts of the content are very >> similar - >> >> >>> e.g. parts of section 6.3 of the draft are word-for-word the same as >> parts >> >> >>> of section 8 of the ITU-T Recommendation. >> >> >>> >> >> >>> The ITU-T Recommendation is missing from the draft's References >> section. >> >> >>> >> >> >>> I am unclear why we are considering duplicating work that appears to >> be >> >> >>> already completed at the ITU. >> >> >>> >> >> >>> Best regards, >> >> >>> >> >> >>> Mike >> >> >>> >> >> >>> On Fri, 5 Dec 2025 at 15:49, Janos Farkas > >> >>> 40ericsson.com@dmarc.ietf.org> wrote: >> >> >>> >> >> >>>> Hi, >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> This email begins a 4-week adoption poll for: >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queui= ng/05/ >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> No IPR has been disclosed for this document. >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> Please voice your support or technical objections to adoption on th= e >> >> >>>> >> >> >>>> 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 >> >> >>>> >> >> >>> _______________________________________________ >> >> >>> detnet mailing list -- detnet@ietf.org >> >> >>> To unsubscribe send an email to detnet-leave@ietf.org >> >> >>> >> >> >> >> >> - [Detnet] WG adoption poll: joung-detnet-stateless=E2=80=A6 >> Janos >> Farkas >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> Mike >> Blanche >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> >> song.xueyan2 >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> Jinoo >> Joung >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> Yizhou >> Li >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> >> =EC=9C=A0=EC=97=B0=EC=B2=A0 >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> Jeong-dong >> Ryoo >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> >> xiong.quan >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> >> =EC=A0=95=ED=83=9C=EC=8B=9D >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> Mike >> Blanche >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> Jinoo >> Joung >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> >> liupengyjy@chinamobile.com >> - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 >> Xuesong >> Geng >> >> >> >> _______________________________________________ >> detnet mailing list -- detnet@ietf.org >> To unsubscribe send an email to detnet-leave@ietf.org >> >> _______________________________________________ >> detnet mailing list -- detnet@ietf.org >> To unsubscribe send an email to detnet-leave@ietf.org >> > --000000000000e2cf0d064c294594 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Mike, for your careful consideratio= n and comments.

We will try our best to align this work = with ITU-T standards.=C2=A0
Please see our answers in-line marked= JJ.

Best regards,
Jinoo (on behalf of a= uthors)

On Tue, Mar 3, 2026 at 9:00=E2=80=AFPM M= ike Blanche <mike-ietf@blanche.= org> wrote:

Hi Jinoo, authors, and the WG,

Thank you Jinoo and the authors for updating this draf= t.

I think the "meat" of what is new in = the proposal is in 6.3.2.1 (IPv6 header format) and 6.3.2.2 (MPLS label for= mat), and possibly 6.3.3, the admission procedure.
=
=C2=A0JJ: Right, and Section 7 (Approximate C-SCORE) too.

=
Most of the other content appears to summarize or restate what is in I= TU-T Y.3129 and Y.3148, albeit with discrepancies.

For example Section 4 appears to be a condensed version of section 6 of IT= U-T Y.3129, although it still appears to include specifications already def= ined in Y.3129, e.g.
section 4 of this I-D: "Instead of deri= ving a new FT at each core node, we will specify a method of deriving the F= T at downstream nodes by using the initial FT calculated at the entrance no= de."
section 6 of Y.3129: "This Recommendation presents= requirements and a framework for generation and update of FT..."

JJ: To provide necessary context fo= r the reader, this draft retains the core principles of Y.3129.

Section 6.1 has five requirements but Y.3129 has nine.

JJ: Right. But the context of the requirement= s remains identical. For example, the first two requirements in Y.3129 stat= es:=C2=A0

R= 1: The entrance node of a flow is required to manage the flow state.
R2:= The entrance node is required to determine initial FTs for packets accordi= ng to the flow state.

These requirements are summari= zed as Requirement 1 below in the draft.

Requirement 1:= In the entrance node, it is REQUIRED to obtain the FTs with the following<= br>equation. 0 denotes the entrance node of the flow under observation.
=
F0(p) =3D max{F0(p-1), A0(p)}+L(p)/r.=C2=A0

O= verall, the texts in Y.3129 are high-level, while those in the draft are sp= ecific.=C2=A0
If you think the texts for the requirements should = be identical, I will gladly change them.


Th= e equations in section 6.2 include clock discrepancy adjustment which appea= rs absent from the equivalent equations in section 8.2 of Y.3129.

JJ: We will add the equation in the futu= re version.=C2=A0
However, this version has been refined for brev= ity, retaining only the critical elements necessary.
=C2=A0
=
The metadata proposal appears to conflict with the ITU Recommen= dations. The I-D suggests two pieces of metadata to be carried,=C2=A0Fh(p) = and L/r. However Y.3129 and Y.3148 refers to three pieces of metadata, Fh(p= ), L and r.

JJ: What is require= d to fulfill the requirements and framework is the metadata L/r. Making two= (L and r) to one (L/r) can be seen as an improvement.=C2=A0
Howe= ver, if necessary we will specify both cases in the draft.=C2=A0
=

Section 6.3.4 is almost word-for-word identical to Y.3129 section 8.4,= with the difference being the I-D suggests writing two pieces of metadata = whereas Y.3129 suggests three.

Section 6.3.5 simil= arly to Y.3129 section 8.5.

Section 6.3.6 similarly to = Y.3129 section 8.6.

JJ: Right. = These are the critical elements and the summarized texts.=C2=A0 =C2=A0
If I have misunderstood any of the above please let me know, i= t's entirely possible.

We must ensure the work= aligns with existing standards. If we refer to those standards we should n= ot seek to recreate them in our drafts for risk of introducing confusion.

The abstract and introduction should also be update= d to reflect what is "new" in this proposal.

JJ: OK. We will update them as suggested.
=C2=A0

Thank you all for your continued efforts here.

Mike




On Fri, 27 Feb 2026 at 14:28, Janos Farkas <Janos.Farkas=3D40ericsson.com@dmar= c.ietf.org> wrote:

Hi Jinoo, Authors,

=C2=A0

Thank you for the updates!

=C2=A0

Prior to publication as a WG document, we ask that you add a sect= ion that describes the relationship of this work to the ITU-T work.<= u>

=C2=A0

Thank you,

Lou and Janos

=C2=A0

=C2=A0

From: Jinoo Joung <jjoung@smu.ac.kr>
Sent: Friday, February 20, 2026 12:11 PM
To: Janos Farkas <Janos.Farkas@ericsson.com>
Cc: Scott Mansfield <scott.mansfield=3D40ericsson.com@dmarc.ietf.org&= gt;; detnet@ietf.org
Subject: Re: [Detnet] Re: WG adoption poll: joung-detnet-stateless-f= air-queuing-05

=C2=A0

Hello Chairs, Scott, and WG,

=C2=A0

Please note that=C2=A0draft-joung-detnet-stateless-f= air-queuing is revised and uploaded as 07.

In line with Scott's suggestions, the new versio= n includes:

1) Abbreviations

2) New references including RFC8200, MPLS-related IE= TF drafts, and two ITU-T Recommendations.

3) Minimized 6.1. Framework and other content that a= re duplicative with ITU-T Recommendations. Only those that are essential=C2= =A0to understand the whole picture=C2=A0are left.

4) Elaborated 6.3.1 Metadata; 6.3.2. Header format; = 6.3.3. Admission control; 7. Approximate C-SCORE

=C2=A0

In 6.3.1 and 6.3.2, the methods for carrying metadat= a with IPv6 and MPLS MNA Sub-stack are described in detail.

6.3.3 delineates two distinct admission control meth= odologies, providing for the selection of either procedure based on specifi= c implementation requirements.

Section 7. Approximate C-SCORE specifies the nodal a= rchitecture and algorithms to approximate C-SCORE with rotating strict prio= rity schedulers.

The E2E latency bound, in a complete math expression= , is also given.

This approximation serves to alleviate the sorting b= ottleneck intrinsic to C-SCORE,=C2=A0

bypassing the intensive priority queue operations wh= ile maintaining near-optimal alignment with theoretical Finish Time objecti= ves.

=C2=A0

Best regards,

Jinoo (on behalf of authors)

=C2=A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=C2=A0

Internet-Draft draft-joung-detnet-stateless-fair-que= uing-07.txt is now
available. It is a work item of the Deterministic Networking (DETNET) WG of=
the IETF.

=C2=A0 =C2=A0Title:=C2=A0 =C2=A0Latency Guarantee with Stateless Fair Queui= ng
=C2=A0 =C2=A0Authors: Jinoo Joung
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jeong-dong Ryoo
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Taesik Cheung
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yizhou Li
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Peng Liu
=C2=A0 =C2=A0Name:=C2=A0 =C2=A0 draft-joung-detnet-stateless-fair-queuing-0= 7.txt
=C2=A0 =C2=A0Pages:=C2=A0 =C2=A023
=C2=A0 =C2=A0Dates:=C2=A0 =C2=A02026-02-20

Abstract:

=C2=A0 =C2=A0This document specifies the framework and the operational proc= edure
=C2=A0 =C2=A0for deterministic networking with a set of rate based work con= serving
=C2=A0 =C2=A0packet schedulers.=C2=A0 The framework guarantees end-to-end (= E2E) latency
=C2=A0 =C2=A0bounds to flows.=C2=A0 The schedulers in core nodes do not nee= d to
=C2=A0 =C2=A0maintain flow states.=C2=A0 Instead, the entrance node of a fl= ow marks an
=C2=A0 =C2=A0ideal service completion time according to a fluid model, call= ed
=C2=A0 =C2=A0Finish Time (FT), of a packet in the packet header.=C2=A0 The = subsequent
=C2=A0 =C2=A0core nodes update the FT by adding the delay factor, which is = a
=C2=A0 =C2=A0function of the flow and the nodes.=C2=A0 The packets in the q= ueue of the
=C2=A0 =C2=A0scheduler are served in the ascending order of FT.=C2=A0 This = mechanism is
=C2=A0 =C2=A0called the stateless fair queuing.=C2=A0 The result is that fl= ows are
=C2=A0 =C2=A0isolated from each other almost perfectly.=C2=A0 The latency b= ound of a
=C2=A0 =C2=A0flow depends only on the flow's intrinsic parameters such = as the
=C2=A0 =C2=A0maximum burst size and the service rate, except the link capac= ities
=C2=A0 =C2=A0and the maximum packet length among other flows sharing each o= utput
=C2=A0 =C2=A0link with the flow.=C2=A0 Furthermore, this document specifies= an
=C2=A0 =C2=A0approximation of stateless fair queuing implemented via a stri= ct
=C2=A0 =C2=A0priority (SP) scheduler.=C2=A0 This approach maintains a guara= nteed end-
=C2=A0 =C2=A0to-end (E2E) latency bound.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-joung= -detnet-stateless-fair-queuing/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html= /draft-joung-detnet-stateless-fair-queuing-07

A diff from the previous version is available at:
https://author-tools.ietf.org/i= ddiff?url2=3Ddraft-joung-detnet-stateless-fair-queuing-07

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts

=C2=A0

=C2=A0

On Fri, Jan 23, 2026 at 10:52=E2=80=AFPM Janos Farkas <Janos.Farkas@ericsson.com= > wrote:

Hi,

=C2=A0

Scott,

Thank you very mush for your guidelines! Much appreciated.=

=C2=A0

Jinoo,

Great to see agreement.

Could you please revise the draft along the guidelines provided? = Once updated per the discussion below, we can publish it as a WG document.

=C2=A0

Thank you,

Lou and Janos

=C2=A0

From: Jinoo Joung <jjoung@smu.ac.kr>
Sent: Tuesday, January 20, 2026 4:23 PM
To: Scott Mansfield <scott.mansfield=3D40ericsson.com@dmarc.ietf.org&= gt;
Cc: detnet@ietf= .org
Subject: [Detnet] Re: WG adoption poll: joung-detnet-stateless-fair-= queuing-05

=C2=A0

Hello Scott,

Thanks for your valuable suggestions.
I deeply appreciate your efforts to resolve this issue in a fair and reason= able manner.
I agree with your proposed action.

I have answered your guidelines in-line marked with JJ. Please take a look.=

In short, there is a clear gap between the ITU-T work and the IETF document= .
While ITU-T work focuses on the requirements and framework, the IETF docume= nt will elaborate on IP/MPLS specific information for deployment, including= header fields and formats, protocols for admission control and time-differ= ence compensation.
It will also include implementation details for approximating fair queuing = with a strict priority scheduler.

Many thanks and best regards,
Jinoo

=C2=A0

On Tue, Jan 20, 2026 at 6:11=E2=80=AFAM Scott Mansfield <scott.mansfield= =3D40eri= csson.com@dmarc.ietf.org> wrote:

Hi,<= /u>

=C2=A0<= u>

Speaking as a liaison= manager between the IETF and ITU-T, it is important to note a few guidelin= es.=C2=A0 Following this discussion, I observe there is concern that there is work being duplicated.=C2=A0 In order to make all pa= rties comfortable I would suggest the following:

=C2=A0<= u>

Potential Action:

The process of =E2=80= =9Cgap analysis=E2=80=9D is used a lot in the ITU-T to ensure new work item= s do not duplicate work already done by the industry recognized center of competence.=C2=A0 The reverse is true as well.=C2=A0 I would want to se= e the gap that the IETF is filling here and how it augments or modifies wha= t the ITU-T has already done.=C2=A0 If there are modifications to the ITU-T= work needed, I would like to see the authors plans to progress that work in the ITU-T.

=C2=A0

JJ: There is a clear gap, as I stated in the main te= xt of this mail. The IETF draft will augment the ITU-T work. There is no ne= ed to modify the ITU-T work. It serves as a solid foundation for the IETF draft. In my opinion, the implementation specific = issues in the IETF draft are not appropriate for standardization in ITU-T.<= u>

=C2=A0

Guidelines To Note: - It is appropriate for the IETF to take ITU-T work and augment it as long = as the augmentation is in the scope and mandate of IETF.=C2=A0 Also, the wo= rk should not fundamentally change (or be backwards incompatible).=C2=A0 It= is imperative that the IETF document be clear what ITU-T work it is using and properly reference the work.=

=C2=A0

JJ: I believe the IP/MPLS issues, protocols, and imp= lementation specifications are well within the scope of IETF. While the wor= k proceeds in IETF, no changes will be introduced. The ITU-T works will be referenced as well.

=C2=A0

- If there is anythin= g being added in the IETF that requires a fundamental change to the ITU-T w= ork, that work needs to be liaised/coordinated with the ITU-T.=C2=A0 If what the IETF is doing is explaining how to use the IT= U-T work in the context of IETF (profiles etc.) that is ok.

=C2=A0

JJ: Again, the ITU-T work won't be changed. The = IETF draft will explain how to use the fundamentals described in the ITU-T = work.

=C2=A0

- If the IETF work is= really changing the math, that should be coordinated too.=C2=A0 If the ITU= -T work missed something, or is not appropriate for the IETF use-case, again, coordination is needed.=C2=A0 Since (at least) some = of the authors are the same in both groups, this is the best way to gain co= nsensus by ensuring the process of each group is followed.=

=C2=A0

JJ: I definitely agree with you.

=C2=A0

I find coordination a= nd cooperation is best handled when people work together and have people th= at attend each organization and follow the processes of the organization when progressing the documents.=C2=A0 Liaison can be u= sed, but they tend to be slow.=C2=A0 The IETF DetNet mailing list is the pr= oper place to have this discussion especially if there are participants in = this working group that need clarity to ensure work is not duplicated.

=C2=A0<= u>

Many thanks,

-scott.=

=C2=A0<= u>

=C2=A0<= u>

=C2=A0<= u>

[Detnet] Re: WG adopt= ion poll: joung-detnet-stateless-fair-queuing-05

Jinoo Joung <jjoung@smu.ac.kr>= =C2=A0Fri, 02 January 2026 22:16 UTCShow header

Hello Mike, it's = great to hear from you.

Thanks for the valuab= le feedback.

It seems that your ma= jor concern is the discrepancy between the standards.<= /p>

=C2=A0<= u>

But I assure you that= there is no conflict.

Because ITU-T did not= allow math equations in the Requirements section,

I had to divide one e= quation into two or three sentences.

That is why it seems = the number of requirements are different.

If you find any discr= epancies, just let me know.

=C2=A0<= u>

Y.3148 also deals wit= h considerations for metadata, but it still is at an

academic level.

These two ITU-T stand= ards are strictly based on the paper:

https://ieeexplore.i= eee.org/document/10261190

=C2=A0<= u>

Best regards,<= u>

Jinoo

=C2=A0<= u>

=C2=A0<= u>

=C2=A0<= u>

=C2=A0<= u>

On Sat, Jan 3, 2026 a= t 4:09= =E2=80=AFAM Mike Blanche <mike-ietf@b= lanche.org> wrote:

=C2=A0<= u>

>=C2=A0<= /u>

> Hi Jinoo and all= ,

>=C2=A0<= /u>

> Although the C-S= CORE approach may be an appropriate solution within the

> agreed taxonomy,= I am still concerned about duplicating work already done<= /u>

> elsewhere.

>=C2=A0<= /u>

> What happens if = the IETF draft diverges from the ITU Recommendation?

> Y.3129 makes 9 &= quot;requirements", whereas the current draft has 5 requirements

> and 3 conditions= . There is already one discrepancy between the two

> documents in the= description of the maths. This may lead to inconsistent or

> incompatible imp= lementations depending on which document implementers<= /p>

> follow.

>=C2=A0<= /u>

> I see the new dr= aft=C2=A0 (-06) focuses more on the necessary metadata. This is

> also already doc= umented in ITU-T Y.3148, which covers metadata creation and

> updating procedu= res in depth. Again, how will it be ensured that this draft

> does not diverge= from or conflict with the existing ITU Recommendation?

>=C2=A0<= /u>

> The latest draft= still does not cite either ITU Recommendation Y.3129 or

> Y.3148.

>=C2=A0<= /u>

> Thanks,

>=C2=A0<= /u>

> Mike

>=C2=A0<= /u>

> On Tue, 23 Dec 2= 025 at 00:08, Jinoo Joung <jjoung@smu.ac.kr> wrote:

>=C2=A0<= /u>

>>=C2=A0=

>> Hello Mike, = thanks for the comment regarding the work in ITU-T.

>> I understand= your concern.

>>=C2=A0=

>> Hello WG and= Mike,

>>=C2=A0=

>> The C-SCORE = draft, as indicated in the version 6, will have the following=

>> details in t= he future, once accepted as the WG draft.

>> 1) MPLS and = IP specific protocol details: This includes the header=

>> fields/forma= ts, interactions between nodes and between control/data planes.

>> 2) Implement= ation issues regarding the priority queue, which is currently=

>> required to = sort the packets in FT orders: This includes an approximation=

>> technique ba= sed on strict priority schedulers.

>>=C2=A0=

>> Y.3129 is fo= cused on the requirements and provides theoretical

>> justificatio= ns but the C-SCORE draft targets on the solution.

>> Some framewo= rk texts are covered in both. But they are necessary

>> information = for readers in order to understand the design principles of the

>> solution in = the C-SCORE draft.

>>=C2=A0=

>> C-SCORE is n= ot a new invention.

>> It is an out= come of the numerous researches conducted during late '90 ~

>> early '0= 0s, which was the peak period of Internet research.

>> There are mo= re than hundreds of papers that are related to the fair

>> queuing, aft= er all.

>>=C2=A0=

>> I believe it= is worth being standardized by such virtues:

>> 1) flow isol= ation capability, which protects from other flows'=

>> join/leave, = bursts, or even malicious behaviours

>> 2) scalabili= ty due to its stateless nature

>> 3) flexibili= ty from network asymmetry such as link capacity variations=

>> and uneven p= ropagation delays

>> 4) simple ad= mission criteria, which allows incremental flow acceptance,

>> without modi= fying existing network setup

>> 5) small ave= rage delay due to work conserving nature,

>> just to ment= ion a few. :-)

>>=C2=A0=

>> Best regards= ,

>> Jinoo (on be= half of authors)

>>=C2=A0=

>>=C2=A0=

>>=C2=A0=

>> On Fri, Dec = 12, 2025 at 12:10=E2=80=AFAM Mike Blanche <mik= e-ietf@blanche.org>

>> wrote:

>>=C2=A0=

>>>=C2=A0

>>> Hi all,<= /span>

>>>=C2=A0

>>> This pro= posal appears very similar to ITU-T Recommendation Y.3129, which<= /u>

>>> I believ= e was developed by some of the same authors.

>>>=C2=A0

>>> https://www.itu.int/rec/T-REC-Y.3129-202404-I/en

>>>=C2=A0

>>> The abst= ract text of the I-D is virtually identical to the summary of=

>>> Y.3129. = In addition, significant parts of the content are very similar -<= /u>

>>> e.g. par= ts of section 6.3 of the draft are word-for-word the same as parts

>>> of secti= on 8 of the ITU-T Recommendation.

>>>=C2=A0

>>> The ITU-= T Recommendation is missing from the draft's References section.=

>>>=C2=A0

>>> I am unc= lear why we are considering duplicating work that appears to be

>>> already = completed at the ITU.

>>>=C2=A0

>>> Best reg= ards,

>>>=C2=A0

>>> Mike

>>>=C2=A0

>>> On Fri, = 5 Dec 2025 at 15:49, Janos Farkas <Janos.Farkas=3D<= /p>

>>> 40ericss= on.com@dmarc.ietf.org> wrote:

>>>=C2=A0

>>>> Hi,<= /span>

>>>>=C2= =A0

>>>>=C2= =A0

>>>>=C2= =A0

>>>> This= email begins a 4-week adoption poll for:

>>>>=C2= =A0

>>>>=C2= =A0

>>>>=C2= =A0

>>>>=C2= =A0

>>>> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/= 05/

>>>>=C2= =A0

>>>>=C2= =A0

>>>>=C2= =A0

>>>> No I= PR has been disclosed for this document.

>>>>=C2= =A0

>>>>=C2= =A0

>>>>=C2= =A0

>>>> Plea= se voice your support or technical objections to adoption on the<= /u>

>>>>=C2= =A0

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

>>>>=C2= =A0

>>>>=C2= =A0

>>>>=C2= =A0

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

>>>>=C2= =A0

>>>> of t= he documents discussed at IETF 124:

>>>>=C2= =A0

>>>>=C2= =A0

>>>>=C2= =A0

>>>>=C2= =A0

>>>> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/= 05

>>>>=C2= =A0

>>>>=C2= =A0

>>>> https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwardin= g/18

>>>>=C2= =A0

>>>>=C2= =A0

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

>>>>=C2= =A0

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

>>>>=C2= =A0

>>>> https://datatracker.ietf.org/doc/draft-eckert-detnet-glbf/06<= /u>

>>>>=C2= =A0

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

>>>>=C2= =A0

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

>>>>=C2= =A0

>>>>=C2= =A0

>>>>=C2= =A0

>>>> Than= k you,

>>>>=C2= =A0

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

>>>>=C2= =A0

>>>>=C2= =A0

>>>> ____= ___________________________________________

>>>> detn= et mailing list -- detnet@ietf.org

>>>> To u= nsubscribe send an email to detnet-leave@iet= f.org

>>>>=C2= =A0

>>> ________= _______________________________________

>>> detnet m= ailing list -- detnet@ietf.org

>>> To unsub= scribe send an email to detnet-leave@iet= f.org

>>>=C2=A0

>>=C2=A0=

=C2=A0<= u>

_______________________________________________
detnet mailing list -- detnet@ietf.org
To unsubscribe send an email to detnet-leave@ietf.org

_______________________________________________
detnet mailing list -- detnet@ietf.org
To unsubscribe send an email to detnet-leave@ietf.org
--000000000000e2cf0d064c294594--