Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method

Greg Mirsky <gregimirsky@gmail.com> Fri, 11 September 2020 18:40 UTC

Return-Path: <gregimirsky@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 37D763A0D05 for <ippm@ietfa.amsl.com>; Fri, 11 Sep 2020 11:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OWz7ucH63yFs for <ippm@ietfa.amsl.com>; Fri, 11 Sep 2020 11:40:40 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 CF8DC3A164E for <ippm@ietf.org>; Fri, 11 Sep 2020 11:40:39 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id s205so13268941lja.7 for <ippm@ietf.org>; Fri, 11 Sep 2020 11:40:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ry1yoPfz1nR8fU9IvyJ+pBcsQ8EXOJRfFKVjEftJ4RY=; b=NMn6e9/tehHPvp6X5gj9XX2DPInxNP5xqxvjT6b0/z5vN6P/5i818KI/KX10JtSY9U 21v2rEsmiL7Vq9vNbCgSsih2aKs0Em8ZRc9Ap0tY+UWqBLGyfuZI0/IBMik3DFT4dqEq 6+RscGO+N9tgolwFxktv2lYNs64I5cWEiZFnIiz/zxG1+/lzqAkpL7cKOmsiV0GlcS2M vMZYN/67Jap9d/iIesddHOqI8WmBCqkZ6Z65w87nS0e0VBVE/9GynN+FXXvL+h1qyPIX g6vil2sPsbXGz2h9Bjgv0wGa2Z78KyFYUDAQa+bscpX4s8Zx9thVd46oh92h3dg830Je C91A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ry1yoPfz1nR8fU9IvyJ+pBcsQ8EXOJRfFKVjEftJ4RY=; b=qwv3jKw94wDTPmlkv1j8VncnCJXnknwAERMJeglWzgF6tLEr99MSuzyQpA1+ppmB8Y IawgXzlC7nS1sM6/h6hjEI6FUqP0ckH8jmr42D+oepvMIivrQHq7Tg3CEnBEHTiX0ugA ABPM4WYzsOtvfLMIc7irS8XzNu0MPVVs9Kc1Ve2/tm6URD29BwS/uiXX7VAcNd5MmU/S SH0OqWMP2KUdQ5xw1OUTZAUOwtGJUtXxHhlgNTHpTNaujFrYC+++eE3pwRSXfjEHd7kG DnPzOWKk5hmxqjE2N29ZOF+dvnYvYDnn+7t/af2VRDwGE3LkfxBBgBONsqVg1mTCj6M1 Q1BA==
X-Gm-Message-State: AOAM531MBlqTeEdPzQp09HnNEBBpTQUHRbMUTWqajrSOnqvh7XK/1jAt ROEdWC8D6wMv++Yoreo2zMo6JyL/pUYuliJPGVc=
X-Google-Smtp-Source: ABdhPJwtnxmF01Vbp77fUNAI8kXo4xKCq3vS7qL6DWOdLj8SmUupYqzXtKWJJTQdu64OOz16zwdZWAOrmSmbOS3eCAQ=
X-Received: by 2002:a2e:99c4:: with SMTP id l4mr1369067ljj.428.1599849637936; Fri, 11 Sep 2020 11:40:37 -0700 (PDT)
MIME-Version: 1.0
References: <03CC314C-21FA-44CD-AF2E-F0076755AF04@apple.com> <CA+RyBmWAH-kj8SnCbreYqbFijHmr1Zhkuf7J-EV3t6P5WEBo4Q@mail.gmail.com> <4D7F4AD313D3FC43A053B309F97543CF0140BD4867@njmtexg5.research.att.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF0140BD4867@njmtexg5.research.att.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 11 Sep 2020 11:40:26 -0700
Message-ID: <CA+RyBmV6SrKyzJh1q6WvtyNy1VLm_CMaX_hCnigcbdukszvZzw@mail.gmail.com>
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005d035e05af0e057a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/OxHBm_hVZyvK2PvY20gnRCsd_F0>
Subject: Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method
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: Fri, 11 Sep 2020 18:40:42 -0000

Hi Al,
thank you for your consideration of my comments. Please find my notes
in-line under the GIM>> tag.

Regards,
Greg

On Sat, Sep 5, 2020 at 12:14 PM MORTON, ALFRED C (AL) <acm@research.att.com>
wrote:

> Hi Greg,
>
>
>
> Thanks for your careful review and comments!
>
>
>
> Please see [acm] replies below, all changes are implemented in the working
> version.
>
>
>
> Al, for the co-authors
>
>
>
> *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Greg Mirsky
> *Sent:* Tuesday, September 1, 2020 9:44 AM
> *To:* Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
> *Cc:* IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
> *Subject:* Re: [ippm] WGLC for draft-ietf-ippm-capacity-metric-method
>
>
>
> Hi Tommy,
>
> I support the publication of this document. It is well-written and, when
> published, become an essential component of industry-wide work on defining
> the IP Maximum Capacity metric and its measurement methodology.
>
>
>
> Dear Authors,
>
> thank you for this work. I have several questions and a number of
> editorial suggestions that you might find useful. I greatly appreciate your
> consideration of the comments below:
>
>    - Is this document intended to update an RFC? The first page suggests
>    that you have thought about that but have not yet pointed to the RFC to be
>    updated. If you decide that the new document does update the existing RFC,
>    you may note that also in the Abstract.
>
> *[acm] RFC5136, mentioned in the Abstract and Intro, is only Informational
> Status. We are revisiting the problem with a more practical standards track
> solution, and developed new metrics as a result (not updating the old
> ones).*
>
>    - The document uses a significant number of acronyms that probably are
>    not well-known at IETF, e.g., RTD, RTL, etc. I think that adding a
>    sub-section Acronyms will be helpful to a reader.
>
> *[acm] If you’ll allow, most of the acronyms are already defined in list
> of Section 4, and others at first usage of course.*
>
GIM>> I'm looking at the current version of the draft in the datatracker
<https://datatracker.ietf.org/doc/draft-ietf-ippm-capacity-metric-method/?include_text=1>.
I think that some acronyms never expanded, e.g., RTD, RTL, OWL.

>
>    - A number of references don't work as links, e.g., "[ refs to ITU-T
>    SG12, ETSI STQ, BBF liaisons ]".
>
> *[acm] I chose a couple of key LS and provided the references.*
>
> Also, several sections are references by title, e.g., "[see section
> Related Round-Trip Delay and Loss Definitions below]", and that makes
> finding the right place more challenging.
>
> *[acm] I think these are all fixed now.*
>
>    - In Section 4 a source IP address of a host accompanied with a note
>    "such as the globally routable IP address". Should the note be
>    interpreted as an example or as a normative statement?
>
> *[acm] “such as” typically indicates an example follows, and that’s the
> case here.*
>
>    - Section 4 defines dt as "dt, the duration of N equal sub-intervals
>    in I (default 1 sec)". But further in the document, on two occasions, it is
>    noted that "all sub-intervals SHOULD be of equal duration". If dt MAY be of
>    varying duration, then the definition in Section 4 might be changed to "dt,
>    the duration of N sub-intervals in I (default 1 sec)". On the other hand,
>    if that definition is interpreted as normative, then s/SHOULD/MUST/2.
>
> *[acm] I was trying to cover practical realities in timing at hosts with
> “SHOULD”. Maybe it’s better to add “nominal” to the definitions of I and
> dt, then the text can use MUST and avoid intentional variation << which is
> NOT what we want!*
>
GIM>> Thank you, I agree with the resolution.

>
>    - It is not obvious whether "Note that the UDP transport layer is one
>    requirement specified below." applies to the test protocol or something
>    else.
>
> *[acm] Ok, clarified as:  Type-P, the complete description of the test
> packets for which this assessment applies (including the flow-defining
> fields). Note that the UDP transport layer is one requirement for test
> packets specified below.*
>
> *Keep in mind that Type-P always applies to the test packets; control
> packets could be anything!*
>
GIM>> I agree with the update, thank you.

>
>    - Also, in Section 4, the last sentence notes that
>
>    Note that time stamps, sequnce numbers, etc. will be established by
>
>    the test protocol.
>
> Perhaps that may be put as a requirement for the test protocol.
>
> *[acm] I added this in Section 9.1:*
>
> *For example, timestamp resolution requirements that influence the choice
> of the test protocol are provided in Table 2 of [TR-471].*
>
> GIM>> Thank you. Referencing TR-471 is fine by me but some might think
differently.

>
>    - Security Consideration section references RFC 4656 OWAMP and RFC
>    5357 TWAMP. Do you think that adding references to RFC 8672 STAMP and
>    draft-ietf-ippm-stamp-option-tlv, as STAMP and its extensions, might be
>    used as the protocol to measure the IP Capacity, is helpful?
>
> *[acm] I read the unique STAMP considerations in RFC 8762, and there seems
> to be enough coverage from the (now) 6 new security considerations we have
> written for Capacity testing (and other requirements in the memo).*
>
>    - I think that the requirement to provide control of the number of
>    concurrent test sessions can be stronger, as the rate-limiting requirement,
>    than a recommendation. The requirement is more applicable to the test
>    protocol that MUST provide control over the number of simultaneous test
>    sessions.
>
> *[acm] OK, I can live with up-levelling concurrent test session control to
> a MUST. It seems like an easy limit for server code to enforce.*
>
GIM>> Thank you.

> Several nits:
>
>    - s/[copycat
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod-2D03-23ref-2Dcopycat&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=yKzCaDdxr4ZdtpAPWdBs6Wb5h1-FvV9zQ-I02NWaLWA&s=beL2wAnc1YD9IALGvCN_EpsLAeRb8zYKb7Mlx4oxmuw&e=>
>    ][copycat]/[copycat]/*[acm] * *ok*
>    -  s/sequnce/sequence/*[acm] * *ok*
>    - A reference in "Type-P is a parallel concept to "population of
>    interest" defined in ITU-T Rec. Y.1540." will be helpful.*[acm] * *ok,
>    it’s clause 6.1.1, added*
>    - I assume that in "T, the host time of the *first* test packet's
>    *arrival* as measured at MP(Dst)", MP stands for Measurement Point. Is that
>    correct?*[acm] * *yes, fixed.*
>    - Capitalization in "Target performance threshold" throughout the
>    document needs consistency, on several occasions, it is used as "target
>    performance threshold".*[acm] * *ok, fixed.*
>
> Regards,
>
> Greg
>
>
>
>
>
> On Fri, Aug 14, 2020 at 2:21 PM Tommy Pauly <tpauly=
> 40apple.com@dmarc.ietf.org> wrote:
>
> Hello IPPM,
>
>
>
> As discussed at IETF 108, draft-ietf-ippm-capacity-metric-method is
> stable, and the group felt it is ready for Working Group Last Call.
>
>
>
> The latest version can be found here:
> https://tools.ietf.org/html/draft-ietf-ippm-capacity-metric-method-02
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dcapacity-2Dmetric-2Dmethod-2D02&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=yKzCaDdxr4ZdtpAPWdBs6Wb5h1-FvV9zQ-I02NWaLWA&s=XJLQkG2WsakslD6KgDyuPlbYYPyQ_p9iWs_WVGuv4ag&e=>
>
>
>
> The last call will end on *Wednesday, September 2*. Please reply to
> ippm@ietf.org with your reviews and comments, and indicate if you think
> the document is ready to progress!
>
>
>
> Best,
>
> Tommy & Ian
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=yKzCaDdxr4ZdtpAPWdBs6Wb5h1-FvV9zQ-I02NWaLWA&s=K2fFqjaHzvIMcEC6GDeXGDKXo66lSqVsO0sreMaEraI&e=>
>
>