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 432AFBA5CD04 for ; Fri, 20 Feb 2026 03:10: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=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 h9St6DkWkdDm for ; Fri, 20 Feb 2026 03:10:53 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 AD101BA5CCFA for ; Fri, 20 Feb 2026 03:10:52 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-59e4a04f059so2634705e87.2 for ; Fri, 20 Feb 2026 03:10:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771585846; cv=none; d=google.com; s=arc-20240605; b=lDY9Kg1u/nNUhwnJQEdlXbrcf9AxBh+SOqVi7kbsALrdccunhzKRsV94ZBS3mblGl3 ZJFJKgibQv9s/PI7cGhOnGeDpD9cgOHVGCyzKzQTxdxNcBQw+VEyWuOZmQvrJIzDeJoP of54iwzdUv8n08aDmtYNcdSrPJwEr3UcMripoWMRQzhKaTsgzikx+VG+eGC0V6XvoIUl I1CA9tA5RAw5nuQ2nEd4iC2MSZR4rEGI63NnFqMHY/+BbytPEw6jP5qM0emB01fNEO7t rCIbMfxRKE1ft77vL3XWn7V8qWWjb/pxb+64S3uU3uiscANsEDCiUPjdbvKrzqTBRMwr 2p6A== 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=97/NGLr3368+hheMZexPZx4gT3ms+iNQBaBvvmNNo+Y=; fh=UKUWmBs7BYGM5B69d5RN6r/X9cZqgBytcwnAShwxudo=; b=HXiokN+GkbjwPpvKQSINotPTIECFBT/VM4MsdPZ4hH0uKNkvklYaOTnjXVXr4lDN/Z L4tSNoBCmFolsJ8jdAW2hQZlgQYVvBfV3JFQOxF+e8AtO4FgSqze3miDAu0JwxtHpJcF 3kfW1Vh/QSpPsn/qtVcb7PXiI4NfIQlbo7x/5NpV10yZE1Yr97kKomlG0oAGotsBOahy RJNZtw0bI7kPUUl67r1XqR+LBTXG/aFB4b3ArCLnAKQTgJUO7w8DoMjWPpeGDehn4AWM GRdB00j50QZLSac9EZVq12+6Se7YSLAY12k0Znn8YiH5avjQgQ+I5O2SoLWqM7+uizGv PoDA==; 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=1771585846; x=1772190646; 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=97/NGLr3368+hheMZexPZx4gT3ms+iNQBaBvvmNNo+Y=; b=gHReW5LO8Jdw4SYIWRdhzh2uGuMYAIHeXtHUpcFDT+jiEQwl1BY8t0hzfLU8jZwueb gxk9mmoZgeuZkz56d3Umk6Tw1Ig0ijUahMh5klQG+PC9OACR45kyz9TdmBu6KbzHTtwA PNXjNJlBeoZjpFmPj4V1Edygq9/KJ38yWZ8B5SOM7rX0bpRWmeNg4kj6qEUIvvla0ilE ONQ8d6emR8bCkJ5AnJNUz76ZcTYeqzODin+QmoYfh9eurEy8pQrNe6CX2r91EdE31BkM hSO55nWUlxr+VuI2ftR8EnkxMNnNtOoVUggmRTOCg+Ek4YJx0XMN3rN2p8g5YCCpxCip 2xuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771585846; x=1772190646; 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=97/NGLr3368+hheMZexPZx4gT3ms+iNQBaBvvmNNo+Y=; b=mIYDS1zXCCYpPAyfMnE3gtesgtBCrbkwGMkb/Y4dFTqxSM+s3CWfj87AREq6d5ozUN fFQ7PmO3JE8GXNJjwj66Njazzx44cQKPaM7miiVfSNsPGiJb0KZzRnI2aCY0H4tu1ee/ 9ZieP72j2NvpH0RkoA8Wh4HnHe6wSdZEphxbaP7VSyiHsoUS9VpRybrh1mkz0sqdY8k2 Qvkaoyb5L0/Pv0DbpzIUI38issoAdeY1A7tM6r4tzY/3WmGe+ZTBpzkXwRjF1Z/SRi6h PdBQIvc5vfxM4U/ML8cg0jqHVK/ed0RXdqtXqIONU5YYdsHFCIeY720t++JItwzpmfzF D3fg== X-Forwarded-Encrypted: i=1; AJvYcCWtHG0QbTtiyf4JaodRrd13c3AapR0gWXR8Y0CCvOuvM7OV91EQ8WgxvlTejSULUfezOqFhzgA=@ietf.org X-Gm-Message-State: AOJu0YwpPeoUElr+tpZX0ow/S+Bhey4FpbijBMVPbAiHU9sRNaIFnRx8 e24a8BnBgCXI2AxPJJcr9Jkpb7QOjktc80jhs03FXYJGAAh7xEQ9YdOpwnil2bfm6b0Gvpuva6e 78a2udtDQ6e8zd3+PA5Oikc4jyhCsLL5W3gPemHN5TxV2tFiDoHWu4CY= X-Gm-Gg: AZuq6aKTOo/S9RI438tS/bBE7hFB8WcTr2K0erOFGrsqvsDep06l5/EMiE28gvvpmN2 +Chbic5WTrV4rGF1b7r1INTXXPVMdPHrdcY4gcv+CDCgdvBmgNKxwVIPYCZLd1483/ydzjSdOH0 fXEwB2k9F8NYWv3geN2HraZzOOcwJY313TIq3xd/qdyAzPmRiSoawjqh540rkjoFS1ocYLzAiXa 4Y0IqCTrKhisrLXsbRQfbhkcwrVh1ojcpNTxKPnDwWI3BItZn8VIMR5+thJ4I4txL5Z/6ugGzeB 77mZ45aKQMreoihkn7i0 X-Received: by 2002:ac2:4bd5:0:b0:595:9d6b:1178 with SMTP id 2adb3069b0e04-59f6d37d4bamr5847504e87.40.1771585845459; Fri, 20 Feb 2026 03:10:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jinoo Joung Date: Fri, 20 Feb 2026 20:10:34 +0900 X-Gm-Features: AaiRm51QZkDWf5EB3LREX38xp6fxR4SNJft6ZqAg5jFido77tBRwwF0HdQlSps8 Message-ID: To: Janos Farkas Content-Type: multipart/alternative; boundary="000000000000020ae5064b3f790c" Message-ID-Hash: 2IYMIKR7CFKKCNMAKYI44EIRYOCWGBAT X-Message-ID-Hash: 2IYMIKR7CFKKCNMAKYI44EIRYOCWGBAT 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: Scott Mansfield , "detnet@ietf.org" 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: --000000000000020ae5064b3f790c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Chairs, Scott, and WG, Please note that draft-joung-detnet-stateless-fair-queuing is revised and 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 schedulers. 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-queuing/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-joung-detnet-stateless-fair-que= uing-07 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=3Ddraft-joung-detnet-stateless-fa= ir-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 loo= k. > > 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 queuin= g > 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 important > to note a few guidelines. Following this discussion, I observe there is > concern that there is work being duplicated. In order to make all partie= s > 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 wha= t > the ITU-T has already done. If there are modifications to the ITU-T work > needed, I would like to see the authors plans to progress that work in th= e > 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 lon= g > 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 an= d > 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 proceeds > in IETF, no changes will be introduced. The ITU-T works will be reference= d > as well. > > > > - If there is anything being added in the IETF that requires a fundamenta= l > 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 etc.) 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 coordinate= d > too. If the ITU-T work missed something, or is not appropriate for the > IETF use-case, again, coordination is needed. Since (at least) some of t= he > authors are the same in both groups, this is the best way to gain consens= us > 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 ca= n > 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 participants > 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 standards= . > > > > 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 an > > 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 the > > > agreed taxonomy, I am still concerned about duplicating work already do= ne > > > 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 inconsisten= t > or > > > incompatible implementations depending on which document implementers > > > follow. > > > > > > I see the new draft (-06) focuses more on the necessary metadata. This > is > > > also already documented in ITU-T Y.3148, which covers metadata creation > 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 o= r > > > 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 o= f > 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 variations > > >> and uneven propagation delays > > >> 4) simple admission criteria, which allows incremental flow acceptance= , > > >> 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 of > > >>> Y.3129. In addition, significant parts of the content are very simila= r > - > > >>> 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-queuin= g/05/ > > >>>> > > >>>> > > >>>> > > >>>> 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 > > >>>> > > >>> _______________________________________________ > > >>> 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 > > --000000000000020ae5064b3f790c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Chairs, Scott, and WG,

Please not= e that=C2=A0draft-joung-detnet-stateless-fair-queuing is revised and upload= ed as 07.
In line with Scott's suggestions, the new version i= ncludes:
1) Abbreviations
2) New references includ= ing RFC8200, MPLS-related IETF drafts, and two ITU-T Recommendations.
=
3) Minimized 6.1. Framework and other content that are duplicative wit= h ITU-T Recommendations. Only those that are essential=C2=A0to understand t= he 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

In 6.3.1 and 6.3.2, the methods for carrying metada= ta with IPv6 and MPLS MNA Sub-stack are described in detail.
6.3.= 3 delineates two distinct admission control methodologies, providing for th= e selection of either procedure based on specific implementation requiremen= ts.
Section 7. Approximate C-SCORE specifies the nodal architectu= re and algorithms to approximate C-SCORE with rotating strict priority sche= dulers.
The E2E latency bound, in a complete math expression, is = also given.
This approximation serves to alleviate the sorting bo= ttleneck intrinsic to C-SCORE,=C2=A0
bypassing the intensive prio= rity queue operations while maintaining near-optimal alignment with theoret= ical 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.

=C2=A0 =C2=A0T= itle:=C2=A0 =C2=A0Latency Guarantee with Stateless Fair Queuing
=C2=A0 = =C2=A0Authors: Jinoo Joung
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jeo= ng-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-jou= ng-detnet-stateless-fair-queuing-07.txt
=C2=A0 =C2=A0Pages:=C2=A0 =C2=A0= 23
=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 conserving
=C2=A0 =C2=A0packet schedulers.=C2=A0 The framework gua= rantees end-to-end (E2E) latency
=C2=A0 =C2=A0bounds to flows.=C2=A0 The= schedulers in core nodes do not need to
=C2=A0 =C2=A0maintain flow stat= es.=C2=A0 Instead, the entrance node of a flow marks an
=C2=A0 =C2=A0ide= al service completion time according to a fluid model, called
=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 queue 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 f= air queuing.=C2=A0 The result is that flows are
=C2=A0 =C2=A0isolated fr= om each other almost perfectly.=C2=A0 The latency bound 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 shari= ng each output
=C2=A0 =C2=A0link with the flow.=C2=A0 Furthermore, this = document specifies an
=C2=A0 =C2=A0approximation of stateless fair queui= ng implemented via a strict
=C2=A0 =C2=A0priority (SP) scheduler.=C2=A0 = This approach maintains a guaranteed end-
=C2=A0 =C2=A0to-end (E2E) late= ncy bound.

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

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

A diff from the previous vers= ion 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, Ja= n 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.<= u>

=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 d= raft. In my opinion, the implementation specific issues in the IETF draft are not appropriate for standardization = in ITU-T.

=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

--000000000000020ae5064b3f790c--