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

["Pascal Thubert (pthubert)" <[e-mail]>]

All good for me!

Pascal

> Le 15 mai 2023 à 14:45, Giuseppe Fioccola <[e-mail]> a écrit :
> 
> 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!
> 
> 
> 
>