[ippm] Intdir telechat review of draft-ietf-ippm-explicit-flow-measurements-03

[Pascal Thubert via Datatracker <[e-mail]>]

Reviewer: Pascal Thubert
Review result: Ready with Nits

I am an assigned INT directorate reviewer for
draft-ietf-ippm-explicit-flow-measurements-03. 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 NO
 OBJECTION.

 I found the document to be very clear and readable.

 A few minor grammar issues will be sorted out by the RFC editor better than I
 could.

2.2.4.  Delay Measurement Using Delay Bit

...
   When the Delay bit is used, a passive observer can use delay samples
   directly and avoid inherent ambiguities in the calculation of the RTT
   as can be seen in Spin bit analysis.
...

PT> If a reroute causes a brutal change, the observer should erealize that
these are not n times T MAX in a raw but the new reality of the RTT.

2.2.4.1.  RTT Measurement

...

PT > is there a filter or something? Just one measure does not account for
variations. See rfc 6298.

...

2.2.5.  Observer's Algorithm

   An on-path observer maintains an internal per-flow variable to keep
   track of time at which the last delay sample has been observed.

PT > the flow characterization must be part of the standard. eg 5 tuple, 6
tuple in IPv6. because the source and the observer must recognize the same
thing as being one flow with one bit and one state.

...

3.1.3.  Observer's Logic for Round Trip Loss Signal

...

           Generation          Pause           Reflection       Pause
      ____________________ ______________ ____________________ ________
     |                    |              |                    |        |
      01 01 00 01 11 10 11 00 00 10 10 10 01 00 01 01 10 11 10 00 00 10

                  Figure 8: Round Trip Loss signal example

PT> in the reflection, why is it that it's not the first 4 consecutive packets
that are marked (why the 00 iun second position) ?

...

3.3.  L Bit -- Loss Event Bit

...

   For protocols, such as TCP ([TCP]), that allow network devices to
   change data segmentation, it is possible that only a part of the
   packet is lost.  In these cases, the sender must increment Unreported
   Loss counter by the fraction of the packet data lost (so Unreported
   Loss counter may become negative when a packet with L=1 is sent after
   a partial packet has been lost).

PT> What is the intention?
>From the network perspective a  packet was discarded, whether it is a fragment
does not seem that relevant. RED does not account for size does it?

...

3.3.1.  End-To-End Loss

   The Loss Event bit allows an observer to estimate the end-to-end loss
   rate by counting packets with L bit value of 0 and 1 for a given
   flow.  The end-to-end loss rate is the fraction of packets with L=1.

   PT> note that calling things rate means "over a period of time" (a rate is
   amount/s ).
      Seems you mean "ratio" instead of "rate" or really "probability" since yu
      use  value in [0,1], in this and many places, right?

Voila!