[ippm] AD Review #2 of RFC8889bis

Martin Duke <martin.h.duke@gmail.com> Wed, 16 February 2022 00:10 UTC

Return-Path: <martin.h.duke@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 56DE53A109E; Tue, 15 Feb 2022 16:10:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBzlXvAS5gms; Tue, 15 Feb 2022 16:10:00 -0800 (PST)
Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3756C3A109C; Tue, 15 Feb 2022 16:09:57 -0800 (PST)
Received: by mail-ua1-x935.google.com with SMTP id g15so291666uap.11; Tue, 15 Feb 2022 16:09:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=GtRc11x4BKWiYrdUSXX5CJyJZlvxCPAFJjOEXuxERdk=; b=L2zTBKqz7gR7sXEc+fSiaEu99hFbGX4fZmQcUp/C3ktctiM9v6VForm7Zmf3bnzaM+ mmxA0QrAtNEApqa40y8pEDimto1hEfeDVL4Yw2J175ItexCzErv/wV8oiBeCICRNYMu9 RfJBJ/ysc2QlVnZWgaIViNJa/aSTVBEnvVslpRaHhxj7Hgw1fqbajOlQL9LT98HQ3tY3 ke0bmo2uSQC+8KGVVSiOku3hadC8Fdw2BIAOcrBGBUoAcYnD5q4pjlxIu9hFBbZEyPAP Os8BA0U+jLFEbTU46QX7o3yv58BQ8GPUUPYDq9JPctsFiDlNVwyxdu5zal2EOOPBruTc ehkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GtRc11x4BKWiYrdUSXX5CJyJZlvxCPAFJjOEXuxERdk=; b=hQmzQh7+B1NubYDXBQ8u/MXngqMGs1kzQYT8IdQ8yEXbIxA3wQX/HST27lrQIl2ufA J8+BKJcm3xj3aP4WE37Ivo72sM/xjsfMRMN56HIQ1jRyjAbBWXj0Rj3bGQgOLemeuxje oVURowwObmgQaxyxA+iaSRRzKDX3ttpU3yWSBxgWv8Ly4wH51HUQA1Z6nI5Wz0OnQ1fy ktLAHqvmgK5VpzuXT2NVwr0xiAyMXRriyxDsTQBtCjHo8nlK1xFH4VXtlmegwNXcQ+mQ z+cis7QzjQaXPbmWQnlHMsdqXBpuq5bLVqmq8PDsO2UuraOoWFHNjHyDnPHA18V9cOFW njyw==
X-Gm-Message-State: AOAM532ZDpZa2xl36Qt2hdVYcoeNIdJozMo8Rgwi8abN1gt1HaNuBEb/ DVn+zOrXdHt465lZXVd/bMVdwOSHJkhYFfrgYRAnPIul
X-Google-Smtp-Source: ABdhPJw+K2TKXzT/d3IJVadINWUrHOfh5KoPS9yL9nMCle9V+0yKJ1uPHctZfozo13JTOrJ0RMFrPjfeSp7hO51Ct88=
X-Received: by 2002:a9f:23c6:0:b0:2fa:3088:eda2 with SMTP id 64-20020a9f23c6000000b002fa3088eda2mr61821uao.55.1644970195893; Tue, 15 Feb 2022 16:09:55 -0800 (PST)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 15 Feb 2022 16:09:43 -0800
Message-ID: <CAM4esxSuREU1+-LsHFKXa8MVR0m6fMii=_6zBntrzrtnGN8+VA@mail.gmail.com>
To: draft-fioccola-rfc8889bis.all@ietf.org, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000031408005d81778de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/WZbmY74zcf9zTpPxa7VYHqXXj_U>
Subject: [ippm] AD Review #2 of RFC8889bis
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
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, 16 Feb 2022 00:10:06 -0000

Giuseppe,

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.

(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?

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

****

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?

Martin

[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!