Re: [ippm] AD review of draft-ietf-ippm-stamp
Rakesh Gandhi <rgandhi.ietf@gmail.com> Tue, 09 July 2019 13:27 UTC
Return-Path: <rgandhi.ietf@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 D928912015B; Tue, 9 Jul 2019 06:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 zeyKk8uEhCMe; Tue, 9 Jul 2019 06:27:44 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 9E6F7120157; Tue, 9 Jul 2019 06:27:43 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id i21so19585018ljj.3; Tue, 09 Jul 2019 06:27:43 -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=1q0+u7ss++a5OalH25imEwCHYgB4RrqALmsM0ulszlo=; b=LrNAt4OkXzLTf+ffAX7jgZprbQ22H4RIc9x2cInouW8VRTq2lLzVL/mPHQkqyaKrrh nASGWt8mjUh0gP1zfeiM7msL9YV8WKTP08GLwkR29DSa6/ekDu9h7S2RAISLUqHPB1Fc jhVFQm6ainx7WeB/oTw+WrRtla/jev8PJgpuixLx6k9KcnAexeSb01e4HaFFLPdhHGDR M3vUX5XUV9S6sbcVGUUUwBuUvfK6cYXY9PBMINuejlE5BIcSd1sE7nWRl1iPKNOERPWz f3nLJVPltwK5IkhBmmLWWWsRvDmfb3efcGoTDhQWMAeFHDot6IvHBFq2I64US9qrm5L0 fbgw==
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=1q0+u7ss++a5OalH25imEwCHYgB4RrqALmsM0ulszlo=; b=sxTqjnI4EbYNUIpCEWWJfhcexlpKnwCzMNDsi9nM925oXnqTUVcW96ij5zp8MdYQ/V SoUa43YSUQHCW5osu1XecBBkrjLxIhjpkeLBYuamy4fjQOgJ9+6aE1HozPA4Z+v4zdYr TSqcKoElBsgTed3nBbhuMPKPKtcnP5GGq9Towt9raiX/+1yQjDGo367qXtboDPImUJEb 6dAiI9LLhH6p9UXfQBdC6yxdTMJTyrsVvJmByT/rR9ov3lPKfYome4FjK5I5T94FeUuz zHmj8g/gpqBQFBsqFnQuJS9lbXEkLmJG9+tqIgcI1Wnw9WVKTiOn0lEqP+9Q4ezykvEa byAg==
X-Gm-Message-State: APjAAAW3QQSOawFBM/Um+4aluwHWMXbbt6cWG1+VWLd8+5+71q4ZHyp9 7BuuvV3c+ToMBIsjS6q1HeSzQBLQDPW+lKLtoA==
X-Google-Smtp-Source: APXvYqyyMYuxUcypFIue1AjQ7GRE3ZyF17XQbA4W+gcXsbzB2CknjvV/WLuRkyRF6lM3y2Yiw4nZtakxrj+7T2bRAdw=
X-Received: by 2002:a2e:9b83:: with SMTP id z3mr10317849lji.84.1562678861685; Tue, 09 Jul 2019 06:27:41 -0700 (PDT)
MIME-Version: 1.0
References: <B617B303-6EBE-4E3B-AE5C-1438FF1C5D7F@kuehlewind.net> <CA+RyBmVEmKQu=LGp9eVT+x5e01LCSk_A4tQD=RE8Ett-R35BVg@mail.gmail.com> <11938018-8A65-483B-8176-A6E1C2A265A3@kuehlewind.net> <CA+RyBmX=Jx2yXrMXu4Y2VKX36iKphymb1Hkyfy0XhPGFmsUGzQ@mail.gmail.com> <B8047CA0-2F5E-48F8-9BE4-3FA41D742F12@kuehlewind.net> <CA+RyBmXPCe7TZQqPgsKsVnifZDG8O8wGafDn-nzYfGpx2OiaXQ@mail.gmail.com> <F167C330-76F4-48FC-B720-415CA190239C@broadcom.com> <CA+RyBmVtfXcwqu1RH-1JXnhpCZcbGgm30ubKGctUPnLNJCgVZQ@mail.gmail.com>
In-Reply-To: <CA+RyBmVtfXcwqu1RH-1JXnhpCZcbGgm30ubKGctUPnLNJCgVZQ@mail.gmail.com>
From: Rakesh Gandhi <rgandhi.ietf@gmail.com>
Date: Tue, 09 Jul 2019 09:27:30 -0400
Message-ID: <CAMZsk6f=x1j_fXAoqZ874y0nw7Y1wP0OeS9eFuToSBQfrqkJLQ@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Shahram Davari <shahram.davari@broadcom.com>, draft-ietf-ippm-stamp@ietf.org, IPPM Chairs <ippm-chairs@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000072e7c1058d3f86b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/paxB0rR60j3XtMmqlunWyU1e-IE>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp
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: Tue, 09 Jul 2019 13:27:47 -0000
Hi Greg, Regarding the size of the padding, yes, it's good to use the same size payload for query and response. However, the STAMP payload with TLV extension (draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size (27 ( or > 29) vs. 30). Is there a way to make them compatible? Does it mean that for STAMP with TLV, Server Octets is set to 1, but it says MBZ 0 for all 30 bytes. If the responder supports Server Octets and see the size > 27, it may find the Server Octet size of 0 confusing? Thanks, Rakesh On Mon, Jul 8, 2019 at 7:20 PM Greg Mirsky <gregimirsky@gmail.com> wrote: > Hi Shahram, > thank you for the review and questions. Please find my answers below > tagged GIM>>. > > Regards, > Greg > > On Mon, Jul 8, 2019 at 2:02 PM Shahram Davari <shahram.davari@broadcom.com> > wrote: > >> HI Greg >> >> I read your draft and have the following questions: >> >> 1) Does it require any UDP/TCP port number or it reuses the one from >> TWAMP? if it reuses from TWAMP then how does the receiver differentiate >> between TWAMP and STAMP? >> > GIM>> STAMP uses the well-known UDP port number allocated for the > OWAMP-Test/TWAMP-Test Receiver port (RFC 8545) as the default destination > UDP port number.. STAMP may use destination UDP port number from the > Dynamic and/or Private Ports range 49152-65535. > >> 2) What is the benefit of STAMO compared to TWAMP? >> > GIM>> The work was driven by several observations, among them: > > - challenges in achieving interoperability among implementations of > TWAMP-Light; > - industry interest in standardizing performance monitoring in IP > broadband access networks (TR-390); > - improve extensibility of IP performance monitoring tool to support > measurements, testing of new metrics and parameters, e.g., consistency of > CoS in the network. > > 3) Why is there so much MBZ byte? >> > GIM>> It was agreed to make the symmetrical size of STAMP test packets the > default. RFC 6038 defined it for TWAMP and TR-390 requires it to be > supported by TWAMP-Light implementations. > >> >> Thx >> Shahram >> >> On Jul 8, 2019, at 10:17 AM, Greg Mirsky <gregimirsky@gmail.com> wrote: >> >> Hi Mirja, >> thank you for the suggested text. The new paragraph now reads as: >> Load of STAMP test packets offered to a network MUST be carefully >> estimated, and the possible impact on the existing services MUST >> be thoroughly analyzed before launching the test session. >> [RFC8085] section 3.1.5 provides guidance on handling network load >> for UDP-based protocol. While the characteristic of test traffic >> depends on the test objective, it is highly recommended to stay in >> the limits as provided in [RFC8085]. >> >> If it is acceptable, I'd like to upload the updated version of >> draft-ieff-ippm-stamp before the cut-off deadline. >> >> Regards, >> Greg >> >> On Mon, Jul 8, 2019 at 8:58 AM Mirja Kuehlewind <ietf@kuehlewind.net> >> wrote: >> >>> Hi Greg, >>> >>> See below. >>> >>> > On 8. Jul 2019, at 16:54, Greg Mirsky <gregimirsky@gmail.com> wrote: >>> > >>> > Hi Mirja, >>> > thank you for the reference to RFC 8085. I agree that the document is >>> very much relevant and a reference to RFC 8085 in STAMP is useful. While >>> reading Section 3.1.3 I came to think that the discussion and guidance in >>> other sections of RFC 8085, particularly, Section 3.1.5 Implications of RTT >>> and Loss Measurements on Congestion Control. Would adding the reference to >>> that section in the new text proposed for the Security Considerations >>> section work? I'll put RFC 8085 as Informational reference as it is BCP. >>> > NEW TEXT: >>> > Load of STAMP test packets offered to a network MUST be carefully >>> > estimated, and the possible impact on the existing services MUST >>> > be thoroughly analyzed using [RFC8085] and its Section 3.1.5 in >>> > particular before launching the test session... >>> >>> >>> Not sure if “using” is the right word but otherwise fine for me. Or you >>> could have a separate sentence like: >>> >>> “RFC8085 section 3.1.5 provides guidance on handling network load for >>> UDP-based protocol. While the characteristic of test traffic depends on the >>> test objective, it is highly recommended to say in the limits as provided >>> in RFC8085.” >>> >>> Or something similar… >>> >>> BCP is the same maturity level as PS. So it wouldn’t be a downref. >>> However, I think having this as informational ref is fine. >>> >>> Mirja >>> >>> >>> >>> > >>> > Regards, >>> > Greg >>> > >>> > On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <ietf@kuehlewind.net> >>> wrote: >>> > Hi Greg, >>> > >>> > Thanks a lot for you reply. Changes are good. I wonder if it would be >>> useful to provide a reference to RFC8085 because it has a lot of >>> information about congestion control of UDP based traffic? It recommends to >>> send not more than 1 packet per 3 seconds (if RTT is unknown). I guess it >>> doesn’t make sense to require this for testing traffic, however, it could >>> maybe still be a good recommendation? What do you think? >>> > >>> > Also I’ve just resend my review to the IPPM list, as I unfortunately >>> cc’ed only the IPPM chairs instead of the whole list. Can you resend you >>> proposed changes to the list, so other people are aware of these changes. >>> Sorry for the unconvience. >>> > >>> > Mirja >>> > >>> > >>> > > On 6. Jul 2019, at 17:46, Greg Mirsky <gregimirsky@gmail.com> wrote: >>> > > >>> > > Hi Mirja, >>> > > thank you for your thorough review, very pointed and helpful >>> comments. Please find my responses in-lined and tagged GIM>>. Attached the >>> diff. >>> > > >>> > > Regards, >>> > > Greg >>> > > >>> > > On Thu, Jul 4, 2019 at 9:10 AM Mirja Kuehlewind <ietf@kuehlewind.net> >>> wrote: >>> > > Hi authors, hi all, >>> > > >>> > > Thanks for this well-written document and very good shepherd >>> write-up! I would like discuss one point before I start IETF last call. >>> > > >>> > > I believe this document should say something about network load and >>> congestion (control). OWAMP and TWAMP discuss quite a bit sender >>> scheduling, however, as this is a simplified version, so I think it could >>> at least be good to put a waring in this document that packet sending >>> should be somehow rate limited. I know it might be hard to provide more >>> concrete guidance but at least having some discussion or warning in this >>> document could be good. >>> > > GIM>> Thank you for your suggestion. Security Considerations >>> section points to the fact that STAMP does not include control and >>> management components: >>> > > Because of the control >>> > > and management of a STAMP test being outside the scope of this >>> > > specification only the more general requirement is set: >>> > > adding the new text here: >>> > > Load of STAMP test packets offered to a network MUST be >>> carefully >>> > > estimated, and the possible impact on the existing services >>> MUST >>> > > be thoroughly analyzed before launching the test session. >>> > > >>> > > >>> > > Another comment: You only say at the very end that a certain UDP >>> port is used, which implies that STAMP runs over UDP. However, I think you >>> should mention at the very beginning that this is a UDP-based protocol. >>> Just to make things crystal clear. >>> > > GIM>> Adding the reference to "UDP transport" into the first >>> sentence of Theory of Operations section: >>> > > STAMP Session-Sender transmits test packets over UDP transport >>> toward STAMP Session-Reflector. >>> > > >>> > > Mirja >>> > > >>> > > P.S.: >>> > > Nit: s/This document defines active performance measurement test >>> protocol/ This document defines an active performance measurement test >>> protocol/ >>> > > -> “an” missing >>> > > GIM>> Thank you. Done. >>> > > <Diff_ draft-ietf-ippm-stamp-06.txt - >>> draft-ietf-ippm-stamp-07...txt.html> >>> > >>> >>> _______________________________________________ >> ippm mailing list >> ippm@ietf.org >> https://www.ietf.org/mailman/listinfo/ippm >> >> >> _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Mirja Kuehlewind
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Shahram Davari
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Shahram Davari
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Shahram Davari
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Mirja Kuehlewind
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp MORTON, ALFRED C (AL)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp MORTON, ALFRED C (AL)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Henrik Nydell
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Greg Mirsky
- Re: [ippm] AD review of draft-ietf-ippm-stamp MORTON, ALFRED C (AL)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Rakesh Gandhi (rgandhi)
- Re: [ippm] AD review of draft-ietf-ippm-stamp Reshad Rahman (rrahman)
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Civil, Ruth
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Civil, Ruth
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Rakesh Gandhi
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Mirja Kuehlewind
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Rakesh Gandhi
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Henrik Nydell
- Re: [ippm] [**EXTERNAL**] Re: AD review of draft-… Rakesh Gandhi