[ippm] 1st AD review of rfc8889bis

Martin Duke <martin.h.duke@gmail.com> Wed, 01 December 2021 23:12 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 82F563A0CE0; Wed, 1 Dec 2021 15:12:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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 uzMhaCJD2e7X; Wed, 1 Dec 2021 15:12:30 -0800 (PST)
Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 4CD8E3A0D19; Wed, 1 Dec 2021 15:12:21 -0800 (PST)
Received: by mail-vk1-xa29.google.com with SMTP id s1so8835331vks.9; Wed, 01 Dec 2021 15:12:21 -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:cc; bh=hQ8KqO4xUUBb1QXmLTKpmYjRYgys3hReuz2KGWlpPC4=; b=oPnXl31s/CuIKpchbToKghmxV9awoGABLxdODg6VXtKWkydYidGlRei2PsmVt13IWz obL0WjCtRiwdKITIWqVSAb5gdabN7g3961IY39xgtWNixI1SrobxmzbqWQgpLAaSugD6 st9GA+fKDJ+k6JuPGnQhOIyDwf9BHPl8tJIdLQX1vu+909RN82DwA1sVlDo2RcWzFXkt 9dkns5Aiw5Z0gMTpqmiZrS3PbV/DalB4jUNkw4bumcrKMAOVr4VE3df6qq1gME0XFJP+ Dvzf0Qsbyzx6LlaTdhHuj4b9N5npyBw1Vi+q6GEaUHgEtA5ML4Pvblq/ed1wqVsAc5/V R6GQ==
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:cc; bh=hQ8KqO4xUUBb1QXmLTKpmYjRYgys3hReuz2KGWlpPC4=; b=W9MhlgVrx3tvHAqSqPKk/SJAQyqlaPEVdad5WHcK4c0hoI/Mg0r98coBseQ62VpW67 iB8lnYGXBCeJUBRz/G5qzcPE5g4v9MMt7CqbJzUCFHsLkovkQqoerPGrtL99G31J1J8X d6gCx9anhjqjQyQE0/B8Ark6USP56pOAgA/Xwuk0SWHYUYDZwE1juylLxnsWpkK/C4kJ ZWDI49Mp+iYgdnD7M2xGMtRfCavgYa4lqqdLzNoKIb1DcYnnzdD/3Cl8tlhAwvuSn9c2 eA1WW99IxMbWKVSGXeIHnFr1sYTSb6+DiP6/PtnrsNUrnxx6ywqbK/oQmJ2/7ppkS4NC KW5w==
X-Gm-Message-State: AOAM532PpXgzlsWWiKkQjzMpURG+px9Z7m0pkgTWM/S/5pS3OANx4G/y nv1SqV8wIREfvLDb9b61O/C06/99u/vKVDL+3mOv02xt
X-Google-Smtp-Source: ABdhPJzOzX3dRtTDKEzlMlwrmVhvBRuQSa7aqJBJg2ugFYQwBXOsv0GBWm9IeJZ2rJCqpvScOqJZo+8dWrqUJTBk09Q=
X-Received: by 2002:a05:6122:221c:: with SMTP id bb28mr12170671vkb.27.1638400338993; Wed, 01 Dec 2021 15:12:18 -0800 (PST)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 01 Dec 2021 15:12:08 -0800
Message-ID: <CAM4esxSq3bY+LATXWhgM5Xth+PwUJYPv0cxWFZk6LDPDcJUAHA@mail.gmail.com>
To: draft-fioccola-rfc8889bis.all@ietf.org
Cc: IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000034a6d105d21dce7b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/KYzG1BYqsYknlMeWnMtUhIRDbMI>
Subject: [ippm] 1st AD review 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, 01 Dec 2021 23:12:33 -0000

Thanks for this doc. Here are some high-level comments in no particular
order:

- My perception is that 8889 is an extension of the concepts in 8321, with
some common elements only defined in 8321, so 8321 should be a normative
reference.

- I am confused as to whether ECMP is covered by 8321 or 8889. The 8321
section on reordering talks about ECMP as a cause, which leads me to
believe it's to be covered; but in the intro 8889 claims this use case. I
suppose it depends on how much you're localizing the measurement?

- The intro claims that 8321 covers BUM traffic. Isn't multicast a classic
point-to-multipoint situation? Indeed, doesn't multicast involve packet
replication, which inherently breaks the packet loss mechanism?

- 8889 brings up IP fragmentation, but this seems like a general concern
for 8321 too. Although it probably ought to be written out in 8321 and not
here, this seems under-addressed here. Some questions:
 (a) if a router has to fragment a packet, should it replicate the marking
on all the fragments?
 (b) at a measurement point, is a packet "lost" if any fragment is lost?
what if the fragments entered separately in the network under test?
 (c) What if the marking location is not replicated across the fragments
(e.g. it's in the transport header)?

- Like 8321, there is a general problem with not addressing the fixed-N
marking scheme at all ("The equation is applied on a per-time-interval
basis...")

- There is a hidden requirement here that there be a measurement point at
all possible egress points. Best to mention that.

- I don't understand the L determination when there are multiple marking
nodes (Sec 7). "The source measurement intervals can be of different
lengths and with different offsets" Some questions:
(a) What is a "source measurement interval"? Does it have anything to do
with L?
(b) So let's say that source nodes start marking at arbitrary times. Isn't
the "offset" then directly a function of L? And if so, how can we scale L
based on the offset m?
(c) if the idea is that there is a clock time when marking should begin,
then why isn't the value of A [clock skew] embedded in d sufficient?

- I can't understand the purpose of "delay measurements on a single-packet
basis" in Section 8. I cannot grok the context of Section 8.2 at all. What
are these techniques trying to achieve? This reads like an informational
exploration of options rather than a normative standard. 8321 has detailed
examples of sample measurements and how you derive a measurement; something
like that would be very useful here.

Martin