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

Tommy Pauly <> Tue, 08 August 2023 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59D75C15109C for <>; Tue, 8 Aug 2023 09:14:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.405
X-Spam-Status: No, score=-4.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8GuYJXFEwI7d for <>; Tue, 8 Aug 2023 09:14:11 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 5D4DAC1519BC for <>; Tue, 8 Aug 2023 09:06:49 -0700 (PDT)
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPS id <> for; Tue, 08 Aug 2023 09:06:48 -0700 (PDT)
X-Proofpoint-GUID: GLQzXsTF_IxZXspltCT7Y5fhMlXHiGxB
X-Proofpoint-ORIG-GUID: GLQzXsTF_IxZXspltCT7Y5fhMlXHiGxB
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.591, 18.0.957 definitions=2023-07-11_09:2023-07-11, 2023-07-11 signatures=0
X-Proofpoint-Spam-Details: rule=interactive_user_notspam policy=interactive_user score=0 bulkscore=0 malwarescore=0 adultscore=0 suspectscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2305260000 definitions=main-2307110153
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=wQZbS7XD0mnFrAkfimmsaAlAnEOzOG55kzJjbtePfWE=; b=fkSJtoqkzQvRddEPPqf1Dqcce6u8nkimz9nG8h/hFieMwiV4V/+82gWn/n8JkJ5DjoRg cx7XBmiUgIVjD+NhjLVFP8TmLTKpjv2h973giaOD0Y3G5Oirsf8VgcCMpPnhGEI2FxZT 6t3jVkDySBDE7zMptoCiM5nhRkXtMhveyOCKTeh6C8JICDqCVcVp8qkRWPRp8jQkORl6 Ocv9Pvku7ZGxQL3dGbvSBxPGdA0hSi0RtJZMvCrssgiXaLsXart9jpXOK01rzMaduqJF OkacOHaKZ4/BUaZ/mbWOUrcPR3vdKrXtbNUoC4lKLtBSV2WgyPDA42OOeoFeIgKp5T9Q 7w==
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPS id <>; Tue, 08 Aug 2023 09:06:45 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) id <>; Tue, 08 Aug 2023 09:06:45 -0700 (PDT)
X-Va-T-CD: 9da32e1d4d62bbc5b549aff1ee920799
X-Va-E-CD: 023086631ccb20425a4403085de4516f
X-Va-R-CD: 1bde24434e92bda6256ad10960f9aaa8
X-Va-ID: b4b8938b-a497-4f70-8ca9-2ae02a60e1b4
X-Va-CD: 0
X-V-T-CD: 9da32e1d4d62bbc5b549aff1ee920799
X-V-E-CD: 023086631ccb20425a4403085de4516f
X-V-R-CD: 1bde24434e92bda6256ad10960f9aaa8
X-V-ID: f655c592-f1f7-4753-a072-a70b7b556578
X-V-CD: 0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.591, 18.0.957 definitions=2023-08-08_14:2023-08-08, 2023-08-08 signatures=0
Received: from ([]) by (Oracle Communications Messaging Server 64bit (built Mar 28 2023)) with ESMTPSA id <>; Tue, 08 Aug 2023 09:06:45 -0700 (PDT)
From: Tommy Pauly <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_08A7B44A-5981-442F-89A5-CF1FE2ADA5F2"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3773.100.6\))
Date: Tue, 08 Aug 2023 09:06:34 -0700
In-reply-to: <>
Cc: Giuseppe Fioccola <>, The IESG <>, "" <>, "" <>, "" <>, Colin Parkins <>
To: Zaheduzzaman Sarker <>
References: <> <> <>
X-Mailer: Apple Mail (2.3773.100.6)
Archived-At: <>
Subject: Re: [ippm] Zaheduzzaman Sarker's Discuss on draft-ietf-ippm-explicit-flow-measurements-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Aug 2023 16:14:15 -0000

Hi Zahed,

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


> On May 29, 2023, at 2:32 AM, Zaheduzzaman Sarker <> wrote:
> Hi Giuseppe,
> This sounds good. Will wait for the actual update. Thanks.
> //Zahed
> On 2023-05-25, 19:01, "Giuseppe Fioccola" <> wrote:
> Hi Zahed,
> Thank you for your review.
> Please see inline [GF]
> Regards,
> Giuseppe
> -----Original Message-----
> From: Zaheduzzaman Sarker via Datatracker <> 
> Sent: Wednesday, May 24, 2023 3:57 PM
> To: The IESG <>
> Cc:;;;;; Lucas Pardue <>; Colin Parkins <>
> 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
> for more information about how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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
> ( ) and
> also Lucas Pardue
> ( ) 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.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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 -
>       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