Re: [Last-Call] Intdir telechat review of draft-ietf-ippm-pam-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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.

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).

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. 
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.
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux