[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!
- [ippm] AD Review #2 of RFC8889bis Martin Duke
- Re: [ippm] AD Review #2 of RFC8889bis Giuseppe Fioccola