[Detnet] Re: WG adoption poll: joung-detnet-stateless-fair-queuing-05

[Jinoo Joung <[e-mail]>]

Hello WG and Mike,

Please find attached the revised C-SCORE draft with Diff file.
This revision includes
- Clear declarations that this draft is based on ITU-T standards, in
Abstract, 1. Introduction, and everywhere.
- Removal of unnecessary contents, which were duplicative with ITU-T
standards
- Shortened 5. Framework section, which summarizes the ITU-T standards
- Metadata that is now aligned with ITU-T (now they are three: FT, L, r)
- Header formats that accommodate three metadata
- Normative references (ITU-T standards)

For Mike's questions:
a) Do you have a timescale for initiating the ITU revisions?
--> The number of metadata is now three. They exactly align with ITU-T
standards. No revision is necessary.
b) Are you aware of any implementations based on the existing ITU standards?
--> In collaboration with ETRI and the Korean vendor Woorinet, we are
currently implementing C-SCORE within a 32T Packet Optical Transport
Network (POTN) system. We are not sure about the other activities.

Best regards,
Jinoo

On Thu, Mar 19, 2026 at 5:26 PM Mike Blanche <[e-mail]> wrote:

>
> 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 <[e-mail]> 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
>> fair queuing, will remain in 6.1 Framework.
>> Without the consideration for readers' ease of understanding, we will
>> 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) 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 PM Mike Blanche <[e-mail]>
>> wrote:
>>
>>>
>>> Hi Jinoo and authors,
>>>
>>> Thanks for the reply - comments inline:
>>>
>>> On Wed, 4 Mar 2026 at 02:06, Jinoo Joung <[e-mail]> 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 PM Mike Blanche <[e-mail]>
>>>> wrote:
>>>>
>>>>>
>>>>> Hi Jinoo, authors, and the WG,
>>>>>
>>>>> Thank you Jinoo and the authors for updating this draft.
>>>>>
>>>>> I think the "meat" of what is new in the proposal is in 6.3.2.1 (IPv6
>>>>> header format) and 6.3.2.2 (MPLS label format), and possibly 6.3.3, the
>>>>> admission procedure.
>>>>>
>>>>  JJ: Right, and Section 7 (Approximate C-SCORE) too.
>>>>
>>>>>
>>>>> Most of the other content appears to summarize or restate what is in
>>>>> ITU-T Y.3129 and Y.3148, albeit with discrepancies.
>>>>>
>>>>> For example Section 4 appears to be a condensed version of section 6
>>>>> of ITU-T Y.3129, although it still appears to include specifications
>>>>> already defined in Y.3129, e.g.
>>>>> section 4 of this I-D: "Instead of deriving a new FT at each core
>>>>> node, we will specify a method of deriving the FT at downstream nodes by
>>>>> using the initial FT calculated at the entrance node."
>>>>> section 6 of Y.3129: "This Recommendation presents requirements and a
>>>>> framework for generation and update of FT..."
>>>>>
>>>>
>>>> JJ: To provide necessary context for the reader, this draft retains the
>>>> core principles of Y.3129.
>>>>
>>>
>>> Mike: I think it is fine to briefly restate the broad principles of the
>>> already standardised approach as an introduction, but the majority of the
>>> 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) = 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.
>>> What 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.3129?
>>> 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.3148
>>> 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 metadata
>>>>> whereas Y.3129 suggests three.
>>>>>
>>>>> Section 6.3.5 similarly to Y.3129 section 8.5.
>>>>>
>>>>> Section 6.3.6 similarly to Y.3129 section 8.6.
>>>>>
>>>>
>>>> JJ: Right. These are the critical elements and the summarized texts.
>>>>
>>>
>>> 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, but
>>> 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
>>>>> is "new" in this proposal.
>>>>>
>>>>
>>>> JJ: OK. We will update them as suggested.
>>>>
>>>>
>>>>>
>>>>> Thank you all for your continued efforts here.
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, 27 Feb 2026 at 14:28, Janos Farkas <Janos.Farkas=
>>>>> [e-mail]> 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 <[e-mail]>
>>>>>> *Sent:* Friday, February 20, 2026 12:11 PM
>>>>>> *To:* Janos Farkas <[e-mail]>
>>>>>> *Cc:* Scott Mansfield <scott.mansfield=[e-mail]>;
>>>>>> [e-mail]
>>>>>> *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
>>>>>> 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)
>>>>>>
>>>>>>
>>>>>>
>>>>>> ====================================
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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-queuing-07
>>>>>>
>>>>>> A diff from the previous version is available at:
>>>>>>
>>>>>> https://author-tools.ietf.org/iddiff?url2=draft-joung-detnet-stateless-fair-queuing-07
>>>>>>
>>>>>> Internet-Drafts are also available by rsync at:
>>>>>> rsync.ietf.org::internet-drafts
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 23, 2026 at 10:52 PM Janos Farkas <
>>>>>> [e-mail]> 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 <[e-mail]>
>>>>>> *Sent:* Tuesday, January 20, 2026 4:23 PM
>>>>>> *To:* Scott Mansfield <scott.mansfield=[e-mail]>
>>>>>> *Cc:* [e-mail]
>>>>>> *Subject:* [Detnet] Re: WG adoption poll:
>>>>>> joung-detnet-stateless-fair-queuing-05
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hello Scott,
>>>>>>
>>>>>> Thanks for your valuable suggestions.
>>>>>> I deeply appreciate your efforts to resolve this issue in a fair and
>>>>>> reasonable manner.
>>>>>> I agree with your proposed action.
>>>>>>
>>>>>> I have answered your guidelines in-line marked with JJ. Please take a
>>>>>> look.
>>>>>>
>>>>>> In short, there is a clear gap between the ITU-T work and the IETF
>>>>>> document.
>>>>>> While ITU-T work focuses on the requirements and framework, the IETF
>>>>>> document will elaborate on IP/MPLS specific information for deployment,
>>>>>> including header fields and formats, protocols for admission control and
>>>>>> time-difference compensation.
>>>>>> It will also include implementation details for approximating fair
>>>>>> queuing with a strict priority scheduler.
>>>>>>
>>>>>> Many thanks and best regards,
>>>>>> Jinoo
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 20, 2026 at 6:11 AM Scott Mansfield <scott.mansfield=
>>>>>> [e-mail]> 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
>>>>>> parties comfortable I would suggest the following:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Potential Action:
>>>>>>
>>>>>> The process of “gap analysis” 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 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 in 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 modify the
>>>>>> ITU-T work. It serves as a solid foundation for the IETF draft. In my
>>>>>> opinion, the implementation specific issues in the IETF draft are not
>>>>>> appropriate for standardization in ITU-T.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Guidelines To Note:
>>>>>> - It is appropriate for the IETF to take ITU-T work and augment it as
>>>>>> long as the augmentation is in the scope and mandate of IETF.  Also, the
>>>>>> work should not fundamentally change (or be backwards incompatible).  It is
>>>>>> imperative that the IETF document be clear what ITU-T work it is using 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 proceeds
>>>>>> in IETF, no changes will be introduced. The ITU-T works will be referenced
>>>>>> 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 appropriate
>>>>>> for the IETF use-case, again, coordination is needed.  Since (at least)
>>>>>> some of the authors are the same in both groups, this is the best way to
>>>>>> gain consensus by ensuring the process of each group is followed.
>>>>>>
>>>>>>
>>>>>>
>>>>>> JJ: I definitely agree with you.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I find coordination and cooperation is best handled when people work
>>>>>> together and have people that attend each organization and follow the
>>>>>> processes of the organization when progressing the documents.  Liaison can
>>>>>> 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 <[e-mail]> Fri, 02 January 2026 22:16 UTCShow
>>>>>> header
>>>>>> <https://mailarchive.ietf.org/arch/msg/detnet/Ea4920SPZmgxU-0npKrss00EI7Y/>
>>>>>>
>>>>>> 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 AM Mike Blanche <[e-mail]>
>>>>>> 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 done
>>>>>>
>>>>>> > elsewhere.
>>>>>>
>>>>>> >
>>>>>>
>>>>>> > What happens if the IETF draft diverges from the ITU Recommendation?
>>>>>>
>>>>>> > Y.3129 makes 9 "requirements", whereas the current draft has 5
>>>>>> requirements
>>>>>>
>>>>>> > and 3 conditions. There is already one discrepancy between the two
>>>>>>
>>>>>> > documents in the description of the maths. This may lead to
>>>>>> inconsistent or
>>>>>>
>>>>>> > incompatible implementations depending on which document
>>>>>> implementers
>>>>>>
>>>>>> > follow.
>>>>>>
>>>>>> >
>>>>>>
>>>>>> > I see the new draft  (-06) focuses more on the necessary metadata.
>>>>>> 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 <[e-mail]> wrote:
>>>>>>
>>>>>> >
>>>>>>
>>>>>> >>
>>>>>>
>>>>>> >> Hello Mike, thanks for the comment regarding the work in ITU-T.
>>>>>>
>>>>>> >> I understand your concern.
>>>>>>
>>>>>> >>
>>>>>>
>>>>>> >> Hello WG and Mike,
>>>>>>
>>>>>> >>
>>>>>>
>>>>>> >> The C-SCORE draft, as indicated in the version 6, will have the
>>>>>> following
>>>>>>
>>>>>> >> details in the future, once accepted as the WG draft.
>>>>>>
>>>>>> >> 1) MPLS and IP specific protocol details: This includes the header
>>>>>>
>>>>>> >> fields/formats, interactions between nodes and between
>>>>>> control/data planes.
>>>>>>
>>>>>> >> 2) Implementation issues regarding the priority queue, which is
>>>>>> currently
>>>>>>
>>>>>> >> required to sort the packets in FT orders: This includes an
>>>>>> approximation
>>>>>>
>>>>>> >> technique based on strict priority schedulers.
>>>>>>
>>>>>> >>
>>>>>>
>>>>>> >> Y.3129 is focused on the requirements and provides theoretical
>>>>>>
>>>>>> >> justifications but the C-SCORE draft targets on the solution.
>>>>>>
>>>>>> >> Some framework texts are covered in both. But they are necessary
>>>>>>
>>>>>> >> information for readers in order to understand the design
>>>>>> principles of the
>>>>>>
>>>>>> >> solution in the C-SCORE draft.
>>>>>>
>>>>>> >>
>>>>>>
>>>>>> >> C-SCORE is not a new invention.
>>>>>>
>>>>>> >> It is an outcome of the numerous researches conducted during late
>>>>>> '90 ~
>>>>>>
>>>>>> >> early '00s, which was the peak period of Internet research.
>>>>>>
>>>>>> >> There are more than hundreds of papers that are related to the fair
>>>>>>
>>>>>> >> queuing, after all.
>>>>>>
>>>>>> >>
>>>>>>
>>>>>> >> I believe it is worth being standardized by such virtues:
>>>>>>
>>>>>> >> 1) flow isolation capability, which protects from other flows'
>>>>>>
>>>>>> >> join/leave, bursts, or even malicious behaviours
>>>>>>
>>>>>> >> 2) scalability due to its stateless nature
>>>>>>
>>>>>> >> 3) flexibility from network asymmetry such as link capacity
>>>>>> 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 AM Mike Blanche <
>>>>>> [e-mail]>
>>>>>>
>>>>>> >> 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
>>>>>> 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 <Janos.Farkas=
>>>>>>
>>>>>> >>> [e-mail]> wrote:
>>>>>>
>>>>>> >>>
>>>>>>
>>>>>> >>>> Hi,
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>> This email begins a 4-week adoption poll for:
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/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-queuing/05
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>> https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding/18
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>> https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechanism/13
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>> https://datatracker.ietf.org/doc/draft-eckert-detnet-tcqf/09
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>> https://datatracker.ietf.org/doc/draft-eckert-detnet-glbf/06
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>> https://datatracker.ietf.org/doc/draft-ryoo-detnet-ontime-forwarding/04
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>> https://datatracker.ietf.org/doc/draft-ryoo-detnet-nscore/02
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>> Thank you,
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>> János (as Co-chair)
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>>> _______________________________________________
>>>>>>
>>>>>> >>>> detnet mailing list -- [e-mail]
>>>>>>
>>>>>> >>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>>> >>>>
>>>>>>
>>>>>> >>> _______________________________________________
>>>>>>
>>>>>> >>> detnet mailing list -- [e-mail]
>>>>>>
>>>>>> >>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>>> >>>
>>>>>>
>>>>>> >>
>>>>>>
>>>>>>    - [Detnet] WG adoption poll: joung-detnet-stateless…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/Q2JXJlfyvd-WzGkkqtRfCr3yHOs/>  Janos
>>>>>>    Farkas
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/tqDrY-nmIDalPRGf5OMD0_xWvOU/>  Mike
>>>>>>    Blanche
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/S51eXeGt_UcT_1cVqUZrUxejR3U/>
>>>>>>      song.xueyan2
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/3MdTx2InCj1rbv31dZrqBFzfio8/>  Jinoo
>>>>>>    Joung
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/BE3XHigD2aMc8-NgWPZhBWRG_ic/>  Yizhou
>>>>>>    Li
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/l6I5fRbyBp1QQZEYv-4sSuSve_E/>
>>>>>>      유연철
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/7ksa7vAMmQ3sehku5DO8LfONpPg/>  Jeong-dong
>>>>>>    Ryoo
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/2GqbxqQFYw2wYOv1c8UnF3alGns/>
>>>>>>      xiong.quan
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/_G3i5tAVEVx2ptaZ5waatbMJo6Y/>
>>>>>>      정태식
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/FFbeeIUbtYnhRQ04YDfa13_3hrc/>  Mike
>>>>>>    Blanche
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/Ea4920SPZmgxU-0npKrss00EI7Y/>  Jinoo
>>>>>>    Joung
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/24tmXTeBKDecp-cQi4rhK1H0jGk/>
>>>>>>      [e-mail]
>>>>>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>>>>>    <https://mailarchive.ietf.org/arch/msg/detnet/AhQOorY02WR6zJowkcLrXGPqk-E/>  Xuesong
>>>>>>    Geng
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> detnet mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>>> _______________________________________________
>>>>>> detnet mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>>