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

[Scott Mansfield <[e-mail]>]

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.
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.
- 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.
- 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.
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]<mailto:[e-mail]>
>>>> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
>>>>
>>> _______________________________________________
>>> detnet mailing list -- [e-mail]<mailto:[e-mail]>
>>> To unsubscribe send an email to [e-mail]<mailto:[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