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

[Zaheduzzaman Sarker <[e-mail]>]

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.