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

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

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.


----------------------------------------------------------------------
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.

  - 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 .

  - 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.

  - 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.

   - 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.

   - 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.