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

Greg Mirsky <gregimirsky@gmail.com> Tue, 09 July 2019 02:07 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 ADFE7120091; Mon, 8 Jul 2019 19:07:55 -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 nqxpqkKv0QwC; Mon, 8 Jul 2019 19:07:52 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 A440A12008A; Mon, 8 Jul 2019 19:07:51 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id u10so12227020lfm.12; Mon, 08 Jul 2019 19:07:51 -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=+SKkyL0vKX74mpdqORcRAMDDWIUMHrdlQNzRsBwQOXo=; b=sZPmnhcPcw6yaXRC3Bgq7G9M7Paj1jM2xWA8umx+osBSrD+vsNWYzoNiSv/D4oiEvu pu3u++YaM2mPIzQ54J15e2Ns/5GTuEfRSnws0LIsQYXJ0/Gd3K+tp2DfIyr5wcbjOFtA uVgjSGN8HTkf92NQ5KMQhQGMtky8w7ZvcNAEUWH98ty81ERkdlONq1mGfY83MqocEGNq aSAiv3h2JHJZIPSIEtRu1Ac3Zhq4i47qmv9z34td5RApMJo2zpCm9AxQkdeiQB9wDumJ jO0gV1fEd4RmX10BJJoyjFekS2QSGhSUBfsgx1h80z3p7uY0qC+Zo2OnwC0AJ2qIhrSK CTng==
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=+SKkyL0vKX74mpdqORcRAMDDWIUMHrdlQNzRsBwQOXo=; b=KtmczZD53hlHn861O6jNSejylIGXtvvBbVLjG+t3WcMwBkCymxolnlswkpv5fGSct9 hlqFPSWQNv/5pj6PHUXhLvHydYgnwlRrgYTxLx2GmV39Wg8eOOwJFVrE+zwOXfhI8Za7 dQn0wwdqRkL1P+quMhT8N5lxQoiPo09IbfDP8cejfQ9Sxk61/aFlbNNQYJnlj+2iBUzS uzyBXubsMTofZpqt6/mUOEmql9VYLT9b5UuKDXQd9nGmHHIcnKOCgfFeG05GMADd2qNQ Km/3KFaM3xSD3wD7KMgyuydeHrRYOwG0W7aZYGIfDeYk7LQO3GFYEoMh568uUqZTF/6h M1DQ==
X-Gm-Message-State: APjAAAVMDYQtLB9VbyCbZgU4jmtMVFbQsqfL1a+wstVDDXtEB2jZtQ5q frArDQXA+LS5gyz/cTvurqJgITI8s1vQoxEd1Fg=
X-Google-Smtp-Source: APXvYqzQ3Kl+6b16ebrrSEc/0Q0OyY+sDrwFOSGyVA5sKyss6YpM5YbtEje18PeUzNTK5tik6x/svRSktH/qqvFtGno=
X-Received: by 2002:a19:c887:: with SMTP id y129mr10296956lff.73.1562638069789; Mon, 08 Jul 2019 19:07:49 -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> <CAMZsk6e-bcFNz327p_u6KEHV2qnJUytPwPmJVgXxEWbzsQr9OA@mail.gmail.com>
In-Reply-To: <CAMZsk6e-bcFNz327p_u6KEHV2qnJUytPwPmJVgXxEWbzsQr9OA@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 08 Jul 2019 19:07:37 -0700
Message-ID: <CA+RyBmW01TgyXPAk3OGhdKqDTszkf0KzT+dDVTdaEhFu7GA7-Q@mail.gmail.com>
To: Rakesh Gandhi <rgandhi.ietf@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="0000000000000ff778058d3607da"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/Syzzvnp75ssrus3Zq99-Ca0aDVY>
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 02:07:56 -0000

Hi Rakesh,
thank you for your question. In my experience, some implementations of
TWAMP-Light have taken the liberty to allow using UDP port numbers outside
the Dynamic/Private range. I believe that is not the right decision. In the
note of IANA's Service Name and Transport Protocol Port Number Registry we
read:

 Service names and port numbers are used to distinguish between different
 services that run over transport protocols such as TCP, UDP, DCCP, and
 SCTP.

 Service names are assigned on a first-come, first-served process, as
 documented in [RFC6335].

 Port numbers are assigned in various ways, based on three ranges: System
 Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private
 Ports (49152-65535); the difference uses of these ranges is described in
 [RFC6335]. According to Section 8.1.2 of [RFC6335], System Ports are
 assigned by the "IETF Review" or "IESG Approval" procedures described in
 [RFC8126]. User Ports are assigned by IANA using the "IETF Review" process,
 the "IESG Approval" process, or the "Expert Review" process, as per
 [RFC6335]. Dynamic Ports are not assigned.

 The registration procedures for service names and port numbers are
 described in [RFC6335].

 Assigned ports both System and User ports SHOULD NOT be used without
 or prior to IANA registration.

My interpretation is that ports in System and User ranges, even if not yet
assigned, must not be used without following the assignment process. Thus,
regardless of whether a number had not yet been assigned to a service, it
must not be used as the destination UDP port number. Also, consider
operational issues if a new service is assigned a new port number from the
User Ports range. One day the number was "free" and tomorrow it may be
assigned. Handling such a scenario will add complexity while benefits are,
in my opinion, questionable.

Regards,
Greg

On Mon, Jul 8, 2019 at 5:09 PM Rakesh Gandhi <rgandhi.ietf@gmail.com> wrote:

> Hi Greg,
>
> Why limit the UDP port range to 49152-65535? Any free UDP port can be
> used, no?
>
> 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
>>
>