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 DD549CDC9862 for ; Thu, 19 Mar 2026 01:26:52 -0700 (PDT) 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=blanche-org.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 BGqB8dg2x0gw for ; Thu, 19 Mar 2026 01:26:50 -0700 (PDT) Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) (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 30352CDC9845 for ; Thu, 19 Mar 2026 01:26:50 -0700 (PDT) Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-417c34b0509so381067fac.1 for ; Thu, 19 Mar 2026 01:26:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773908809; cv=none; d=google.com; s=arc-20240605; b=RDjDCT8IiJYsabC0gEIFx1oSld+eGoiodkIVBWSWJurE19PQTyP9fHpoONgbzrDPRg vBNzBHUD8f04tcUH0mMr7AocY4Nc6QLgLUJHrhmSDVBCvDTi6hFKw+NpdmtcDHVDextw 9dnyGyLHOoZEEOim72goANJrNHJTj3FyZCU0+Pd9aDrzCC96gy14McycwY8Hypc8KMuq SAxoGeaEA5pNdtBGhyTDPy49MK2yx3Zfgs2z7q2KpIntbQ3QY1HVbBrznkJZnvZFGguS YwwnMTAZg0NTQE44GxYj1s3M+qh8F9QpdARgja0qzHRJzJU+ypeNE3ZBdZEaZlFm3DOs cK9g== 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=2M+ZnnF0qHVzWDKXKWxO2t0HZPqpYxT8DwU3EE0v+5U=; fh=RdbJ5wvmwvNDgkLv3+ZDM/V5F08bU9+GxBgInE6j5Pg=; b=SX/XjK+m8py+NumZzDBty48Ndneol7EGwPo9sNZsJ7LKMvbFv5ArnvU5/aAPgD12AP Rfr2bG3fF0GfzGESz1V75Qf+Lkp8wOoaStRiiNcHG2zoujvLGZSKEuePZodjzmxEgNPX Pbz3KlbvIkNyx/Wh41libcgYD4kjtgvBQ54Y7pLsMP/6yGsRp/ZdgGrwNVrEwDGMbG6L EOOqsCAESlj0iu5mRW5I8RYbaPtrrfyNH3S0DPLeuIFc0pt5SY13Kg5NbuWMzOkz2N8f s4+Isl9bqVD8ee7nkPxPae6WFxB8jTHPxXjpf97Y98yKwrv5aDp5sn55Ef409Kkayy6j Fqkw==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blanche-org.20230601.gappssmtp.com; s=20230601; t=1773908809; x=1774513609; 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=2M+ZnnF0qHVzWDKXKWxO2t0HZPqpYxT8DwU3EE0v+5U=; b=eIh7UVsE7DslNup1vuW2ijVs5Dh9qvGrtJDu8SYQphT3t0Kp5VcYU054Hp9GdJvV8C QLugBQF/Jn809jk52W6sAI5alh2WmqKczyKYD8LNN3DtFXn/E+hmA+lRV+apMruk0OF6 VGO+KV9soM1BmRO69WW5qUy2awAbEtJZ0sTuIfkF9G9iS6E4/J7F3W24hv6ClFBemY2e cXB7VRWYRvuT84X4WxVYSsm4jaWFwlv8WsrgQiDnDWPAxgy77mdXnn8bWdlpOcjt4OL2 z9cYPvt9g5xwfJ7u554afReQWXLi8X6oIa/XE91i2ohHwM4Mii/tWjeuyoqurVT5MqqB kKUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773908809; x=1774513609; 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=2M+ZnnF0qHVzWDKXKWxO2t0HZPqpYxT8DwU3EE0v+5U=; b=Axpy78mMANncUGKisItacchJfRwBdqvBdntZolOx7PIxgD1dP36hE4BsCAk5Li/x0g 6pVtLJaqriOwqk9EFFD9tay423/2GO+JmI2N4E7gkxqIeznF+UMSveUu7L4CpkMb1ASN iLnUc5gtGrbswBZ3AgnylbdkrmTqPMnPIJDLn6SAeqO4FuXWDTJ24ib0Er9lBG4Ap352 cwPpA9b3eDZNNc+uLCNHF+eWpjkwmmXdt+u95F30RnZIzd+VTtv3tJG/zF4borXMySQh eNZLTUjWz1nBFVrS/b6xT5cqpB0w0A+CeLGEJ/jnQMl126ZVpTVys8bhuxUq+PGTuAzY JEMA== X-Forwarded-Encrypted: i=1; AJvYcCUBl0iwxID1wxbLnGxNXLLlWBMabQxrv9jIEf4YD087oY1/rMpaKf6T2vLjW5u3LNgyWN7cBEA=@ietf.org X-Gm-Message-State: AOJu0YxRZhAjAEYWxcOV7Wa08ToNJtkOP/5eKAjO8ihWAXMOoB7QUXaN kOXttCQm6QOwB7R7PcqiW6XKD1UPg9Pb1oj3cFazwaWUh/75RYw8V4qgfklZgvMmr2liya/rBwy /EEXJMc1W9tkVFf/QHtqrs0mwtv8WjJlQxBCwIKhc/Q== X-Gm-Gg: ATEYQzy6h/2jXHDQ8nBFztpTA+uwVtLkUEmbBhbWijsr3MFEPMrxXLdPuc8ZyblBCzL IgmlKY+kT4Ys0HsgZzNHmkICP0HUE5A0eG4jPaJLz1YO+0DEgQEOHuYEr/U02CpaG6lM+4sXjil jqwgZgiySp/ffr3ojw1x05UVFp7Sb5b62Q4vVWnyX3J+ta9eb39foWhTuimzsiFLbi/R96pPMpt 3L95tHW9yMx7TC9nS/bx+kbzTe+TuPxrUsctqf0VzQrGajoDageaxuga9YhsjFpK3YdQ7PrVVmH ofqbXnhYH/Fews5j5CBXcP51DH5JJ8/aFvRBXoZ57XZEnXw= X-Received: by 2002:a05:6820:4b98:b0:67b:c368:1352 with SMTP id 006d021491bc7-67c0dafa52fmr4625956eaf.33.1773908809149; Thu, 19 Mar 2026 01:26:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mike Blanche Date: Thu, 19 Mar 2026 08:26:11 +0000 X-Gm-Features: AaiRm53ejhnlLvwL167rfB5TEkfs9PVFrsuvsSnpawRRNOamxpr5uzI4Lc5RMo4 Message-ID: To: Jinoo Joung Content-Type: multipart/alternative; boundary="0000000000006efe13064d5c54b0" Message-ID-Hash: DQZ3EZ4LBKQAQCN77GHWIL5ZUK3ZO6H2 X-Message-ID-Hash: DQZ3EZ4LBKQAQCN77GHWIL5ZUK3ZO6H2 X-MailFrom: mike@blanche.org 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: --0000000000006efe13064d5c54b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jinoo and all, Thanks for the session at 125 just now... to confirm your mail above, that the next version will be removing duplication with the ITU standards and focussing on the new material, that would be great, thank you. On the metadata, I understand the proposal is to revise the two ITU Recommendations (Y.3129 and Y.3148) to refer to two metadata fields rather than three, which would then be consistent with what you propose to include in this I-D. This ensures consistency between the standards, which I support. Two questions on this: a) Do you have a timescale for initiating the ITU revisions? b) Are you aware of any implementations based on the existing ITU standards= ? Many thanks, Mike On Sun, 8 Mar 2026 at 10:18, Jinoo Joung wrote: > Hello Mike, thanks for the comments. > I fully understand your concerns. > > Here is our plan. > > Any duplicate parts will be removed. > Only a couple of sentences, regarding the philosophy of the stateless fai= r > queuing, will remain in 6.1 Framework. > Without the consideration for readers' ease of understanding, we will jus= t > refer to the ITU-T standards. > The readers should open up the ITU-T standards for complete understanding > of the technology. > > However, the metadata enhancement (two instead of three) will be stated, > as an option, with clearly stating that this is a deviation from ITU-T > standards. > Of course, the original three metadata can be also carried by default. > > If this plan suits your requirements, please let me know. > We will gladly revise accordingly. > > Best regards, > Jinoo (on behalf of authors) > > > On Sun, Mar 8, 2026 at 6:14=E2=80=AFPM Mike Blanche wrote: > >> >> Hi Jinoo and authors, >> >> Thanks for the reply - comments inline: >> >> On Wed, 4 Mar 2026 at 02:06, Jinoo Joung wrote: >> >>> 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, th= e >>>> 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 o= f >>>> ITU-T Y.3129, although it still appears to include specifications alre= ady >>>> defined in Y.3129, e.g. >>>> section 4 of this I-D: "Instead of deriving a new FT at each core node= , >>>> we will specify a method of deriving the FT at downstream nodes by usi= ng >>>> 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. >>> >> >> Mike: I think it is fine to briefly restate the broad principles of the >> already standardised approach as an introduction, but the majority of th= e >> text in this I-D repeats or summarizes Y.3129, rather than referring to = it. >> >> >>> 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. >>> >> >> Mike: it is better to refer to Y.3129 than to copy it word for word. Wha= t >> happens if Y.3129 is updated or corrected? >> >> >>> 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. >>> >> >> Mike: do you mean that Y.3129 will be updated to include the clock >> discrepancy adjustment? Or that this draft will be changed to match Y.31= 29? >> This I-D should be consistent with the already published standards. >> >> >>> 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= and >>>> 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. >>> >> >> Mike: The ITU-T metadata standard specifies three pieces of metadata. >> This is the published standard. Having the I-D use (possibly) two pieces= of >> metadata conflicts with the standard. If the approach in Y.3129 and Y.31= 48 >> is now considered inefficient, then these standards should be updated. >> (Although, I don't know where that leaves someone who has implemented a >> standards-compliant implementation of either of those Recommendations). >> >> >>> 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 metad= ata >>>> 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. >>> >> >> Mike: They are word for word identical (apart from the discrepancies >> regarding the number of pieces of metadata carried). Why are we not >> referring to the existing standard? >> >> >> >> My overall issue is... imagine I'm trying to build a standards-compliant >> implementation. I am reading two ITU standards, and one IETF standard, b= ut >> they differ, or are described differently. Which do I follow? >> >> Two ITU standards already explain the overall approach. The new work in >> this I-D should specify the IPv6 and MPLS formatting for the metadata >> defined in Y.3129 and Y.3148. >> >> Thanks, >> >> Mike >> >> >> >> >>> >>>> If I have misunderstood any of the above please let me know, it's >>>> entirely 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 = risk >>>> of introducing confusion. >>>> >>>> The abstract and introduction should also be updated to reflect what i= s >>>> "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 >>>>> that 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 >>>>> 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 tw= o >>>>> ITU-T Recommendations. >>>>> >>>>> 3) Minimized 6.1. Framework and other content that are duplicative >>>>> with ITU-T Recommendations. Only those that are essential to understa= nd 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 sched= ulers. >>>>> >>>>> 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 no= w >>>>> 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 procedur= e >>>>> 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 subsequen= t >>>>> 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 t= he >>>>> 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 capacitie= s >>>>> and the maximum packet length among other flows sharing each outpu= t >>>>> 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-qu= euing/ >>>>> >>>>> There is also an HTMLized version available at: >>>>> >>>>> https://datatracker.ietf.org/doc/html/draft-joung-detnet-stateless-fa= ir-queuing-07 >>>>> >>>>> A diff from the previous version is available at: >>>>> >>>>> https://author-tools.ietf.org/iddiff?url2=3Ddraft-joung-detnet-statel= ess-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 < >>>>> Janos.Farkas@ericsson.com> 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 deploymen= t, >>>>> 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 >>>>> important to note a few guidelines. Following this discussion, I obs= erve >>>>> there is concern that there is work being duplicated. In order to ma= ke all >>>>> parties comfortable I would suggest the following: >>>>> >>>>> >>>>> >>>>> Potential Action: >>>>> >>>>> The process of =E2=80=9Cgap analysis=E2=80=9D is used a lot in the IT= U-T to ensure new >>>>> work items do not duplicate work already done by the industry recogni= zed >>>>> 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= what >>>>> 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 i= n the >>>>> 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 modif= y 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 usin= g and >>>>> 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 proc= eeds >>>>> in IETF, no changes will be introduced. The ITU-T works will be refer= enced >>>>> 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= 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 >>>>> coordinated too. If the ITU-T work missed something, or is not appro= priate >>>>> for the IETF use-case, again, coordination is needed. Since (at leas= t) >>>>> 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. Liaiso= n can >>>>> be used, but they tend to be slow. The IETF DetNet mailing list is t= he >>>>> proper place to have this discussion especially if there are particip= ants >>>>> in this working group that need clarity to ensure work is not duplica= ted. >>>>> >>>>> >>>>> >>>>> 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 sectio= n, >>>>> >>>>> 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 a= t >>>>> 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 alread= y >>>>> 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 implemente= rs >>>>> >>>>> > 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 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/dat= a >>>>> 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 fai= r >>>>> >>>>> >> 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 < >>>>> mike-ietf@blanche.org> >>>>> >>>>> >> 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 summar= y >>>>> of >>>>> >>>>> >>> 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-qu= euing/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 adoptio= n >>>>> calls >>>>> >>>>> >>>> >>>>> >>>>> >>>> of the documents discussed at IETF 124: >>>>> >>>>> >>>> >>>>> >>>>> >>>> >>>>> >>>>> >>>> >>>>> >>>>> >>>> >>>>> >>>>> >>>> >>>>> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-qu= euing/05 >>>>> >>>>> >>>> >>>>> >>>>> >>>> >>>>> >>>>> >>>> >>>>> https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-for= warding/18 >>>>> >>>>> >>>> >>>>> >>>>> >>>> >>>>> >>>>> >>>> >>>>> https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-me= chanism/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 >>>>> >>>> --0000000000006efe13064d5c54b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Jinoo and all,

=
Thanks for the session at 125 just now... to confirm your mail above, = that the next version will be removing duplication with the ITU standards a= nd focussing on the new material, that would be great, thank you.

On the metadata, I understand the proposal is to revise the= two ITU Recommendations (Y.3129 and Y.3148) to refer to two metadata field= s rather than three, which would then be consistent with what you propose t= o include in this I-D. This ensures consistency between the standards, whic= h I support.

Two questions on this:
a) D= o you have a timescale for initiating the ITU revisions?
b) Are y= ou aware of any implementations based on the existing ITU standards?
<= div>
Many thanks,

Mike
On Sun, 8 Mar 2026 at 10:18, Jinoo Joung <jjoung@smu.ac.kr> wrote:
Hello Mike, thanks f= or the comments.
I fully understand your concerns.

=
Here is our plan.

Any duplicate parts wi= ll be removed.
Only a couple of sentences, regarding the philosop= hy of the stateless fair queuing, will remain in 6.1 Framework.
=
Without the consideration for readers' ease of understanding, we w= ill just refer to the ITU-T standards.
The readers should open up= the ITU-T standards for complete understanding of the technology.

However, the metadata enhancement (two instead of three) w= ill be stated, as an option, with clearly stating that this is a deviation = from ITU-T standards.
Of=C2=A0course, the original three metadata= can be also carried by default.=C2=A0

If this pla= n suits your requirements, please let me know.
We will gladly rev= ise accordingly.

Best regards,
Jinoo (on= behalf=C2=A0of authors)


On Sun, Mar 8, 2026 at 6:14=E2= =80=AFPM Mike Blanche <mike-ietf@blanche.org> wrote:

Hi Jinoo and authors,

Thanks for the reply - comments inline:

On Wed, 4 Mar 2026 at 02:06, = Jinoo Joung <jjoun= g@smu.ac.kr> wrote:
Hello Mike, for your careful c= onsideration 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 authors)

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

Hi Jinoo, authors, and the = WG,

Thank you Jinoo and the authors for updating t= his 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 l= abel format), 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 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 alr= eady defined in Y.3129, e.g.
section 4 of this I-D: "Instead= of deriving a new FT at each core node, we will specify a method of derivi= ng the FT at downstream nodes by using the initial FT calculated at the ent= rance node."
section 6 of Y.3129: "This Recommendation = presents requirements and a framework for generation and update of FT...&qu= ot;

JJ: To provide necessary co= ntext for the reader, this draft retains the core principles of Y.3129.

Mike: I think it is fine to = briefly restate the broad principles of the already standardised approach a= s an introduction, but the majority of the text in this I-D repeats or summ= arizes Y.3129, rather than referring to it.
=C2=A0
Section 6.1 has five requirements but Y.3129 has nine.

JJ: Right. But the context of the requiremen= ts remains identical. For example, the first two requirements in Y.3129 sta= tes:=C2=A0

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 denote= s the entrance node of the flow under observation.
F0(p) =3D max{F0= (p-1), A0(p)}+L(p)/r.=C2=A0

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

Mike:= it is better to refer to Y.3129 than to copy it word for word. What happen= s if Y.3129 is updated or corrected?
=C2=A0
= The equations in section 6.2 include clock discrepancy adjustment which app= ears absent from the equivalent equations in section 8.2 of Y.3129.

JJ: We will add the equation in the fu= ture version.=C2=A0
However, this version has been refined for br= evity, retaining only the critical elements necessary.

Mike: do you mean that Y.3129 will be updated= to include the clock discrepancy adjustment? Or that this draft will be ch= anged to match Y.3129? This I-D should be consistent with the already publi= shed standards.
=C2=A0
The metadata proposa= l appears to conflict with the ITU Recommendations. The I-D suggests two pi= eces of metadata to be carried,=C2=A0Fh(p) and L/r. However Y.3129 and Y.31= 48 refers to three pieces of metadata, Fh(p), L and r.

JJ: What is required to fulfill the requirements an= d framework is the metadata L/r. Making two (L and r) to one (L/r) can be s= een as an improvement.=C2=A0
However, if necessary we will specif= y both cases in the draft.=C2=A0

Mike: The ITU-T metadata standard specifies three pieces of metadat= a. This is the published standard. Having the I-D use (possibly) two pieces= of metadata conflicts with the standard. If the approach in Y.3129 and Y.3= 148 is now considered inefficient, then these standards should be updated. = (Although, I don't know where that leaves someone who has implemented a= standards-compliant implementation of either of those Recommendations).
=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

Mike: They are word for word = identical (apart from the discrepancies regarding the number of pieces of m= etadata carried). Why are we not referring to the existing standard?
<= div>


My overall issue is... ima= gine I'm trying to build a standards-compliant implementation. I am rea= ding two ITU standards, and one IETF standard, but they differ, or are desc= ribed differently. Which do I follow?=C2=A0

Two IT= U standards already explain the overall approach. The new work in this I-D = should specify the IPv6 and MPLS formatting for the metadata defined in Y.3= 129 and Y.3148.

Thanks,

M= ike


=C2=A0
<= br>
If I have misunderstood any of the above please let me know, = it's entirely possible.

We must ensure the wor= k aligns with existing standards. If we refer to those standards we should = not seek to recreate them in our drafts for risk of introducing confusion.<= /div>

The abstract and introduction should also be updat= ed 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@dma= rc.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
--0000000000006efe13064d5c54b0--