[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
- [ippm] 1st AD review of rfc8889bis Martin Duke
- Re: [ippm] 1st AD review of rfc8889bis Giuseppe Fioccola
- Re: [ippm] 1st AD review of rfc8889bis Martin Duke
- Re: [ippm] 1st AD review of rfc8889bis Giuseppe Fioccola
- Re: [ippm] 1st AD review of rfc8889bis Martin Duke
- Re: [ippm] 1st AD review of rfc8889bis Giuseppe Fioccola