Re: [ippm] AD review of draft-ietf-ippm-stamp

Greg Mirsky <gregimirsky@gmail.com> Wed, 10 July 2019 23:01 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 7C0241201C9; Wed, 10 Jul 2019 16:01:16 -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 DpFixtk4LwgD; Wed, 10 Jul 2019 16:01:13 -0700 (PDT)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 27A961200C7; Wed, 10 Jul 2019 16:01:13 -0700 (PDT)
Received: by mail-lf1-x135.google.com with SMTP id b17so2708914lff.7; Wed, 10 Jul 2019 16:01:13 -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=LLiOkSRrYb4ERnybPw7RV0OZ2isCDXkQqpWF49tcFfY=; b=A22x/9s741g5Lx57zKs3NwZZzGpjyYf5pRV0bcH/tH0jpTJOya1n9rWgpsN+6gYKxn M4n1qPzxNfKO+Zy+uI4KQ9vxAyGCgen1rETu6J9a421qgkIDIbXkAFuhMrl5XExOkYme VMIl8rD+K85lsvt/VVk/8mDUDbSU/sRKz+vMHa9+KyeveYhi+8sKcobBJCJaDtQtYePo hfb0N1cshncM0DyBnqb1Bfx5deM0MBrmWHpuq4UQIbv7+9IHXN8j8FHFEgSh9dBwYrWm mF3fICw/32GvVZ/Q48bgOvAnS6G8SMkPiEigK2q0v8VMTf1MpuOdyduWdiObCOWuOYx9 +dNA==
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=LLiOkSRrYb4ERnybPw7RV0OZ2isCDXkQqpWF49tcFfY=; b=LPHILGLETAVTJhag/b1njPqlazCvji7vvdJ6aP8pSFje+q0EDUACJK/qns2F5vZBOG jpCiOtG4QGenO02mn1nlRgH5HYDlaBrQsL9S18fyXHa8cqFX8HUTyhrtwcERhd6ZkT61 renrtnNuKEt6asgoUS2cfJSiJDBGgayKhUeYSpQoiF7CjFIY2kckgPfHFGy61dMlq1JP SczWtYy0IzuHIshnMq8LnSdEhO1X9gTcfq3ipzcsQrYPE7xqQ7Ez1rLitWBplaeE401l waQiQgn67N0ZdGe/9lCKaYNj6jxqsNqRAyRNwqH9fcQy99m+vimfhm4oDsZInYun2CT0 /eMw==
X-Gm-Message-State: APjAAAV4GjYTsrp5TnDbJOehNVv2NggAAMAFMNwoUPRO9yzp06WMhNq3 2pBDCgZcVWkRekj4XICMTxiWER/7pUX+QPXAgZE=
X-Google-Smtp-Source: APXvYqwW4m9ixbLA+RxDSMRhpp/kcZVCvy6K7+DqUb3pbtS3u40Lf7nGlpV7hiEu+Zqp7Cx4125I9bwNml8iY7TLcRk=
X-Received: by 2002:a05:6512:48f:: with SMTP id v15mr82101lfq.37.1562799671230; Wed, 10 Jul 2019 16:01:11 -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> <F7F3E842-01B1-4DFD-BFA3-D9DDBCED7D79@broadcom.com> <CA+RyBmUcMEjOwCt_DjsbYbB1zSTx9d5_Va2kcmxpFUQmXQ7gvA@mail.gmail.com> <A8DD6099-2473-4DBD-B592-57B2B1C67FCA@cisco.com>
In-Reply-To: <A8DD6099-2473-4DBD-B592-57B2B1C67FCA@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 10 Jul 2019 16:00:59 -0700
Message-ID: <CA+RyBmX=GizBEpQmscTPZp1bFGfZDRLTLTSvGpaG1YMmW3suSw@mail.gmail.com>
To: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
Cc: Shahram Davari <shahram.davari@broadcom.com>, "draft-ietf-ippm-stamp@ietf.org" <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="000000000000424726058d5ba77d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/YPUl696v0BHn2pJLhZVACNiax38>
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: Wed, 10 Jul 2019 23:01:17 -0000

Hi Rakesh,
yes, you're right. I've responded to your thoughtful questions but was late
to upload the updated version of the draft. Will do that as soon as I can.

Regards,
Greg

On Wed, Jul 10, 2019 at 10:57 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com>
wrote:

> Hi Greg,
>
>
>
> I do not see the procedure you mentioned below in the draft. There is only
> one sentence for TLV in the draft as below.
>
>
>
> And if any of TLV-based STAMP extensions are used, the TWAMP Light
> Session-Reflector will view them as Packet Padding field.
>
>
>
> Am I missing something?
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> *From: *ippm <ippm-bounces@ietf.org> on behalf of Greg Mirsky <
> gregimirsky@gmail.com>
> *Date: *Tuesday, July 9, 2019 at 1:17 PM
> *To: *Shahram Davari <shahram.davari@broadcom.com>
> *Cc: *"draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>rg>,
> IPPM Chairs <ippm-chairs@ietf.org>rg>, Mirja Kuehlewind <ietf@kuehlewind.net>et>,
> IETF IPPM WG <ippm@ietf.org>
> *Subject: *Re: [ippm] AD review of draft-ietf-ippm-stamp
>
>
>
> Hi Shahram,
>
> excellent question, thank you!
>
> When using STAMP extensions, STAMP Session-Sender must use the basic STAMP
> test packet followed by a TLV. A STAMP Session-Reflector is expected to
> compare the value in the Length field of the UDP header with the length of
> the basic STAMP test packet (44 octets). If the difference is larger than
> the length of the UDP header, then the Session-Reflector should process
> STAMP TLVs following the basic STAMP test packet.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Jul 9, 2019 at 9:53 AM Shahram Davari <shahram.davari@broadcom.com>
> wrote:
>
> Thanks Greg,
>
>
>
> How does the receiver distinguish between TWAMP and STAMP if they use the
> same UDP Port number?
>
>
>
> Thx
>
> Shahram
>
>
>
> On Jul 8, 2019, at 4:14 PM, Greg Mirsky <gregimirsky@gmail..com
> <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
>
>
>
>
>
>