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

Greg Mirsky <> Mon, 08 July 2019 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D909612021F; Mon, 8 Jul 2019 07:55:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.702
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e3hRgSV_Vj3F; Mon, 8 Jul 2019 07:55:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 439BC12018A; Mon, 8 Jul 2019 07:55:09 -0700 (PDT)
Received: by with SMTP id q26so11146419lfc.3; Mon, 08 Jul 2019 07:55:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=emRCXEJ/bkrQuVOFG4OnOF6fupH7J/j0ztxDtlc43f4=; b=APd2ihhPsJNoXQ9YmKnkK+BQUBvsqimJhAAsQF96wvvMLlsag/5hreMqRLy6ri2CDd Ua/trmFUUHn4P0COAfAqWc0GOeVxSkVFdqeH0j8Ex4foS58BEeHqXn+DsYQAbx6dcrqs rJ+Tld4N1xLAPJ3uvn/o9lbgSZADsU7c4C1iqHa8EEtt2cjjnq9QnFfhYlnft/VzFin4 0OCysazrVAdOjmeEMHs+DPUUus/Z/J+1dR9MQrnV+hoqF0jc5co0pvBTZyvJ6Qna4OG+ d271FIPNB+2wC2nXNgDz8EDLTpcevpveMzB2J2VCwWsScM7oRIDXYyXd7R6E4WQq/dZ0 bxjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=emRCXEJ/bkrQuVOFG4OnOF6fupH7J/j0ztxDtlc43f4=; b=K6/DcHI6yr0b6zpx+n+1DUO9aPsmVNUuCvEUy1KGCzlNUf2NAOYd9GZ5Hpf3zddvLt nHBWme9FJB17tMIEzpr3E3g69OrKCQZNcf50EpojSsWHzAufwYLErxa+37u+rBJjY80M um+X8zIykHDevbpzBpI8xp6dur3b/jQm+gmgK4KUiO8+wKEKwKvB/FtluITctFxydlSc MHrjdShPiLLKLttLpBq55WHvbaiFL8pnvru4RBxV2PVDdnWebClCrEggggrAtYYxIcu3 eQ5r3xqxVqM8jzB5ZUQS/rHimZ4lGJl+a645mtNwNFLKDAvYeoGG+J39q6gi94T1OWsH +y6Q==
X-Gm-Message-State: APjAAAVp0yZ7uD+bbwtrQWBgqUkMAGqunvZNNjbQIdaMRhPLnxdD4eWU 50P/SmwUuVWpoViRvQg8UiNQiTAn+eMIRVAIGFA=
X-Google-Smtp-Source: APXvYqyDwnOkLZSI6+NlwJAWDJZlLuxCyvMZ8ufeLn7LtVmNacDndGtnR9E69Ppffld3CJUnpLKYMzuLSEvjcw2NR6o=
X-Received: by 2002:ac2:5609:: with SMTP id v9mr8490353lfd.27.1562597707334; Mon, 08 Jul 2019 07:55:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Mon, 8 Jul 2019 07:54:55 -0700
Message-ID: <>
To: Mirja Kuehlewind <>
Cc:, IPPM Chairs <>, IETF IPPM WG <>
Content-Type: multipart/alternative; boundary="00000000000045ca37058d2ca1d0"
Archived-At: <>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jul 2019 14:55:31 -0000

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.
      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.


On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <> 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 <> 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 <>
> 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>