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

[Jinoo Joung <[e-mail]>]

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