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

[Mike Blanche <[e-mail]>]

Hi Jinoo and all authors,

Apologies for the delay in replying.

Thank you for your work on this; it's much improved. We are now aligned
with ITU standards (with 3 metadata fields) and the draft focuses on the
new requirements (metadata formats for IPv6 and MPLS, and the admission
procedure). From my perspective this looks like a good basis for the
adopted draft.

Best regards,

Mike

On Mon, 30 Mar 2026 at 11:04, Jinoo Joung <[e-mail]> wrote:

> 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]
>>>>>>>
>>>>>>