On 12/1/23 03:09, Greg Mirsky wrote: > Hi Benson, > thank you for your kind words about our work on PAM; much appreciated. > Your thoughtful comments and suggestions are very helpful, please find > my notes below tagged GIM>>. > > Regards, > Greg > > On Wed, Nov 22, 2023 at 10:08 AM Benson Muite via Datatracker > <noreply@xxxxxxxx <mailto:noreply@xxxxxxxx>> wrote: > > Reviewer: Benson Muite > Review result: Ready with Nits > > I am an assigned INT directorate reviewer for <draft-ietf-ippm-pam>. > These > comments were written primarily for the benefit of the Internet Area > Directors. > Document editors and shepherd(s) should treat these comments just > like they > would treat comments from any other IETF contributors and resolve > them along > with any other Last Call comments that have been received. For more > details on > the INT Directorate, see > https://datatracker.ietf.org/group/intdir/about/ > <https://datatracker.ietf.org/group/intdir/about/> > <https://datatracker.ietf.org/group/intdir/about/ > <https://datatracker.ietf.org/group/intdir/about/>> > > Based on my review, if I was on the IESG I would ballot this > document as YES. > > The main aim of this informational draft is to introduce sampling of > traffic > flows to enable data reductions that make it feasible to check the > quality of > service, in particular by enabling checks on the number of packets > delivered > within a suitably defined time interval. The notion that is > introduced seems > useful for a flow between two specified points. It does not seem to > impact any > INT directorate related areas directly, though any resulting measurement > techniques that are developed may be very useful, for example when > comparing IPv4 > and IPv6. > > > The following are minor issues (typos, misspelling, minor text > improvements) with > the document: > > a) The term precision availability metrics may be misleading, since > counts are > aggregated over a specified time interval. Maybe something like > "Aggregated > Availability Metrics" could be used instead? There is a loss of > precision since > information about each packet is not recorded, but the resulting > data reduction > makes this concept useful. > > GIM>> Aggregated is an interesting idea. Indeed, performance metrics for > each packet are not preserved. But the same can be said about any metric > derived based on a set of measurements, for example, mean, median, and > percentile. And, AFAICS, Service Level Indicators usually use a > combination of metrics that, in that sense, aggregate per packet > measured metrics. > BM>> "aggregate per packet measured metrics" (appmm) would be ok or something more descriptive than precision. > > b) At the beginning of section 3, it may be helpful to first > introduce the > notions of violated and severely violated, and then apply these to > intervals and > packet counts. Alternatively, clear definitions could be given for the > violated and severely violated packet counts. One thing that is > unclear is if > the violated and severely violated packet counts apply to a single > specified > time interval, or are aggregated over multiple time intervals. > > GIM>> The intention is to position the accounting of the > violated/severely violated packets as complementary to intervals that > are aggregated over the course of monitoring the flow. The scope of > these metrics is explained in the following: > Maintaining such counts and comparing them with > the overall amount of traffic also facilitates assessing compliance > with statistical SLOs (see Section 4). > > BM>> This is ok. Thanks for the explanation. > c) Section 3.3 introduces a new topic, available and unavailable > states. How > this might be implemented is not fully specified. > > GIM>> I think that that could be the subject of a set of specific > documents that demonstrate the applicability of the performance > measurement protocols with nodal functional requirements. We can discuss > where that scope fits better. > BM>> Section 3 is mostly composed of concept definitions that are broadly applicable and do not need further drafts to support them. It is the core part of the draft. Section 3.3 seems like an exception, in particular the paragraph: "While the definition of a service state model is outside the scope of this document, the following section provides some considerations for how such a state model and accompanying configuration settings could be defined." Sections 4 and 6 give possible extensions using similar phrasing. It seems that for SLAs, the concepts of available and unavailable states may be useful in their own right. Can a two state model be concisely and concretely defined within this document? > It may be helpful to combine > this with section 4, a section on possible extensions, as perhaps > section 4.1, > with material on possible statistical SLOs as 4.2. Both these > sections could > perhaps also be shortened and added as further bullet points in > section 6. > > GIM>> These are interesting ideas. The authors reviewed the scope of the > proposed updates, and we hope that you can agree with the current > structure of the document. BM>> It is not clear to me why possible extensions to statistical SLOs need a full section of their own. Why are they more important than any of the other possible extensions in section 6? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
