Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)
Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Wed, 03 August 2022 07:59 UTC
Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C216DC16ECA2; Wed, 3 Aug 2022 00:59:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level:
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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unk_CMQOUYow; Wed, 3 Aug 2022 00:59:45 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56415C13CCD9; Wed, 3 Aug 2022 00:59:45 -0700 (PDT)
Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LyPKv3WLDz67mcQ; Wed, 3 Aug 2022 15:55:31 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml712-chm.china.huawei.com (10.206.15.61) 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 fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2375.024; Wed, 3 Aug 2022 09:59:40 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
CC: "ippm@ietf.org" <ippm@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "tpauly@apple.com" <tpauly@apple.com>, "draft-ietf-ippm-rfc8321bis@ietf.org" <draft-ietf-ippm-rfc8321bis@ietf.org>
Thread-Topic: Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)
Thread-Index: AQHYlWfxAjqObBwkZUaN2+5eN8IY16161aSggCE3IoCAAORPoA==
Date: Wed, 03 Aug 2022 07:59:40 +0000
Message-ID: <d1e370f884954cc1b8233a3fb7de056b@huawei.com>
References: <165757265819.6343.12304305700617728056@ietfa.amsl.com> <17bcac6689774754ba56d9913d9c6685@huawei.com> <CAMMESswWt4=otHfVtWcjDfdc35Yi0NgcX=ahvvDr1fz6pjAKfQ@mail.gmail.com>
In-Reply-To: <CAMMESswWt4=otHfVtWcjDfdc35Yi0NgcX=ahvvDr1fz6pjAKfQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.216.37]
Content-Type: multipart/alternative; boundary="_000_d1e370f884954cc1b8233a3fb7de056bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/70ipOoTrNXRtOIUqysCAqQTS06U>
Subject: Re: [ippm] Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2022 07:59:47 -0000
Hi Alvaro, Thank you for the review. Regards, Giuseppe From: Alvaro Retana <aretana.ietf@gmail.com> Sent: Tuesday, August 2, 2022 10:15 PM To: The IESG <iesg@ietf.org>; Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Cc: ippm@ietf.org; ippm-chairs@ietf.org; tpauly@apple.com; draft-ietf-ippm-rfc8321bis@ietf.org Subject: RE: Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT) Giuseppe: Hi! I reviewed -03. It looks good to me. I’m clearing my DISCUSS. Thanks! Alvaro. On July 12, 2022 at 11:40:53 AM, Giuseppe Fioccola (giuseppe.fioccola@huawei.com<mailto:giuseppe.fioccola@huawei.com>) 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, Giuseppe -----Original Message----- From: Alvaro Retana via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> Sent: Monday, July 11, 2022 10:51 PM To: The IESG <iesg@ietf.org<mailto:iesg@ietf.org>> Cc: draft-ietf-ippm-rfc8321bis@ietf.org<mailto:draft-ietf-ippm-rfc8321bis@ietf.org>; ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>; ippm@ietf.org<mailto:ippm@ietf.org>; tpauly@apple.com<mailto:tpauly@apple.com> 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 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-rfc8321bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- §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 3.2.1.1) 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). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (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
- [ippm] Alvaro Retana's Discuss on draft-ietf-ippm… Alvaro Retana via Datatracker
- Re: [ippm] Alvaro Retana's Discuss on draft-ietf-… Giuseppe Fioccola
- Re: [ippm] Alvaro Retana's Discuss on draft-ietf-… Alvaro Retana
- Re: [ippm] Alvaro Retana's Discuss on draft-ietf-… Giuseppe Fioccola