Re: [ippm] Zaheduzzaman Sarker's Discuss on draft-ietf-ippm-explicit-flow-measurements-03: (with DISCUSS and COMMENT)

[Tommy Pauly <[e-mail]>]

Hi Zahed,

Can you please review the latest version the document? It’s been updated a few times since you filed your DISCUSS.

Thanks,
Tommy

> On May 29, 2023, at 2:32 AM, Zaheduzzaman Sarker <zaheduzzaman.sarker=[e-mail]> wrote:
> 
> Hi Giuseppe,
>  
> This sounds good. Will wait for the actual update. Thanks.
>  
> //Zahed
>  
> On 2023-05-25, 19:01, "Giuseppe Fioccola" <[e-mail]> wrote:
>  
> Hi Zahed,
> Thank you for your review.
> Please see inline [GF]
> 
> Regards,
> 
> Giuseppe
> 
> -----Original Message-----
> From: Zaheduzzaman Sarker via Datatracker <[e-mail]> 
> Sent: Wednesday, May 24, 2023 3:57 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Lucas Pardue <[e-mail]>; Colin Parkins <[e-mail]>
> Subject: Zaheduzzaman Sarker's Discuss on draft-ietf-ippm-explicit-flow-measurements-03: (with DISCUSS and COMMENT)
> 
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-ippm-explicit-flow-measurements-03: Discuss
> 
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-explicit-flow-measurements/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thanks for working on this specification. I hope it will be helpful for the
> valid network observer who does the flow measurement (given that the end-points
> actually implements the markings).
> 
> Thanks to Colin Perkins for the TSVART review
> (https://mailarchive.ietf.org/arch/msg/ippm/OMrRG_0CG8uRHVz0o6ivqRD8T6g/ ) and
> also Lucas Pardue
> (https://mailarchive.ietf.org/arch/msg/ippm/RgtxAHmJfANjlfPkn1Jb4Hbbcs8/ ) for
> his review of the document. Both reviews had led to changes in the document
> which should improve and clarify the specification even more.
> 
> As I agree with both the reviewers , even though I have already see some
> resolutions, I am holding this discuss to make sure agreed resolutions are
> landed in the document we approve.
> 
> [GF]: It sounds good. We plan to submit a new version soon.
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Besides, I have following comments that I believe will improve the document if
> addressed -
> 
>   - Please define the collaborative endpoints in the context of this document.
>   At least set the exceptions on the client and server to comply with this
>   specification.
> 
> [GF]: The document refers to collaborative in the sense of the measurements. Both client and server needs to cooperate. If only the client supports these methods, most of the techniques described in the draft cannot be applied. We will further clarify this point in the next version.
> 
>   - It would great if we can add a separate section or amend the introduction
>   to explain why the loss and delay is important to measure in the network to
>   provide QoS. A list of use cases would be very motivating .
> 
> [GF]: Some considerations are already in the Introduction. I think we can add further considerations on that.
> 
>   - It would also be very useful to describe why "the accurate measurement of
>   packet loss and delay experienced by encrypted transport-layer protocols is
>   highly desired". I believe the information about the need is available and
>   would help the reader and implementer of this specification to understand the
>   need.
> 
> [GF]: Of course this can be the point of view of a network operator that could not perform any measurement in case of encrypted protocols. We will explain better the need.
> 
>   - It says -
> 
>       Accurate loss and delay information is not critical to the operation of
>       any protocol, though its presence for a sufficient number of flows is
>       important for the operation of networks.
> 
>     How critical is to have the flow visibility to the observers? I guess the
>     scenario here is that you have a node in the network which act as a gateway
>     to the Internet hence would see sufficient number of flows to decide what
>     might be the RTT, hence can measure loss or delay on a flow. However, I
>     think this specification should also mention the effectiveness of these
>     passive measurements if that is not the case.
> 
> [GF]: I think we can slightly revise this sentence and only mention that loss and delay information is important for the network operation. Regarding the flow visibility to the observers, it is up to the implementation to decide the flows to monitor.
> 
>    - It says in section 3.3.2.1 -
> 
>       If the observer is unable to estimate RTT of the flow, it should
>       accumulate loss measurements over time periods of at least 4 times the
>       typical RTT for the observed flows.
> 
>     I am not sure I completely understand what this "the observed flows" refers
>     to. As described in my previous comment, I can relate this to a certain
>     network setup where the is one node via which all the traffic traverses
>     however, not sure how this works for cases where the observer have no other
>     flow visibility between the same endpoints.
> 
> [GF]: Yes, the observed flows refer to the flows that the probe is observing for measurement purpose.
> 
>    - Question on section 2.2.5. will there be substantial measurement error
>    depending on whether an observer is unidirectional or can see both direction
>    of the flow that the observers should be aware of? As high accuracy of the
>    measurement is desired, it might be worth mentioning the potential issues.
> 
> [GF]: We can mention the impact on the accuracy but It is also the type of measurement that is different. If the observer can observe both directions, it is possible to measure also the observer-client half-RTT or the observer-server half-RTT.
> 
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm