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

Alvaro Retana <aretana.ietf@gmail.com> Tue, 02 August 2022 20:15 UTC

Return-Path: <aretana.ietf@gmail.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 B3B42C157B35; Tue, 2 Aug 2022 13:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 R-Nr0OplhYcN; Tue, 2 Aug 2022 13:15:11 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 ietfa.amsl.com (Postfix) with ESMTPS id DB1D5C14F74B; Tue, 2 Aug 2022 13:15:10 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id w15so7703733ljw.1; Tue, 02 Aug 2022 13:15:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=SJdv8WM3Koe9/FRRDAYOo2nHr0TxRlU4eQ1u0fMO0lU=; b=g2EIp2Qq/ObBWiCpV+EwybHb88xaqfnbRxu1QEu2XYScQOumWLqhVXDjW4v6r2G62t sSwvD2IXQLj9YUbPVgFXUA9jsaMKHntvxdN+FqwYaxu1mMta2G+XtdfRwoqZtHeF8FVr RpJm6j8OTjkbYwyrlvZAEHkFpXlBYvmKaAP7jY5A7rC/KO6E0pU6TuddjORircFb5dYx AkK3MMEjhFviJQygWmyu2g1cEZ9WfjBf8H4XsYB2W77fUMmqoSSM+k9Rxvpt1JmhgdLM fQEKpnHzvfai8ikdeeuEIF0PqukKh6iEB0H9bD1Lr8k+t7jRpdewvV0YmVk4HCmfE0h/ GTHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=SJdv8WM3Koe9/FRRDAYOo2nHr0TxRlU4eQ1u0fMO0lU=; b=MduhqBNncRmZKrDMetJY8W8UuIT8yE7B4hvsMAd1qvgya/OI9ZM4k/FPyOMS+Stm+B 4SeVeSSm7xf/xChcZL8Gkt66irFplGSgd0ELQmGI6edyoybXwm9o7cpqo1CBRdKNdgRq Mkr9CEofAYWA3wTd2odPfs6YKl5Q8oywbNdlphkgPe9YvRvrYnTaYLaqlqUNNsmdSt0N /4BjSseRtvTNbO9VavbD6U/mlow5IsWHTNu7bu//tNn+NAvjdnLJ3Nv8kz8IUu8fNaDm 7yMwyB/QZXQg8l5LnB8mnXvOPkSfr9aLgpH8ioM33p6ER5Qplc03hf6wtvdds+9ypygt zsQA==
X-Gm-Message-State: ACgBeo008lFbkF64YtcfcqaYOCCaC4zJBQMpmQ61ag7y8nKHPSiNAO1D 2soxzvfCr4VmDMSk7/jZKXBaPtDqdTozDS/lOuLHqit5
X-Google-Smtp-Source: AA6agR5+FPe7kJG6n33FK2or+v3WZkuV3+JC8zGZMChWAIrYJIwW1DO4xY0o3er6kY9BhD9OyaAG3+jJVayr1Libb3o=
X-Received: by 2002:a2e:8198:0:b0:25e:5300:b040 with SMTP id e24-20020a2e8198000000b0025e5300b040mr3122089ljg.210.1659471308282; Tue, 02 Aug 2022 13:15:08 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 2 Aug 2022 13:15:07 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <17bcac6689774754ba56d9913d9c6685@huawei.com>
References: <165757265819.6343.12304305700617728056@ietfa.amsl.com> <17bcac6689774754ba56d9913d9c6685@huawei.com>
MIME-Version: 1.0
Date: Tue, 2 Aug 2022 13:15:07 -0700
Message-ID: <CAMMESswWt4=otHfVtWcjDfdc35Yi0NgcX=ahvvDr1fz6pjAKfQ@mail.gmail.com>
To: The IESG <iesg@ietf.org>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
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>
Content-Type: multipart/alternative; boundary="000000000000d85d9805e547c5d8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/C9xCS5Cz_6uZ1K-ZOyEyl3cxBYI>
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: Tue, 02 Aug 2022 20:15:11 -0000

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) 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>
Sent: Monday, July 11, 2022 10:51 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-rfc8321bis@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org;
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