Re: [ippm] AD Review #2 of RFC8889bis

Giuseppe Fioccola <> Wed, 16 February 2022 13:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14F3C3A12F8; Wed, 16 Feb 2022 05:35:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pueRJgK8sbcH; Wed, 16 Feb 2022 05:35:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B23713A1318; Wed, 16 Feb 2022 05:35:49 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4JzJkt4rVfz67yS4; Wed, 16 Feb 2022 21:31:18 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 16 Feb 2022 14:35:46 +0100
Received: from ([]) by ([]) with mapi id 15.01.2308.021; Wed, 16 Feb 2022 14:35:46 +0100
From: Giuseppe Fioccola <>
To: Martin Duke <>, "" <>, IETF IPPM WG <>
Thread-Topic: AD Review #2 of RFC8889bis
Thread-Index: AQHYIsmUap9e33VqMU+d1M8OK2dk6qyWFjgg
Date: Wed, 16 Feb 2022 13:35:46 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_2af9dadf3bdb450083ffa6d30d106a94huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [ippm] AD Review #2 of RFC8889bis
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Feb 2022 13:36:03 -0000

Hi Martin,
Thanks for your review.
I can update RFC8889bis as well in the next few days.

Please find my answers inline tagged as [GF]



From: Martin Duke <>
Sent: Wednesday, February 16, 2022 1:10 AM
Subject: AD Review #2 of RFC8889bis


Only two new issues with this one:

1) The formula for L in section 7 is not exactly wrong, but it is very oddly expressed.

(a) In 8321 you introduce the value A, which is the maximum clock skew between the two nodes. Together with the path delay, this provides the lower bound for L.

In 8889, you introduce m as the maximum divergence between marking nodes, but the text says this is not clock skew but a result of the nodes being "overloaded". I don't know if overloading is a concern or not, but if it is, clearly it is an issue in the point-to-point case as well!

It would be better if all skew issues -- both clock and overloading -- were brought into a single quantity A. I don't see any reason that marking nodes would have different properties than counting nodes[1], so why not use the same value?

IIUC, 8321 and 8889 should have the same constraints on L -- the worst-case for clock skew is the same for both.

[GF]: Yes, we can keep it simple and use the same constraints on L. I agree that the additional mismatch between the marking nodes can simply be incorporated into A. I will revise the text accordingly.

(b) A question I don't know the answer to: is 3 standard deviations really enough in the multipoint case? If there are thousands of possible paths and a few of them are quite a bit longer, won't that introduce many errors? This isn't a single entity you're sampling, but a heterogenous set of paths. Is there a reason to think this is a normal distribution?

[GF]: We can assume that the multiple paths behaviors can still be represented by distinct normal distributions. In this case, the combination of normal distributions can result in a new normal distribution. So, we can say that the range of 3 standard deviations is still valid under this assumption.

(2) The delay measurement section is vague about one-way vs. two-way delay. Is two-way delay meaningful in a multipath environment?

[GF]: Yes I can add more considerations in section 8. In case of delay measurements on the basis of multipoint paths, the one-way delay value is representative of an entire multipoint path and you can calculate the two-way delay by summing the one-way delays of the two directions, as we do for RFC8321. While, in case of delay measurements on a single-packet basis (e.g. double marking or hashing), it is always possible but it is not immediate since you have to couple the measurement on each single path with the opposite direction. In this case the NMS can do the calculation.


These seem like the sort of questions that would be answered by implementation and deployment experience. How do we set L? What times of delay measurement are viable? If 8889 doesn't have enough deployment to answer these questions, maybe it's not ready for PS?

[GF]: RFC8889 has enough implementation and deployment experience as RFC8321. So it is ready for PS since it is the natural extension of RFC8321 for multipoint scenarios. If you find it useful, I can add a section about the "Results of the Multipoint Alternate Marking Experiment", similarly to RFC8321.


[1] In the multipoint case, the distinction between marking nodes and egress nodes seems artificial -- the diagrams seem to envision traffic going from left to right, but of course it should be traveling in all directions!

[GF]: To simplify the explanation, we considered one way but, of course, it is always two way. I can highlight this point in the next version.