Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)

Giuseppe Fioccola <> Wed, 03 August 2022 07:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C216DC16ECA2; Wed, 3 Aug 2022 00:59:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id unk_CMQOUYow; Wed, 3 Aug 2022 00:59:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56415C13CCD9; Wed, 3 Aug 2022 00:59:45 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4LyPKv3WLDz67mcQ; Wed, 3 Aug 2022 15:55:31 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 3 Aug 2022 09:59:40 +0200
Received: from ([]) by ([]) with mapi id 15.01.2375.024; Wed, 3 Aug 2022 09:59:40 +0200
From: Giuseppe Fioccola <>
To: Alvaro Retana <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)
Thread-Index: AQHYlWfxAjqObBwkZUaN2+5eN8IY16161aSggCE3IoCAAORPoA==
Date: Wed, 3 Aug 2022 07:59:40 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_d1e370f884954cc1b8233a3fb7de056bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (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: Wed, 03 Aug 2022 07:59:47 -0000

Hi Alvaro,
Thank you for the review.



From: Alvaro Retana <>
Sent: Tuesday, August 2, 2022 10:15 PM
To: The IESG <>rg>; Giuseppe Fioccola <>
Subject: RE: Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)



I reviewed -03.  It looks good to me.  I’m clearing my DISCUSS.



On July 12, 2022 at 11:40:53 AM, Giuseppe Fioccola (<>) wrote:
Hi Alvaro,
Thanks for your review.
Please find my replies inline tagged as [GF].
I will publish a new version to address your comments.

Best Regards,


-----Original Message-----
From: Alvaro Retana via Datatracker <<>>
Sent: Monday, July 11, 2022 10:51 PM
To: The IESG <<>>
Subject: Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-ippm-rfc8321bis-02: 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:


§7 ("Results of the Alternate Marking Experiment") makes several
recommendations about the use of one or two flag bits:

One flag: packet loss measurement SHOULD be done as described in
Section 3.1, while delay measurement MAY be done according to the
single-marking method described in Section 3.2.1. Mean delay
(Section is NOT RECOMMENDED since it implies more
computational load.

Two flags: packet loss measurement SHOULD be done as described in
Section 3.1, while delay measurement SHOULD be done according to
double-marking method Section 3.2.2. In this case single-marking
MAY also be used in combination with double-marking and the two
approaches provide slightly different pieces of information that
can be combined to have a more robust data set.

These recommendations are good, as they are the result of experimentation.
However, they don't provide any deployment or operational guidelines of when
is it ok to follow them and when it isn't. For example, for the one flag case,
when it is ok to not measure packet loss as described in §3.1? Why is the use
of that mechanism only recommended and not required?

I have the same questions for all the recommendations and optional indications
in the text above. To clear this DISCUSS I expect deployment or operational
recommendations that can be used as implementation/deployment guidance.

[GF]: I agree. I can surely add more details. Regarding the packet loss measurement SHOULD can be replaced with MUST since it is the only option. Regarding the delay measurements, there are some considerations to do in order to provide guidelines, such as the number of flags available (If there is only one flag you have no choice) or the kind of information needed (double marking is more robust and allows to get more statistics) or software/hardware limitations (mean delay calculation is resource consuming).


(1) I support Roman's DISCUSS position, and have a related question to this
text in §7.1 (Controlled Domain requirement):

For security reasons, the Alternate Marking Method is RECOMMENDED
only for controlled domains.

When is it ok to use the Alternate Marking Method in any other deployment?
IOW, given the definition of a controlled domain earlier in this section, why
is its use only recommended and not required?

[I am not including this point as a DISCUSS because I expect it to be solved
when Roman's concern is addressed.]

[GF]: Indeed, I will replace that sentence with: "For security reasons, the Alternate Marking Method MUST only be applied in controlled domains."

(2) §7 says that a deployment "SHOULD also take into account how to handle and
recognize marked and unmarked traffic". I don't see any interoperability need
to use an rfc2199 keyword. IOW, s/SHOULD/should

[GF]: Ok, will do