Hi Paul, Thanks again for your review!
As proposed in my previous email, we have added a dedicated discussion on composability. In that context, we have also picked up some of the use cases from Section 4 in that discussion to show what is possible even if there is no full sharing across networks/operators/etc. While working on the section, I noticed that we might have been talking past each other in our previous exchange so I’d like to provide some additional context. As I also mentioned in my earlier responses to Martin, QoO values (and latency percentiles) are not directly composable but only the underlying Quality Attenuation measurements, i.e., measurement distributions. Hence, the alignment of latency percentiles across operators I mentioned is mainly about enabling meaningful comparisons between QoO scores reported for different network segments and to support common application “profiles” and not about enabling true composability. I believe part of this confusion stems from what is now Section 5.1, which introduces the simplification of reporting percentiles instead of distributions. This simplification comes with the trade-off of losing composability which we now mention explicitly in the document. Another possible reason for the confusion lies in what is now Section 5.2 where the document stated that requirement percentiles need to match those reported by the measurements (which could imply that measurement always only report percentiles, even though reporting percentiles is only a simplification as stated in Sec. 5.1). To resolve this ambiguity, the document now clarifies that requirements can use arbitrary percentiles when latency distributions are reported and that percentiles need to match those reported by measurements when the simplified reporting scheme is used. I hope these modifications help resolve the confusion. Thank you very much for bringing this issue to our attention! We have also updated the QoO calculation formulas based on Martin’s suggestions, using the pseudocode-style instead of the math environment approach. Please let us know if you feel that there are still aspects of your review that need to be addressed. Thanks again for the helpful comments! Cheers, Ike Friendly Note: I send emails at times that work best for me. Please don’t feel any pressure to reply outside your usual working hours. [Background pattern Description automatically generated] Ike Kunze Senior Researcher Phone +47 408 81 254 CUJO AI<https://cujo.com/> | News <https://cujo.com/blog/> | LinkedIn<https://www.linkedin.com/company/cujoai> From: Paul Kyzivat <[email protected]> Date: Tuesday, 10 February 2026 at 16:46 To: Ike Kunze <[email protected]>, [email protected] <[email protected]> Cc: General Area Review Team <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: Gen-ART Last Call review of draft-ietf-ippm-qoo-06 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Ile, On 2/10/26 7:55 AM, Ike Kunze wrote: > Hi Paul, > > Thank you very much for taking the time to review the draft! > > You are right in that the measurements / reported percentiles of > different network segments need to be the same to enable composability. > Ensuring this alignment across different networks / operators might be > challenging, especially considering that the draft does not impose > standardized percentiles for the network performance requirements of > applications. > The draft does follow BITAG recommendations regarding > measurement percentiles, though, and I think that once we have a better > understanding which measurement percentiles have the most meaning for > applications (with application “profiles" then also using those > percentiles), alignment across operators could very well just follow > naturally. > Even if it does not follow, there is still a lot of value to be gained > by just using the methodology on different network segments within the > same network. > > I believe we already have some limited (implicit) text along this line > in the document. If you see value in clarifying possible deployment / > adoption challenges beyond what we currently have, we could add some > additional, explicit discussion focusing on this aspect in the > operational consideration section. > What do you think? It was the existing text that mentions the need for alignment of percentiles, in a different context, that led me to ask the question. I do believe it is important to add a discussion about the challenges to successful deployment, including the challenges to composability. How useful will this method be without composability over the end-to-end path? And how will that alignment be achieved? Toward that end, it would be helpful if you included some important use-cases. For instance, a way for an end user to obtain statistics for their own network attachment, for the ways they use the network. > Regarding the presentation of the formulas, you have probably also seen > in the thread with Martin that we plan to (at the very least) implement > his suggestion that you also refer to in your comment. Additionally, > Martin has kindly provided me additional pointers for alternative forms > of formula rendering and we plan to also explore these options to come > up with a version that is as clear and easy to understand as possible. > I would very much appreciate your feedback on the final version once we > have it. Yes, I have been following that. And will be happy to review the changes you ultimately make. Thanks, Paul This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
img-2458bd2e-7d8c-4793-944f-7d2451498a8f
Description: img-2458bd2e-7d8c-4793-944f-7d2451498a8f
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
