Re: [Int-dir] Intdir telechat review of draft-ietf-ippm-explicit-flow-measurements-03

[Giuseppe Fioccola <[e-mail]>]

Hi Pascal,
Thank you for your review.
Please find my replies inline tagged as [GF].

Regards,

Giuseppe


-----Original Message-----
From: Pascal Thubert via Datatracker <[e-mail]> 
Sent: Thursday, May 11, 2023 6:14 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Intdir telechat review of draft-ietf-ippm-explicit-flow-measurements-03

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.

[GF]: Thanks for the good opinion.

 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 
PT> that
these are not n times T MAX in a raw but the new reality of the RTT.

[GF]: We can highlight this potential issue. Anyway we also mentioned that T_Max should be large enough to absorb any possible variations in the delay.

2.2.4.1.  RTT Measurement

...

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

[GF]: Yes, the method proposes one delay sample each RTT. If needed, the idea is to couple Spin Bit and Delay Bit for more statistics.

...

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.

[GF]: It is possible to mention that. We did not further specify since the methods described in the draft are general and transport agnostic. But the application of these methods to specific protocols must consider per-flow information that can also be part of the protocol.

...

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 
PT> packets
that are marked (why the 00 iun second position) ?

[GF]: It depends on the rate of the two directions. This is just an example.

...

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?

[GF]: I agree with you. But, since it was experimented, we explained what can happen if the method is applied to TCP and Loss Event is used. I will revise to make it clearer.

...

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?

[GF]: Yes, I will replace.

Voila!