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=> > >
- [ippm] WGLC for draft-ietf-ippm-capacity-metric-m… Tommy Pauly
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… Tommy Pauly
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… Carlos Pignataro (cpignata)
- Re: [ippm] [EXT] Re: WGLC for draft-ietf-ippm-cap… Cociglio Mauro
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… Ruediger.Geib
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… Joachim Fabini
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… J Ignacio Alvarez-Hamelin
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… Joachim Fabini
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… Frank Brockners (fbrockne)
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… Greg Mirsky
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… Tommy Pauly
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… Greg Mirsky
- Re: [ippm] WGLC for draft-ietf-ippm-capacity-metr… MORTON, ALFRED C (AL)